Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: continuum-dev@maven.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-Id: <FB6B65C0-575B-4E4E-9FB9-0DA69E8FB4BD@israfil.net>
From: Christian Edward Gruber <cgruber@israfil.net>
To: continuum-dev@maven.apache.org
In-Reply-To: <495914f00802060833q1daf41f6xe331dddad084b61c@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Subject: Re: [Discussion] Continuum 2.0 Roadmap
Mime-Version: 1.0 (Apple Message framework v915)
Date: Wed, 6 Feb 2008 12:04:36 -0500
References: <f345f3480801291434y232263d3q2257fa0fcfd82679@mail.gmail.com>
 <1a5b6c410802051612y4ae82330i878202576583a11d@mail.gmail.com>
 <16978026-20BB-4EBD-8AFE-110B49EAB422@israfil.net>
 <495914f00802060833q1daf41f6xe331dddad084b61c@mail.gmail.com>

Sorry, that was sort of my point - many implementation-specific tricks  
make it into OR/M configuration, and sometimes code. Or rather  
assumptions about subtle behaviour or one ORM are factored into the  
design, but another ORM may not perform in the same way under the same  
conditions because it's internally optimized differently.

Also, unfortunately, a lot of this configuration ends up in  
Annotations in JPA, so the code is not really portable POJOs.  So  
while it can be largely swappable, let's just not get fooled into  
thinking it's "easily swappable without effort" and then do no due- 
diligence around what the default JPA implementation would be.

Having said that, JPA itself is based on a much stronger approach to  
ORM than many previous ones, and if Toplink provides reference  
implementation code then I'd be inclined to trust it.  It's one of the  
most battle-tested ORM's out there.  Of course hibernate has much more  
currency in the open-source community.

Christian.

On 6-Feb-08, at 11:33 , Thierry Lach wrote:

> Hibernate can be used in a completely JPA-compliant mode, so it  
> would be
> (theoretically) just as swappable as any other JPA implementation as  
> long as
> you don't use any hibernate-specific extensions.
>
> On Feb 5, 2008 10:12 PM, Christian Edward Gruber <cgruber@israfil.net>
> wrote:
>
>> Toplink is mentioned, but it's a commercial app, and I don't think
>> they'll license it in a way that's compatible (unless they've
>> radically changed policies recently).  I'm not a huge hibernate fan,
>> but at least its supported.  At least with JPA and decent  
>> abstraction,
>> you should be able to have more "swapability" though at the O/R-M
>> level I find it's rare to get true swapability.
>>
>> I've been using and supporting spring for a long time, but after  
>> doing
>> some tapestry work, and re-thinking IoC approaches, I'm moving in
>> favor of picocontainer.  Tapestry doesn't use picocontainer but has  
>> an
>> IoC framework that's got some similar design concepts.  Actually,  
>> that
>> gets to another point, which is that Tapestry is happy and easy and
>> fun (well, T5), and since it comes with an IoC framework that can
>> integrate cleanly with Spring if we want that benefit, you can get  
>> the
>> whole kit together.
>>
>> The other nice thing about Tapestry, is that several people have made
>> "quickstart" projects which include everything Continuum would likely
>> use including Spring, spring-acegi, hibernate/jpa, etc.  One could  
>> use
>> that as a structural basis, and T5 is (currently) built with maven,
>> and will at least be deployed to maven repositories in perpetuity.
>>
>> Christian.
>>
>>
>> On 5-Feb-08, at 19:12 , Carlos Sanchez wrote:
>>
>>> Some comments
>>>
>>> Database vs xml: definitely database. Throwing away the db access  
>>> api
>>> (JDO/JPA/...) now that it's already there doesnt make much sense.
>>> Maybe there are implementations that use xml for storage and that's
>>> where you'd need to look if you want file storage
>>>
>>> Spring vs Guice vs Plexus: Spring for sure. Big community, lots of
>>> users, documentation, support,... Specially if you want to add JMX
>>> support (can be done really easily just with annotations using
>>> reflection), and thinking in OSGi in the future I'm sure it will be
>>> really easy to integrate Spring and OSGi if it is not already. I'd
>>> start softly, just migrating thing that would require adding  
>>> features
>>> to plexus, and move from there.
>>>
>>> I agree with Brett on having 1.2, 1.3,... it's good to have a list  
>>> of
>>> what you want to do for 2.0 but as it gets done it should be  
>>> released
>>> in minor versions.
>>>
>>> On Jan 29, 2008 2:34 PM, Emmanuel Venisse <emmanuel@venisse.net>
>>> wrote:
>>>> Hi
>>>>
>>>> I started a document [1] with my ideas about Continuum 2.
>>>> As you can see in this doc, I want to add lot of things in the next
>>>> version.
>>>>
>>>> Feel free to comment on it.
>>>>
>>>>
>>>> [1]
>>>>
>> http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion
>>>>
>>>> Emmanuel
>>>>
>>>
>>>
>>>
>>> --
>>> I could give you my word as a Spaniard.
>>> No good. I've known too many Spaniards.
>>>                            -- The Princess Bride
>>>
>>
>>