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
