On 23 February 2011 11:10, Guillaume Nodet <[email protected]> wrote:
> 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 ?
What I mean is that I don't think people will go
BundleContext.install("ttp://repo2.maven.org/maven2/org/apache/aries/blueprint/org.apache.aries.blueprint.core/0.3/org.apache.aries.blueprint.core-0.3.jar")
I think people will download things to their local machine.
>
>> 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.
>
Isn't this something we should do when we do release voting? I thought based
on experience people do run tests and so on, even tests that are not a part of
any itests, like does it work in karaf or geronimo. In which case shouldn't we
just continue to do this?
>>>> 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.
>
I think that is because we have been focusing on a "release management" process
rather than looking at what we should do in documentation etc.
Alasdair
>
>>
>>>>
>>>> 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
>
--
Alasdair Nottingham
[email protected]
