[
https://issues.apache.org/jira/browse/JCLOUDS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13670629#comment-13670629
]
Andrew Bayer commented on JCLOUDS-104:
--------------------------------------
Maven nuttiness, basically. The first module to get built by Maven is always
going to be the parent (whether that's separate from the top-level or not). If
your top-level POM doesn't actually do anything itself, that's perfectly fine.
But if it actually does anything (like assemblies or aggregate javadocs, most
notably), then things get weird - since it's running before any of the child
modules, if it's trying to get at their artifacts (as it would need to for
assemblies or aggregate javadocs), it'll actually pull them from the local
Maven repo (falling back to remote repos). This means that the first time you
try to do assemblies or aggregate javadocs with a new version when the
top-level POM is also the parent POM, the build will fail, because there aren't
any artifacts for the child modules with the new versions yet.
But if the parent and top-level POMs are split, then the parent POM (which just
has things to inherit, like properties, dependency versions, plugin
configuration, etc) will build first, followed by the child modules, and then
finally at the end the top-level POM. That means that assemblies/aggregate
javadocs in the top-level POM work fine, because they run after all the child
modules have built their new versions.
There's no single standard for how to lay this stuff out, but in my experience
as a build guy, separating parent and top-level POMs is a very, very good idea,
at least once you have to worry about things like assemblies/javadocs, as we
do.
> Change labs/cli/karaf to have their own parent POMs separate from the
> top-level POM
> -----------------------------------------------------------------------------------
>
> Key: JCLOUDS-104
> URL: https://issues.apache.org/jira/browse/JCLOUDS-104
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-cli, jclouds-karaf, jclouds-labs,
> jclouds-labs-aws, jclouds-labs-google, jclouds-labs-openstack
> Reporter: Andrew Bayer
> Assignee: Andrew Bayer
> Fix For: 1.7.0, 1.5.11, 1.6.2
>
>
> Currently, jclouds and jclouds-chef each have a parent POM,
> (repo)/project/pom.xml, which all the other POMs, including the top-level
> POM, in the project inherit from. jclouds-labs*, jclouds-cli and
> jclouds-karaf all just have the top-level POM, and everything else inherits
> from that top-level POM. That makes some processes (like aggregate javadoc
> and assemblies) done in the top-level POM a bit problematic for the first
> build of a new version (i.e., in releases). It'd be nice if these projects
> separated out the parent and top-level POM functionality as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira