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
