[
http://jira.codehaus.org/browse/MVERSIONS-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223777#action_223777
]
Marcus Holl commented on MVERSIONS-112:
---------------------------------------
I contacted our managers in the meantime. We will not spent any time now to
improve the behaviour here regarding aggregator POM detection since there are
known "workarounds", e.g. putting aggregator POM somewhere inside the parent
folders. But nota bene: the point as it is valid. There is no spec that
requires aggregator POMs beeing located in the parent folder hierachy.
Best regards,
Marcus
> 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
