[ http://jira.codehaus.org/browse/MRELEASE-178?page=all ]
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: http://jira.codehaus.org/browse/MRELEASE-178
> 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:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
