Bryan Hunt wrote:
I respectfully disagree with these project priorities. As an Eclipse hosted project, I would expect an Eclipse (bundle) based architecture to be top priority.
I hear what you're saying. But the reality is we have an existing code base that is being contributed to Eclipse and the first step is to get it compiling and building "as is". Best to have it working so we at least have a solid code base to start from. However we are looking ahead as this conversation proves--we've only got Milestone 1 out and yet we're already talking about packaging in bundles. It's obviously a priority but "priority one" is get the code compiling and the build infrastructure into place.
It's been my observation that technology such as JPA (Hibernate) and SDO (Tuscany) have inherent architectures that are orthogonal to OSGi. It is my hope that this problem of opposing architectures would be top priority, as opposed to retrofitting things later.
This is exactly why this is so interesting! We have an opportunity to shape EclipseLink so that it is compatible with OSGi.
Given my experience so far I don't see any major issues with JPA beyond byte code weaving (which is optional in EclipseLink) in OSGi but the classes that make up the SDO specification are problematic. In SDO they find "the" key HelperProviderImpl class via a classForName lookup and then stick it into a static. It's not possible to have multiple co-existing SDO implementations on your classpath because of this. JPA has intentionally addressed this issue. What this means is that I've had to package the SDO commonj.sdo classes in the EclipseLink bundle to ensure that those using EclipseLink SDO don't have to worry about colliding with other SDO impls. I expect other SDO impls like Tuscany to have to do the same--at least in SDO 2.1. SDO 3.0 may address this problem.
eclipselink-users mailing list
-- <oracle_sig_logo.gif> Shaun Smith | Principal Product Manager | +1.905.502.3094
110 Matheson Boulevard West, Suite 100
Mississauga, Ontario, Canada L5R 3P4