What needs to be moved out is "cayenne-jpa-unpublished" (and the
corresponding itest modules), NOT the lifecycle events or EJBQL stuff
in "cayenne-jdk1.5-unpublished" - these we will keep. As I mentioned
before we are legally prohibited by the JSR license agreement from
releasing non-compliant provider as a final release. So we can't make
3.0-final that includes classes from "cayenne-jpa-unpublished". This
was the driving factor behind this discussion. Having to support API
compliance of the backend is also a consideration, albeit minor for now.
Andrus
On Apr 9, 2009, at 2:57 AM, Aristedes Maniatis wrote:
> On 09/04/2009, at 7:26 AM, Robert Zeigler wrote:
>
>> I've always considered specs like JPA to be, well, a bit of a pipe
>> dream. Once upon a time, I thought I cared about the ability to
>> switch between persistence providers. But then I realized that,
>> no, actually, I really don't. Persistence is an area where you
>> choose a provider based on differences from rather than
>> similarities to other providers. Even having an opportunity last
>> year to do a significant amount of work with a (largely) JPA shop
>> didn't really change my perspective; they still found areas where
>> the spec wasn't enough, where they had to lean on hibernate-
>> specific features. At that point, the "happy promise" of "switch
>> providers anytime" is broken. So, I'm with Andrus: let's not be
>> afraid to adopt /good/ ideas in other frameworks, but also forge
>> ahead where we're strong.
>
> I'm still unsure why anything has to be done about this now within
> Cayenne. Yes, there is a 80% JPA solution in there. Many people use
> bits of it: lifecycle events, EJBQL, etc
>
> I'm not clear what would be removed or why anything would be
> removed. What not just change the documentation to reflect the fact
> that the JPA is not a current goal but there are plenty of parts of
> it which are implemented which will make migration from other
> frameworks simpler (but not automatic). For example, we have
> lifecycle events which match the JPA but we agree they aren't all
> the ideal. So we could add more, but still leave those existing
> hooks in place for people coming from a tool where they are
> supported and where they don't want to rewrite too much code.
>
> JPA is a useful marketing moniker. It will help (sometimes) get
> Cayenne across the line with management in some organisations just
> by having a section of the docs that discusses it, even if
> ultimately the development team don't use any part of it.
>
> JPA pages on the Cayenne site make up 2.14% of page views (not
> including javadocs) but are less likely than other pages on the site
> to be the last page a reader looks at before leaving (that is, they
> tend to go on to read other parts of the site).
>
>
> Ari Maniatis
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
This archive was generated by hypermail 2.0.0 : Thu Apr 09 2009 - 02:04:27 EDT