openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: API discussion: dependencies between modules
Date Wed, 08 Aug 2007 21:53:04 GMT

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


Mime
View raw message