[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] project packaging?

This is definitely the time for these discussions.   Let's figure out what we have to add to make JPA work in OSGi and what additional services on top of the spec provided API we need for it to be effective.  We can also feed this intelligence back into the JPA expert group working on JPA 2.0.

   Shaun

Bryan Hunt wrote:
Shaun, Thanks for the clarification.  Is now the appropriate time to start discussions on things like how to deal with separating the javax.persistence api from the implementation and how to deal with the fact that the implementation of javax.persistence.Persistence does not fit into the Eclipse architecture?  Or is it too early to start these discussions?

Bryan

On Nov 30, 2007, at 8:59 AM, Shaun Smith wrote:

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.

    Shaun

Bryan
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

--


<oracle_sig_logo.gif>
Shaun Smith | Principal Product Manager | +1.905.502.3094
Oracle TopLink
110 Matheson Boulevard West, Suite 100
Mississauga, Ontario, Canada L5R 3P4
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users


_______________________________________________ eclipselink-users mailing list eclipselink-users@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-users

--


Oracle
Shaun Smith | Principal Product Manager | +1.905.502.3094
Oracle TopLink
110 Matheson Boulevard West, Suite 100
Mississauga, Ontario, Canada L5R 3P4

GIF image