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
