[
http://jira.codehaus.org/browse/MVERSIONS-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=224697#action_224697
]
Marcus Holl commented on MVERSIONS-112:
---------------------------------------
I found a way how we can deal with aggregator poms that are not located in the
parent folder hierachy. The call to the set mojo could be triggered inside the
folder that contains the aggregator pom. In this case it is required to provide
-DartifactId and -DgroupId with the corresponding values for the project that
should be updated. I checked it with the example attached to that thread
(dependencyupdate.zip) and it seems to work fine.
> Detection of aggragtor pom does not work when aggregator pom is not inside a
> parent directory
> ---------------------------------------------------------------------------------------------
>
> Key: MVERSIONS-112
> URL: http://jira.codehaus.org/browse/MVERSIONS-112
> Project: Maven 2.x Versions Plugin
> Issue Type: Bug
> Affects Versions: 1.2
> Environment: maven 3 beta 1
> Reporter: Marcus Holl
> Attachments: dependencyupdate.zip
>
>
> Having a look into the coding of the SetMojo inside the maven-versions-plugin
> (v1.2) I can see that the SetMojo of the maven-versions-plugin promisses to
> detect aggregator pom files. But this does not work if the aggregator pom
> files is not located in the parent directory or any parent of the parent
> directory. Apparently the behaviour is the same in trunk.
> Attached there can be found a zip file with an example that outlines the
> behaviour. There is an aggregator pom located inside a folder "aggregator".
> This pom contains a module section that defines two modules
> (../projectwithdependency, ../someproject). "projectwithdependency" defines a
> dependency to "someproject".
> The expected behaviour when we call "mvn
> org.codehaus.mojo:versions-maven-plugin:1.2:set -DnewVersion=1.0.1-SNAPSHOT"
> inside "someproject" is: the corresponding dependency inside
> "projectwithdependency" to "someproject" should be updated from
> "1.0.0-SNAPSHOT" to "1.0.1-SNAPSHOT".
> The actual behaviour is: The version inside the dependency to "someproject"
> is not updated within project "projectwithdependency".
> When the aggragator pom file is moved to the common parent directory of
> "projectwithdependency" and "someproject" alongside with the corresponding
> update regarding the location of the modules inside the modules section the
> version update inside the dependency to "someproject" in
> "projectwithdependency" does work fine.
> The location of aggregator pom files is not limited to parent directories.
> The implemented strategy searches inside parent directories. That is not
> sufficient. Since there is no better search strategy (aggregator pom files
> could be located anywhere inside the directory structure) there should be a
> parameter that specifies the aggregator pom file.
> An additional remark: Of course it needs to be checked if a externally
> provided pom file is in fact an aggregator pom for the project that should be
> updated with a new version. This check is implemented inside
> PomHelper.getLocalRoot(./.) like this: getAllChildModules( parentProject,
> logger ).contains( project.getBasedir().getName() ). The problem here when we
> deal with e.g. "../myproject" is that the contains check does not work
> anymore since the strings that are contained in the set reflects the
> directory structure rather than the name of the project base dir
> ("../myproject" vs "myproject").
> Best regards,
> Marcus
--
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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
