[
https://issues.apache.org/jira/browse/JCLOUDS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723974#comment-13723974
]
Andrew Phillips edited comment on JCLOUDS-104 at 7/30/13 3:46 PM:
------------------------------------------------------------------
> However I am still a bit unclear on removing (or not) the version from the
> child projects.
[~zack-s]: Just to take a step back and explain my understanding of the
fundamental requirements for the project setup:
* during development, the dependent project (labs/cli/karaf) will have a
snapshot version and will inherit from *the same* snapshot version of
jclouds-project
* it is not necessary for the snapshot version of the dependent project to be
different
* it must be possible to release the dependent project so that it inherits from
a release version of jclouds-project
* the release version of the dependent project can be the same as, but may also
need to be different from, the release version of jclouds-project (e.g. a fix
release for the dependent project)
* for a release of the dependent project, the versions of "core" dependencies
must match the version of jclouds-project
* all the modules of the dependent project will have the same release version.
It is not necessary for individual module versions to differ
https://github.com/jclouds/jclouds-cli/pull/14 is based on these assumptions:
* during development, the dependent project inherits the snapshot version of
jclouds-project
* during release, the Maven release plugin prompts for the version of
jclouds-project *independently of* the release version for the dependent
project. This allows the dependent project to have a different release version.
* during release, the Maven release plugin also prompts for the versions of
"core" dependencies. This allows the core dependency versions to match the
jclouds-project version
This works for CLI. For other projects, OSGi exports could still present a
problem, since they need to import the correct version of the "core"
dependencies, which can differ from the version of the dependent project. So
${project.parent.version} will not work, as that points to the version of the
*dependent* project.
Hope this helps!
was (Author: andrewp):
> However I am still a bit unclear on removing (or not) the version from
the child projects.
[~zack-s]: Just to take a step back and explain my understanding of the
fundamental requirements for the project setup:
* during development, the dependent project (labs/cli/karaf) will have a
snapshot version and will inherit from *the same* snapshot version of
jclouds-project
* it is not necessary for the snapshot version of the dependent project to be
different
* it must be possible to release the dependent project so that it inherits from
a release version of jclouds-project
* the release version of the dependent project can be the same as, but may also
need to be different from, the release version of jclouds-project (e.g. a fix
release for the dependent project)
* for a release of the dependent project, the versions of "core" dependencies
must match the version of jclouds-project
* all the modules of the dependent project will have the same release version.
It is not necessary for individual module versions to differ
https://github.com/jclouds/jclouds-cli/pull/14 is based on these assumptions:
* during development, the dependent project inherits the snapshot version of
jclouds-project
* during release, the Maven release plugin prompts for the version of
jclouds-project *independently of* the release version for the dependent
project. This allows the dependent project to have a different release version.
* during release, the Maven release plugin also prompts for the versions of
"core" dependencies. This allows the core dependency versions to match the
jclouds-project version
This works for CLI. For other projects, OSGi exports could still present a
problem, since they need to import the correct version of the "core"
dependencies, which can differ from the version of the dependent project. So
{{${project.parent.version}}) will not work, as that points to the version of
the *dependent* project.
Hope this helps!
> 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
> 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
