Maven 2 & 3

Profiles ignored when working with non-projects (such as archetype:create)

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.0.9
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    3

Description

Several conditions have to be met to show this bug.

1) Be in an environment that does not have access to repo1.maven.org, (such as a corporate environment)
2) Have no content in your local repository (a fresh install of maven 2.0.4)
3) Attempt to use a plugin that has no project requirement (such as archetype:create)

The plugin fails because access to repo1.maven.org cannot be accessed.

Recommended solution:
Create a settings.xml profile that changes the location of the 'central' repository to point to an internal resource (such as a maven-proxy installation).

<settings>
<profiles>
<profile>
<id>use_internal</id>
<repositories>
<repository>
<id>central</id>
<name>Internal Central Repository</name>
<url>http://repo.internal.com/maven2</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<name>Internal Central Repository</name>
<url>http://repo.internal.com/maven2</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>

<activeProfiles>
<activeProfile>use_internal</activeProfile>
</activeProfiles>
</settings>

Try again.
Still fails.

The reason is that the default behaviour for non-project execution is to use the maven super pom, however there is a bug with that flow that does not allow for the merging of the settings.xml profiles.

Issue Links

This issue is duplicated by:
MNG-3337 Downloading plugins for an inhouse repository problem Blocker Closed
MNG-2236 DefaultMavenProjectBuilder.buildStandaloneSuperProject() should include a ProfileManager that includes active profiles from settings.xml Major Closed
MNG-1928 ignores pluginRepository in settings.xml, honors in POM Major Closed
MNG-2716 pluginRepositories seems to be ignored when running a goal without pom.xml Major Closed
MNG-3235 Profiles in settings.xml not loaded when running maven without a POM Major Closed
MNG-2918 Active-by-default profiles from settings.xml are not active without pom.xml Major Closed
This issue relates to:
ARCHETYPE-66 The archetype:create goal ignores activated profiles in local settings.xml Major Closed
ARCHETYPE-59 archetype plugin doesn't use private plugin repository configured in <MAVEN-HOME>/conf/settings.xml Major Closed
ARCHETYPE-89 archetypeng:create doesn't use configured repos to find artifacts Major Closed
MNG-4109 When running a plugin, project builder does not pick up settings profiles Major Closed
MNG-4246 plugin resolution failures during pom-less execution (like archetype:generate) Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Joakim Erdfelt added a comment -

Patch against maven-core and maven-project in ..
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x
Revision: 398684

Show
Joakim Erdfelt added a comment - Patch against maven-core and maven-project in .. https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x Revision: 398684
Hide
Permalink
Carlos Sanchez added a comment -

Updated patch agains trunk

Tests don't pass after applying the patch

Show
Carlos Sanchez added a comment - Updated patch agains trunk Tests don't pass after applying the patch
Hide
Permalink
John Casey added a comment -

I found that a similar piece of code already exists in the trunk, written by mkleint in revId 415000. I'm trying to lift that piece instead, for consistency's sake. If that works, I'll add some unit tests and call it good.

At a basic level, all we need to do is verify that the superPOM, when loaded standalone, is injected with existing properties from active profiles. We should be able to work up a much more elemental unit test to give this a try, and then come back around to the type of test explained above for one more level of verification.

Show
John Casey added a comment - I found that a similar piece of code already exists in the trunk, written by mkleint in revId 415000. I'm trying to lift that piece instead, for consistency's sake. If that works, I'll add some unit tests and call it good. At a basic level, all we need to do is verify that the superPOM, when loaded standalone, is injected with existing properties from active profiles. We should be able to work up a much more elemental unit test to give this a try, and then come back around to the type of test explained above for one more level of verification.
Hide
Permalink
John Casey added a comment -

Unit test applied to trunk that will verify that repositories and properties injected into the standalone superPOM via profile are available in the project instance.

Also, merged the changes to implementation and unit test into the 2.0.x branch, and verified that all ITs which are active still run.

Show
John Casey added a comment - Unit test applied to trunk that will verify that repositories and properties injected into the standalone superPOM via profile are available in the project instance. Also, merged the changes to implementation and unit test into the 2.0.x branch, and verified that all ITs which are active still run.
Hide
Permalink
Bulent Erdemir added a comment -

Hi,

I checked out the trunk, compiled, assembled and installed. And tried to execute archetype:create but it still won't honor the global settings.xml file. Am I missing something ?

Note: When I compiled and assembled, maven-2.0.6-SNAPSHOT-bin.zip is created and I used this for testing.

Does any one has any comments on this ?

Bulent Erdemir

Show
Bulent Erdemir added a comment - Hi, I checked out the trunk, compiled, assembled and installed. And tried to execute archetype:create but it still won't honor the global settings.xml file. Am I missing something ? Note: When I compiled and assembled, maven-2.0.6-SNAPSHOT-bin.zip is created and I used this for testing. Does any one has any comments on this ? Bulent Erdemir
Hide
Permalink
Jason Melnick added a comment -

This bug needs to be reopened as it still does not work

