[
https://issues.apache.org/jira/browse/JCLOUDS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306319#comment-14306319
]
Andrew Phillips commented on JCLOUDS-104:
-----------------------------------------
> The jclouds-labs-openstack repo can be used as a model to apply the changes.
>From my perspective, the main goal here is to ensure that running a release
>does not require manual input. Based on the release log for 1.8.0 [1], the
>setup in jclouds-labs-openstack still results in Maven asking questions about
>resolving SNAPSHOT deps.
As long as we can avoid that, I'm fine. As far as I can see (again, based on
the log), it's only jclouds-karaf and jclouds-cli (which use
{{jclouds.version}}) which meet this criterion at the moment.
[1]
https://docs.google.com/document/d/10LkAD8Wk5Kcj38nQghTW-bQdCOXaxZad5W5Chu6HUCA/edit#heading=h.rkdy3ww6v0w6
> 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: Zack Shoylev
> Attachments: JCLOUDS-104-cli.patch
>
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
