openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: API discussion: dependencies between modules
Date Thu, 09 Aug 2007 00:45:59 GMT

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?

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.

So, now:

interface OpenJPAEntityManager
     extends EntityManager, EntityTransaction,  
javax.resource.cci.Connection,
     javax.resource.cci.LocalTransaction,  
javax.resource.spi.LocalTransaction,
     Closeable, ConnectionRetainModes, DetachState, RestoreState,  
AutoDetach,
     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,
     javax.resource.cci.LocalTransaction,  
javax.resource.spi.LocalTransaction,
     Closeable, ConnectionRetainModes, DetachState, RestoreState,  
AutoDetach,
     AutoClear, CallbackModes {
...
     /**
      * Return the managed runtime in use.
      */
     public ManagedRuntime getManagedRuntime();

...}

Craig
>
> -Patrick
>
> On 8/8/07, Marc Prud'hommeaux <mprudhom@apache.org> 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 <mprudhom@apache.org> 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

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


Mime
View raw message