This is a portion of my profiles.xml for mvn:
<profilesXml>
<profiles>
<profile>
<id>production</id>
<build>
<plugins> .. </plugins>
</build>
</profile>
</profiles>
</profilesXml>
This is what mvn says:
Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException:
Unrecognised tag: 'build' (position: START_TAG seen ...</id>\n
<build>... #32:20)
What's wrong here?
The error message is giving you the correct feedback here, you cannot specify a <build/> section in an external profile, you are only allowed to specify <properties>, <pluginRepositories>, and <repositories>. From the Introduction to Build Profiles:
Profiles in external files
Profiles specified in external files
(i.e in settings.xml or
profiles.xml) are not portable in
the strictest sense. Anything that
seems to stand a high chance of
changing the result of the build is
restricted to the inline profiles in
the POM. Things like repository lists
could simply be a proprietary
repository of approved artifacts, and
won't change the outcome of the build.
Therefore, you will only be able to
modify the <repositories> and
<pluginRepositories> sections, plus
an extra <properties> section.
The <properties> section allows you
to specify free-form key-value pairs
which will be included in the
interpolation process for the POM.
This allows you to specify a plugin
configuration in the form of
${profile.provided.path}.
If your snippet is coming from a book, the book should be fixed.
You can not have <build> area in your profile. Only plugins etc. You can configure the plugins etc.
Related
We have a Maven 2 project with lots of modules in it. Example:
<modules>
<module>common</module>
<module>foo</module>
<module>data</module>
<module>bar</module>
... more ...
</module>
Let's say the "data" module is time consuming to build and we want to exclude it when the project is build by a CI server. Currently we use two pom.xml files to achieve this. One has all modules in it and the other one has all modules except the ones which can be left out for CI. But that's pretty annoying because sometimes we forget to put a new module into both files.
Is there a solution which doesn't need two separate module lists?
With Maven 3.2.1, you can now use -pl !<module_name>,!<module_name> to exclude certain modules from the reactor build.
See this feature request: https://issues.apache.org/jira/browse/MNG-5230
The easiest might be to use profiles like this:
<project>
...
<modules>
<module>common</module>
<module>foo</module>
<module>bar</module>
<modules>
...
<profiles>
<profile>
<id>expensive-modules-to-build</id>
<modules>
<module>data</module>
</modules>
</profile>
</profiles>
</project>
You should then check out ways you can activate profiles
The projects to build can also be specified on the mvn command line. This would remove the need for a separate pom, but instead you would have to change the CI configuration everytime there is a new module.
-pl,--projects <arg> Comma-delimited list of specified
reactor projects to build instead
of all projects. A project can be
specified by [groupId]:artifactId
or by its relative path.
Maybe a combination of this flag and --also-make-dependents or --also-make would reduce this maintenance burden again.
-am,--also-make If project list is specified, also
build projects required by the
list
-amd,--also-make-dependents If project list is specified, also
build projects that depend on
projects on the list
I assume you want the default build to always build everything, regardless of speed, so that new developers can get started quickly without having to understand lots about the POM. You can use profiles like this:
<modules>
<module>common</module>
<module>foo</module>
<module>bar</module>
</modules>
...
<profiles>
<profile>
<id>expensive-modules-to-build</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<modules>
<module>data</module>
</modules>
</profile>
</profiles>
</project>
The problem with this is that if a developer specifies another profile on the command line, then the expensive-modules-to-build isn't included (unless the developer also specifies it). This makes it complicated to remember which profiles need to be included.
Here is a hacky way around that. Both profiles are always included, because the pom.xml file always exists. So to exclude the expensive modules, you can use -P!full-build on the command line.
<profiles>
<profile>
<id>full-build</id>
<activation>
<file>
<exists>pom.xml</exists>
</file>
</activation>
<modules>
<module>data</module>
</modules>
</profile>
<profile>
<id>short-build</id>
<activation>
<file>
<exists>pom.xml</exists>
</file>
</activation>
<modules>
<module>common</module>
<module>foo</module>
<module>bar</module>
</modules>
</profile>
</profiles>
Another idea: Reactor modules can be nested, so it should be possible to group your fast and slow-building modules into separate poms and then add another aggregator pom containing these two as modules. Your CI Server could then only reference the pom containing the fast building modules.
<artifactId>fast</artifactId>
<modules>
<module>fast-a</module>
<module>fast-b</module>
<module>fast-c</module>
</module>
<artifactId>all</artifactId>
<modules>
<module>fast</module>
<module>slow</module>
</module>
You could be to use maven profiles. In our build environment, we created a profile quick that disables many plugins and test execution.
This is done by
<profile>
<id>quick</id>
<properties>
<skipTests>true</skipTests>
<!-- others... -->
</properties>
<build>
<plugins>
<!-- configuration... -->
</plugins>
</build>
</profile>
And then we invoke maven the following way
mvn groupId:artifactId:goal -P quick
You could maybe disable compilation and other standard plugins in the pom of your module to speed it up.
Not exactly the answer these folks were asking for. My situation was I wanted to deploy only the parent pom. I'm using the spring-boot-thin-layout in a child module. This requires the parent module be deployed into artifactory. I added the following into my project. It enables skipping of install and/or deploy phase.
In my parent pom:
<properties>
<disable.install>true</disable.install>
<disable.deploy>true</disable.deploy>
<enable.deployAtEnd>true</enable.deployAtEnd>
</properties>
<profiles>
<profile>
<id>deploy-parent</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<disable.install>true</disable.install>
<disable.deploy>true</disable.deploy>
<deployAtEnd>${enable.deployAtEnd}</deployAtEnd>
</properties>
<build>
<finalName>${project.version}</finalName>
</build>
</profile>
</profiles>
And the in my child pom(s) or any module you don't want deployed with parent:
<properties>
<maven.install.skip>${disable.install}</maven.install.skip>
<maven.deploy.skip>${disable.deploy}</maven.deploy.skip>
<deployAtEnd>${enable.deployAtEnd}</deployAtEnd>
</properties>
So effectively when I run mvn deploy on the parent pom, it will compile all the modules, not run install on anything, and then at the end deploy any module not having <maven.deploy.skip>${disable.deploy}</maven.deploy.skip> in it's properties. So in my case only deploying the parent.
Suppose I have a module A:jar, whose runtime and compilation set of dependencies depends on the JDK version. In my example, I have a pre-jdk6-profile for JAXB API: prior to JDK 1.6.0 I need to include jaxb-api-nnn.jar as a compile dependency. This profile is placed to A.pom.
I also have module B:war, which depends on A:jar. I want to be able to activate this profile on a build server to build the JDK 1.5.x deliverable. When I execute Maven with a given profile activated, I get the message:
mvn -Ppre-jdk6-profile -o install
[WARNING]
Profile with id: 'pre-jdk6-profile' has not been activated.
and jaxb-api-nnn.jar is missing in resulting B.war. However if I activate this profile when building from the parent pom.xml, everything is OK. That means the profiles are not inherited from dependencies, and the parent multi-module pom.xml was able to build everything correctly because it seems like all profiles are merged in reactor.
Shifting the profile to parent pom makes things worse, as the dependencies are applied to all other projects (e.g. to C:ear). Are there nice solutions for this task, namely, if any module A depends on module B, then all compile and runtime dependencies which are activated by a profile, are correctly handled?
The profile in project A:jar follows:
<project ...>
<artifactId>A</artifactId>
<packaging>jar</packaging>
...
<parent>
<artifactId>P</artifactId>
...
</parent>
<profiles>
<profile>
<id>pre-jdk6-profile</id>
<activation>
<jdk>(,1.6.0)</jdk>
</activation>
<dependencies>
<dependency>
<groupId>javax.xml.ws</groupId>
<artifactId>jaxws-api</artifactId>
</dependency>
</dependencies>
</profile>
</profiles>
...
</project>
a) In a multi-module build, you should always build from the top pom, never from an individual module. If you want to build only one module, use advanced reactor options (see mvn --help) like this:
mvn -pl mymodule
b) Define and activate the profile in the parent pom, but add the configuration in the child pom.
parent pom.xml
<profiles>
<profile>
<id>pre-jdk-6</id>
<activation>
<jdk>(,1.6.0)</jdk>
</activation>
</profile>
</profiles>
child pom.xml
<profiles>
<profile>
<id>pre-jdk-6</id>
<dependencies>
<dependency>
<groupId>javax.xml.ws</groupId>
<artifactId>jaxws-api</artifactId>
</dependency>
</dependencies>
</profile>
</profiles>
Several notes way after the fact:
When you use -P profName, it activates a profile named 'profName'
After that, it disables all profiles that have an <activation> tag for them. It doesn't matter whether they are activated by the java version, as in the example, or by default or env value or anything.
That means the -P causes any otherwise activated profile to become deactivated.
Solution: Either use <activation><jdk>...</jdk></activation> or use -P but do not use both.
I have a POM which declares web application stuff that is common to my projects. I use this as the parent for all web applications.
Is it possible to activate a profile only when the packaging is war? I have tried the property approach, but that doesn't work (as it isn't a system/environment property).
Since this fails the build, I can simply disable that profile when installing the POM, but I'd like it to be more intelligent on its own.
Walter
You can simply check the existence of src/main/webapp. Each web application that uses the Maven standard directory layout should contain this folder. So you avoid unnecessary dummy files.
<profile>
<id>custom-profile-eclipse-project-generation-webapp</id>
<activation>
<file>
<exists>${basedir}/src/main/webapp</exists>
</file>
</activation>
<build>
</build>
</profile>
More precise you can also check for the the existence of ${basedir}/src/main/webapp/WEB-INF/web.xml. That should definitively identify a war-project.
For myself I use this configuration in my common super-pom to configure the maven-eclipse-plugin for different project types. Thats very handy to get homogenous eclipse-configurations over the same project type in our organization, especially when developers straightforwardly run eclipse:eclipse on multi-module-projects.
I know this isn't answering your question directly, but the usual workaround for problems like this is to just use specialization (as with classes).
So you have your MasterPom with all common behavior.
MasterWarPom that extends MasterPom (is it's parent), and put any 'packing is war' specializations in here.
Likewise you could have MasterJarPom, etc ...
That way the differences are split out nicely.
There's no clean way to do that, the parent module has no way of knowing the child's packaging. (Non-clean solutions would involve creating a plugin that parses the child module's pom etc.)
The best I've been able to come up with for these sorts scenarios has been to use a file-based activation trigger.
eg my parent pom has
<profile>
<id>maven-war-project</id>
<activation>
<file><!-- add a file named .maven-war-project-marker to webapp projects to activate this profile -->
<exists>${basedir}/.maven-war-project-marker</exists>
</file>
</activation>
<build>
<plugins>
<!-- configuration for webapp plugins here -->
</plugins>
</build>
and webapp projects that inherit from this parent contain a file named
'.maven-war-project-marker'
that activates the profile
This looks pretty obtuse but works fairly reliably whereas
- using property-activation is unreliable if a different person or system does the build,
- inheriting from type-specific parents became a bit cumbersome for me as the grandparent-pom changes version relatively frequently as it is used to define 'standard' or preferred versions of common dependencies which in turn required corresponding releases of all of the type-specific parents with no change other than the grandparent version
Try in this way ?
mvn package -Dmaven.test.skip=true -Dwar
<project ×××××>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>××××</groupId>
<artifactId>×××××</artifactId>
<version>×××××</version>
<relativePath>../../</relativePath>
</parent>
<artifactId>×××××</artifactId>
<name>${project.artifactId}-${project.version}</name>
<description>${project.artifactId}-${project.version}</description>
<properties>
<packaging.type>jar</packaging.type>
</properties>
<profiles>
<profile>
<activation>
<property>
<name>war</name>
</property>
</activation>
<properties>
<packaging.type>war</packaging.type>
</properties>
<build>
<finalName>ROOT</finalName>
</build>
</profile>
</profiles>
<packaging>${packaging.type}</packaging>
<dependencies>
<dependency>
... ...
</dependency>
... ...
</dependencies>
I use maven/hudson to build my project. One of the goals run by hudson is mvn package so I have a full distribution produced on every build. Is there a way (maybe an argument to package?) that I can append the build number to the name of archive that's produced?
thanks,
Jeff
Try the following. It should only activate if the BUILD_NUMBER property is set, so you'll still generate correctly named builds when not using hudson.
<profiles>
<profile>
<id>hudson-build</id>
<activation>
<property>
<name>BUILD_NUMBER</name>
</property>
</activation>
<build>
<finalName>${artifactId}-${version}-${BUILD_NUMBER}</finalName>
</build>
</profile>
</profiles>
I'd suggest putting this into a base pom.xml that can then be referenced as a parent to your other pom.xml configs.
For a list of other properties that hudson passes on to maven builds, see http://weblogs.java.net/blog/johnsmart/archive/2008/03/using_hudson_en.html.
You can pass an arbitrary property to a Maven build using -D[key]=[value], for example -DbuildNumber=1234 then configure the version in your pom as `1.0.0-${buildNumber}. This approach goes against the general Maven principle though. You'd be better to use Maven's SNAPSHOT processing. SNAPSHOT is a keyword to Maven to update the dependency each time.
You could also use the buildnumber-maven-plugin to automatically add a number to the build version each time. See this answer for some details. The buildnumber plugin can be set to produce a revision based on the SCM revision, a timestamp, or on a sequence.
I am trying to setup a shared authentication system on a build server.
We have several maven projects that declares how the deployment should be done regarding the different teams that we have (each team has its own authentication user/password):
<profile>
<id>release-profile</id>
<distributionManagement>
<repository>
<id>rep-releases</id>
<name>rep-releases</name>
<url>http://somewhere-releases</url>
</repository>
<snapshotRepository>
<id>rep-snapshots</id>
<name>rep-snapshots</name>
<url>http://somewhere-snapshots</url>
</snapshotRepository>
</distributionManagement>
</profile>
Then I declare in the settings.xml the authentification to the declared servers as following:
<servers>
<server>
<id>rep-releases</id>
<username>${release.user.name}</username>
<password>${release.user.password}</password>
</server>
<server>
<id>rep-snapshots</id>
<username>${release.user.name}</username>
<password>${release.user.password}</password>
</server>
</servers>
Finally, depending on the projects I want to deploy I have several profiles defined in the settings.xml of the build server:
<profile>
<id>dep-team1</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<properties>
<release.user.name>team1-user</release.user.name>
<release.user.password>team1-password</release.user.password>
</properties>
</profile>
The problem is that when doing a deploy of the project I got an authentication error (HTTP 401) like the following:
Error deploying artifact: Failed to transfer file: http://......./my-project-0.2-20090423.123247-3.pom. Return code is: 401
If I modify the server authentication by replacing the properties with the user/password of the team, all is working fine.
Don't the tags <servers><server> accept values as properties?
How do others setup their build system in order to achieve the same?
Thanks for your help.
Edit: I am using hudson, a solution for me can be to install several time maven2 and have duplicated settings (except user/password) for each team and tie each project to the good maven installation. I must admit that this solution does not enchant me...
The easiest and most direct method if you have multiple teams and thus multiple auth schemes, is just use a different id in the distributionManagement. So instead of rep-releases/rep-snapshots, you can have team1-repo / team2-repo (there's generally no value in separating the auth between release and snapshots...particularly if you use a repo manager with good security controls)
Then in the settings of your build machine, just define a user and password for each team for the build server.
This approach does have a draw back that it would mess up inheritence if you defined the repos in a single corporate pom...but if you have a team level pom it would be easy.
Another thought is why does the same build machine need to login as a different person when doing builds? Shouldn't that build machine have mostly full access?
First of all, I do not see how dep-team1 profile is connected to the distributionManagement tag - it seems to need release-profile to be active.
Second, I have my profile element structured a bit differently (see, there is no distributionManagement tag within). Not sure if it makes the difference.:
<profile>
<id>release-profile</id>
<repositories>
<repository>
<id>central</id>
<url>http://central</url>
<releases><enabled>true</enabled></releases>
<snapshots><enabled>true</enabled></snapshots>
</repository>
</repositories>
</profile>
Here is the distribution management:
<project>
<distributionManagement>
<repository>
<id>releases</id>
<url>http://myurl/releases</url>
</repository>
<snapshotRepository>
<id>snapshots</id>
<url>http://myurl/snapshots</url>
</snapshotRepository>
</distributionManagement>
</project>