jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven 2.x and 3.x Deploy Plugin
  • MDEPLOY-94

Variables in the version element in pom.xml need to be expanded before deployment

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

We use an external tool to manage our releases (instead of maven-release-plugin). The version in our pom.xml is declared as:

<version>${build.number}</version>

The actual version number is passed in during a release deployment on the command line "mvn deploy -Dbuild.number=1.2.3"

The pom.xml is deployed literally without the variable replaced with the actual value. This causes problems, in particular multi-module releases are impossible since the parent pom can't be resolved properly as well as this issue with Nexus https://issues.sonatype.org/browse/NEXUS-1552

I started digging into the code and see deployment is deferred to the DefaultArtifactDeployer
http://maven.apache.org/ref/current/xref/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.html

Can I somehow install a custom ArtifactTransformation that expands these variables before deployment? How would I install it in my builds? Would I build it as a Plexus component and add it as a plugin dependency of maven-deploy-plugin? If someone could give me a little guidance I'd be happy to implement it, test it and submit a patch.

Issue Links

duplicates

Bug - A problem which impairs or prevents the functions of the product. MNG-3057 properties not expanded in generated POMs when building A/B/C nested projects

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Brian Jackson added a comment - 08/Feb/09 8:07 PM

Well I started writing a new ArtifactTransformation to handle this logic but I've hit a road block since I'm now discovering that Plexus isn't recognizing my class as an additional component when I add my project as a plugin dependency of maven-install-plugin or maven-deploy-plugin in my pom. So instead I got the source for maven-artifact-manager and tried adding it directly there. But it appears Maven loads these directly from the maven-2.0.x-uber.jar under M2_HOME instead of from the maven-artifact-manager jar from within my local m2 repository. This makes it impossible for me to test this without ripping apart the maven-2.0.x-uber.jar. Am I missing a simple way to override maven-artifact-manager?

Show
Brian Jackson added a comment - 08/Feb/09 8:07 PM Well I started writing a new ArtifactTransformation to handle this logic but I've hit a road block since I'm now discovering that Plexus isn't recognizing my class as an additional component when I add my project as a plugin dependency of maven-install-plugin or maven-deploy-plugin in my pom. So instead I got the source for maven-artifact-manager and tried adding it directly there. But it appears Maven loads these directly from the maven-2.0.x-uber.jar under M2_HOME instead of from the maven-artifact-manager jar from within my local m2 repository. This makes it impossible for me to test this without ripping apart the maven-2.0.x-uber.jar. Am I missing a simple way to override maven-artifact-manager?
Hide
Permalink
John Casey added a comment - 11/Feb/09 10:20 AM

I've added a link to MNG-3057 as this is basically the same issue. I'll take a look at how we can revisit these issues for 2.1.0 as soon as I'm done with another issue that I'm testing at the moment. You might have some luck doing what Brian proposed on the maven dev list, and prepend the path to your jar into the m2.conf file in $(maven.home)/bin.

If you have a patch that will interpolate all versions in the POM, can you post it?

Show
John Casey added a comment - 11/Feb/09 10:20 AM I've added a link to MNG-3057 as this is basically the same issue. I'll take a look at how we can revisit these issues for 2.1.0 as soon as I'm done with another issue that I'm testing at the moment. You might have some luck doing what Brian proposed on the maven dev list, and prepend the path to your jar into the m2.conf file in $(maven.home)/bin. If you have a patch that will interpolate all versions in the POM, can you post it?
Hide
Permalink
John Casey added a comment - 24/Feb/09 11:11 AM

This is a problem in the core of Maven, not in the deploy plugin. It's been resolved in MNG-3057, and will be available for use in Maven 2.1.0.

Show
John Casey added a comment - 24/Feb/09 11:11 AM This is a problem in the core of Maven, not in the deploy plugin. It's been resolved in MNG-3057, and will be available for use in Maven 2.1.0.

People

  • Assignee:
    John Casey
    Reporter:
    Brian Jackson
Vote (1)
Watch (1)

Dates

  • Created:
    06/Feb/09 11:04 PM
    Updated:
    24/Feb/09 11:11 AM
    Resolved:
    24/Feb/09 11:11 AM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.