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