openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@gmail.com>
Subject Re: API discussion: dependencies between modules
Date Thu, 09 Aug 2007 00:15:40 GMT
> 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 <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

Mime
View raw message