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. > 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. [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? 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? > 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 > > > -- Thank you... Regards, Rajini
