aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [DISCUSS] Release process
Date Thu, 10 Feb 2011 07:20:06 GMT
On Wed, Feb 9, 2011 at 21:06, zoe slattery <> wrote:
> On 09/02/2011 19:26, Guillaume Nodet wrote:
>> In "Disadvantages of the release by module process" :
>> #1 what do you imply here ? We can't release the same bundle with the
>> exact same version I think. This would mean we'd have to at least
>> change the micro version or the qualifier (but preferably the micro
>> version), even if the content hasn't changed.
> That's a good question. I can't actually find any ruling that says that we
> can't release the same thing twice, so it would come down to a view about
> whether it was better to release the same thing twice with the same name, or
> the same thing twice with a different name.

Maven central will refuse to deploy if one tries to upload another
copy of the same artifact / version afaik.
Also a release, once voted should be immutable imho.

>> #3 I guess you made some tests in your branch. so mavne can't cope
>> with blueprint-core 1.0.1-SNAPSHOT and blueprint-cm 1.0.3-SNAPSHOT in
>> the same build. Or rather, maven can, but the release plugin can't,
>> right ?  If so and if that can't be easily change, it kinda forbid
>> this option imho.
> Yes - that's what I was doing in the branch. And personally I agree with
> your conclusion.
>> #4 i think this is a consequence of applying the semantic versioning
>> at the bundle level and I don't see any nice way to solve that
> Indeed.
>> In the "Disadvantages of releasing by bundle"
>> #2 svn: Sling uses a single tree, which makes branching very difficult
>> #3: i think if we apply at the package level the rule we talked about,
>> i.e. each change which is not a pure bug fix lead to a minor version
>> bump (from 1.3.2 to 1.4.0 for example), this would reflect at the
>> bundle level, so it should be possible to maintain correct branches
>> per bundle
> That would help, but there is a lot of personal judgement in making that
> decision. I wonder if we should look at the versioning
> tooling in Ace (I think Felix (?) posted a link to it earlier). I read a bit
> about it but have not actually tried it.

Yes, we can't have any hard rule on that, though we could see it in a
different way.  Any change that does not ugrade the minor version
should be backported to all previous branches.  I think it's closer to
the usual development model, but lead to the same conclusion.

Not sure what you're referring to for the tooling.  Any pointer ?

>> I'd add:
>>  #4 there is no way to ensure a coherent (meaning to artifact is
>> needed twice) set of bundles is sufficient (granted OSGi can easily
>> cope with that, but it's kind ugly, and from a maven perspective, very
>> difficult to deal with as maven does not allow having two dependencies
>> with different versions in the same build)
> I'm not totally sure that I understand you here. Do you mean 'a set of
> bundles that we know all work together', like for example the blueprint
> bundles?
> If so, I had thought about maybe having something like a 'profile' -
> basically a pom which would assemble a set of bundles and their source (?)
> so a user would just download the pom.xml and run it to assemble something
> like what we release in the Blueprint (for example) module.

Let's say we have blueprint-core depends on utils [1,2) and
transaction-blueprint depends on utils [2,3) at some point in time.
There's no way to have maven capture such dependencies if you build
something that depends on both blueprint-core and
It's also much less convenient for users when you need to know what to install.

>> If the release by bundle would be favored, I wonder if we should
>> follow more closely the felix model, where usually a bundle has very
>> few dependencies, i.e. it embeds the API (export + import pacakge) and
>> the implementation.  This would have the following advantages:
>>   # we'd roughly combine "release per component" and "release per bundle"
>>   # all disadvantages listed in "release per bundle" would go away
>>   # we'd still have all the advantages of "release per bundle" and
>> "release per module"
>> The release process would be much simplier, consumption much simplier too.
> It's a thought. Do you really mean that we would abandon everything except
> the uber-bundles? Or have I misunderstood?

That's a suggestion yes.  It's a granularity problem.  The finer we
go, the more work we'll have.  The question is: what's the benefit of
finer bundles and to which level we want to go.    That would help
hiding internal APIs too (for example most of the packages in
blueprint-core should not be exposed ideally).

>> Another way, if we don't want to keep a clean organization in several
>> maven projects, would be to have each maven project generate a jar,
>> and only put the metadata on the bundle for the whole component.
> Again, not sure that I understand, could you give an example?

The fact we'd keep osgi metadata only for uber-bundles does not
necessarily mean that we'd have to drop our svn layout and the way
maven modules are created.
For example, we would have to combine all blueprint maven projects in
a single one, but only to not create osgi metadata but for the

It's really just a thought, I'm sure there would be drawbacks in doing that too.

> Thanks for the feedback.
> Zoe
>> On Wed, Feb 9, 2011 at 19:55, Guillaume Nodet<>  wrote:
>>> Fair point.  I missed that quote, which doesn't seem to imply that
>>> require bundle is far from a best practice ...
>>> On Wed, Feb 9, 2011 at 19:45, zoe slattery<>
>>>  wrote:
>>>> Hi
>>>>> Throughout the web page, you refer to "semantic versioning of
>>>>> bundles", but afaik, there's no such thing.
>>>> This is a quote from the OSGi semantic versioning white paper:
>>>> "Requiring another bundle is similar to a short form of importing all
>>>> the
>>>> exported packages of that required bundle. The version of a bundle must
>>>> therefore semantically aggregate the semantics of all its constituent
>>>> packages. If any of these packages is incompatible with its providers
>>>> then
>>>> the bundle version must increment the minor version. If any of these
>>>> packages is incompatible with consumers, the bundle version must
>>>> increment
>>>> the major version. It is clear, that on average, the version of a bundle
>>>> will be much more volatile than the versions of its constituent
>>>> packages,
>>>> increasing the dependency problems."
>>>> This indicated to me that bundles are semantically versioned.
>>>> Zoe
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog:
>>> ------------------------
>>> Open Source SOA

Guillaume Nodet
Open Source SOA

View raw message