Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Wed, 08 Aug 2007 17:45:59 -0700
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Re: API discussion: dependencies between modules
In-reply-to: <7262f25e0708081715x1f66aa95x80d45e290afd79c9@mail.gmail.com>
Sender: Craig.Russell@Sun.COM
To: dev@openjpa.apache.org
Message-id: <7BE78FA6-C7EE-46A7-B6CF-18C347D4C59D@SUN.com>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 boundary=Apple-Mail-265-7245521; micalg=sha1
References: <7262f25e0708081436y7c3ce76en2c5eb98779b568f2@mail.gmail.com>
 <4A889F23-F437-49A2-A3A9-059DF4147E62@apache.org>
 <7262f25e0708081448h1f03bfadh209735339a50db58@mail.gmail.com>
 <2FD0AD3B-1C83-4FFD-A878-5D47CDC5A005@apache.org>
 <7262f25e0708081715x1f66aa95x80d45e290afd79c9@mail.gmail.com>

--Apple-Mail-265-7245521
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed


On Aug 8, 2007, at 5:15 PM, Patrick Linskey wrote:

>> 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?

Well, as we discussed, it's easier for our customers to do now than  
later when we will have hundreds more customers. And I do think that  
the current interfaces have way too much stuff in them.

I don't know that I've seen this possibility discussed, which would  
make the transition easier:

Take the current o.a.o.persistence.OpenJPAEntityManager and split it  
into two interfaces, with only the user-intentioned methods left in  
the original interface, and the rest in the new interface.

So, now:

interface OpenJPAEntityManager
     extends EntityManager, EntityTransaction,  
javax.resource.cci.Connection,
     javax.resource.cci.LocalTransaction,  
javax.resource.spi.LocalTransaction,
     Closeable, ConnectionRetainModes, DetachState, RestoreState,  
AutoDetach,
     AutoClear, CallbackModes {
...
     /**
      * Return the (mutable) fetch plan for loading objects from this
      * entity manager.
      */
     public FetchPlan getFetchPlan();

...
     /**
      * Return the managed runtime in use.
      */
     public ManagedRuntime getManagedRuntime();

...}

becomes

interface OpenJPAEntityManager
     extends EntityManager {
...
     /**
      * Return the (mutable) fetch plan for loading objects from this
      * entity manager.
      */
     public FetchPlan getFetchPlan();

...
package org.apache.openjpa.persistence.internal

interface OpenJPAEntityManagerInternal extends OpenJPAEntityManager,
     EntityTransaction, javax.resource.cci.Connection,
     javax.resource.cci.LocalTransaction,  
javax.resource.spi.LocalTransaction,
     Closeable, ConnectionRetainModes, DetachState, RestoreState,  
AutoDetach,
     AutoClear, CallbackModes {
...
     /**
      * Return the managed runtime in use.
      */
     public ManagedRuntime getManagedRuntime();

...}

Craig
>
> -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

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


--Apple-Mail-265-7245521
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw
ggJyoAMCAQICECpJVMO68ii+Xfsc1O1YYFIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MTIwOTE5NTEwNVoXDTA3MTIwOTE5NTEw
NVowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny
YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMNAB4Ih+ShsCt89HzqIdwEx8L4o1UHiY6V7
16mrCedfd4Y0/uI7z9Zam8ysgEh+F7aDnQEKmEsVFN35G4nPMfLU6dZYkvADwUjbq82t/dJ3FDDg
Q945nHHpqECZff/S/UMho9AFfj6PZvZBAlDCJAayb4RdKIlfuvPW9YcQStQ1IfVJcVuKnC0Q+tdc
a4A7zn7IzLOQohO1lTc3hXSBigEIGiGYn6Ny0wmexfA3X1WsXekFx5czd+M4GjDjswn8CNoBmnBr
jOTGK1mOsXR6GSRHnly2s9xTdE4qv9qimM+7C2yzMHbKcszV7OQoLsRsZKDh+6u9wYU+TrjcY4ym
bA8CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQEFBQADgYEAU/EpPDztnb55Fz7iGSVm1mYEVj5m2OQKTYG26POUAomCBRrt
/CdBBvqYmcHUTpra0qLELHAQadYFl2v11iQkqwF5PPJs19oU/zA0m5qFnOMTAiCvel7IprIwA2r6
eJR9siaPwDRgVJ/Sj71dD+utwf+nRrNy0/7PMNK5y+ocsYQwggM/MIICqKADAgECAgENMA0GCSqG
SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH
EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp
Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw
NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE
cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef
kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB
AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js
LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD
VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+
hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC
3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECECpJVMO68ii+Xfsc1O1YYFIwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwODA5MDA0NTU5WjAjBgkqhkiG9w0B
CQQxFgQUcg2WbthqinCy3tUOHfUA/790aKgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqSVTDuvIovl37HNTtWGBSMIGHBgsqhkiG
9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAq
SVTDuvIovl37HNTtWGBSMA0GCSqGSIb3DQEBAQUABIIBAJwQxPSpgAq8c6y0f96pawc9FJe9Nf31
if45EXt2Y7R8ecsk+e1gJ6jPE58+IMsZhZ9aWwVQmdZih/fhI6ai+iwbOuHYsFVAPyNEFecDTp8b
aXHR1ToJrxm6oiXMsXOlHYkTwsk7zIfENtbWu8qQqBSdL7JzAAw0Z/PCmI9BR88X/7iSf5E3+XWR
U6PaqkAttJha/K4+rXBwlRkCxqE/4Ki88SCxCsCwg3ST0JM7g2J6UtZBuswG0agSxdfb7FHt7K8q
5LQGPSuc3shA18GRFKhjSHajpDCA1gmQzN7yFDJXRwZ5OGVhGjkidaEZpRcK3iKdSuSjTvERbe6Q
kKXebCQAAAAAAAA=

--Apple-Mail-265-7245521--