You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Patrick Linskey <pl...@gmail.com> on 2007/08/08 23:36:01 UTC
API discussion: dependencies between modules
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
Re: API discussion: dependencies between modules
Posted by Craig L Russell <Cr...@Sun.COM>.
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 <mp...@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 <mp...@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!
Re: API discussion: dependencies between modules
Posted by Patrick Linskey <pl...@gmail.com>.
> 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 <mp...@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 <mp...@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
Re: API discussion: dependencies between modules
Posted by Marc Prud'hommeaux <mp...@apache.org>.
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 <mp...@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
Re: API discussion: dependencies between modules
Posted by Patrick Linskey <pl...@gmail.com>.
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 <mp...@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
Re: API discussion: dependencies between modules
Posted by Marc Prud'hommeaux <mp...@apache.org>.
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