Zoe, Thanks for doing this great piece of work, and presenting the options so well.
Personally, I feel, as an enterprise OSGi programming model project, we need to be practicing what OSGi preaches. If there are problems associated with that, then it would be good if we could feed that back into OSGi, or try to fix/improve the processes. We're not the only ones to be going down this path. There are well-documented reasons why separating API from implementation is generally a good thing. If we can preserve that, I think it would be great. Granted, this results in more modules, which will complicate the release process and perhaps make management harder. Zoe mentioned 'profiles'. Maybe there are roll-up distributions we could build targeted at different types of consumer (e.g. full aries, blueprint, application, etc). I'd like to think we could also address the uber-bundle use case with distributions and subsystem (a little raw at the moment), as we've discussed in the past. I think the semantic versioning tool that Zoe was referring to is described in this presentation: http://www.osgi.org/wiki/uploads/CommunityEvent2010/OSGi%20Community%202010%20-%20Brada.pdf . It's described as "prototype", but that was a little while ago and it might be worth a try. Just my 2 pence. Regards, Graham. On 10 February 2011 07:20, Guillaume Nodet <[email protected]> wrote: > On Wed, Feb 9, 2011 at 21:06, zoe slattery <[email protected]> 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 > transaction-blueprint. > 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 > blueprint-bundle. > > 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<[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 >
