This page is focussed on capturing how EclipseLink will be developed and used for an OSGi (Equinox) environment.
The goal of this effort is to produce OSGi bundles for use in other Eclipse projects and RCP applications. While the focus is on OSGi it is understood that Equinox extensions will be required.
- Make EclipseLink bundles easy to use within other Eclipse projects and RCP applications without hindering the Java (SE/EE) usage
- Ensure that the bundles offer flexibility in their independent usage. The usage of EclipseLink JPA should not force the usage of EclipseLink's JAXB
As of 1.0M2 EclipseLink does not make OSGi/Equinox bundles available. This page is tracking the requirements, proposals, and discussion as to how EclipseLink can most effectively be bundled.
- Native object-relational persistence using ElcipseLink-ORM.XML or API
- Native Object-XML API using native XML mapping file or API configuration
- JPA 1.0 functionality
- Extended JPA support using EclipseLink's annotations, PU properties, and query hints
- Support for partial and complete EclipseLink-ORM.XML extensions of JPA
- JAXB 2.0 using annotations
- JAXB 2.0 using native XML mapping file
- SDO 2.1 support
- Native Object-EIS/JCA using native XML mapping file or API configuration
Proposal: Bundle Components
This proposal refers to making parallel bundle PDE projects which expose the existing functionality from the Java projects.
Proposal: Use PDE for Component Projects
Convert the existing Java projects into PDE projects.
QUESTION: Is there any value in having JPA (persistence.jar) available as a separate bundle or is this just part of the API exposed from the org.eclipse.persistence.jpa bundle?
- Current Proof-of-Concept packaging of EclipseLink into bundles has relied upon the Equinox Buddy Classloader extension. This approach is not portable to other OSGi containers and is therefore not a long term solution. In his blog, Peter Kriens, OSGi Director of Technology, describes his efforts to address classloader issues with Hibernate that are similar to those facing EclipseLink in an OSGi environment. Unfortunately he concludes that future versions of OSGi would require new features to solve the problem elegantly and portably.