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
