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?
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
