Thank you very much for all your replies and pointers. This discussion has been very useful for me...
On 6/5/08, Peter Kriens <[EMAIL PROTECTED]> wrote: > > Ahh, and here we find that OSGi has the same achilles heel as Maven. I >> anticipate that these kind of issues will be the basis for a shrill of >> complaints as they are in Maven. >> > I do not think so. In contrast with maven, OSGi has version ranges. This > allows you to implement > your own policy ... We defined a convention but did not make this > convention mandatory. > > And this is a very tricky area where you easily end up in unsolvable > constraints. The trick > of good modularity is to minimize the dependencies between bundles as much > as possible. > Services with properly designed interfaces are the magic trick here. > > Another solution is also to include some of the code inside the bundle and > not expose it. As > long as you do not use a class to communicate with another bundle, then > each can have its > own class. > > Managing dependencies is good, not having them is better ... I am puzzled > that you have > so many external dependencies. I would expect a relatively small core, a > few bundles with basic function > blocks and a large number of plugins that support multiple protocols? Yes, Tuscany has a small (ish) core with a lot of extensions. Based on the dependency list generated using maven, the core uses around 35 third party jars. Each extension adds a tuscany module, which brings with it a set of 3rd party libs. Altogether a Tuscany distribution contains roughly 150 different third party libs (and this is using maven to choose one version of each library regardless of the fact that dependencies specified across some of these libraries in maven bring in multiple versions of many libraries). At any one time, an application may use only a subset of these. But applications could also have installed different copies (with same or different versions) of these libraries from elsewhere. I agree with Alan that managing large sets of these is just as complex with OSGi as it is with maven (at least at the moment). Kind regards, > > Peter Kriens > > > On 4 jun 2008, at 17:24, Alan Cabrera wrote: > > >> On Jun 4, 2008, at 1:21 AM, Rajini Sivaram wrote: >> >> >>> Thank you all for the replies with all the useful information and >>> pointers. >>> >>> For versioning Tuscany bundles themselves, we are using >>> maven-bundle-plugin at the moment, which gives us import and "uses" clauses >>> with version="2.0.0". Since this includes all versions from 2.0 to infinity, >>> and we are not currently addressing execution of two different versions of >>> Tuscany side-by-side, the default looks sufficient. We could change it to >>> "[2.0.0,3.0.0)" to make it more specific, but either way, it should be fine >>> for now. >>> >>> I am still not entirely sure about versioning of 3rd party libraries >>> distributed with Tuscany though. Since Tuscany is used to assemble SOA >>> applications, Tuscany uses a large number of 3rd party libraries to provide >>> different bindings and implementation types. Many of these 3rd party >>> libraries may also be used by applications (either directly from Tuscany or >>> from a different source). If for example, Tuscany's version of wsdl4j used >>> import version "[1.6.2, 2.0,0)", and this version of Tuscany doesn't work >>> with wsdl4j version 1.7, doesn't the version range "[1.6.2, 2.0,0)" prevent >>> an application from installing and using version 1.7 along with Tuscany for >>> something else? So should the version range only specifically include the >>> version range that Tuscany has been tested against? And then we run into >>> problems with too narrow version ranges. And what happens when an >>> application is using wsdl4j from SpringSource or another repository where a >>> different version range is included? How do we ensure that Tuscany and >>> applications can all coexist? >>> >> >> Ahh, and here we find that OSGi has the same achilles heel as Maven. I >> anticipate that these kind of issues will be the basis for a shrill of >> complaints as they are in Maven. >> >> I've had a fair bit of experience wiring in large sets of 3rd party jars. >> No one follows any single kind of version nomenclature and many violate the >> ones they espouse. >> >> Setting a version range in anticipation of what down stream application >> assemblers will use will be a futile task. Only the Pope and my >> mother-in-law are infallible and you're sure to get it wrong for some >> significant part of your community. The best you can do is set the range >> for what is safe for Tuscany in the hopes of providing accurate information >> for down stream application assemblers. >> >> >> Regards, >> Alan >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- Thank you... Regards, Rajini
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
