On Jun 5, 2008, at 7:27 AM, Peter Kriens 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.
As does Maven.
This allows you to implement
your own policy ... We defined a convention but did not make this
convention mandatory.
Understood. The problem is when you run into a plethora of
conventions. It makes it difficult to create a "safe" set of version
ranges. Projects violating their own conventions makes the job even
more hard.
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.
It is this tricky area that causes a lot of the agony because for all
but the most trivial apps where you are in control of most of the
"down stream" components, you will run into this problem.
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?
Not sure if this is directed toward me or Rajini.
Regards,
Alan
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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
