On 22/02/2011 13:46, Guillaume Nodet wrote:
I forgot to explain how it helps imho:
* a single release per component (less jira work, less release
notes, less work overall for the RM), ability to use the maven release
plugin
* easier to consume for users (you just grab all bundles with the
same version), less documentation to write about compatiblity between
bundles
* does not remove any osgi semantic at the package or bundle level
* easier for svn layout (we can have a trunk/tags/branches per
component and we'd have a nice mapping between releases / svn layout
which is also git friendly)
Thanks - I get the point now. I'm still worried about it though, I don't
think there is anything that says we _can't_ have a version in the
artifact name that is different from the Bundle-Version. However, I
think it is a very widely used convention. Just to check this I compared
the Bundle-Version with the artifact name for the following:
asm-all-3.2.jar
cm-3.2.0-v20070116.jar
commons-collections-3.2.1.jar
commons-lang-2.5.jar
commons-pool-1.5.4.jar
geronimo-j2ee-connector_1.5_spec-2.0.0.jar
geronimo-jpa_2.0_spec-1.1.jar
geronimo-jta_1.1_spec-1.1.1.jar
geronimo-servlet_2.5_spec-1.2.jar
geronimo-transaction-2.1.3.jar
openjpa-2.0.0.jar
org.apache.felix.bundlerepository-1.6.4.jar
org.apache.felix.fileinstall-3.1.4.jar
org.apache.servicemix.bundles.serp-1.13.1_2.jar
osgi-3.5.0.v20090520.jar
pax-logging-api-1.4.jar
pax-logging-service-1.4.jar
pax-web-extender-war-0.8.1.jar
pax-web-jetty-bundle-0.8.1.jar
pax-web-jsp-0.8.1.jar
services-3.1.200-v20070605.jar
In every case the Bundle-Version matches the version string in the jar
name. I am worried about breaking widely used conventions because I have
no idea where people might have code that relies on them, so for this
reason, if we go the 'release-by-module' route I'd rather find a way to
modify the maven release plugin to work for us than dissociate the
Bundle-Version from the artifact version.
Zoe
On Tue, Feb 22, 2011 at 14:35, Guillaume Nodet<[email protected]> wrote:
On Tue, Feb 22, 2011 at 14:14, zoe slattery<[email protected]> wrote:
Hi Guillaume
How to version a bundle?
===============
There is a tool [1] but it's a prototype and will not always do what we
need. Guillaume said "Theproblem is that there are cases where a purely
semantic change (i.e. you change a service implementation in an
incompatible
way without changing the API) can't be find by such a tool, as it can
only
work at the API (class / method) level I think." Graham agreed and said
that
we would need a way to manually specify a version. I believe Jeremy has
asked about the state of the tool on the dev@ace list.
Guillaume is also right to point out that a released version of a bundle
doesn't have to be the same as the version in development. So, a bundle
version 1.0.1 could be released from a development stream at
0.4.0-SNAPSHOT.
In fact, I believe it would be necessary to use this because one cannot
be
certain of the correct release version until development has finished and
the code can be compared with the previous release.
That's not exactly what I meant. What i meant is that even for a
release, the maven version does not have to be the same than the
Bundle-Version header, so we could have a bundle blueprint-core-0.4.0
with a Bundle-Version of 1.0.1. The same way we de-correlate the
package version and the bundle version, we could de-correlate the
maven version and the bundle version.
This is true but I must be missing something because I don't understand how
it helps us.
To use your example, I think we could release:
- blueprint-core-0.4.0.jar
- blueprint-core-0.3.0.jar
and both could have a Bundle-Version of 1.0.1
So, we would release exactly the same code twice (but called something
different). I thought we wanted to avoid releasing the same thing twice?
What would happen if someone accidentally installed these two bundles in the
same framework believing them to have different content?
Am I missing the point somehow?
Yes, the consequence of not releasing per-bundle is necessarily to
allow the same code to be released with two different versions. But
in itself that's not really a drawback.
Now if you want to install two bundles that have the same
symbolic-name and version, the osgi framework will throw an error per
the osgi specs. Is that really a problem ? I'm not sure it is.
The first question is why would you want to have those two bundles in
the same container ? I think you'd rather want to update 0.3.0 with
0.4.0 in which case it should not be a problem.
I think the point is that users can easily install a component by
choosing all the bundles with the same version and you know which
bundles work together at a glance. If you want to go into details,
you can always look at the osgi metadata.
Zoe
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
