[ http://jira.codehaus.org/browse/MRELEASE-151?page=comments#action_72602 ] John Casey commented on MRELEASE-151: -------------------------------------
FWIW, it might be helpful to know how you arrived at the conclusion that the release plugin expects all modules to have the same parent. What symptoms are you seeing? > All child modules are forced to share the same parent POM > --------------------------------------------------------- > > Key: MRELEASE-151 > URL: http://jira.codehaus.org/browse/MRELEASE-151 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Affects Versions: 2.0-beta-4 > Environment: Windows XP > Reporter: James Carpenter > Priority: Blocker > > Problem Description: > Assume the following layout: > fooProject/pom.xml > fooProject/dotnet1/pom.xml (has parent pom of maven-csharp-master-parent) > fooProject/dotnet2/pom.xml (has parent pom of maven-csharp-master-parent) > fooProject/dotnet3/pom.xml (has parent pom of maven-csharp-master-parent) > fooProject/java1/pom.xml (has parent pom found above it ../pom.xml) > fooProject/java2/pom.xml (has parent pom found above it ../pom.xml) > fooProject/java3/pom.xml (has parent pom of > maven-fancy-framework-master-parent) > Assume fooProject/pom.xml lists dotnet1, dotnet2, dotnet3, java1, and java2 > in the modules section. Furthemore, assume that the dotnet modules all refer > to a parent pom of maven-csharp-master-parent rather than refering to the pom > shown at fooProject/pom.xml. By changing into the fooProject directory one > can successfully run mvn clean, and mvn install without any problems. > Unfortunately, the maven release plugin has problems because it seems to > expect all of the child poms to refer to the parent above them. > Motivation: > Any time a child pom needs a bunch of custom plugin's configured, its always > nice to inherit the setup from a parent pom. As it turns out, modules which > should naturally be released and packaged together occassionally need to be > configured quite differently. This is certainly the case whenever dotnet > code is co-released with java code. The dotnet code requires a significant > number of custom plugins be setup for any arbitrary csharp build. It > therefore makes a lot of sense to have a maven-csharp-master-parent to take > care of this. These csharp related configurations are inappropriate for a > java build. In my case the java code happens to be a maven plugin which is > executing the csharp code from a sister module (equivalent in example above > would be for a plugin in fooProject/java1 to be executing code from > fooProject/dotnet3. > Although the motivating example above describes the issue in terms of java > and dotnet build interactions, its not at all unreasonable to think one might > have java code requiring lots of plugins (say cactus configuration, etc) > which would be inappropriate for sister modules. Required differences in > plugin configuration should not impose any constraints on which modules are > considered to be released/packaged together. Maven doesn't impose any such > constraint, but the release plugin is. > Progress So Far: > I havn't taken the time to dig around in the release plugin and figure out > how to fix this. Currently, I am just manually performing what the release > plugin would normally do for me. -- 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
