I am very pleased to see this discussion happening. My thoughts below.
Simon
Rajini Sivaram wrote:
On 6/12/08, Graham Charters <[EMAIL PROTECTED]> wrote:
Hi Rajini, I think your summary on the wiki is great. I have a couple
of comments:
1. I believe SpringSource try to create sensible version ranges based
on the versioning governance of the project, such as that of Apache
[1]. I have no doubt this takes quite a bit of effort and there are a
number of examples which do not follow guidelines, but it seems like a
sensible place to start.
"Sensible" is quite difficult to define. Here is example of one of the
SpringSource versioned jars - Axiom 1.2.5 (this is on Apache License):
The versions going upto infinity are those provided by the Java SDK. For the
others, the minimum versions are similar to the minimum versions that we
would generate using maven-bundle-plugin in Tuscany (based on current
versions), and the maximum versions (at least in this example) go upto the
maximum within the major version range. I have only looked at a few, but the
ones I looked at follow this pattern.
javax.activation [1.1.0, 2.0.0)
javax.mail [1.4.0, 2.0.0)
javax.mail.internet [1.4.0, 2.0.0)
javax.xml.namespace [0.0.0,infinity)
javax.xml.stream [1.0.1, 2.0.0)
junit.framework [3.8.2, 4.0.0)
org.apache.commons.logging [1.1.1, 2.0.0)
org.jaxen [1.1.1, 2.0.0)
org.jaxen.saxpath [1.1.1, 2.0.0)
org.jaxen.util [1.1.1, 2.0.0)
org.w3c.dom [0.0.0,infinity)
org.xml.sax [0.0.0,infinity)
org.xml.sax.helpers [0.0.0,infinity)
Whenever we import a package using a version other than the currently
implemented and tested versions, we are making an assumption about being
future-proof. IMHO, that is hardly ever the case. eg. If Tuscany 1.2.1 was
released with Axis version 1.3, and Axis version 1.4 was not available for
testing at the time, can we really assume that Tuscany 1.2.1 will work with
Axis 1.4 when it comes out just because the major version has not changed?
By choosing the version range [1.3.0,2.0.0) for Tuscany imports, we are
making that assumption. Now this does not matter as long as the user wants
to use Tuscany out of the box and does not install Axis version 1.4 into the
OSGi runtime. But what happens when the user does install Axis 1.4 to use it
with another application? Tuscany could fall over in spite of the fact that
there is an Axis 1.3 present in the runtime, because Tuscany will be wired
to 1.4 since it believed that it would work with any version beyond 1.3. I
do agree that SpringSource provides a good starting point, since a lot of
work has already gone into it. But I would expect that some level of fine
tuning will be required for Tuscany beyond that.
I think this is a serious problem and we do need to take into account
that users will install higher levels of Tuscany dependencies such as
Axis2.
We could guard against Tuscany breaking in this case by specifying the
Axis2 dependency as a narrower range such as (1.3.0, 1.4.0) instead of
(1.3.0, 2.0.0). This would mean that if Axis2 1.4 is installed, Tuscany
will still use Axis2 1.3 even though other code is using Axis2 1.4.
This should avoid breakage.
The next step is for Tuscany to determine whether or not Axis2 1.4
is compatible for Tuscany purposes. If it is compatible, Tuscany
could release an update for its bundles that changes their Axis2
dependency to (1.3.0, 1.5.0), with no change to the Tuscany code.
This approach keeps Tuscany working at all times, no matter what
other versions of its dependencies are installed. The downside
is the work needed for Tuscany to do compatibility testing and
release updated dependency specifications from time to time, and
for the user to install these updates when she wants to move
forward to the latest possible Tuscany dependencies without also
upgrading Tuscany.
Are there any other problems with this approach?
At least this approach is not arbitrary and
therefore, IMO, stands a chance of working in most situations.
Arbitrary schemes will be difficult to explain and defend when issues
arise. I dislike the idea of narrow or broad ranges for the reasons
you state.
Yes, "stands a chance of working in most situations", where "most" is the
key word. We will work in all situations where applications dont install
different versions of Tuscany's 3rd party libs. Once we have an application
and Tuscany within one OSGi runtime with multiple versions of 3rd party
libraries installed, there will always remain some situations where we dont
work as expected. The default behaviour for maven-bundle-plugin (which we
will probably end up using to generate our bundles) is [current.version,
infinity). If we go out of our way to modify this for individual 3rd
party bundles, I doubt that is in anyway going to be "arbitrary". It really
needs to be based on real scenarios.
Any non-infinite version number requires making some assumption
about the future compatibility of the 3rd party library. Without
a crystal ball, this will be hard to get right every time. This
is why I am suggesting a more conservative approach.
[current.version, next.major.version) gives the best starting point IMO. In
past notes about multiple extensions in Tuscany running with different
versions of a 3rd party lib, I am not sure if the examples involved
different major versions of a 3rd party lib. I would really like to
understand real scenarios:
1. Why do we want two Tuscany extensions to use two different versions of
a 3rd party library? Would these ever involve two minor versions at the same
major version level? If so, couldn't both extensions just work with the
higher of those two - do we really want to force one of them to work with
the lower version?
>
This could happen if the Tuscany extensions are using the same 3rd party
library in different ways, such that one extension can't tolerate the
upgrade to a higher level of the library but the other can tolerate it.
2. Why would an end user want to run Tuscany and an application with two
different versions of a 3rd party library? Would these ever involve two
minor versions at the same major version level? If so, what stops both from
using the higher of the two?
If the user is developing the application herself, that should not occur.
If it's developed by someone else, this situation could apply. The user
might need Tuscany level X and Other Application level Y. These might
have different version dependencies on the same 3rd party library.
Simon
2. You asked if we should be able to work with bundles from other
projects (e.g. ServiceMix, SpringSource Application Platform). I
wonder if we're able to learn from these projects to seed our
versioning. The SpringSource repository, for example, seems to allow
this, although I'm no legal expert [2].
Regards, Graham.
[1] http://commons.apache.org/releases/versioning.html
[2]
http://www.springsource.com/repository/app/faq;jsessionid=3F9467729AC282FE4E08199FDCE40863#q6
2008/6/11 Rajini Sivaram <[EMAIL PROTECTED]>:
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?
Thank you...
Regards,
Rajini
