On Wed, Feb 23, 2011 at 11:49, Alasdair Nottingham <[email protected]> wrote: > On 23 February 2011 10:19, Guillaume Nodet <[email protected]> wrote: >> 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 disagree. I don't think people will generally install directly from > maven like that and I think people that do will > know that those two things are the same.
Interesting. How will you tell aries users to install aries ? > I would be more concerned > about someone getting blueprint 0.8 and > application 0.6 and ending up with two utils with different pom > version which are the same thing. In short I > think the following is a real problem: > > http://repo2.maven.org/maven2/org/apache/aries/blueprint/org.apache.aries.blueprint.core/0.6/org.apache.aries.blueprint.core-0.6.jar > http://repo2.maven.org/maven2/org/apache/aries/blueprint/org.apache.aries.blueprint.core/0.8/org.apache.aries.blueprint.core-0.8.jar > > if internally they both have a Bundle-Version of 0.5. There is no way > someone can know this and they > are very likely to believe the content of these two is different. Even > worse in this case is getting two > BlueprintExtenders will cause all kinds of complications. Not sure to understand. if they use a tool to do the provisioning, the tool could be smart enough to look at the osgi metadata. Something like OBR will not really care about the bundle location for example. I'd like know the proportion of users that will rebuild their system and update the whole thing at once vs deploy individual bundles. Even when deploying, it might very well be the case that people will want to stop all applications, update all bundles, refresh and restart everything. And for those scenarios, having a single version across multiple bundles reduces the amount of work. Even when for a simple example as Karaf, if we need to worry about 5 different versions when we want to upgrade blueprint, it *is* a pain. So I don't even imagine for people that are somewhat new to OSGi. Another point which strikes me, is when/how/why would anyone run/release the integration tests and examples... And with which version of each bundle do you run those ? For example I fix a bug in blueprint-core and I release it, that may very well have an effect on blueprint-cm, but the release process is not really able to catch the problem as the blueprint integration tests won't be run at all. >>> 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. >> > > I think we need to find a solution that doesn't rely on the way we > release things. > As an example application relies on blueprint, blueprint relies on proxy and > if > we rely on release by module to say "these things work together" we are only > addressing a very small part of the problem, that of having a consistent set > of > blueprint-api, blueprint-core and blueprint-cm. I don't see how it > helps ensure they > have the right util, proxy, and so on. Well, I think it helps, but I'm not opposed to any other solution, but I haven't heard much so far. > >>> >>> 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 >> > > > > -- > Alasdair Nottingham > [email protected] > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
