Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of mprudhomapache@gmail.com
 designates 64.233.162.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=hOojmC8NLsiWtr+ZfaMtdxmnUVKcvujnmu7oMPFUm0PMET2Skcy68A9AtlBtKsnkEjlLqbxVfnbtAbmh0T6vcUHwnOiv9o8W4AfnJbguUvC46Y+KFAae1i+itnRXIXRtXjPNAd9l8351Ov5PaeceFVnLm2ecJEokuZPSqTdELiE=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <72c1350f0708081147w75594b41s5aa302fcdbaffebe@mail.gmail.com>
References: <7262f25e0708071344x22d55055k38e77e2c9f590124@mail.gmail.com>
 <72c1350f0708081147w75594b41s5aa302fcdbaffebe@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <23BB6930-A539-4E21-A8D6-6A26EA50D078@apache.org>
Content-Transfer-Encoding: 7bit
From: Marc Prud'hommeaux <mprudhom@apache.org>
Subject: Re: API discussion
Date: Wed, 8 Aug 2007 12:07:09 -0700
To: dev@openjpa.apache.org
Sender: Marc Prud'hommeaux <mprudhomapache@gmail.com>


-0. I very much like the idea of separating out our published APIs  
into maven modules (both because we would then have the  
infrastructure to enforce that incompatible changes don't get  
introduces in minor releases, as well as having the ability to easily  
publish an API jar should we so desire).

However, I am concerned with the refactoring. In my experience with  
changing package names, while trivial to implement, always leads to  
problems. Since we don't currently support OSGi (I don't think we  
have even discussed OSGi plans in the lists), I don't see why we need  
to bind goal A (separating of the API/SPI into separate packages)  
with goal B (moving the implementations into different sub-packages).  
We underwent a fair amount of effort to ship only a single aggregate  
jar of all of OpenJPA, rather than jars for each of the individual  
modules, so this wouldn't even affect anyone currently using OpenJPA  
in any context other than having a Maven dependency on the separate  
module jars.

That being said, I'll just vote a -0, and will happily accede to the  
sentiment of the community should it differ with mine.


On Aug 8, 2007, at 11:47 AM, Michael Dick wrote:

> <snip>
>
> 2. Break the openjpa-persistence and openjpa-persistence-jdbc modules
>> into separate modules for API and SPI. This would require repackaging
>> the current impl classes (EntityManagerImpl etc.) into a new
>> sub-package, in order to work with the OSGi model (it is my
>> understanding that OSGi does not allow multiple bundles (jars) to
>> contribute to the same package), but would provide strong compile- 
>> time
>> guarantees and a more formal contract.
>
>
> +1
>
> Having a separate maven module for the APIs should be easier to  
> consume for
> other maven users. Also this approach seems easier to maintain once  
> we're
> done. If we invent a build procedure we'll have to ensure that it's
> compatible with maven version.next.
>
> The impact to current users should be minimal if we only change the  
> packages
> on implementation classes and shouldn't raise too many red flags  
> since we
> haven't shipped v1.0 yet.
>
> -Mike