Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44E09A1D.8040009@apache.org>
Date: Mon, 14 Aug 2006 09:43:25 -0600
From: Jeff Genender <jgenender@apache.org>
Reply-To: jgenender@apache.org
Organization: Apache Geronimo
User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: JPA Plugin Status
References: <74e15baa0608132024m6011c9cds259f084c33ffc52c@mail.gmail.com>
	 <44E06824.9070007@apache.org>
 <74e15baa0608140839q7383d476vd049b0ee8800b1d7@mail.gmail.com>
In-Reply-To: <74e15baa0608140839q7383d476vd049b0ee8800b1d7@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Excellent!

Aaron Mulder wrote:
> OK, now it should work if you don't set up a provider but just bundle
> all the needed stuff in your WAR or set up your dependencies right.
> I'd still prefer to use the provider registry for the ones we know of,
> since then we can let you manage them in the console, perhaps support
> default properties to be applied to all apps for that provider, etc.
> 
> Thanks,
>    Aaron
> 
> On 8/14/06, Jeff Genender <jgenender@apache.org> wrote:
>> Aaron,
>>
>> Why do you need to have vendor code?  Why can't this be a bit more
>> dynamic?  Long term, I think its a bad idea to have to declare a vendor
>> wrapped API when our competitors just need to dump the provider jars in
>> a directory somewhere or include them in a deployment.  Basically,
>> anyone who wants to use a provider that we haven't supported has to
>> write vendor G-only code...right?  If this is the case, I think that is
>> a bit burdensome.  Thoughts?
>>
>> Jeff
>>
>> Aaron Mulder wrote:
>> > The code for the app-managed-JPA-for-web-apps plugin is up at SVN
>> > https://svn.sourceforge.net/svnroot/gplugins/jpa/trunk
>> >
>> > So far, it's just got a TopLink provider, but if people want to copy
>> > that to create providers for Cayenne or OpenJPA or whatever, that
>> > would be great.  It basically just needs to have a customized name and
>> > ClassPath, though I'm assuming any provider we integrate with will be
>> > compatible with the Geronimo JPA spec JAR (currently
>> > org.apache.geronimo.specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/jar)
>> >
>> > If you try to build and run this, you'll be held up by a couple things:
>> > * It needs the latest car-maven-plugin, and I'm not sure whether
>> > Jason has pushed a fresh snapshot since the last changes to it
>> > * It needs Geronimo 1.1 CARs in the M2 repo, and Matt has said
>> > posting those is on his to-do list
>> > * It only runs in Geronimo 1.1.1 due to reference resolution bugs in
>> > G 1.1, and currently the G 1.1.1 build is broken
>> >
>> > But if you get past all that (or comment out the plugins child from
>> > the main POM to avoid the first two issues) and run your server under
>> > Java 5, you can deploy web apps using JPA.  :)
>> >
>> > My goal is to have a release of this plugin with sufficient user
>> > documentation when G 1.1.1 is released.  It would be great to have
>> > some open source JPA providers for that release too.
>> >
>> > I also started talking to David B about the JPA work being done in
>> > OpenEJB, and I think we're agreed that we probably don't need two such
>> > plugins for G 1.1.x, so hopefully we can work toward a unification as
>> > we move forward.
>> >
>> > Thanks,
>> >     Aaron
>>