[
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?
|
Thanks Jeff. Some of this saga is documented
in the Orbit bug
226068.
And, being inspired by your note, I
opened PDE bug
226813.
> but given they
are javax.* things there must be an API of sorts
Yes, it's the "of sorts"
part that's a little fuzzy :)
I just meant there was no
published standard from a standards body, that I'm aware of. This could
well be my lack of knowledge of this area.
And, to bemoan a recurring
Orbit issue, sometimes we Orbiteers are trying to do things with other's
(3rd party) code with little knowledge of the details of the code. Perhaps
if one of us was to inspect all the javax class from the two providers,
we'd find they were identical. But, prioritizing my work based on need,
didn't want to do that for "mere" purity reasons ... and, in
fact, that alone wouldn't solve all the problems (since no known "factory"
methods to get the intended implementations.
But, you're right, the "uses"
clause might help with lack of factory methods, stating essentially "we
don't care which implementation you use, just make sure it's the same one,
if more than one is available". I'm still not clear, though,
on the state of "uses" vs. "require-bundle" techniques.
Last I heard, there will need to be a mass effort to have all of eclipse
transition to the "uses" construct at once? But, not sure.
As documented in bug
226068 I did follow Thomas's advice
to include "vendor = " attribute on the export package statements
(and marked the vendor specific packages with x-internal).
Since in this particular
case (from what I've heard so far), no one is really using these bundles
directly -- they are only used by _other_ third party bundles, I think
we have a good situation to begin exposing and documenting these issues,
without having to solve them all right now ... and simply take one expedient
solution for now ... until someone has some concrete needs, that would
justify them expending the energy on solving the problems in a more general
way.
Thanks again.
From:
| "Jeff McAffer" <jeff@xxxxxxxxx>
|
To:
| "'Orbit Developer discussion'"
<orbit-dev@xxxxxxxxxxx>
|
Date:
| 04/12/2008 08:45 AM
|
Subject:
| 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
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
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev