aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <>
Subject Re: [DISCUSSION] Using packageinfo to set package versions
Date Tue, 08 Feb 2011 10:59:16 GMT

Am Sonntag, den 06.02.2011, 16:42 +0000 schrieb zoe slattery: 
> Hi
> > Yes, each bundle has its own change log because each bundle release has
> > its own Version identifier in JIRA. But we collect similar bundles into
> > bigger compoinents. For example all scripting related bundles (api,
> > core, scripting language support) are under the same "Scripting"
> > component.
> Sling is an interesting model. The essential difference between what you 
> do and what we currently do in Aries is that our bundles are grouped in 
> modules and that the module is the thing that we release. If we stay 
> with this we either need to accept that we may well release exactly the 
> same thing twice (or more) under different names  or find a way to 
> release the bundles that have changed when we release the module. To do 
> this,  after a release (say 0.3), the module version changes to 
> 0.4-SNAPSHOT but it's internal dependencies (sub modules) should all be 
> on released artifacts. The sub-modules would need to be commented out of 
> the module's pom. When a change is required in the sub-module it's 
> version has to change to A.B.C-SNAPSHOT and the it has to be listed as a 
> module in the parent modules pom again.

I think one of the ties that you have is that your module poms are both
parent poms and reactor poms. In my experience in a modular development
environment this poses a lot of problems, which is why we (Sling but
also our company internal projects) clearly separate  between parent POM
and reactor POM.

In your quiesce case, this would given the following structure:

    +--> pom.xml (reactor only)
    +--> parent
           +--> pom.xml  <-+
    +--> api               |
           +--> pom.xml  --+
    +--> manager           |
           +--> pom.xml  --+
    +--> manager-itest     |
           +--> pom.xml  --+

And in the parent POM we only use dependency management for a small
select number of dependencies and have full dependencies in each pom.

Its maybe harder to setup but pays off later -- and we don't update
dependencies on each release.


> This is rather ugly, but it does work - see this pom.xml for quiecse 

> This means that we'd never increase a bundle version artificially and 
> when we came to release (say) quiesce we would not re-release the same 
> code with a different name. The release process still gives you all the 
> source for the whole quiesce module - which I suppose is OK.
> >
> >

View raw message