Re: JPA crossroads

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Thu Apr 09 2009 - 02:03:48 EDT

  • Next message: Andrus Adamchik: "Re: JPA crossroads"

    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