You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by zoe slattery <zo...@gmail.com> on 2011/02/13 15:14:21 UTC
[SUMMARY][DISCUSS] Release process
I believe we are ruling out the middle way (release by module) as it
presents too many challenges, both in making existing tools work,
avoiding releasing the same thing twice in a sub-module and just being
hard to understand. This leaves us, as Guillaume suggested originally,
with a choice between what we have now (a single release) and some sort
of release-by-bundle scheme.
Releasing by bundle, with the correct semantic versioning, still
presents a number of issues. I suggest that the next step is that I
create another branch and attempt to devise an optimum SVN layout and
process for release by bundles. This would still be purely experimental
but it would give us something concrete to compare with the current process.
I have summarised the issues that I believe you have raised below:
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.
[1]
http://www.osgi.org/wiki/uploads/CommunityEvent2010/OSGi%20Community%202010%20-%20Brada.pdf
What size bundles?
===========
OSGi good practice (Graham) indicates separating the API from
implementation. This argues in favour of keeping the bundles as we have
them now. Alasdair also supported this view.
Consumability.
=========
Consumers need (at least) two things:
1) For each "module" what is the set of bundles (names and versions)
that I need to implement some functionality? Eg - if I want to implement
a blueprint service what do I need from Aries? How can I get them
without doing multiple manual downloads?
2) What is the most recent complete set of released Aries bundles that
has been tested together with a released, documented, set of the
samples? Not being able to run the samples is the 3rd most irritating
thing when looking at OS projects (no build instructions, and not being
able to build from source are the first two). It's also true that the
blog sample is a good catch-all test, in the past it has caught problems
that get by other tests.
3) To avoid conflicts in dependencies. Guillaume raised this as a
problem - but I believe that Alasdair addressed it in terms of using
OSGi to avoid conflicts. Correct me if this is still an issue.
Branching
======
I don't think there is any way to combine semantic versioning and SVN
branching in a fool proof manner. That is, if a bundle has been released
at version 1.0.1 and again at 1.0.2 there is no 'OSGi blessed' way to
release a bundle that fixes a single bug in 1.0.1. This situation may of
course never happen in Aries, but surely it is a general concern? If so,
has someone raised it with the Alliance?
Zoe
Re: [SUMMARY][DISCUSS] Release process
Posted by Alasdair Nottingham <no...@apache.org>.
On 13 February 2011 14:14, zoe slattery <zo...@gmail.com> wrote:
> I believe we are ruling out the middle way (release by module) as it
> presents too many challenges, both in making existing tools work, avoiding
> releasing the same thing twice in a sub-module and just being hard to
> understand. This leaves us, as Guillaume suggested originally, with a choice
> between what we have now (a single release) and some sort of
> release-by-bundle scheme.
>
> Releasing by bundle, with the correct semantic versioning, still presents a
> number of issues. I suggest that the next step is that I create another
> branch and attempt to devise an optimum SVN layout and process for release
> by bundles. This would still be purely experimental but it would give us
> something concrete to compare with the current process.
>
> I have summarised the issues that I believe you have raised below:
>
>
> 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.
>
> [1]
> http://www.osgi.org/wiki/uploads/CommunityEvent2010/OSGi%20Community%202010%20-%20Brada.pdf
>
>
> What size bundles?
> ===========
>
> OSGi good practice (Graham) indicates separating the API from
> implementation. This argues in favour of keeping the bundles as we have them
> now. Alasdair also supported this view.
>
>
> Consumability.
> =========
> Consumers need (at least) two things:
>
> 1) For each "module" what is the set of bundles (names and versions) that I
> need to implement some functionality? Eg - if I want to implement a
> blueprint service what do I need from Aries? How can I get them without
> doing multiple manual downloads?
>
> 2) What is the most recent complete set of released Aries bundles that has
> been tested together with a released, documented, set of the samples? Not
> being able to run the samples is the 3rd most irritating thing when looking
> at OS projects (no build instructions, and not being able to build from
> source are the first two). It's also true that the blog sample is a good
> catch-all test, in the past it has caught problems that get by other tests.
>
> 3) To avoid conflicts in dependencies. Guillaume raised this as a problem -
> but I believe that Alasdair addressed it in terms of using OSGi to avoid
> conflicts. Correct me if this is still an issue.
>
>
> Branching
> ======
>
> I don't think there is any way to combine semantic versioning and SVN
> branching in a fool proof manner. That is, if a bundle has been released at
> version 1.0.1 and again at 1.0.2 there is no 'OSGi blessed' way to release a
> bundle that fixes a single bug in 1.0.1. This situation may of course never
> happen in Aries, but surely it is a general concern? If so, has someone
> raised it with the Alliance?
>
I do not agree that we need, or want to support releasing a single bug
fix to 1.0.1 that isn't in
1.0.2. I think when someone asks for a release with a bug they should
get the latest level in that
major minor stream with the additional bug fixes and we should update
the micro.
> Zoe
>
>
>
--
Alasdair Nottingham
not@apache.org
Re: [SUMMARY][DISCUSS] Release process
Posted by Alasdair Nottingham <no...@apache.org>.
On 14 February 2011 07:32, Guillaume Nodet <gn...@gmail.com> wrote:
> On Sun, Feb 13, 2011 at 15:14, zoe slattery <zo...@gmail.com> wrote:
>> I believe we are ruling out the middle way (release by module) as it
>> presents too many challenges, both in making existing tools work, avoiding
>> releasing the same thing twice in a sub-module and just being hard to
>> understand. This leaves us, as Guillaume suggested originally, with a choice
>> between what we have now (a single release) and some sort of
>> release-by-bundle scheme.
>>
>> Releasing by bundle, with the correct semantic versioning, still presents a
>> number of issues. I suggest that the next step is that I create another
>> branch and attempt to devise an optimum SVN layout and process for release
>> by bundles. This would still be purely experimental but it would give us
>> something concrete to compare with the current process.
>>
>> I have summarised the issues that I believe you have raised below:
>>
>>
>> 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.
>
While this is possible I think it is majorly sucky. When you have a bundle:
a.b.c-.0.4.jar it isn't clear what level of bundle you have unless you crack it
open and look at the manifest. I would not be in favour of this.
>>
>> [1]
>> http://www.osgi.org/wiki/uploads/CommunityEvent2010/OSGi%20Community%202010%20-%20Brada.pdf
>>
>>
>> What size bundles?
>> ===========
>>
>> OSGi good practice (Graham) indicates separating the API from
>> implementation. This argues in favour of keeping the bundles as we have them
>> now. Alasdair also supported this view.
>>
>>
>> Consumability.
>> =========
>> Consumers need (at least) two things:
>>
>> 1) For each "module" what is the set of bundles (names and versions) that I
>> need to implement some functionality? Eg - if I want to implement a
>> blueprint service what do I need from Aries? How can I get them without
>> doing multiple manual downloads?
>>
>> 2) What is the most recent complete set of released Aries bundles that has
>> been tested together with a released, documented, set of the samples? Not
>> being able to run the samples is the 3rd most irritating thing when looking
>> at OS projects (no build instructions, and not being able to build from
>> source are the first two). It's also true that the blog sample is a good
>> catch-all test, in the past it has caught problems that get by other tests.
>>
>> 3) To avoid conflicts in dependencies. Guillaume raised this as a problem -
>> but I believe that Alasdair addressed it in terms of using OSGi to avoid
>> conflicts. Correct me if this is still an issue.
>
> Those were not really addressed with maven, but I agree this is an
> edge case issue that we can put aside.
>
>>
>>
>> Branching
>> ======
>>
>> I don't think there is any way to combine semantic versioning and SVN
>> branching in a fool proof manner. That is, if a bundle has been released at
>> version 1.0.1 and again at 1.0.2 there is no 'OSGi blessed' way to release a
>> bundle that fixes a single bug in 1.0.1. This situation may of course never
>> happen in Aries, but surely it is a general concern? If so, has someone
>> raised it with the Alliance?
>
> Imho we should look at that the other way around. 1.0.2 should mean
> that his is a bug fix release over 1.0.1, which in turns mean that any
> change which is not a bug should lead to a minor version bump. I
> don't think this is really in contradiction with the semantic
> versioning, it's more about what you consider "backward compatible".
> There is the java method signatures and classes which obviously play a
> role in backward compatibility, but any other kind of change can
> impact such a compatiblity too.
>
In terms of the API I disagree, we should not push an API minor, or
major, version
up unless we have to within the rules of semantic versioning. When it comes to
the bundle version I am prepared to be a little more flexible in my
staunch view.
If we aded a new blueprint namespace to our blueprint implementation, or amended
an existing one this, in my view, would be a minor version update even
though we don't
change the API. I think this is a case by case basis though. I do not
think we should
just bump the minor version for no particularly good reason.
>>
>> Zoe
>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: [SUMMARY][DISCUSS] Release process
Posted by zoe slattery <zo...@gmail.com>.
....PS
>
> 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
It looks as though the release plugin _should_ cope with different
SNAPSHOT versions, so I may have been wrong when I said it didn't. I'm
going to spend more time looking at that.
> release plugin to work for us than dissociate the Bundle-Version from
> the artifact version.
>
Zoe
Re: [SUMMARY][DISCUSS] Release process
Posted by zoe slattery <zo...@gmail.com>.
On 23/02/2011 09:08, Guillaume Nodet wrote:
> Well, I'd argue than in a lot of those jars, the package version is
> also the same as the bundle version.
Many do, but as you say not all. However, I think that is a slightly
different point.
> 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<zo...@gmail.com> 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<gn...@gmail.com> wrote:
>>>> On Tue, Feb 22, 2011 at 14:14, zoe slattery<zo...@gmail.com>
>>>> 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
>>>>
>>>
>>
>
>
Re: [SUMMARY][DISCUSS] Release process
Posted by Jeremy Hughes <hu...@apache.org>.
On 23 February 2011 10:19, Guillaume Nodet <gn...@gmail.com> wrote:
> On Wed, Feb 23, 2011 at 11:00, Alasdair Nottingham <no...@apache.org> 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.
To solve the problem of indicating to the user what works together we
could create an Aries distribution a zip of all the bundles that we've
tested work together. We'd have bundle releases and distribution
releases. Each bundle could be released fairly independently of each
other. (Clearly if an API bundle has a minor version change then the
impl bundle will need to be released at the same time). The
distribution can be released independently of bundles. Using a a
distribution release (we can finesse the name), users get the most
confidence that bundles work together. Using individual bundle
releases on top, things should still work but there's no statement
that we've tested the combination of bundles / bundle versions that
they have.
Jeremy
Re: [SUMMARY][DISCUSS] Release process
Posted by Alasdair Nottingham <no...@apache.org>.
On 23 February 2011 11:10, Guillaume Nodet <gn...@gmail.com> wrote:
> On Wed, Feb 23, 2011 at 11:49, Alasdair Nottingham <no...@apache.org> wrote:
>> On 23 February 2011 10:19, Guillaume Nodet <gn...@gmail.com> wrote:
>>> On Wed, Feb 23, 2011 at 11:00, Alasdair Nottingham <no...@apache.org> 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 <gn...@gmail.com> 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 <zo...@gmail.com> 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<gn...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On Tue, Feb 22, 2011 at 14:14, zoe slattery<zo...@gmail.com>
>>>>>>>> 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
>>>> not@apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: [SUMMARY][DISCUSS] Release process
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Feb 23, 2011 at 11:49, Alasdair Nottingham <no...@apache.org> wrote:
> On 23 February 2011 10:19, Guillaume Nodet <gn...@gmail.com> wrote:
>> On Wed, Feb 23, 2011 at 11:00, Alasdair Nottingham <no...@apache.org> 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 <gn...@gmail.com> 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 <zo...@gmail.com> 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<gn...@gmail.com> wrote:
>>>>>>>
>>>>>>> On Tue, Feb 22, 2011 at 14:14, zoe slattery<zo...@gmail.com>
>>>>>>> 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
>>> not@apache.org
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [SUMMARY][DISCUSS] Release process
Posted by Alasdair Nottingham <no...@apache.org>.
On 23 February 2011 10:19, Guillaume Nodet <gn...@gmail.com> wrote:
> On Wed, Feb 23, 2011 at 11:00, Alasdair Nottingham <no...@apache.org> 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. 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.
>> 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.
>>
>> Alasdair
>>
>> On 23 February 2011 09:08, Guillaume Nodet <gn...@gmail.com> 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 <zo...@gmail.com> 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<gn...@gmail.com> wrote:
>>>>>>
>>>>>> On Tue, Feb 22, 2011 at 14:14, zoe slattery<zo...@gmail.com>
>>>>>> 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
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: [SUMMARY][DISCUSS] Release process
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Feb 23, 2011 at 11:00, Alasdair Nottingham <no...@apache.org> 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 <gn...@gmail.com> 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 <zo...@gmail.com> 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<gn...@gmail.com> wrote:
>>>>>
>>>>> On Tue, Feb 22, 2011 at 14:14, zoe slattery<zo...@gmail.com>
>>>>> 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
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [SUMMARY][DISCUSS] Release process
Posted by Alasdair Nottingham <no...@apache.org>.
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 <gn...@gmail.com> 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 <zo...@gmail.com> 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<gn...@gmail.com> wrote:
>>>>
>>>> On Tue, Feb 22, 2011 at 14:14, zoe slattery<zo...@gmail.com>
>>>> 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
not@apache.org
Re: [SUMMARY][DISCUSS] Release process
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <zo...@gmail.com> 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<gn...@gmail.com> wrote:
>>>
>>> On Tue, Feb 22, 2011 at 14:14, zoe slattery<zo...@gmail.com>
>>> 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
Re: [SUMMARY][DISCUSS] Release process
Posted by zoe slattery <zo...@gmail.com>.
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<gn...@gmail.com> wrote:
>> On Tue, Feb 22, 2011 at 14:14, zoe slattery<zo...@gmail.com> 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
>>
>
>
Re: [SUMMARY][DISCUSS] Release process
Posted by Guillaume Nodet <gn...@gmail.com>.
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)
On Tue, Feb 22, 2011 at 14:35, Guillaume Nodet <gn...@gmail.com> wrote:
> On Tue, Feb 22, 2011 at 14:14, zoe slattery <zo...@gmail.com> 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
Re: [SUMMARY][DISCUSS] Release process
Posted by Guillaume Nodet <gn...@gmail.com>.
On Tue, Feb 22, 2011 at 14:14, zoe slattery <zo...@gmail.com> 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
Re: [SUMMARY][DISCUSS] Release process
Posted by zoe slattery <zo...@gmail.com>.
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?
Zoe
Re: [SUMMARY][DISCUSS] Release process
Posted by Guillaume Nodet <gn...@gmail.com>.
On Sun, Feb 13, 2011 at 15:14, zoe slattery <zo...@gmail.com> wrote:
> I believe we are ruling out the middle way (release by module) as it
> presents too many challenges, both in making existing tools work, avoiding
> releasing the same thing twice in a sub-module and just being hard to
> understand. This leaves us, as Guillaume suggested originally, with a choice
> between what we have now (a single release) and some sort of
> release-by-bundle scheme.
>
> Releasing by bundle, with the correct semantic versioning, still presents a
> number of issues. I suggest that the next step is that I create another
> branch and attempt to devise an optimum SVN layout and process for release
> by bundles. This would still be purely experimental but it would give us
> something concrete to compare with the current process.
>
> I have summarised the issues that I believe you have raised below:
>
>
> 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.
>
> [1]
> http://www.osgi.org/wiki/uploads/CommunityEvent2010/OSGi%20Community%202010%20-%20Brada.pdf
>
>
> What size bundles?
> ===========
>
> OSGi good practice (Graham) indicates separating the API from
> implementation. This argues in favour of keeping the bundles as we have them
> now. Alasdair also supported this view.
>
>
> Consumability.
> =========
> Consumers need (at least) two things:
>
> 1) For each "module" what is the set of bundles (names and versions) that I
> need to implement some functionality? Eg - if I want to implement a
> blueprint service what do I need from Aries? How can I get them without
> doing multiple manual downloads?
>
> 2) What is the most recent complete set of released Aries bundles that has
> been tested together with a released, documented, set of the samples? Not
> being able to run the samples is the 3rd most irritating thing when looking
> at OS projects (no build instructions, and not being able to build from
> source are the first two). It's also true that the blog sample is a good
> catch-all test, in the past it has caught problems that get by other tests.
>
> 3) To avoid conflicts in dependencies. Guillaume raised this as a problem -
> but I believe that Alasdair addressed it in terms of using OSGi to avoid
> conflicts. Correct me if this is still an issue.
Those were not really addressed with maven, but I agree this is an
edge case issue that we can put aside.
>
>
> Branching
> ======
>
> I don't think there is any way to combine semantic versioning and SVN
> branching in a fool proof manner. That is, if a bundle has been released at
> version 1.0.1 and again at 1.0.2 there is no 'OSGi blessed' way to release a
> bundle that fixes a single bug in 1.0.1. This situation may of course never
> happen in Aries, but surely it is a general concern? If so, has someone
> raised it with the Alliance?
Imho we should look at that the other way around. 1.0.2 should mean
that his is a bug fix release over 1.0.1, which in turns mean that any
change which is not a bug should lead to a minor version bump. I
don't think this is really in contradiction with the semantic
versioning, it's more about what you consider "backward compatible".
There is the java method signatures and classes which obviously play a
role in backward compatibility, but any other kind of change can
impact such a compatiblity too.
>
> Zoe
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com