EDIT
The problem is the generate-resources goal is not executed by Maven in Unix.
With Maven 2.0.10, I execute that instruction : mvn resources:resources
On windows :
[INFO] [dependency:unpack {execution: unpack-filters}]
[INFO] Configured Artifact: com.viaccess.testtools:filters:1.0-SNAPSHOT:jar
[INFO] filters-1.0-SNAPSHOT.jar already unpacked.
On Unix :
[INFO] No goals needed for project - skipping
Strange ... Same maven, same conf.
OLD POST
I have a problem with filtering my maven project.
It works good on windows, but not on unix (redhat).
Though, maven version is the same, java version is the same and settings.xml of maven is the same. So, I don't see where is the problem.
The maven instruction is mvn clean package
On windows, it works good. On windows, it failed with the error Error loading property file '/var/tmp/test/target/filters/empty.properties'
And not target directory is created.
Somebody can help me ?
More information about the pom files.
Here info about the parent pom :
<properties>
<filters.path>${project.build.directory}/filters</filters.path>
<filter.default>empty.properties</filter.default>
</properties>
<profiles>
<profile>
<id>default</id>
<properties>
<filter.defaut>default.properties</filter.defaut>
</properties>
</profile>
<profile>
<id>windows</id>
<properties>
<filter.defaut>default.properties</filter.defaut>
</properties>
</profile>
</profiles>
<build>
<resources>
<resource>
<directory>filters</directory>
<targetPath>${project.build.directory}/filters</targetPath>
</resource>
</resources>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack-filters</id>
<phase>generate-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.viaccess.testtools</groupId>
<artifactId>filters</artifactId>
<version>1.0-SNAPSHOT</version>
<includes>*.properties</includes>
<outputDirectory>${filters.path}</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
The filter project is like that :
<build>
<resources>
<resource>
<directory>src/filters</directory>
<targetPath>${project.build.directory}/classes</targetPath>
<includes>
<include>*.properties</include>
</includes>
</resource>
</resources>
</build>
And the main project is like that.
<parent>
<!-- link to my parent project -->
</parent>
<build>
<filters>
<filter>${filters.path}/${filter.defaut}</filter>
</filters>
Thanks for your help.
I have found the problem. No problem on the pom, a problem of nexus.
On windows, I used the last pom parent beacause it's my work desktop (and I make a pom install).
Unix is a remote server. The downloading of the pom parent was already done, so new version was never uploaded.
Noob problem, sorry ... :)
Thanks for your help.
Eric
Related
Often related to Background scanning of projects people complain that this happens when NetBeans is started.
I have a Spring Boot 2.6.x with Maven 3.8.2 project, using Cisco AXL Schema 12.5.
With Apache CXF from this AXL Schema a lot of Java source code files are generated.
When I do a Clean and Build on my project afterwards immediatly the Background scanning of projects starts.
And it takes most of the times recently quite long.
I see for example that it scans also
netbeans-12.6/webcommon/jsstubs/corestubs.zip
Why should it scan this too when building my project?
But most of the time, although it shows 100% scanning done, it spends in the folder where the generated Java source code files are
<project folder>/target/generated/cxf
There are 2282 generated Java source code files.
I'm not sure if NetBeans hangs or really scans these files, it shows 100% scanning so it should be done.
Often it takes too long so I have to terminate NetBeans from the console. After a restart of NetBeans the Background scanning for projects starts and takes much shorter time, but this is annoying.
What can I do about it?
When I start NetBeans from console I do only ./netbeans. Is there a difference if starting NetBeans with sudo ./netbeans?
Here is how my project folder/file structure looks like, maybe I don't use correctly:
First of all I extracted the AXL Schema next to my src folder
<project folder>
-> schema
-> 12.5
AXLAPI.wsdl
AXLEnums.xsd
AXLSoap.xsd
-> src
-> main/...
-> test/...
In pom.xml I use
...
<build>
...
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>3.4.5</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<sourceRoot>${project.build.directory}/generated/cxf</sourceRoot>
<wsdlOptions>
<wsdlOption>
<wsdl>${basedir}/schema/12.5/AXLAPI.wsdl</wsdl>
<wsdlLocation>classpath:schema/12.5/AXLAPI.wsdl</wsdlLocation>
<extraargs></extraargs>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
...
<resources>
...
<resource>
<directory>./</directory>
<includes>
<include>schema/**</include>
</includes>
</resource>
<resource>
<directory>target/generated/cxf</directory>
<includes>
<include>**/*.java</include>
</includes>
</resource>
...
</resources>
</build>
...
Maybe this pom.xml setup is not correct, and that's why the Background scanning for projects works wrongly.
When I look into the resulting war file after build, I see
WEB-INF
-> classes
-> com/cisco/axl/api/_12
-> schema/12.5
and there are artifacts which might not belong there.
For example in com/cisco/axl/api/_12 there are not only the class files but all related generated Java source code files (all 2282).
And perhap schema/12.5 shouldn't be in the war file too.
I tried this pom:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>cxf</artifactId>
<version>1.0-SNAPSHOT</version>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>17</maven.compiler.source>
<maven.compiler.target>17</maven.compiler.target>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>3.4.5</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<wsdlOptions>
<wsdlOption>
<wsdl>src/main/resources/wsdl/CustomerService.wsdl</wsdl>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
</dependency>
</dependencies>
</project>
(Latest cxf-codegen-plugin, no additional config, wsdl file from here, java ee dependencies)
Running mvn clean install ("Clean and Build Project"...takes less than 5 seconds with this wsdl), and gets us:
..this nice picture (resolution of generated sources! grouped by provider (cxf)...we could have more).
Conclusion
Netbeans is mature regarding "generated sources". (As long as they are in target/generated-sources/<provider>;).
With "generated projects" (maven/gradle e.g. openapi-plugin) on the other hand, I experienced (netbeans) issues...and had to externalize/"source control" the "generated stuff" (/project!).
Don'ts
build>resources>resource>directory>. This will(try to) package your project root (additionally) to target/classes!! (This may confuse any IDE.)
...>resource>directory>target, for similar reasons esp. in Netbeans.
Hints
When we want the schemas & definitons to reside in (packaged) class path, we place them within src/main/resources. Otherwise: outside.
We add <resources/> to our <build/>, only when we decided so/know what we do/don't create "circles" (with existing maven-defaults), notto "trick netbeans"! (this is out-dated;)
Update:
I updated same project with this wsdl (axl-demo/schema).
It generated 1647 classes.
Netbeans took a while to scan:
I increased memory:
{nb_home}/etc/netbeans.conf:
netbeans_default_options="-J-Xmx4g ..."
(thx to: How to assign more memory to Netbeans? , ...)
(Restarted netbeans,) drank coffee
But then (once scan was completed): Still "nice picture", we can import/declare/use the generated classes:
Some Tweaks
..Yoda added to the build:
moved cxf-execution to profile:
<profiles>
<profile>
<id>gen</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
...
to activate it (only) with mvn install -Pgen (or in netbeans (Project>Properties>Run>) Configuration(drop-down)).
applied this: How to protect auto-generated sources during clean package in maven? like:
<build>
<plugins>
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>3.1.0</version>
<configuration>
<excludeDefaultDirectories>true</excludeDefaultDirectories>
<filesets>
<fileset>
<directory>${project.build.directory}</directory>
<excludes>
<exclude>generated-sources/**</exclude>
<exclude>classes/com/cisco/**</exclude>
</excludes>
</fileset>
</filesets>
</configuration>
</plugin>
</plugins>
</build>
I don't agree with "recommended solution"! For "thousands of" classes that b/rarely change, who wants to clean & re-generate them "hundreds" times/day?
Which accelerates us from (mvn -Pgen clean install):
------------------------------------------------------------------------
BUILD SUCCESS
------------------------------------------------------------------------
Total time: 44.515 s
To "Project>Clean and Build" (mvn clean install):
------------------------------------------------------------------------
BUILD SUCCESS
------------------------------------------------------------------------
Total time: 4.494 s
I have a multi-module Maven project where the project version is set via the revision variable.
<groupId>pricing</groupId>
<artifactId>pricing-backend-pom</artifactId>
<version>${revision}</version>
<packaging>pom</packaging>
<properties>
<revision>3.0.7</revision>
</properties>
<modules>
<module>pricing-backend-war</module>
<module>pricing-backend-model</module>
<module>pricing-backend-client</module>
</modules>
<build>
<plugins>
<!-- flatten before deploy. removes $revision -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>flatten-maven-plugin</artifactId>
<version>1.2.7</version>
<configuration>
</configuration>
<executions>
<!-- enable flattening -->
<execution>
<id>flatten</id>
<phase>process-resources</phase>
<goals>
<goal>flatten</goal>
</goals>
</execution>
<!-- ensure proper cleanup -->
<execution>
<id>flatten.clean</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
During the Gitlab build, the project is deployed to a Nexus repository. Each module and the parent appear in Nexus but only the modules appear to be flattened. The module POMs each contain <version>3.0.7</version> but the parent POM still contains <version>${revision}</version>.
I find it difficult to understand why the parent is deployed differently to the modules. I have checked the build logs but cannot see any indication that the parent is handled in a different way.
The parent POM taken from Nexus:
<groupId>pricing</groupId>
<artifactId>pricing-backend-pom</artifactId>
<version>${revision}</version>
<packaging>pom</packaging>
<properties>
<revision>3.0.7</revision>
...
A module POM:
<groupId>pricing</groupId>
<artifactId>pricing-backend-client</artifactId>
<version>3.0.7</version>
<dependencies>
...
The build applies the required version:
$ echo New version= ${MAVEN_VERSION}
New version= -Drevision=3.0.7-SNAPSHOT
$ mvn $MAVEN_CLI_OPTS ${MAVEN_VERSION} deploy -DskipTests
The pom file to be installed can be explicitly set:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.4</version>
<configuration>
<pomFile>.flattened-pom.xml</pomFile>
</configuration>
</plugin>
Above, flatten-maven-plugin has been previously invoked to produce .flattened-pom.xml
If you do a test by adding -Drevision=<someVersion> to the command line, does that produce correct results in Nexus?
I suspect it will.
Properties are interpolated very early in the process. When the command first runs, ${revision} is undefined, so Maven leaves it as-is. The flatten then calculates ${revision}, but that only applies from the time the plugin runs and later.
You can try researching "late binding" properties (they start with '#' instead of '$') but I'm not sure if those work in top level fields like the GAV coords.
I have a question regarding how maven calculates the classpath during building. Specifically, what controls when the "target/classes" is used and when the "jar" from a repository (local/remote) is used.
I have a project on version 1.0.0-SNAPSHOT where the artifacts have NOT been installed/deployed so there is no "jar" in some repository (remote or local) to resolve them. I want to run "generate-sources" WITHOUT installing locally (no 'mvn install' run).
The structure looks like this:
parent-prj
parent-prj/sub-prj
parent-prj/gen-src-prj <--- This depends on 'sub-prj'
When I run "mvn -am -pl parent-prj/gen-src-prj generate-sources" in order to just generate some java files, it does not work:
[ERROR] Failed to execute goal on project gen-src-prj: Could
not resolve dependencies for project
mygrp:gen-src-prj:jar:1.0.0-SNAPSHOT:
Could not find artifact
mygrp:sub-prj:jar:1.0.0-SNAPSHOT -> [Help 1]
Using debug output and adding "dependency:build-classpath" I can confirm that maven ignores the presence of "sub-prj" in the reactor and looks for a "jar" somewhere which it can't find. Yet the project is printed in the reactor summary:
[INFO] Reactor Summary:
[INFO]
[INFO] parent-prj ..................................... SUCCESS [ 0.625 s]
[INFO] sub-prj ........................................ SUCCESS [ 0.018 s]
[INFO] gen-src-prj .................................... FAILURE [ 0.040 s]
The interesting thing I noticed is that running the compile goal works fine! This uses sub-prj/target/classes (as shown by dependency:build-classpath) and has no trouble generating the sources and even compiling them: "mvn -am -pl parent-prj/gen-src-prj compile"
So here are the points I want to understand:
Why does the compile goal work but the generate-sources doesn't work?
At what point does maven decide to use the output folder of previous projects on the reactor classpath instead of looking for a jar?
Is there a way for generate-sources to run directly as I want it EVEN WITHOUT having its dependencies resolved?
Regarding (3) my generation tool is a utility invoked by:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.6.0</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
The tool reads some XML in src/main/resources and generates Java files and does NOT need anything in its class-path (so there is no need for maven to resolve it).
Also note that I would be interested to understand (1) and (2) even if a solution for (3) is provided.
EDIT: Per comment request, adding full example
parent-prj/pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>mygrp</groupId>
<artifactId>parent-prj</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>pom</packaging>
<modules>
<module>sub-prj</module>
<module>gen-src-prj</module>
</modules>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<source>1.8</source>
<target>1.9</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
</project>
parent-prj/sub-prj/pom.xml
<?xml version="1.0"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"
xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>mygrp</groupId>
<artifactId>parent-prj</artifactId>
<version>1.0.0-SNAPSHOT</version>
</parent>
<artifactId>sub-prj</artifactId>
</project>
parent-prj/gen-src-prj/pom.xml
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>mygrp</groupId>
<artifactId>parent-prj</artifactId>
<version>1.0.0-SNAPSHOT</version>
</parent>
<artifactId>gen-src-prj</artifactId>
<dependencies>
<dependency>
<groupId>mygrp</groupId>
<artifactId>sub-prj</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.6.0</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>java</goal>
</goals>
</execution>
</executions>
<configuration>
<includeProjectDependencies>false</includeProjectDependencies>
<includePluginDependencies>true</includePluginDependencies>
<mainClass>uk.co.real_logic.sbe.SbeTool</mainClass>
<systemProperties>
<systemProperty>
<key>sbe.output.dir</key>
<value>${project.build.directory}/generated-sources/java</value>
</systemProperty>
<systemProperty>
<key>sbe.validation.warnings.fatal</key>
<value>true</value>
</systemProperty>
</systemProperties>
<arguments>
<argument>${project.build.resources[0].directory}/Examples.xml</argument>
</arguments>
<workingDirectory>${project.build.directory}/generated-sources/java</workingDirectory>
</configuration>
<dependencies>
<dependency>
<groupId>uk.co.real-logic</groupId>
<artifactId>sbe-tool</artifactId>
<version>1.7.10</version>
</dependency>
</dependencies>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>add-source</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>target/generated-sources/java/</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
EDIT: Armed with the knowledge from the answers I have come up with this workaround that allows one to achieve the desired behaviour. I list the dependencies in a profile that is active by default, then use another profile to run generate-sources with no dependencies active, like follows:
parent-prj/gen-src-prj/pom.xml
<profiles>
<profile>
<id>default</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>mygrp</groupId>
<artifactId>sub-prj</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
</profile>
<profile>
<id>excludeDependency</id>
<dependencies>
</dependencies>
</profile>
</profiles>
To generate sources with above, use: mvn -PexcludeDependency generate-sources
Maven can reference only output generated in current Session (during currently executing shell command). It uses the most "mature" place to look for the "output":
If compile is run - the classes end up in the target/classes dir, thus other modules can reference that
If package is run - then target/*.jar is created and this jar file ends up in the classpath instead
If install is run - then jar file ends up in the local repository - which is what ends up on the classpath
So there are 3 factors that impede your task:
maven-exec-plugin requires dependency resolution (as pointed out by #mondaka)
Your module1 references module2
generate-sources is run before the compilation. Thus module2 is not yet prepared to be used as a dependency.
So if you want to do it your way - you'll have to run at least compile phase each time you use anything from the Default Lifecycle. Or you could write your own plugin that doesn't require dependency resolution.
This problem is related to an open maven bug:
https://issues.apache.org/jira/browse/MNG-3283
The issue says: "The problem only occurs when a plugin binds itself to the
generate-sources phase and has #requiresDependencyResolution".
I have checked that exec-maven-plugin Mojo have indeed requiresDependencyResolution = ResolutionScope.TEST. You can see that on https://github.com/mojohaus/exec-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/exec/ExecJavaMojo.java
Then, your only option is to use compile or process-classes phases. This is a Major open bug from 2007...
<plugin>
<groupId>com.googlecode.flyway</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>1.7</version>
<configuration>
<driver>com.mysql.jdbc.Driver</driver>
<url>jdbc:mysql://127.0.0.1:3306/db_abc</url>
<user>db_user</user>
<sqlMigrationPrefix>V</sqlMigrationPrefix>
</configuration>
</plugin>
I don't want to mention driver, url and user here. I already have a abc.property on src/main/resources. How can use that file here?
Have a look at the properties-maven-plugin. It allows you to read properties from a file to then use them in your pom.
Add the following plugin defintion:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0.0</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>src/main/resources/abc.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
If abc.properties contains:
jdbc.driver = com.mysql.jdbc.Driver
jdbc.url = jdbc:mysql://127.0.0.1:3306/db_ab
jdbc.user = db_user
You can then use the properties as follows:
<!-- language: xml -->
<driver>${jdbc.driver}</driver>
<url>${jdbc.url}</url>
<user>${jdbc.user}</user>
in version 3.0 you have to use configFile like :
<configFile>src/main/resources/db/config/flyway.properties</configFile>
In my opinion, the best and the most flexible approach is to:
a) use profiles and filtering - keep all configuration properties for specific profile (development, test, etc.), e.g. in development.properties:
jdbc.url=jdbc:mysql://127.0.0.1:3306/testdb?useSSL=false
jdbc.user=testuser
jdbc.password=testpass
jdbc.driver=com.mysql.jdbc.Driver
Then, in your pom file (possibly in root pom) define a profile, e.g:
...
<profiles>
<profile>
<id>development</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<filters>
<filter>../filters/development.properties</filter>
</filters>
</build>
...
here you can see that development profile is activated by default. If you want to use another profile set it with
-p [profile-id]
b) set flyway.properties with filtered values - your flyway.properties should sit e.g. in src/main/resources and the values should be used from the parameters defined in the profile properties file:
flyway.driver = ${jdbc.driver}
flyway.url = ${jdbc.url}
flyway.user = ${jdbc.user}
flyway.password = ${jdbc.password}
c) reference flyway.properties from build directory - use simple plugin configuration (I really like clean poms):
...
<build>
<resources>
<!-- This way we instruct maven to inject values from filters into the resources -->
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
<plugins>
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<configuration>
<configFile>${project.build.directory}/classes/flyway.properties</configFile>
<locations>
<location>classpath:migration/mysql</location>
</locations>
</configuration>
</plugin>
</plugins>
</build>
...
Don't forget to enable filtering in resources as shown in many examples here. My flyway-maven-plugin version is 3.2.1 and it is managed in pluginManagement in parent pom, therefore version is not visible here. I also use explicit sql scripts with locations configuration.
There are several ways to deal with this. One approach is to do it the other way around.
That means that the properties to use are saved as properties inside the pom.xml and that the file abc.properties only has placeholders that will be filled in at build time.
I will show you how it can be configured.
This is what the pom.xml will look like:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.stackoverflow</groupId>
<artifactId>Q12619446</artifactId>
<version>1.0-SNAPSHOT</version>
<name>${project.artifactId}-${project.version}</name>
<properties>
<jdbc.driver>com.mysql.jdbc.Driver</jdbc.driver>
<jdbc.url>jdbc:mysql://127.0.0.1:3306/db_abc</jdbc.url>
<jdbc.user>db_user</jdbc.user>
</properties>
<build>
<plugins>
<plugin>
<groupId>com.googlecode.flyway</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>1.7</version>
<configuration>
<driver>${jdbc.driver}</driver>
<url>${jdbc.url}</url>
<user>${jdbc.user}</user>
</configuration>
</plugin>
</plugins>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
</project>
And this will be your src/main/resources/abc.properties (use the key names of your choice):
jdbcDriver = ${jdbc.driver}
jdbcUrl = ${jdbc.url}
jdbcUser = ${jdbc.user}
After the build the target/classes/abc.properties will look like this:
jdbcDriver = com.mysql.jdbc.Driver
jdbcUrl = jdbc:mysql://127.0.0.1:3306/db_abc
jdbcUser = db_user
As stated this is only one of several ways to do it. It might not suit your exact needs but it could.
Garry,
there is one more way not to place database connection parameters to your pom-file. In particular, one can add them to settings.xml file in .m2 sub-folder of the user's folder [1]. The benefit is that the db paraneters do not live in the project folder and are not transmitted to the repository, so each developer may use her own settings.
The example of the settings file could look like the example below.
<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
<profiles>
<profile>
<id>fw</id>
<properties>
<flyway.url>jdbc:oracle:thin:#//localhost:1521/xe</flyway.url>
<flyway.user>Your login</flyway.user>
<flyway.password>Your password</flyway.password>
</properties>
</profile>
</profiles>
<activeProfiles>
<activeProfile>fw</activeProfile>
</activeProfiles>
</settings>
After that your can modify your pom-file according to the following snippet.
<?xml version="1.0"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
...
<dependencies>
...
</dependencies>
<profiles>
<profile>
<id>fw</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>3.2.1</version>
<configuration>
<url>${flyway.url}</url>
<user>${flyway.user}</user>
<password>${flyway.password}</password>
</configuration>
<dependencies>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc7</artifactId>
<version>12.1.0.1.0</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
In the example above Oracle's driver is used, but you can replace it with the required one.
To print current settings execute the following.
mvn help:effective-settings
In version 3.x you have configFile option
By default- flyway.properties in the same directory as the project POM.
You can add external property file in configuration section of pom or can be pass when running maven goal example-
command line-
mvn <goal> -Dflyway.configFile=myConfig.properties
Pom file-
<plugin>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-maven-plugin</artifactId>
<version>3.2.1</version>
<configuration>
<driver/>
<url/>
<user/>
<password/>
<baselineVersion>1.0</baselineVersion>
<baselineDescription>Base Migration</baselineDescription>
<skip>false</skip>
<configFile>myConfig.properties</configFile>
</configuration>
</plugin>
I have a product that contains a Jar file in its distribution and I have created a pom.xml that uses the install-file mojo to install the Jar into the local repository. So the user unpacks my zip file and types "mvn install" and everything works.
My problem is I have a second Jar file that I would also like to install using the same pom.xml, but this Jar file is optional and may or may not be present (the Jar file is downloaded separately by the user and placed in the same directory). I have tried install-file and also build-helper:attach-artifact and can't figure out how to do this within a single POM. I'm happy to have the user type some different command to install this Jar file, or have it work with "mvn install".
One possibility is to use a profile, which gets activated based on the existence of the second jar. This profile can be used to attach an additional artifact using the build helper maven plugin goal that you have referred above. Something like this...
<project>
...
<profiles>
<profile>
<id>second-jar</id>
<activation>
<file>
<exists>${basedir}/location/of/second.jar</exists>
</file>
</activation>
<build>
<plugins>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>attach-artifacts</id>
<phase>package</phase>
<goals>
<goal>attach-artifact</goal>
</goals>
<configuration>
<artifacts>
<artifact>
<file>second</file>
<type>jar</type>
</artifact>
</artifacts>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>