> maven. Furthermore, people wouldn't be able to rely on just the the > public API jar for compilation, since they would get a > NoClassDefFoundError for SomeInternalClass.
I don't think that that's the case -- if the only refs were in code blocks, that should work fine for compilation dependencies. So in any event, this definitely puts us in a difficult position. I think that it makes sense to not violate OSGi rules for our modules, since I think that eventually we may want to do more OSGi stuff. And clearly, we shouldn't do something that maven won't let us do without good cause. However, I think that I'm still in favor of moving the non-API classes to a .impl sub-package. It just seems cleaner to me, and more like what we'll want in the long term. Thoughts? Is it worth the pain for current OpenJPA-internals consumers to move things like EntityManagerImpl and FetchPlanImpl to a sub-package, even if we don't get any maven goodness from it? -Patrick On 8/8/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: > > That would make the whole thing much less appealing to me, since then > we wouldn't have the advantage of enforcing API/SPI restrictions via > maven. Furthermore, people wouldn't be able to rely on just the the > public API jar for compilation, since they would get a > NoClassDefFoundError for SomeInternalClass. > > If the point is to make it so we have a clean separation of public > APIs/SPIs from internal implementation and kernel classes, I think we > should go all the way and really separate them out. > > > > On Aug 8, 2007, at 2:48 PM, Patrick Linskey wrote: > > > Hmm. That's annoying. I think I'd prefer to just keep the impl libs > > inside the API module rather than adding the SomeInternalClass style. > > > > -Patrick > > > > On 8/8/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote: > >> > >> This is a show-stopper if we were to refactor the code into different > >> maven modules, since you can't have circular dependencies between > >> modules (e.g., openjpa-persistence-public-api couldn't depend on > >> openjpa-persistence if openjpa-persistence itself depeneds on > >> openjpa- > >> persistence-public-api). > >> > >> My suggestion for this kind of thing would be that if our API has > >> some method like: > >> > >> public SomeInternalClass getFoo() > >> > >> then we would instead add a SomeInternalBogusInterface with no > >> methods that is opaque to the user, and which SomeInternalClass will > >> implement. The advantage to this is that our public APIs couldn't > >> then have a transitive dependency on non-public APIs, which I think > >> is beneficial from an API consistency standpoint. > >> > >> > >> > >> On Aug 8, 2007, at 2:36 PM, Patrick Linskey wrote: > >> > >>> Hi, > >>> > >>> I think it's probably worth discussing module dependency a bit. I > >>> believe that it will be important for the API module (if we make > >>> such > >>> a module) to depend on the non-API modules internally. IOW, the code > >>> blocks of some of the classes in the API module will need to use > >>> non-API classes. I don't see this as a problem, but thought it would > >>> be worth pointing out. > >>> > >>> It also is relevant because it means that we can directly use the > >>> symbolic constants as the enum ordinal values. > >>> > >>> -Patrick > >>> > >>> -- > >>> Patrick Linskey > >>> 202 669 5907 > >> > >> > > > > > > -- > > Patrick Linskey > > 202 669 5907 > > -- Patrick Linskey 202 669 5907
