Hi, In the meeting today, we discussed API and SPI compatibility. We covered a lot of ground, and I expect that we'll see a few email threads coming out of the discussion.
To get started, I'd like to go over what we discussed about APIs first: - OpenJPA has a set of published developer-centric interfaces. - These interfaces are relatively loosely-defined - Our users would benefit from a more rigorously-defined set of APIs - It is possible to traverse past the "published interface" set pretty easily, since some of the published interfaces return types that are not themselves published, or require arguments from classes that are not published During the meeting, we discussed the following options for addressing the above points: 1. Review which classes are marked as @published, and change the build process to build an API jar based on scanning source for @published tags. This would have minimal impact on current users, but would be less-rigorous and would not allow OSGi enforcement of API boundaries. 2. Break the openjpa-persistence and openjpa-persistence-jdbc modules into separate modules for API and SPI. This would require repackaging the current impl classes (EntityManagerImpl etc.) into a new sub-package, in order to work with the OSGi model (it is my understanding that OSGi does not allow multiple bundles (jars) to contribute to the same package), but would provide strong compile-time guarantees and a more formal contract. Let's discuss which route we want to take to improve our API definitions. -Patrick -- Patrick Linskey 202 669 5907
