That makes me think that we don't necessarily have to tie the maven version to the Bundle-Version, which would remove the problem Zoe mentioned with the release plugin. So we could release per component (i.e. a bunch of bundles together), where all bundles would have a maven version of 0.4.0, but the Bundle-Version would evolve separately.
The bundle semantic versioning service is actually open source, so we could integrate it into maven-bundle-plugin (or anywhere else). The problem is that there are cases where a purely semantic change (i.e. you change a service implementation in an incompatible way without changing the API) can't be find by such a tool, as it can only work at the API (class / method) level I think. On Fri, Feb 11, 2011 at 11:55, Graham Charters <[email protected]> wrote: > 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 >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
