Rajini Sivaram wrote:
Following on from the discussion on OSGi-enabling third party libraries (
http://markmail.org/message/snltdk2yovr6maq5), this thread addresses the
options for versioning Tuscany bundles and 3rd party libraries distributed
with Tuscany and the implications of choosing these options. I have put
together some notes on the wiki (
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Versioning)
There were two outstanding questions from Simon Nash in the previous
discussion which I will summarize here to ensure that they are not lost in
this discussion.
1. Why can't we generate import constraints which will suit all
applications?
2. *I'm concerned by the assumption here that Tuscany's versions of 3rd
party bundles will be used both by Tuscany and by applications. An
application may be using other software as well as Tuscany, and this other
software may include its own versions of bundles for javax.servlet or jaxb.
If Tuscany requires its versions of these bundles to be used, and the other
software requires its versions to be used, this requires the application
developer to understand how to resolve any conflicts.*
The answer to 1) relates to how broad (or narrow) version ranges in imports
are. Broad ranges prevent isolation and reduce scope for side-by-side
execution, narrow ranges prevent class sharing and upgrading to newer
versions. There is more detail with examples on the wiki.
Question 2) is addressed first on the wiki (Figure 1 and Figure 2 show these
scenarios). I would personally like to follow OSGi best practice and enable
maximum sharing. There are some cases where we have no choice but to share
(eg. SDO). I don't believe we can eliminate conflicts altogether - but
following standard practice will make it less complicated for OSGi
developers to resolve conflicts.
Thoughts?
I'm sure people will find that too simplistic, but I'm going to say it
anyway. IMO if we test a release with version X we should just import
version X. If somebody wants to run with version Y he gets the source,
changes the import to Y, and takes responsiblity for building and
testing with Y.
If somebody wants version X and Y to co-exist in a VM, well that's
possible too. And by the way in an SOA not everybody needs to run
everything in a single JVM, so the best option is probably to run
incompatible things in different JVMs. Sometimes we're so Java centric
that we forget that the JVM runs on an operating system, which can run
more than one JVM :)
--
Jean-Sebastien
