You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Eric Bernstein (JIRA)" <ji...@codehaus.org> on 2006/11/17 00:18:31 UTC
[jira] Created: (MRELEASE-178) Release prepare fails to update
version information for ejb-client dependencies
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
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
[jira] Updated: (MRELEASE-178) Release prepare fails to update
version information for ejb-client dependencies
Posted by "Emmanuel Venisse (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRELEASE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Venisse updated MRELEASE-178:
--------------------------------------
Assignee: Emmanuel Venisse
Fix Version/s: 2.0-beta-6
> 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
> Assignee: Emmanuel Venisse
> Fix For: 2.0-beta-6
>
> Attachments: MRELEASE-178-similar-deps.patch, MRELEASE-178-similar-deps_rev_535938.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
[jira] Commented: (MRELEASE-178) Release prepare fails to update
version information for ejb-client dependencies
Posted by "Eric Bernstein (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRELEASE-178?page=comments#action_82199 ]
Eric Bernstein commented on MRELEASE-178:
-----------------------------------------
Jason, any chance of this getting included in 2.0-beta-5? Currently, I'm maintaining my own branch of the code for my company to use. I'd love to drop our release plugin in favor of the official one when 2.0-beta-5 is released.
> 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
[jira] Closed: (MRELEASE-178) Release prepare fails to update
version information for ejb-client dependencies
Posted by "Emmanuel Venisse (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MRELEASE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Emmanuel Venisse closed MRELEASE-178.
-------------------------------------
Resolution: Fixed
Fixed. I didn't apply patches 1 or 2 but a mix of them because both was wrong.
> 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
> Assignee: Emmanuel Venisse
> Fix For: 2.0-beta-6
>
> Attachments: MRELEASE-178-similar-deps.patch, MRELEASE-178-similar-deps_rev_535938.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
[jira] Updated: (MRELEASE-178) Release prepare fails to update
version information for ejb-client dependencies
Posted by "Eric Bernstein (JIRA)" <ji...@codehaus.org>.
[ 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