Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [orbit-dev] How to handle (name and wire) multiple implementations of a 3rd party bundle and package?

First reaction. Is this a Ganymede issue?

 

Second reaction: we should find a way to host both.  Saying there can only be one is an unfortunate precedent.

 

So assuming that, we have two issues:  naming and dependency management.  These are somewhat interdependent.  David, your statement about there not being an API was interesting.  I’ve not looked at these setups but given they are javax.* things there must be an API of sorts.  So the first cut would be to separate out the javax.* stuff into one package and the “implementation” into another.  The implementation may have API but wouldn’t it be in a different/distinct namespace?

 

Even if we don’t do an actual separation, OSGi will elect only one provider of a given package with a given version.  So if all consumers use Import-Package there will be fewer issues.

 

Third reaction: export package “uses” clause can help here.  This allows package P in bundle B to say that it uses package Q.  Then if some other bundle C wants both P and Q, the resolver binds C’s P and Q requirement to the same provider that P uses.

 

Reaction while writing response:  Does anyone else have this problem in the real world?

 

Clearly details need to be worked out but it seems this could be made to work.

 

Jeff

 

From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris Aniszczyk
Sent: Monday, April 07, 2008 6:05 AM
To: Orbit Developer discussion
Subject: Re: [orbit-dev] How to handle (name and wire) multiple implementations of a 3rd party bundle and package?

 

If we need to keep both... how about an attribute on the export packages to include vendor information?

ie.,

Export-Package: javax.mail; vendor="Geronimo"
Export-Package: javax.mail; vendor="Sun"

If someone cares about the vendor, they can specify an attribute in the Import-Package header, otherwise it shouldn't matter where the package comes from.

If we go this route, we should try to standardize on how we specify vendor information maybe... or how to deal with attribute matching in Orbit...

Or if we just pickup versions that are more license friendly, that works too for me.

Cheers,

---
Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga.blogspot.com | +1.860.839.2465

Inactive hide details for David M Williams---04/07/2008 03:16:43 AM---Here's a new situation we should discuss as a project ...David M Williams---04/07/2008 03:16:43 AM---Here's a new situation we should discuss as a project ... it's part technical, and part protocol.


From:


David M Williams/Raleigh/IBM@IBMUS


To:


Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>


Date:


04/07/2008 03:16 AM


Subject:


[orbit-dev] How to handle (name and wire) multiple implementations of a 3rd party bundle and package?






Here's a new situation we should discuss as a project ... it's part technical, and part protocol.

We already have two bundles in Orbit

javax.activation
javax.mail

and now there has been a request to also include two new, similar ones, that are different implementations of these. And exact same version!

Many, and especially the main, packages are named the same between the two, but there are also some differences in that the current one contains some specific "com.sun....." packages and the new ones will contain some specific "org.apache.geronimo...." packages.

They are supposedly identical functionally, but an Eclipse project has requested the Apache Geronimo implementations.

So ... how to handle? Should we replace the old with the new (the same project (webservices project, in WTP) requested both implementations (previously the sun implementation, but now the geronimo implementation), but there are now some other clients in Eclipse as well. (Mylin is the only one I've informally talked to ... they use indirectly, and they said they didn't care (as long as truly same function) but would impact their testing, at least.

Other ideas?

On the surface we could just name the bundle slightly differently, e.g. "javax.activation.geronimo") which I guess works for the "require bundle" cases, but does not work if/when anyone uses import-packages. The risk, of course, is that both implementations could exist in the plugin stack, and in theory cause "class cast" exceptions. Plus, even having slightly different names, we'd still need to change some other bundles in Orbit (e.g. Axis) which pre-req these, hence being the same effect as replacing the old with the new.

Also, before you ask, I don't think we can "split up" into separate bundles (interface and implementation) in this case, since I don't think that 'interface' part is formal enough ... sort of a defacto standard, as far as I know -- plus, there's no registration mechanism for which implementation to use ... especially since, as far as I know, these are only required for use by other 3rd party software (which I'd rather not customize!). As far as know, no one in Eclipse is writing code directly to these packages (so, hence, it's not feasible to "register", or use Factory methods to get one implementation over another).

Any suggestions? I don't see a way to safely keep/provide both from Orbit.

Would I be rude to suggest the sun implementations in Orbit be replaced by the geronimo implementations? That would be the easiest, and most straightforward (and least risk) ... but, thought I'd ask here before suggesting it to the larger community. Advice welcome.

Thanks,

P.S. If you're wondering why the webservices project even cares, if code is functionally equivalent, it is related to source, licensing, and consistency (supposedly the Apache Axis group has started to use this Apache Geronimo implementation, for example) so it's a legitimate request.
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev


Back to the top