On Wed, Feb 23, 2011 at 11:00, Alasdair Nottingham <[email protected]> wrote: > 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 think the argument does not hold as i'll be able to install using http://repo1.maven.org/maven2/org/apache/aries/blueprint/org.apache.aries.blueprint.core/0.3/org.apache.aries.blueprint.core-0.3.jar http://repo2.maven.org/maven2/org/apache/aries/blueprint/org.apache.aries.blueprint.core/0.3/org.apache.aries.blueprint.core-0.3.jar file:deploy/org.apache.aries.blueprint.core-0.3.jar and the same problem would happen. I suppose if you put the framework in this mode you need a deployment agent smart enough to handle the deployments. > 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. That's actually my main concern too. Forcing the user to find a correct combination of bundles that work together because each of those have a different version, does not seem to go in the right direction for me. > > 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] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
