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
