Difference between revisions of "Talk:EclipseLink/DesignDocs/384399"

Revision as of 11:31, 24 September 2012

Binary Compatibility / Backward Compatibility

I'm not sure the changes can be backward compatible or binary compatible. I think the usage of generics might be able to resolve many of the backward compatibility issues, but this would require a recompile, I'm not sure if generics are binary compatible in this way.

James.sutherland.oracle.com 17:20, 27 August 2012 (UTC)

---

Refer to my example in Concepts section as to how binary compatibility could be maintained for the ORM piece

- http://wiki.eclipse.org/EclipseLink/DesignDocs/384399#Generics_.26_Parameterized_Types

blaise.doughan.oracle.com 18:52, 27 August 2012 (UTC)

ORM Deployment XML

I don't think we can remove this. It is still our only meta-data format for many of our API's (native ORM, DBWS, BPEL) and has not been deprecated or even replaceable without requiring a migration to JPA. Potentially we could deprecated it and provide a way to use the JPA orm.xml meta-data format for native ORM (DBWS, BPEL), and provide some migration utilities perhaps. But would probably require a couple releases to get rid of it.

Note, getting rid, or deprecating the project deployment XML would also mean deprecating or removing the Mapping Workbench and JDev/ADF native ORM support, or migrating these to generate a JPA orm.xml file.

James.sutherland.oracle.com 17:20, 27 August 2012 (UTC)

---

I am specifically referring to the OXM deployment XML. I believe the DBWS component depends upon the OXM file. This may be enough reason to keep it, or have the DBWS component upgrade to the preferred oxm.xml file.

blaise.doughan.oracle.com 18:54, 27 August 2012 (UTC)

NoSQL

I assume this project would also include moving the NoSQL/EIS class into the nosql component. Note that nosql would most likely need to depend on both jpa and jaxb components.

James.sutherland.oracle.com 17:23, 27 August 2012 (UTC)

Fork and Stripe 2.4

I think we should think very carefully of how this is actually going to work in future deployments.

I believe one of the goals of this project is to allow Moxy to be small and independent of EclipseLink so it can be used in other projects that just need JAXB, such as possibly the JDK. But what happens if this is successful? If EclipseLink is dependent on Moxy, and Moxy is embedded in other projects, possibly the JDK, then how is this going to work, given EclipseLink has very low level dependencies and requires a specific version. EclipseLink will no longer be able to function, and will no longer be able to run on multiple JDK versions, or be incompatible with other libraries that use Moxy.

I think a simple solution would be to create a new product, Moxy Lite, that has different package names. Take 2.4, package rename it, strip anything not required from it. Maintain it as a separate patch stream. When 2.5 comes along, do the same, (package rename it, strip it). The package rename could even be done as part of the build process to make merging patches easier. EclipseLink will never use Moxy Lite, only the full version of Moxy. Moxy Lite can only be JAXB, JSON and other non-required features could be stripped, allowing it to be very small.

This would give us the quickest solution, and avoid duplicate development streams (only the patch stream is duplicated). It is not an ideal solution, as you have to strip each release, but this could be somewhat automated. I don't think any other solution will result in not having to maintain two different development streams indefinitely. Core uses OXM in a very integrated fashion, especially for EIS/NoSQL, and increasingly for JAXRS, I can't see how any other solution would allow for this.

James.sutherland.oracle.com 15:31, 24 September 2012 (UTC)