Carsten Ziegeler wrote:
Ralph Goers wrote:
It uses the relative path so you will need the parent also.
Hmm, I'm not sure if this is a good idea :) as it permits building a
module standalone.
For Cocoon we have the dream (tm) to have separate
buildable/deployable modules one day.
Carsten
If you can think of a way to have it both ways let me know.
In the Maven issue (http://jira.codehaus.org/browse/MNG-624) the
suggestion was made to use a variable. I'm not a big fan of that if it
requires the variable always be set via -D or in the users settings.xml.
Too much room to get it wrong. Using the version in the pom at the
relative path you are sure to always get it right.
The way my patch is right now if you specified MavenParentVersion as the
version and it couldn't find the parent pom an exception would get
thrown more or less as if a version wasn't specified. I suppose instead
of throwing the exception it could try to find the pom some other way,
but what?
I have a feeling that if the way Cocoon's blocks parent pom was changed
than what I'm suggesting would be easy. If the parent pom was in
cocoon-blocks-parent instead of being the aggregation pom this would be
a lot easier to deal with as you would only need the Cocoon parent
project and the block parent project to create your block.
Ralph
