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?

Thanks David.  This does make sense to me. 

 

WRT uses, I think it can be valuable in small clusters of packages that go together to form API sets.  To really get the full effect you would indeed have to have it everywhere but in this case it would/should be enough to have just the affected bundles use uses.

 

Tom?

 

Jeff

 

 

 

From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Saturday, April 12, 2008 1:48 PM
To: Orbit Developer discussion
Subject: 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

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
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev


Back to the top