From dev-return-5404-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Thu Aug 09 00:16:07 2007 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 75203 invoked from network); 9 Aug 2007 00:16:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Aug 2007 00:16:06 -0000 Received: (qmail 63129 invoked by uid 500); 9 Aug 2007 00:16:05 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 63093 invoked by uid 500); 9 Aug 2007 00:16:05 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 63084 invoked by uid 99); 9 Aug 2007 00:16:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Aug 2007 17:16:05 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of plinskey@gmail.com designates 64.233.166.183 as permitted sender) Received: from [64.233.166.183] (HELO py-out-1112.google.com) (64.233.166.183) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Aug 2007 00:16:01 +0000 Received: by py-out-1112.google.com with SMTP id f31so540966pyh for ; Wed, 08 Aug 2007 17:15:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hJ0LMJn8ASpbG3e8HiEIulyVUMfdXmQ5aVcOtZhA0tKA9ovYHmQ15XUzJOe8HXvUXmPC002cNEmDUCNSXncSS4YTDKKUprS1VgWCOHemJhVHlaMSdeea00xToYFK05RdYpv+h6xDxbSdSDt6wch7EyxXipumA6LfbvLsHud8Bm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OpMpAdFmOTOQzfi4HtQsMjcv+zZX+cHrGUjjAyBUIX6rDuHak5OaYaZuU9NifVSZ2QtpIQcyW5mGgjUXxx1DvTKImoJARXUoWyVPO9V2hQ7jPZRBDNZEwuaz2AZ4ru48g5dKkz+pP2XFyCPLxTr4AnI5xXscYlMqs9rUs7ux2Ms= Received: by 10.35.110.13 with SMTP id n13mr2426884pym.1186618540631; Wed, 08 Aug 2007 17:15:40 -0700 (PDT) Received: by 10.35.8.4 with HTTP; Wed, 8 Aug 2007 17:15:40 -0700 (PDT) Message-ID: <7262f25e0708081715x1f66aa95x80d45e290afd79c9@mail.gmail.com> Date: Wed, 8 Aug 2007 17:15:40 -0700 From: "Patrick Linskey" To: dev@openjpa.apache.org Subject: Re: API discussion: dependencies between modules In-Reply-To: <2FD0AD3B-1C83-4FFD-A878-5D47CDC5A005@apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7262f25e0708081436y7c3ce76en2c5eb98779b568f2@mail.gmail.com> <4A889F23-F437-49A2-A3A9-059DF4147E62@apache.org> <7262f25e0708081448h1f03bfadh209735339a50db58@mail.gmail.com> <2FD0AD3B-1C83-4FFD-A878-5D47CDC5A005@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org > 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? -Patrick On 8/8/07, Marc Prud'hommeaux 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 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