What are possible causes of the following maven warning:
Overriding profile: 'null' (source: pom) with new instance from source: pom
I've tried commenting out my entire default profile as the warning mentions "profile", but that didn't help. I've also tried commenting out my reporting options and the warning still shows up.
I've ran maven with the -X flag and the warning shows up immediately after my hamcrest dependency is brought in, but commenting it out doesn't eliminate the warning.
EDIT: additional information per request:
Output from mvn help:active-profiles:
Active Profiles for Project 'com.sophware.XXX:main:jar:0.0.1-SNAPSHOT':
The following profiles are active:
- default (source: pom)
Output from mvn help:all-profiles:
[INFO] Listing Profiles for Project: com.sophware.XXX:main:jar:0.0.1-SNAPSHOT
Profile Id: default (Active: true , Source: pom)
default is indeed the id of the profile that I use in my pom. At this point, I only have one profile, although I expect to add more in the future.
Resolution:
Peter was right about the problem. The problem stems from not having an id element within a maven profile. In my case, a pom file was being pulled in because of my miglayout dependency.
Upon looking through the dependent pom's, I found that miglayout, indeed, does not use id's in its profiles:
<profile>
<activation>
<os>
<family>windows</family>
<arch>x86</arch>
</os>
</activation>
<dependencies>
<dependency>
<groupId>org.eclipse.swt.win32.win32</groupId>
<artifactId>x86</artifactId>
<version>3.3.0-v3346</version>
<optional>true</optional>
</dependency>
</dependencies>
</profile>
There's a number of other profiles missing id's as well as well, each of which cause the warning to be present.
This is easy to reproduce in Maven 2.2.9. The only cause of this is two maven profiles are defined without a profile id element in the same pom.xml, thus the ids are treated null. I don't know what the use case for such a profile is, but Maven 2.2.9 silently allows such a profile to exist, unless you try to override it of course - you get the mentioned warning.
Here is a simple pom that will reproduce the error. Notice the missing <id> element for each profile.
<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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.apache.maven.its.mngxxxx</groupId>
<artifactId>parent</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>parent</name>
<profiles>
<profile>
<activation>
<property><name>foo</name></property>
</activation>
</profile>
<profile>
<activation>
<property><name>foo</name></property>
</activation>
</profile>
</profiles>
</project>
Simply type mvn -X validate -Dfoo=true and you should see near the top of the output the warning message. This is caused by the second profile definition trying to override the first.
The relevant code in Maven 2 that emits this warning is in DefaultProfileManager.java line 123.
In Maven 3, this has changed. Using the latest maven 3.0-alpha-6 you get.
[ERROR] The build could not read 1 project -> [Help 1]
org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs:
[ERROR] profiles.profile.id must be unique but found duplicate profile with id default # org.apache.maven.its.mngxxxx:parent:1.0-SNAPSHOT, /Users/plynch/dev/apache/maven/core-integration-testing/mytests/mng-xxxx-IT/src/test/resources/mng-xxxx/pom.xml
at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:285)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:402)
at org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:351)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:171)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:104)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:422)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:157)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[ERROR] The project org.apache.maven.its.mngxxxx:parent:1.0-SNAPSHOT (/Users/plynch/dev/apache/maven/core-integration-testing/mytests/mng-xxxx-IT/src/test/resources/mng-xxxx/pom.xml) has 1 error
[ERROR] profiles.profile.id must be unique but found duplicate profile with id default
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
Notice also that the missing <id> will cause Maven 3 to apply a 'default' profile id.
Lastly in a multi-module build, should a parent pom define a profile with the same id as one in the child, there is no warning or other indication emitted from Maven.
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.
Given three POM files:
C depends on B.
B inherits from A.
I can build A and B
C fails to build because of its dependency on B.
The full source-code and build output is included below for your review.
Here is A's POM:
<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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.foo</groupId>
<artifactId>A</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<name>A</name>
<repositories>
<repository>
<id>foo releases</id>
<name>libs-releases-local</name>
<layout>default</layout>
<url>http://foo.net/artifactory/libs-releases-local</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>org.eclipse.swt</groupId>
<artifactId>swt</artifactId>
<classifier>${swt.classifier}</classifier>
<version>3.6.1</version>
</dependency>
</dependencies>
<profiles>
<profile>
<id>windows-x86</id>
<properties>
<swt.classifier>win32-x86</swt.classifier>
</properties>
</profile>
</profiles>
</project>
Here is B's POM:
<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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>com.foo</groupId>
<artifactId>A</artifactId>
<version>1.0-SNAPSHOT</version>
<relativePath>../A</relativePath>
</parent>
<artifactId>B</artifactId>
<packaging>jar</packaging>
<name>B</name>
<profiles>
<profile>
<id>windows-x86</id>
<properties>
<swt.classifier>win32-x86</swt.classifier>
</properties>
</profile>
</profiles>
</project>
Here is C's POM:
<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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.foo</groupId>
<artifactId>C</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>C</name>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>B</artifactId>
<version>${project.version}</version>
</dependency>
</dependencies>
</project>
Here is the build output from C:
------------------------------------------------------------------------
Building C
task-segment: [install]
------------------------------------------------------------------------
[compiler:compile]
Nothing to compile - all classes are up to date
Downloading: http://foo.net/artifactory/libs-releases-local/org/eclipse/swt/swt/3.6.1/swt-3.6.1-${swt.classifier}.jar
[WARNING] Unable to get resource 'org.eclipse.swt:swt:jar:${swt.classifier}:3.6.1' from repository foo releases (http://foo.net/artifactory/libs-releases-local): Error transferring file: foo.net
Downloading: http://repo1.maven.org/maven2/org/eclipse/swt/swt/3.6.1/swt-3.6.1-${swt.classifier}.jar
Unable to find resource 'org.eclipse.swt:swt:jar:${swt.classifier}:3.6.1' in repository central (http://repo1.maven.org/maven2)
------------------------------------------------------------------------
[ERROR]BUILD ERROR
------------------------------------------------------------------------
Failed to resolve artifact.
Missing:
----------
1) org.eclipse.swt:swt:jar:${swt.classifier}:3.6.1
I know this issue is related to https://issues.apache.org/jira/browse/MNG-3228 but I'm not sure how to fix it. Please help!
UPDATE:
Adding a classifier to B helped. Now C builds so long as the repository only contains B's jar file. If I upload B's POM file alongside the JAR in the repository, C fails with the aforementioned error (${swt.classifier} not defined). Any ideas?
In a comment you write, "I am expecting SWT's classifier to get resolved at B's build-time, not C's build-time", but that is wrong - you need the classifier at C's build time because C has a dependency on swt (transitive via A). That dependency is only fully-determined by a property, so you have to have a way of evaluating the property in C's pom.
A depends on swt-${classifier}
C depends on A
therefore C depends on swt-${classifier}
therefore C's pom must define the property. It can be defined by a profile (as in A), or manually at runtime (bad for reproducibility), but you can't build C without it.
It's as simple (and puzzling) as that.
If you're expecting the property to somehow get fully "resolved" along the way, and be already well-defined by the time you build C, you are not understanding how Maven treats those properties. It leaves them alone. There was an attempt to do some different stuff in Maven 2.1 (the classifier property expression would be transformed to its value when you installed A), but it was not successful, caused many surprising behaviours, it was reverted for 2.2, and in fact caused 2.1 to be quickly deprecated. For more details, and some hints as to how complicated the problem really is, see the link below.
https://cwiki.apache.org/confluence/display/MAVENOLD/Artifact-Coordinate+Expression+Transformation
Until the Maven developers decide otherwise, I think we will continue to have the behaviour that has been around since 2.0: "Expressions in artifact coordinates are ignored. Users have plenty of rope with which to hang themselves"
Once you get used to it, though, it's not confusing anymore. It's only when you're trying to second-guess Maven that you get surprised.
Maven is trying to find the artifact org.eclipse.swt:swt:3.6.1 but the coordinates aren't being resolved correctly. The error is saying that ${swt.classifier} isn't being recognized from a <properties/> block in your POM.xml. Since that value shows up in a <profile/> block, can you verify what Maven command you are running?
Try this: mvn dependency:resolve -P windows-x86
Also, verify that both the version of SWT and the Classifier are actually correct. The latest version I see on Maven Central is not 3.6.0, but 3.3.0-v3346
This isn't possible as of Maven 3.1.0. Here is the relevant feature request: https://issues.apache.org/jira/browse/MNG-1388
I know this issue is related to https://issues.apache.org/jira/browse/MNG-3228 but I'm not sure how to fix it.
I'm not sure there is a link with this issue, I don't see anything related to profile activation in the pom.xml shown above.
Actually, I'm not even sure to understand the expected result. From where is the classifier supposed to come? Maybe I'm missing some parts but I think you should install/deploy a qualified version of B (with a fully resolved POM) and have C depend on this qualified version.
How would I need to modify B's POM to deploy a qualified version? I am expecting SWT's classifier to get resolved at B's build-time, not C's build-time.
Yes but at C's build-time, C needs B and B's dependencies so the installed/deployed .pom of B has to be fully resolved. At least, that's how I think things can work.
But I must admit I'm not sure how to handle this case exactly and after reading issues like MNG-4140 or the Artifact-Coordinate Expression Transformation page, I'm totally confused.
I suggest to post this on the maven users list for the right way (and I'll follow the thread closely because I think I have some broken POMs using profiles, properties and dependencies to fix now, thanks :)
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>
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.