Maven 2 & 3

Variable substition not performed in transitive dependency using value from active profile

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 3.0-alpha-1
  • Fix Version/s: Issues to be reviewed for 3.x
  • Component/s: Dependencies
  • Labels:
    None
  • Environment:
    Java version: 1.6.0_07
    OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
  • Complexity:
    Intermediate
  • Number of attachments :
    5

Description

When invoking the 'mvn compile' command and a profile is active, defined in settings.xml, a variable substitution is not performed in a transitive dependency.

In the example provided the project to be built, C, depends on B which in its turn depends on A. The versions of B and A to be used are defined in a profile, the POM-files defines a variable indicating the versions. The profile in question is defined in the settings.xml and is always active (check with command 'mvn help:active-profiles'). The results of project A and B are successfully built and installed in the local repository.

Invoking a build for project C using a command line parameter indicating, 'mvn compile -Dparentversion=0.0.1-SNAPSHOT, the versions render a successful build. The transitive dependency is resolved correctly.

This problem is also visible in Eclipse, m2eclipse, as the project C in the example provided, does not build (error indication). The example provided includes Eclipse projects displaying this (version 0.9.7.20081001-2217 of the Eclipse plugin is used).

The settings.xml and a build log are provided as attachments to this issue.

Issue Links

This issue is duplicated by:
MNG-4989 Properties defined in settings.xml not being passed to dependent project dependency classifiers Major Closed
This issue relates to:
MNG-4369 Maven does not expand expressions while installing artifacts locally Major Closed
MNG-3057 properties not expanded in generated POMs when building A/B/C nested projects Major Closed
MNG-624 automatic parent versioning Blocker In Progress
This issue is related to:
MNG-4148 Apply profiles from settings.xml to POMs built from the repository Major Reopened

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Robert Varttinen added a comment - - edited

The uploaded file (MavenCli.java) has an altered version of MavenCli, it has a piece of code added to a section of the main(...) method. The "patch" passed the properties of an active profile to the system properties. Thus, in our case, we get a variable substitution performed accordingly. This can, however, also be performed by passing the properties in question using the '-D..' option on the command line. This might be a problem though when invoked from an automatic build tool.

Show
Robert Varttinen added a comment - - edited The uploaded file (MavenCli.java) has an altered version of MavenCli, it has a piece of code added to a section of the main(...) method. The "patch" passed the properties of an active profile to the system properties. Thus, in our case, we get a variable substitution performed accordingly. This can, however, also be performed by passing the properties in question using the '-D..' option on the command line. This might be a problem though when invoked from an automatic build tool.
Hide
Permalink
Robert Varttinen added a comment - - edited

Attaching a patch (MyEclipseArtifactResolver.zip), addition, to m2eclipse that performs the desired result. This alteration of the code is a bit more complicated and involves two classes:

  • MavenProjectManagerImpl, pointing out MyEclipseArtifactResolver for instantiation instead of EclipseArtifactResolver
  • MyEclipseArtifactResolver with an additional method doing the variable substation prior to resolving the artifact in question.

Please keep in mind that the solution in m2eclispe we have presented works for substituting variables appearing in group- or artifactId and version of an artifact to be resolved. It is not as generic as the Maven CLI patch. For us in our current project it works fine as we are about work with POM:s with variables in version fields. Somebody taking a look at this might very well find a much better, and more generic, way of doing substitution.

Show
Robert Varttinen added a comment - - edited Attaching a patch (MyEclipseArtifactResolver.zip), addition, to m2eclipse that performs the desired result. This alteration of the code is a bit more complicated and involves two classes:
  • MavenProjectManagerImpl, pointing out MyEclipseArtifactResolver for instantiation instead of EclipseArtifactResolver
  • MyEclipseArtifactResolver with an additional method doing the variable substation prior to resolving the artifact in question.
Please keep in mind that the solution in m2eclispe we have presented works for substituting variables appearing in group- or artifactId and version of an artifact to be resolved. It is not as generic as the Maven CLI patch. For us in our current project it works fine as we are about work with POM:s with variables in version fields. Somebody taking a look at this might very well find a much better, and more generic, way of doing substitution.
Hide
Permalink
Brett Porter added a comment -

profiles are currently not working completely in the version embedded in eclipse

Show
Brett Porter added a comment - profiles are currently not working completely in the version embedded in eclipse
Hide
Permalink
Jason van Zyl added a comment -

I don't think this is even a good idea. Beyond your project, or reactor, influencing variable interpolation in transitive projects is probably not something we want to allow.

Show
Jason van Zyl added a comment - I don't think this is even a good idea. Beyond your project, or reactor, influencing variable interpolation in transitive projects is probably not something we want to allow.
Hide
Permalink
Brett Porter added a comment -

agreed - I've regularly recommended not to use properties to affect values inside a dependency for this reason, and even in 2.0.x they work inconsistently.

Show
Brett Porter added a comment - agreed - I've regularly recommended not to use properties to affect values inside a dependency for this reason, and even in 2.0.x they work inconsistently.

People

Vote (11)
Watch (6)

Dates

  • Created:
    Updated:
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.