FYI, JPA TCK has very low coverage over the spec itself, that said being compliant is certainly not a portability label.
You will only get portability if you test your jpa code against all implementations and find the lowest common denominator. -----Message d'origine----- De : Thierry Lach [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 février 2008 17:34 À : continuum-dev@maven.apache.org Objet : Re: [Discussion] Continuum 2.0 Roadmap 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > 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 > > > >
