Hi, I want to +1 on Zoe's concern here. I also have a few more observations:
In OSGi 4.3 you can install the same bundle multiple times, i.e. I can have a bundle with symbolic name a.b.c and version 1 and I can install it 20 times assuming the location is different. In this situation having multiple jars containing a.b.c at version 1 would not produce an error, and would be a problem in my view. I personally think most people who use aries will want the pre-built binaries, rather than the source zips, so I think we should be focusing on making that easy to do and I don't think that requires us to release in this way. Alasdair On 23 February 2011 09:08, Guillaume Nodet <[email protected]> wrote: > Well, I'd argue than in a lot of those jars, the package version is > also the same as the bundle version. But I agree it's not a widely > used scheme and it definitly only makes sense with a release-by-module > policy. > > On Wed, Feb 23, 2011 at 09:51, zoe slattery <[email protected]> wrote: >> On 22/02/2011 13:46, Guillaume Nodet wrote: >>> >>> I forgot to explain how it helps imho: >>> * a single release per component (less jira work, less release >>> notes, less work overall for the RM), ability to use the maven release >>> plugin >>> * easier to consume for users (you just grab all bundles with the >>> same version), less documentation to write about compatiblity between >>> bundles >>> * does not remove any osgi semantic at the package or bundle level >>> * easier for svn layout (we can have a trunk/tags/branches per >>> component and we'd have a nice mapping between releases / svn layout >>> which is also git friendly) >> >> Thanks - I get the point now. I'm still worried about it though, I don't >> think there is anything that says we _can't_ have a version in the artifact >> name that is different from the Bundle-Version. However, I think it is a >> very widely used convention. Just to check this I compared the >> Bundle-Version with the artifact name for the following: >> >> asm-all-3.2.jar >> cm-3.2.0-v20070116.jar >> commons-collections-3.2.1.jar >> commons-lang-2.5.jar >> commons-pool-1.5.4.jar >> geronimo-j2ee-connector_1.5_spec-2.0.0.jar >> geronimo-jpa_2.0_spec-1.1.jar >> geronimo-jta_1.1_spec-1.1.1.jar >> geronimo-servlet_2.5_spec-1.2.jar >> geronimo-transaction-2.1.3.jar >> openjpa-2.0.0.jar >> org.apache.felix.bundlerepository-1.6.4.jar >> org.apache.felix.fileinstall-3.1.4.jar >> org.apache.servicemix.bundles.serp-1.13.1_2.jar >> osgi-3.5.0.v20090520.jar >> pax-logging-api-1.4.jar >> pax-logging-service-1.4.jar >> pax-web-extender-war-0.8.1.jar >> pax-web-jetty-bundle-0.8.1.jar >> pax-web-jsp-0.8.1.jar >> services-3.1.200-v20070605.jar >> >> In every case the Bundle-Version matches the version string in the jar name. >> I am worried about breaking widely used conventions because I have no idea >> where people might have code that relies on them, so for this reason, if we >> go the 'release-by-module' route I'd rather find a way to modify the maven >> release plugin to work for us than dissociate the Bundle-Version from the >> artifact version. >> >> Zoe >>> >>> On Tue, Feb 22, 2011 at 14:35, Guillaume Nodet<[email protected]> wrote: >>>> >>>> On Tue, Feb 22, 2011 at 14:14, zoe slattery<[email protected]> >>>> wrote: >>>>> >>>>> Hi Guillaume >>>>>>> >>>>>>> How to version a bundle? >>>>>>> =============== >>>>>>> >>>>>>> There is a tool [1] but it's a prototype and will not always do what >>>>>>> we >>>>>>> need. Guillaume said "Theproblem 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." Graham agreed and >>>>>>> said >>>>>>> that >>>>>>> we would need a way to manually specify a version. I believe Jeremy >>>>>>> has >>>>>>> asked about the state of the tool on the dev@ace list. >>>>>>> >>>>>>> Guillaume is also right to point out that a released version of a >>>>>>> bundle >>>>>>> doesn't have to be the same as the version in development. So, a >>>>>>> bundle >>>>>>> version 1.0.1 could be released from a development stream at >>>>>>> 0.4.0-SNAPSHOT. >>>>>>> In fact, I believe it would be necessary to use this because one >>>>>>> cannot >>>>>>> be >>>>>>> certain of the correct release version until development has finished >>>>>>> and >>>>>>> the code can be compared with the previous release. >>>>>> >>>>>> That's not exactly what I meant. What i meant is that even for a >>>>>> release, the maven version does not have to be the same than the >>>>>> Bundle-Version header, so we could have a bundle blueprint-core-0.4.0 >>>>>> with a Bundle-Version of 1.0.1. The same way we de-correlate the >>>>>> package version and the bundle version, we could de-correlate the >>>>>> maven version and the bundle version. >>>>> >>>>> This is true but I must be missing something because I don't understand >>>>> how >>>>> it helps us. >>>>> To use your example, I think we could release: >>>>> >>>>> - blueprint-core-0.4.0.jar >>>>> - blueprint-core-0.3.0.jar >>>>> >>>>> and both could have a Bundle-Version of 1.0.1 >>>>> >>>>> So, we would release exactly the same code twice (but called something >>>>> different). I thought we wanted to avoid releasing the same thing twice? >>>>> What would happen if someone accidentally installed these two bundles in >>>>> the >>>>> same framework believing them to have different content? >>>>> >>>>> Am I missing the point somehow? >>>> >>>> Yes, the consequence of not releasing per-bundle is necessarily to >>>> allow the same code to be released with two different versions. But >>>> in itself that's not really a drawback. >>>> Now if you want to install two bundles that have the same >>>> symbolic-name and version, the osgi framework will throw an error per >>>> the osgi specs. Is that really a problem ? I'm not sure it is. >>>> The first question is why would you want to have those two bundles in >>>> the same container ? I think you'd rather want to update 0.3.0 with >>>> 0.4.0 in which case it should not be a problem. >>>> >>>> I think the point is that users can easily install a component by >>>> choosing all the bundles with the same version and you know which >>>> bundles work together at a glance. If you want to go into details, >>>> you can always look at the osgi metadata. >>>> >>>>> 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 > -- Alasdair Nottingham [email protected]
