maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Bernstein (JIRA)" <>
Subject [jira] Updated: (MRELEASE-178) Release prepare fails to update version information for ejb-client dependencies
Date Fri, 17 Nov 2006 14:14:31 GMT
     [ ]

Eric Bernstein updated MRELEASE-178:

    Attachment: MRELEASE-178-similar-deps.patch

I finally did find my way around the unit test setup and put together a patch and a unit test
to validate it.  The patch is for the maven-release-manager in maven-shared rather than under
the plugin itself (I couldn't find a separate project to put a release-manager bug under).
I'm fairly comfortable with this patch - it's basically just dropping the assumption that
a given pom has only one dependency with a given groupId and artifactId.  For the average
case, it should work exactly as it always had.  

> Release prepare fails to update version information for ejb-client dependencies
> -------------------------------------------------------------------------------
>                 Key: MRELEASE-178
>                 URL:
>             Project: Maven 2.x Release Plugin
>          Issue Type: Bug
>    Affects Versions: 2.0-beta-4
>            Reporter: Eric Bernstein
>         Attachments: MRELEASE-178-similar-deps.patch
> If you use the dependency management section of a parent pom to include sub-poms of the
same project, the release plugin will update the version number for those projects as part
of the prepare phase. 
> Unfortunately, if you have two dependencies with the same groupId and artifactId (as
is the case with generated ejb-clients) prepare will just update one of them.  
> I believe the problem in the code is in AbstractRewritePomsPhase.updateDomVersion.  The
code currently uses an xpath expression matching on groupId and artifactId and then calls
xpath.getSingleNode to find the object to update.  This will leave out one of the dependencies
(either ejb or ejb-client).  
> I'm having a little trouble writing a unit test for this (hence no patch upload), but
if I could do that, I believe the fix would either be looping over the elements returned from
the xpath expression, or altering the xpath expression (and the rest of the artifact handling
- read: bigger change) to be more explicit about what artifacts it's looking at (including
type, classifier, etc...).  

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message