Show
Jason Melnick added a comment - This bug needs to be reopened as it still does not work
Hide
Permalink
Wendy Smoak added a comment -

Reopening based on comments and ARCHETYPE-66.

Show
Wendy Smoak added a comment - Reopening based on comments and ARCHETYPE-66.
Hide
Permalink
Wendy Smoak added a comment -

Workaround: mvn ... -f /path/to/simple.pom

and "simple.pom" contains the following:

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.example</groupId>
<artifactId>MNG-2261-workaround</artifactId>
<packaging>pom</packaging>
<version>1</version>
</project>

If there is "a project" involved, Maven will use the profiles and repositories in settings.xml

For archetype:create, you don't want a pom.xml in the current directory or the plugin will add a <module> to it and hook it up as the newly created project's parent, so use the -f switch to point it at a file somewhere else.

For other things such as deploy:deploy-file, having a pom.xml file in the current directory works fine. (If you're actually deploying a pom with -DpomFile=..., then name that one something else, or just use -f as above.)

Related thread: http://www.nabble.com/Maven-ignoring-Artifactory-proxy-settings--t3397576s177.html

Show
Wendy Smoak added a comment - Workaround: mvn ... -f /path/to/simple.pom and "simple.pom" contains the following: <project> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>MNG-2261-workaround</artifactId> <packaging>pom</packaging> <version>1</version> </project> If there is "a project" involved, Maven will use the profiles and repositories in settings.xml For archetype:create, you don't want a pom.xml in the current directory or the plugin will add a <module> to it and hook it up as the newly created project's parent, so use the -f switch to point it at a file somewhere else. For other things such as deploy:deploy-file, having a pom.xml file in the current directory works fine. (If you're actually deploying a pom with -DpomFile=..., then name that one something else, or just use -f as above.) Related thread: http://www.nabble.com/Maven-ignoring-Artifactory-proxy-settings--t3397576s177.html
Hide
Permalink
Jason van Zyl added a comment -

The archetype problem is really something similar to the staging plugin problem where the wagons being setup aren't getting populated with repository, proxy, or authentication information from the settings.xml. Each of these plugins does it's own thing which is the problem. We need a base class for all these things to use. Or a utilitity. Making a note.

Show
Jason van Zyl added a comment - The archetype problem is really something similar to the staging plugin problem where the wagons being setup aren't getting populated with repository, proxy, or authentication information from the settings.xml. Each of these plugins does it's own thing which is the problem. We need a base class for all these things to use. Or a utilitity. Making a note.
Hide
Permalink
Jason van Zyl added a comment -

After looking the code this is definitlely archetype specific and specific to any mojo using resolution capabilties that are not done in the same way that Maven does it. If you look up the artifact resolver, or downloader, without initializings the WagonManager then there will be no meshing of the settings.xml. I'll make a more general issue for this.

Show
Jason van Zyl added a comment - After looking the code this is definitlely archetype specific and specific to any mojo using resolution capabilties that are not done in the same way that Maven does it. If you look up the artifact resolver, or downloader, without initializings the WagonManager then there will be no meshing of the settings.xml. I'll make a more general issue for this.
Hide
Permalink
Joakim Erdfelt added a comment -

This is not archetype specific.

The problem outlined here occurs for any non-project plugin that accesses the repository system.
This problem also exists in the stage:copy plugin.

Show
Joakim Erdfelt added a comment - This is not archetype specific. The problem outlined here occurs for any non-project plugin that accesses the repository system. This problem also exists in the stage:copy plugin.
Hide
Permalink
Joakim Erdfelt added a comment -

This is not archetype specific.

This occurs with the maven-eclipse-plugin too.

Show
Joakim Erdfelt added a comment - This is not archetype specific. This occurs with the maven-eclipse-plugin too.
Hide
Permalink
Joakim Erdfelt added a comment -

When working in limited environments, NONE of the $HOME/conf/settings.xml or the $HOME/.m2/settings.xml values are merged.
This is important when working with custom repositories for example.

Show
Joakim Erdfelt added a comment - When working in limited environments, NONE of the $HOME/conf/settings.xml or the $HOME/.m2/settings.xml values are merged. This is important when working with custom repositories for example.
Hide
Permalink
William Ferguson added a comment - - edited

Invoking a Mojo that doesn't require a project (ie @requiresProject false in your Mojo) doesn't load the Profiles defined in LOCAL_HOME settings or MAVEN_HOME settings.

In an effort to make this issue as explicit as possible, I have attached Plugin-showing-MNG3099.zip

It contains a plugin project (with a Mojo conigured with @requiresProject false) and local and global settings files.

Put the local and global settings files in the normal place and build and install the plugin.

Then from the plugin project folder execute:

D:\Modules\maven-test-plugin>mvn com.yarris.maven.plugins:maven-test-plugin:profile-props
[INFO] Scanning for projects...
[INFO] snapshot com.yarris.maven.plugins:maven-test-plugin:1.0-SNAPSHOT: checking for updates from snapshot
[INFO] ----------------------------------------------------------------------------
[INFO] Building maven-test-plugin
[INFO] task-segment: [com.yarris.maven.plugins:maven-test-plugin:profile-props] (aggregator-style)
[INFO] ----------------------------------------------------------------------------
[INFO] [test:profile-props]
[INFO] local-profile-prop=local-profile-prop-value
[INFO] global-profile-prop=global-profile-prop-value
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Thu Sep 13 15:47:18 EST 2007
[INFO] Final Memory: 2M/4M
[INFO] ------------------------------------------------------------------------

Note that the local-profile-prop and global-profile-prop have resolved to the expected values.

Now execute:

D:\Modules\maven-test-plugin>mvn com.yarris.maven.plugins:maven-test-plugin:profile-props -f no-pom.xml
[INFO] Scanning for projects...
[INFO] ----------------------------------------------------------------------------
[INFO] Building Maven Default Project
[INFO] task-segment: [com.yarris.maven.plugins:maven-test-plugin:profile-props] (aggregator-style)
[INFO] ----------------------------------------------------------------------------
[INFO] [test:profile-props]
[INFO] local-profile-prop=null
[INFO] global-profile-prop=null
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Thu Sep 13 15:48:56 EST 2007
[INFO] Final Memory: 2M/4M
[INFO] ------------------------------------------------------------------------

Note how local-profile-prop and global-profile-prop no longer have values.

As has been noted the most common example of this is archetype:create which requires the remote repository to be explicitly provided on the command line via the remoteRepositories System property if you are pulling an archetype from somewhere other than central. Eg

mvn archetype:create -DgroupId=com.yarris -DartifactId=foo-project -DarchetypeGroupId=com.yarris.maven.archetype \
  -DarchetypeArtifactId=archetype-standard -DremoteRepositories=http://somewhere.com.au:8080/proximity/repository/release

It should be possible to define an active Profile in either local or global settings.xml that defines a remote repository, and have the archetype pulled from that repository.

It should also be possible to refer to a property provided by an active Profile
But it occurs for any Mojo that does not require a project.

Show
William Ferguson added a comment - - edited Invoking a Mojo that doesn't require a project (ie @requiresProject false in your Mojo) doesn't load the Profiles defined in LOCAL_HOME settings or MAVEN_HOME settings. In an effort to make this issue as explicit as possible, I have attached Plugin-showing-MNG3099.zip It contains a plugin project (with a Mojo conigured with @requiresProject false) and local and global settings files. Put the local and global settings files in the normal place and build and install the plugin. Then from the plugin project folder execute:
D:\Modules\maven-test-plugin>mvn com.yarris.maven.plugins:maven-test-plugin:profile-props [INFO] Scanning for projects... [INFO] snapshot com.yarris.maven.plugins:maven-test-plugin:1.0-SNAPSHOT: checking for updates from snapshot [INFO] ---------------------------------------------------------------------------- [INFO] Building maven-test-plugin [INFO] task-segment: [com.yarris.maven.plugins:maven-test-plugin:profile-props] (aggregator-style) [INFO] ---------------------------------------------------------------------------- [INFO] [test:profile-props] [INFO] local-profile-prop=local-profile-prop-value [INFO] global-profile-prop=global-profile-prop-value [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1 second [INFO] Finished at: Thu Sep 13 15:47:18 EST 2007 [INFO] Final Memory: 2M/4M [INFO] ------------------------------------------------------------------------
Note that the local-profile-prop and global-profile-prop have resolved to the expected values. Now execute:
D:\Modules\maven-test-plugin>mvn com.yarris.maven.plugins:maven-test-plugin:profile-props -f no-pom.xml [INFO] Scanning for projects... [INFO] ---------------------------------------------------------------------------- [INFO] Building Maven Default Project [INFO] task-segment: [com.yarris.maven.plugins:maven-test-plugin:profile-props] (aggregator-style) [INFO] ---------------------------------------------------------------------------- [INFO] [test:profile-props] [INFO] local-profile-prop=null [INFO] global-profile-prop=null [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1 second [INFO] Finished at: Thu Sep 13 15:48:56 EST 2007 [INFO] Final Memory: 2M/4M [INFO] ------------------------------------------------------------------------
Note how local-profile-prop and global-profile-prop no longer have values. As has been noted the most common example of this is archetype:create which requires the remote repository to be explicitly provided on the command line via the remoteRepositories System property if you are pulling an archetype from somewhere other than central. Eg 
mvn archetype:create -DgroupId=com.yarris -DartifactId=foo-project -DarchetypeGroupId=com.yarris.maven.archetype \
  -DarchetypeArtifactId=archetype-standard -DremoteRepositories=http://somewhere.com.au:8080/proximity/repository/release
It should be possible to define an active Profile in either local or global settings.xml that defines a remote repository, and have the archetype pulled from that repository. It should also be possible to refer to a property provided by an active Profile But it occurs for any Mojo that does not require a project.
Hide
Permalink
John Casey added a comment -

should be fixed in revIds:

618391
618393

Show
John Casey added a comment - should be fixed in revIds: 618391 618393

People

Vote (27)
Watch (22)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.