Sorry, I haven't been able to make any progress because of other commitments. I had an offline discussion with Mike Edwards a couple of weeks ago, and we concluded that we need some level of testing before we support version ranges for 3rd party libraries. When I have some time, I will try and build a test harness to test multiple versions of the most common 3rd party libraries with Tuscany - obviously we can only test against already released versions and snapshots and we will have to extrapolate the results to future releases. Once we get some idea of the backward compatibility of these, we can decide on how we should version these in Tuscany.
Here is my plan (sorry again about the delay, I am waiting to find a reasonable period of time to dedicate to this, but I will try to get at least some of the items from the list below done this month). 1. Modify itest/osgi-tuscany to generate 3rd party libraries and Tuscany modules with OSGi manifests which uses single versioned import statements 2. Build a test harness to automate testing of Tuscany against multiple versions of 3rd party libs 3. Test Tuscany against multiple versions of commonly used 3rd party libraries using 2). Ant mentioned stax-api, woodstox, jaxb and cglib, if there are others which are likely to work across broad ranges, please let me know and I will test against those. I will start with the core dependencies and the dependencies that are shared across many extensions since they are the ones which are likely to be also used by applications. 4. Based on the results of 3), modify itest/osgi-tuscany to use broader ranges for a limited set of 3rd party libs 5. Modify distribution to generate OSGi manifest entries for Tuscany modules as well as 3rd party libs based on 4) Thoughts? On 7/4/08, ant elder <[EMAIL PROTECTED]> wrote: > > > On Mon, Jun 16, 2008 at 4:06 PM, Rajini Sivaram < > [EMAIL PROTECTED]> wrote: > >> 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 >> > > This has thread has been quiet for a while so i'll bring it up again with a > reference to some recent blog posts for alternative POVs: > http://www.1060.org/blogxter/entry?publicid=C9CBD0D71A1E8D020D25A79C2F091BF0 > > Re supporting version ranges on dependencies - if we do ever decide to go > with some aggregated jars as suggested in [1] then we could aim for > different version ranges for the different tusany jars. For example, > tuscany-scdl4j uses only stax-api and woodstox and should work with a very > wide range of releases of those. Tusany-runtime needs it a bit tighter, but > if we're careful we could probably keep the required releases of the > dependencies like jaxb, cglib etc quite wide. Then its only when it comes to > specific extensions like tuscany-runtime-axis2 where the dependency versions > need to be pinned down to a single release. > > Re supporting multiple Tuscany extensions using different versions of 3rd > party libraries - that seems to make things so much more complicated i don't > think we should try. As mentioned earlier in the thread if you need that you > can use multiple JVMs. > > ...ant > > -- Thank you... Regards, Rajini
