Re: JPA crossroads

From: Andrey Razumovsky (razumovsky.andre..mail.com)
Date: Mon Apr 06 2009 - 05:18:22 EDT

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

    Just curious, how much of JPA spec is currently supported? Can it possibly
    be all covered ever before it will become obsolete?

    2009/4/6 Andrus Adamchik <andru..bjectstyle.org>

    > NDA is not such a big hurdle for a potential contributor. You just sign it
    > and that's it. Somehow no such contributors materialized even when JPA was a
    > new frontier (compared to now when there's a bunch of alternative providers,
    > and we don't have a way to differentiate ourselves).
    >
    > The reasons for splitting that code are related to reducing the overhead we
    > will incur. Namely:
    >
    > 1. We need to get JPA out of the releases, including documentation. (If we
    > don't ship the libs, keeping the docs does not make sense).
    >
    > 2. Updating JPA classes as Cayenne core API evolves and ensuring all the
    > tests still pass requires extra effort. This is not a huge deal now, but I
    > expect it to become a drag in 3.1+, as we start diverging from JPA in things
    > like callbacks, etc.
    >
    > But I agree that doing the proposed reorg is a strategical decision in a
    > sense that we are sending a clear signal to the community: there will be no
    > Cayenne JPA. At least this is honest. I am doing that reluctantly,
    > considering how many man-months I spent on that. The consolation is that we
    > filled the blanks in Cayenne core as a result, while staying true to Cayenne
    > user-friendly origins. This is something to build upon.
    >
    > Andrus
    >
    >
    >
    > On Apr 6, 2009, at 11:48 AM, Aristedes Maniatis wrote:
    >
    >> On 06/04/2009, at 5:55 PM, Andrus Adamchik wrote:
    >>
    >> Since we are not shipping JPA with 3.0, and further future of this line
    >>> of development is undefined, we need to make some decisions now. I suggest
    >>> doing what we did for DataViews - a separate location in SVN, and a separate
    >>> wiki space. If this effort is revived (of which I have very strong doubts),
    >>> we'll get it back to the main subtree.
    >>>
    >>
    >> What is the downside of just leaving it as is? The framework is nicely
    >> separated as a separate maven/eclipse project, and moving the documentation
    >> to be a second class citizen will only discourage anyone else from working
    >> on it.
    >>
    >> As it is, there is perhaps more chance of someone finding it interesting
    >> and working on it, although the hurdles of signing the NDA, etc make that
    >> less likely.
    >>
    >> Ari
    >>
    >>
    >>
    >> -------------------------->
    >> 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 : Mon Apr 06 2009 - 05:18:55 EDT