Rajini Sivaram wrote:
On 6/12/08, Simon Nash <[EMAIL PROTECTED]> wrote:
Yes, this is true. But how narrow should the range be? SpringSource assumes
compatibility at major version. Should we assume minor version? Or should we
restrict to revision? Are we saying that we work with 1.3.0, so we would
work with 1.3.2, but not 1.4? Or are we saying that we have only tested
against 1.3.0, so we will only use 1.3.0?
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.
Well, we now know that Axis 1.4 is a very different beast than Axis 1.3.x - so here is an example
where we have to be doubtful that we can span both.
The dependency graphs for Tuscany (even ignoring applications) is likely to
be very complex, because we have 149 3rd party libraries with many 3rd party
libraries having dependencies on each other. In the first instance, yes, I
agree, we can easily restrict to a single major.minor.revision for each
library. We test Tuscany with one combinarion of these 149 libraries. And it
works, so we force this combination. But what happens in a year or two, when
each of these 149 libraries may have 5 releases (minor releases perhaps, but
new versions nevertheless). Do we test all 5 ** 149 combinations of 3rd
party libraries to ensure that they can all work together? Even if we had
tools which could work through the dependency graphs and provide a minimal
set of combinations that could coexist, this would still be an awful lot of
testing. Add to this application versioning requirements, third party
bundles from other sources, and we will end up with a problem of enormous
complexity.
This is the full nightmare.
Without the testing, we can't be sure of anything.
But the testing combinations become nightmarish very fast.
It *MIGHT* be practicable to consider doing a single pass "reverse versions" test run towards the
end of doing a new release of Tuscany for more significant libraries *SHARED WITH APPLCATIONS
THROUGH THE APIs*. No way would we want to do this on a regular basis, but it would give us some
assurance that some range of each library might work. This should keep the number of libraries and
the combinations down a bit, but even then it could get out of hand fast.
Broad version ranges can potentially lead to incompatibility issues, but
narrow ones can potentially lead to classloading errors, and force
restrictions on application's use of 3rd party libraries.
1. TCCL based classloading (XML parsing for instance) : as we allow more
versions to co-exist, there is more likelihood of TCCL picking up the wrong
versions of libraries
2. Class sharing between applications and Tuscany - It would be really
good to have a definitive list of classes which applications share with
Tuscany directly or indirectly. For classes which are shared, narrow version
ranges in Tuscany automatically impose narrow version ranges for
applications. For applications which also use 3rd party libraries from other
sources, the result will be runtime classloading exceptions.
3. Upgrading 3rd party libraries will require new Tuscany releases. This
is inconsistent with how we work in the non-OSGi space where the user has
the flexibility to upgrade 3rd party libraries by just adding them to
CLASSPATH.
4. This is inconsistent with other repositories like SpringSource etc
(and also not standard/best practice in OSGi)
I do think that there may be some libraries like Axis2 kernel where a narrow
range (at minor version?) makes the most sense. But I would expect that a
larger number of 3rd party libraries can cope with broader ranges, and I
think we should adopt broad ranges "where possible" (not sure what that
means).
Hmm - nice idea but this is the nettle of untestable combinations.
