On 6/12/08, Simon Nash <[EMAIL PROTECTED]> wrote: > > 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.
On 6/13/08, Mike Edwards <[EMAIL PROTECTED]> wrote: > If Tuscany itself allows the use of a range of versions of some 3rd party > library, then in principle given that we attempt a form of test driven > development, we should be testing with ALL of the versions of that 3rd party > library. > > If we don't do that, then we are really "winging it" in terms of testing - > we are implying that the Tuscany code has been verified to work with any and > all of the levels within the range, when we have not done that. > > Experience in general says that it is not wise to assume that because > Tuscany works with level 1.x of some library, that it will also work with > level 1.x+1. Loosening a tight range is going to be tough. > > On 6/13/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > 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 :) I have cut-and-paste three comments from Simon, Mike and Sebastien in this thread, and they all reflect the same viewpoint : use single tested versions of 3rd party libraries to avoid incompatibilities. Since this view is backed by Tuscany experience, I do fully accept that this is probably the safest starting point (I say starting point because I believe that we will need to broaden version ranges for 3rd party libraries which are shared with Tuscany, use TCCL etc. to support classloading constraints in commonly used scenarios without repackaging Tuscany). But before we go ahead and implement the narrowest possible versioning system, I would like to step back and look at why we are implementing versioning. - What value does versioning add to Tuscany? In other words, why are we doing this? The answer as far as I know is because OSGi users of Tuscany require some level of versioning in order to integrate Tuscany into their OSGi runtimes. At the moment, it is not very clear how much of sharing, isolation, side-by-side execution etc. is typically required. But we should be able to start either with a broad range and fine-tune by narrowing it for specific cases OR we could start with a narrow range and fine-tune by broadening for specific cases. We are never going to be able to get it right for all possible scenarios IMHO. - Do we require side-by-side execution of Tuscany extensions with multiple versions of 3rd party libraries? This has been cited in some notes in the past as a reason why we would like to version Tuscany. But given that Tuscany typically runs outside an OSGi runtime, are we ever going to build Tuscany extensions which mandate OSGi? Personally I dont see this as an immediate requirement - or rather I dont see versioning of Tuscany being adopted in the near future to solve extension versioning problems within Tuscany. - Do we require Tuscany to co-exist applications which use different versions of 3rd party libraries? We do know that there are OSGi users of Tuscany who have this requirement. In fact OSGi users will expect this to work. But do we see versioned third party libraries as first class support in Tuscany? Do we expect non-OSGi users of Tuscany to migrate to OSGi in order to use the versioning support in Tuscany once it is out there? Personally I see versioned libraries only being used by OSGi users of Tuscany and hence it makes sense to adopt OSGi best practice and follow broader version ranges. - When 3rd party libraries become OSGi-enabled by default, do we expect to reuse them, rather than re-bundle them? And another related question is - do we expect to interoperate with 3rd party libraries from other repositories like SpringSource? If we do expect to use 3rd party libraries bundle-ized elsewhere we should be prepared for relatively broad version ranges. Should we have two different versioning strategies - one for Tuscany where we restrict to using single version ranges, and another for 3rd party libraries where we tolerate broader ranges? What would that mean for testing? IMO if we want to interoperate with other 3rd party libraries, we have to start accepting the limitations in our testing, at least for OSGi. At least for interoperability, it would make sense to follow standard practice in OSGi rather than stay with single versioned imports. - Where do we see all this versioning and OSGi-enablement leading to? IMHO this is the most important question. As we start seeing more and more libraries being OSGi-enabled and more and more repositories of 3rd party bundles becoming available and tested, do we think that 1. it is going to end up in a complete mess with unsolvable constraints, classloading nightmares and a testing catastrophe OR 2. do we expect to see 3rd party libraries (and Tuscany) evolving to support multiple versions? If we believe in 1), we should definitely go for narrow constraints and leave it to OSGi users of Tuscany to sort out their classloading/versioning requirements by repackaging, running in different VMs etc. If we believe that 2) could be the future, I think we should go for a broader version range in most cases, except specific libraries like Axis2 and others where we dont expect either Tuscany or the library to remain compatible over ranges. There is no doubt that we will get it wrong in the first instance, and there will be users who will need to repackage Tuscany, but hopefully we will learn as we go and eventually be ready along with other 3rd party software to handle multi-versioned systems. Or do we believe in 1) followed by 2), in which case we could delay adopting broad version ranges until we feel more confident in doing so. And from the comments I have quoted at the start, it doesn't sound like we are ready for working across version ranges, yet. Thank you... Regards, Rajini
