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
