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.
#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.
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.
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?
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?
Thanks for the feedback.
Zoe
On Wed, Feb 9, 2011 at 19:55, Guillaume Nodet<[email protected]> 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<[email protected]> 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: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
