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. #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. #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
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 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) 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. 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. 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 > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
