Re: API discussion: dependencies between modules

[Craig L Russell]

On Aug 8, 2007, at 5:15 PM, Patrick Linskey wrote:

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?

So, now:

interface OpenJPAEntityManager

    AutoClear, CallbackModes {
...
    /**
     * Return the (mutable) fetch plan for loading objects from this
     * entity manager.
     */
    public FetchPlan getFetchPlan();

...
    /**
     * Return the managed runtime in use.
     */
    public ManagedRuntime getManagedRuntime();

...}

becomes

interface OpenJPAEntityManager
    extends EntityManager {
...
    /**
     * Return the (mutable) fetch plan for loading objects from this
     * entity manager.
     */
    public FetchPlan getFetchPlan();

...
package org.apache.openjpa.persistence.internal

interface OpenJPAEntityManagerInternal extends OpenJPAEntityManager,
    EntityTransaction, javax.resource.cci.Connection,

    AutoClear, CallbackModes {
...
    /**
     * Return the managed runtime in use.
     */
    public ManagedRuntime getManagedRuntime();

...}

Craig

Well, as we discussed, it's easier for our customers to do now than later when we will have hundreds more customers. And I do think that the current interfaces have way too much stuff in them. I don't know that I've seen this possibility discussed, which would make the transition easier: Take the current o.a.o.persistence.OpenJPAEntityManager and split it into two interfaces, with only the user-intentioned methods left in the original interface, and the rest in the new interface. extends EntityManager, EntityTransaction, javax.resource.cci.Connection, javax.resource.cci.LocalTransaction, javax.resource.spi.LocalTransaction, Closeable, ConnectionRetainModes, DetachState, RestoreState, AutoDetach, javax.resource.cci.LocalTransaction, javax.resource.spi.LocalTransaction, Closeable, ConnectionRetainModes, DetachState, RestoreState, AutoDetach,

-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


-Patrick

On 8/8/07, Marc Prud'hommeaux <[EMAIL PROTECTED]> wrote:

inside the API module rather than adding the SomeInternalClass style.

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

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:

This is a show-stopper if we were to refactor the code into different methods that is opaque to the user, and which SomeInternalClass will

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

blocks of some of the classes in the API module will need to use

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

a module) to depend on the non-API modules internally. IOW, the code non-API classes. I don't see this as a problem, but thought it would

--
Patrick Linskey
202 669 5907

--
Patrick Linskey
202 669 5907

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature