If I have Maven builds set up for an app with profiles set up for different environments (say like prod vs. dev, defining different DB settings and stuff like that) the 'install' goal doesn't seem to make sense, as I don't know which environment got installed into my repo - I've just got com.example.myproject:myapp:0.0.1.
Have I misunderstood something, or are profiles supposed to be used with other goals?
Well, you could use the classifier attribute so that each profile creates a jar with the classifier, i.e. a unique jar for each environment. Here is a code snippet to illustrate this. When run with the dev profile (mvn -P dev install), it creates a jar with -dev classifier, like myapp-dev-0.0.1.jar
<project>
...
<properties>
<env></env>
</properties>
...
<build>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<classifier>${env}</classifier>
</configuration>
</plugin>
</plugins>
</build>
<profiles>
...
<profile>
<id>dev</id>
<properties>
<env>dev</env>
</properties>
...
</profile>
</profiles>
</project>
You run the usual mvn commands and can select the appropriate profile with -P http://maven.apache.org/guides/introduction/introduction-to-profiles.html So it dependends on which profile you chose, what gets installed in the repository.
Related
How can I specify the outputDirectory only for packaging a jar?
http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html this shows all parameters, but how can I set them in the commandline or pom.xml?
on command line
-DoutputDirectory=<path>
and in pom.xml
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<configuration>
<outputDirectory>/my/path</outputDirectory>
</configuration>
</plugin>
</plugins>
</build>
Parameter Expressions
About command line usage:
The parameter documentation specifies that the parameter is initialized to the value of the property ${project.build.directory} (which is the property referring to the target folder)
Here's what this means:
For mojos that are intended to be
executed directly from the CLI, their
parameters usually provide a means to
be configured via system properties
instead of a <configuration/> section
in the POM. The plugin documentation
for those parameters will list an
expression that denotes the system
properties for the configuration. In
the mojo above, the parameter url is
associated with the expression
${query.url}, meaning its value can be
specified by the system property
query.url as shown below:
mvn myquery:query -Dquery.url=http://maven.apache.org
Reference:
Guide to Configuring Plug-ins > Generic Configuration
Configuring ${project.build.directory}
However, ${project.build.directory} is not a system property, it's a property of the Project's Build object.
You can't set maven's internal properties directly on the command line, but you can get there with a little trick by adding placeholders in your pom.xml:
<build>
<directory>${dir}</directory>
</build>
Now, the output directory is set via the property from the command line (using -Ddir=somedirectory). Downside: now you always have to use the -Ddir parameter on the command line.
Using Profiles
But there's help here, too. Just use a profile when you want to configure the directory:
<profiles>
<profile>
<id>conf</id>
<build>
<directory>${dir}</directory>
</build>
</profile>
</profiles>
Now you can either do
# everything goes in someOtherDir instead of target
mvn clean install -Pconf -Ddir=someOtherDir
or plain old
# everything goes in target
mvn clean install
Configuring the Jar Plugin
Now if you just want to change the jar outputDirectory from the command line without redirecting everything from target, we'll modify the profile to configure the plugin from a command line property:
<profiles>
<profile>
<id>conf</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<configuration>
<outputDirectory>${dir}</outputDirectory>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
The usage is identical to above:
# everything goes in someOtherDir instead of target
mvn clean install -Pconf -Ddir=someOtherDir
Thanks #Sean Patrick Floyd for the excellent explanation.
Instead of creating a profile and using mvn always by -P switch, I'd like to use another way that making a default value of property ${dir}.
Just define ${dir}'s default value as ${project.build.directory}
<properties>
<dir>${project.build.directory}</dir>
</properties>
and same as #Sean Patrick Floyd, set outputDirectory.
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<configuration>
<outputDirectory>${dir}</outputDirectory>
</configuration>
</plugin>
</plugins>
Now you can either do
# everything goes in someOtherDir instead of target
mvn clean install -Ddir=someOtherDir
or plain old
# everything goes in target
mvn clean install
If you wish copy dependency jars as well to a target folder, use maven-dependency-plugin.
<project>
...
...
<build>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Something like the following.
I would like a way to skip my dao tests in surefire. Trying to avoid overhead of defining Suites.
With CI I'd like to have one nightly that runs all tests and another 5 minute poll of SCM that runs only 'fast' tests.
mvn -DskipPattern=**.dao.** test
Let me extend Sean's answer. This is what you set in pom.xml:
<properties>
<exclude.tests>nothing-to-exclude</exclude.tests>
</properties>
<profiles>
<profile>
<id>fast</id>
<properties>
<exclude.tests>**/*Dao*.java</exclude.tests>
</properties>
</profile>
</profiles>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<excludes>
<exclude>${exclude.tests}</exclude>
</excludes>
</configuration>
</plugin>
Then in CI you start them like this:
mvn -Pfast test
That's it.
Sure, no problem:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.6</version>
<configuration>
<excludes>
<!-- classes that include the name Dao -->
<exclude>**/*Dao*.java</exclude>
<!-- classes in a package whose last segment is named dao -->
<exclude>**/dao/*.java</exclude>
</excludes>
</configuration>
</plugin>
Reference:
Maven Surefire Plugin > Inclusions and Exclusions of Tests
(The excludes can not be configured via command line, so if you want to turn this behavior on conditionally, you will have to define a profile and activate that on the command line)
It is possible to exclude tests using the commandline; using ! to exclude.
Note: I'm not sure but possibly needs 2.19.1 or later version of surefire to work.
Examples:
This will not run TestHCatLoaderEncryption
mvn install '-Dtest=!TestHCatLoaderEncryption'
Exclude a package:
mvn install '-Dtest=!org.apache.hadoop.**'
This can be combined with positive filters as well. The following will run 0 tests:
mvn install '-Dtest=Test*CatLoaderEncryption,!TestHCatLoaderEncryption'
See the Maven Surefire docs.
I am using the maven release plugin. Problem is simple: I don't want to do a deploy on release:perform. I actually want to execute a shell script that will do the deploy for me. So I have two things to accomplish:
Somehow disable the default "deploy" goal from release:perform
Somehow make release:perform call the exec:exec plugin to execute a shell script
Here is my pom:
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.0</version>
<configuration>
<tagBase>svn://saoj-la.dyndns.org/webapp-test/tags</tagBase>
<connectionUrl>scm:svn:svn://saoj-la.dyndns.org/webapp-test/trunk</connectionUrl>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>/bin/sh</executable>
<arguments>
<argument>run.sh</argument>
</arguments>
</configuration>
</plugin>
A little late, but for reference:
For your step 1, you can disable the maven deploy step by using the "skip" option. Click here for reference.
On the commandline you could call something like:
mvn release:perform -Darguments="-Dmaven.deploy.skip=true"
I am using the maven release plugin. Problem is simple: I don't want to do a deploy on release:perform. I actually want to execute a shell script that will do the deploy for me.
I must be missing something because when I read this, I don't see the point of the script... But let's just say I don't get it.
Somehow disable the default "deploy" goal from release:perform
According to the documentation of release:perform, you can use the optional goals parameter to specify:
A space separated list of goals to execute on deployment. Default value is either deploy or deploy site-deploy, if the project has a <distributionManagement>/<site> element.
You could maybe use install instead of deploy.
Somehow make release:perform call the exec:exec plugin to execute a shell script
Bind it on install in a profile activated during release. Here is one way to do this:
<profile>
<!-- Profile used when the release plugin executes. -->
<id>release</id>
<activation>
<property>
<!-- This property is automatically defined by the Maven release plugin when executing
a release. Thus this profile will be automatically enabled when releasing -->
<name>performRelease</name>
<value>true</value>
</property>
</activation>
<build>
...
</build>
</profile>
But honestly, there is something weird with your request. Maybe giving more details would help.
I am using two profiles: development and production.
Development should be active on default; production should be used when I am releasing.
In my pom.xml I have:
[...]
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.0-beta-9</version>
<configuration>
<useReleaseProfile>false</useReleaseProfile>
<goals>deploy</goals>
<arguments>-Pproduction</arguments>
</configuration>
</plugin>
[...]
<profiles>
<profile>
<id>production</id>
<properties>
<profile.name>production</profile.name>
</properties>
[...]
</profile>
<profile>
<id>development</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<profile.name>development</profile.name>
</properties>
[...]
</profile>
[...]
It just does not work.
useReleaseProfiles doesn't work either:
http://jira.codehaus.org/browse/MRELEASE-459
The development profile should be always active but not when running mvn release:perform.
How do you achieve this?
[UPDATE]:
I have seen with the debug flag that my production profile is used, but development profile is used too, because it is activeByDefault. This cant be overridden by the releaseProfile argument. It would be nice to force the release plugin to use only the "production" profile.
The maven-release-plugin documentation encourages using the releaseProfiles configuration parameter to automatically invoke profiles during the release process.
This is a better approach than manually invoking release profiles from the command-line. One reason, is because the profiles used in the release will be documented in the pom.xml and stored with the tagged code. This makes the build process easier to understand and easier to repeat later, exactly the same way the project was originally released.
If using maven-release-plugin older than 2.4 see this bug preventing use of the above mentioned parameter.
Be aware that in case of a multi-module project you'll have to put the "releaseProfiles" configuration in the root pom! See also this issue for more information about that.
I think you should simply activate your profiles through a property.
<profiles>
<profile>
<id>production</id>
<activation>
<property>
<name>build</name>
<value>release</value>
</property>
</activation>
[...]
</profile>
<profile>
<id>development</id>
<activation>
<property>
<name>build</name>
<value>develop</value>
</property>
</activation>
[...]
</profile>
<profiles>
Do your builds by executing something like this
mvn -Dbuild=develop package
mvn -Dbuild=develop test
mvn -Dbuild=release release:prepare
mvn -Dbuild=release release:perform
If you check "Introduction to Build Profiles", "Deactivating a profile":
mvn groupId:artifactId:goal -P !profile-1,!profile-2
I guess you could use this to deactivate your default profile?
This is a very old post but I came across this issue quite recently. The releaseProfile only worked for me when I set the releaseProfiles to profile called release. Any other profile gives same error.
Sample code:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.3</version>
<configuration>
<tagNameFormat>#{project.artifactId}-#{project.version}</tagNameFormat>
<autoVersionSubmodules>true</autoVersionSubmodules>
<releaseProfiles>release</releaseProfiles>
<allowTimestampedSnapshots>true</allowTimestampedSnapshots>
</configuration>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>release</id>
<properties>
<connectionUrl>${scm-base}/tags/${project.artifactId}-${project.version}</connectionUrl>
</properties>
</profile>
</profiles>
I have a project that consist of 3 different libraries. When I run install script it takes all libraries from repo and run mvn clean install on them. But this version of library already installed in repo. Is there a way to skip install phase if version in pom.xml equal version in my local repo.
I know that I can use local repo and just set dependencies. But my boss want that our project can build only with public repos and without any our repos.
You can bypass like this
-Dmaven.install.skip=true
<profiles>
<profile>
<id>skipInstall</id>
<activation>
<property>
<name>maven.install.skip</name>
<value>true</value>
</property>
</activation>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>default-install</id>
<phase>none</phase>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
Last week Olivier Lamy patched this jira.
MINSTALL-73
Most maven plugins can be skipped by specifying something like:
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>X.Y</version>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
you can also set up build profiles to set properties and use that to determine the value. for example, running the command: mvn -Pexample would select the "example" profile. The POM would then contain:
...
<properties>
<skip.install>false</skip.install>
...
</properties>
...
<profile>
<id>example</id>
<properties>
<skip.install>false</skip.install>
</properties>
</profile>
...
<plugin>
<artifactId>maven-install-plugin</artifactId>
<version>X.Y</version>
<configuration>
<skip>${skip.install}</skip>
</configuration>
</plugin>
...
Using these POM additions, the default behavior for the install plugin will be to perform its default goal, but if the example profile is selected, then the install plugin will skip its goal.
Using what I learned from the other answers, this was the cleanest result for me.
In my super pom I added a pluginManagement/plugin to disable default-install and default-test phases when the property deployOnly is set.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>default-install</id>
<configuration>
<skip>${deployOnly}</skip>
</configuration>
</execution>
<execution>
<id>default-test</id>
<configuration>
<skip>${deployOnly}</skip>
</configuration>
</execution>
</executions>
</plugin>
So on the command line, I can disable install and test phases by adding -DdeployOnly.
mvn clean install #build and test everything
mvn deploy -DdeployOnly #just deploy it
I know that I can use local repo and just set dependencies. But my boss want that our project can build only with public repos and without any our repos.
Are you sure you understood correctly what you boss meant? I interpret the above as "don't install third party libraries in your local repository, use only libraries available in public repositories". This is different from "don't use your local repository" which is basically impossible, that's just not how maven works. I'd try to clarify this point.
Apart from that, I don't get the question which is very confusing (what repo are you talking about? What is the install script doing? Why do you call clean install on libraries? etc).
Extending the other answers, from the future.
Maven plugins have a surprisingly high freedom, how do they run. If they want, they can ignore/override the typical pom.xml settings. Furthermore, also the <configuration><skip>true</skip></configuration> is only a convention, nothing obligates a plugin to follow it, except that most of them is developed so.
My experiments with the recent problem show, that both #Cemo's and #MiloshBoroyevich solution should be utilized, also the plugin requires both to really let us in peace. More concretely, the only working configuration by me was this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>default-install</id>
<phase>none</phase>
</execution>
</executions>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
One of your options is to put the deployment to another module. I.e. have one pom.xml build the artifact and install it to the local repo, and another pom.xml to deploy it. This separation is quite common in larger projects, where the testsuite is sometimes a separate module or even a project, the packaging happens in several stages, etc.
- pom.xml - myProject-root - type=pom
- pom.xml - myProject-artifact - type=jar
- pom.xml - myProject-deploy - type=pom, does the deployment, skips it's own `install` goal