I.e. the soul searching part of this discussion is a separate issue of
Cayenne direction. Excluding provider from the release is a legal
prerequisite for 3.0 final.
Andrus
On Apr 9, 2009, at 9:03 AM, Andrus Adamchik wrote:
> 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:07:56 EDT