You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2009/04/06 09:55:40 UTC
JPA crossroads
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.
Comments?
Andrus
Re: JPA crossroads
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
>>
>>
>>
>
>
Re: JPA crossroads
Posted by Andrus Adamchik <an...@objectstyle.org>.
My last attempt to implement generics led me to a conclusion that this
is too big of an issue that late in the game for 3.0. We need to do
lots of backend changes to make it tight. Here is a few things that I
feel are important prerequisites: get rid of DataRows (or at least
stop exposing them to the users); merge SelectQuery and EJBQLQuery in
a single type-safe object query. In other words, I suggest to
reschedule that for the release after 3.0.
Andrus
On Apr 11, 2009, at 2:33 PM, Aristedes Maniatis wrote:
> On 11/04/2009, at 8:54 PM, Andrus Adamchik wrote:
>
>> Otherwise the list is probably along the lines of "(1) implement
>> the inheritance ; (2) fix bugs".
>
> (3) finalise the decisions about generics (since that changes the
> API which we'd prefer to do once and not again too soon).
>
> Andrus, you had the strongest ideas about the query generics API.
> Would you like to restate your proposal. We have two new team
> members since we last discussed that and they might like to put
> forward their ideas.
>
> Cheers
>
> 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
>
>
>
Re: JPA crossroads
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 11/04/2009, at 8:54 PM, Andrus Adamchik wrote:
> Otherwise the list is probably along the lines of "(1) implement the
> inheritance ; (2) fix bugs".
(3) finalise the decisions about generics (since that changes the API
which we'd prefer to do once and not again too soon).
Andrus, you had the strongest ideas about the query generics API.
Would you like to restate your proposal. We have two new team members
since we last discussed that and they might like to put forward their
ideas.
Cheers
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
Re: JPA crossroads
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Apr 9, 2009, at 10:22 PM, Andrey Razumovsky wrote:
> But I really feel that Cayenne should rise another strict "plan for
> 3.0". It's much simplier to tell users that Cayenne's going to grow
> and
> improve when you have one.
For 3.0 it is mostly finishing the features that are already there. Of
course we are in a feature creep situation, when instead of finishing
the existing features, we start the new ones, previously unexpected
(case in point, me initiating schema update strategy and Cayenne
monitoring tasks recently)... :-/
Otherwise the list is probably along the lines of "(1) implement the
inheritance ; (2) fix bugs".
Andrus
Re: JPA crossroads
Posted by Andrey Razumovsky <ra...@gmail.com>.
I've never used JPA as it is, so I don't have any objections for excluding
it. But I really feel that Cayenne should rise another strict "plan for
3.0". It's much simplier to tell users that Cayenne's going to grow and
improve when you have one.
About Cayenne and Web 2.0.. This is a theme I would like to discuss.
Currently I'm using Cayenne and GWT (not Cayenne *with* GWT) and JSON for
transporting data between client and server. I, however, dream of something
ROP-like in GWT. There are two major disparities - the lack of synchronious
requests and the lack of Reflection, which make it a far target. I'm
planning to do some research in this someday.
2009/4/9 Andrus Adamchik <an...@objectstyle.org>
> While generally I have no objections to doing it one step at a time, let's
> look at the practical side of it. At the minimum we'll need to exclude
> cayenne-jpa-unpublished from cayenne-server aggregated artifact. This is
> easy and non-invasive. But... we'll also need to remove the JPA docs from
> the release bundle, and make a clear statement on the site about the JPA
> status ("not a part of Cayenne"). As a result it doesn't look like any
> marketing benefit will be preserved, so is it worth the trouble of going
> half way with it?
>
> Andrus
>
>
>
> On Apr 9, 2009, at 10:24 AM, Aristedes Maniatis wrote:
>
>
>> On 09/04/2009, at 4:03 PM, 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.
>>>
>>
>>
>> That makes sense. Could the simple solution for the legal issue be just a
>> change to the maven scripts so that JPA doesn't end up in the final
>> packaging. Then soul searching can be postponed for a while to let the dust
>> settle.
>>
>> 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
>>
>>
>>
>>
>
Re: JPA crossroads
Posted by Andrus Adamchik <an...@objectstyle.org>.
While generally I have no objections to doing it one step at a time,
let's look at the practical side of it. At the minimum we'll need to
exclude cayenne-jpa-unpublished from cayenne-server aggregated
artifact. This is easy and non-invasive. But... we'll also need to
remove the JPA docs from the release bundle, and make a clear
statement on the site about the JPA status ("not a part of Cayenne").
As a result it doesn't look like any marketing benefit will be
preserved, so is it worth the trouble of going half way with it?
Andrus
On Apr 9, 2009, at 10:24 AM, Aristedes Maniatis wrote:
>
> On 09/04/2009, at 4:03 PM, 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.
>
>
> That makes sense. Could the simple solution for the legal issue be
> just a change to the maven scripts so that JPA doesn't end up in the
> final packaging. Then soul searching can be postponed for a while to
> let the dust settle.
>
> 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
>
>
>
Re: JPA crossroads
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 09/04/2009, at 4:03 PM, 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.
That makes sense. Could the simple solution for the legal issue be
just a change to the maven scripts so that JPA doesn't end up in the
final packaging. Then soul searching can be postponed for a while to
let the dust settle.
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
Re: JPA crossroads
Posted by Andrus Adamchik <an...@objectstyle.org>.
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
>
>
>
Re: JPA crossroads
Posted by Aristedes Maniatis <ar...@ish.com.au>.
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
Re: JPA crossroads
Posted by Robert Zeigler <ro...@gmail.com>.
Good thoughts.
My $0.02:
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.
Robert
On Apr 8, 2009, at 4/83:56 PM , Andrus Adamchik wrote:
> I'll try to reply to the specific non-JPA items in this email in a
> separate thread. I should just say that *now* I share Michael's
> viewpoint. Below is a long version of the initial email that started
> this thread.
>
> A couple of years ago when I started on the JPA effort the dynamics
> was different. JPA was the first persistence standard by the Java
> Community Process that made any kind of sense, with the possibility
> to differentiate the providers behind the standard API facade (kind
> of like Tomcat and Jetty are very different beasts, even though both
> are standard-compliant servlet containers). My plan was to provide
> Java developers with a standard API built on the stable and tested
> Cayenne core, convincing enough of the hardcode J2EE crowd to switch
> to Cayenne (the audience that has been traditionally in the
> Hibernate camp).
>
> So I still think the plan was good, but a little too ambitious.
> First I was encouraged by a number of the new "volunteers" who
> emailed me privately offering help. And I do not mean people on this
> list who were happily using Cayenne for years and had no incentive
> to switch to JPA - that I can understand. Those were people totally
> new to the project, seemingly excited about the opportunity to work
> on a new framework, and at the end not a single person showed up. So
> there was a failure in building a developer community. Also I
> overestimated my own availability to do coding, which has shrunk
> significantly in the last two years. Racing against teams of full-
> time paid employees of big companies writing their own JPA providers
> ended up being a losing proposition (not complaining, just
> reflecting on the fact that I picked the wrong fight).
>
> So now we've gone a full circle back to "Cayenne the way it is
> supposed to be" :-). As mentioned elsewhere the time wasn't wasted.
> It was spent to compare head to head Cayenne and "mainstream" Java
> persistence models (conclusion: Cayenne model still gives the users
> the smoothest ride, but we shouldn't be ashamed to borrow the best
> ideas from others, and we need to evolve), sync up in a few areas
> (EJBQL, etc..), and keep improving our strong sides (ROP, Modeler,
> etc.)
>
> There's lots of things to look forward to in and after 3.0. So I
> wanted to turn this page and move ahead.
>
> Andrus
>
>
>
> On Apr 6, 2009, at 7:10 PM, Michael Gentry wrote:
>
>> On Mon, Apr 6, 2009 at 3:55 AM, Andrus Adamchik <andrus@objectstyle.org
>> > wrote:
>>> Comments?
>>
>> I fear this will be a bit long-winded, but I hope it will be
>> coherent.
>>
>> Having JPA in Cayenne has never been a selling point for me
>> personally. Chasing the JPA specification feels like a distraction
>> and almost like an admission that Cayenne classic (the "real" Cayenne
>> -- Cayenne's strength) isn't worthwhile. We may never get there and
>> the cost of chasing the JPA specification is that Cayenne classic
>> suffers. For people that want JPA, they'll almost always choose
>> Hibernate because it is popular and/or because it is driving the
>> specification. Even if Cayenne could satisfy someone's JPA checklist
>> requirement, they'd most likely find another reason to not use
>> Cayenne. That's fine. You can't appeal to everyone. Besides, the
>> J2EE world seems to chase a different silver bullet every few years
>> and JPA may evaporate as trends change.
>>
>> I think Cayenne should focus on what separates it from Hibernate/JPA
>> and, in my mind, makes it better, plus add new features that make
>> sense within the Cayenne world. Apple isn't gaining market share
>> from
>> Microsoft by trying to be more like Microsoft.
>>
>> Some examples:
>>
>> Improve Cayenne Modeler. This is a huge advantage of Cayenne over
>> Hibernate. It is very useful as-is, but has some weaknesses, such
>> as:
>> can't open multiple models at the same time, related DbEntity and
>> ObjEntity get too spread out in large models (too much scrolling),
>> relationship mapping could be easier, no way to browse the database
>> (I'm still working on my DBEdit clone, but it isn't close to finished
>> yet), getting rid of HSQLDB for the preferences, etc. The better the
>> modeler, the better the image of Cayenne -- especially to new users.
>> From Gavin King's comments in the past, he thinks GUIs are for wimps
>> and I don't think Hibernate will ever have one (in the core
>> distribution) as long as he is the driving force behind Hibernate.
>> This is a key distinguishing feature of Cayenne and should be
>> leveraged. Even Apple has dropped their EOModeler support in OS X
>> 10.5.
>>
>> Hibernate/JPA has nothing like an ObjectContext. This feature should
>> be emphasized more. I doubt Hibernate/JPA will incorporate one
>> anytime in the near future, either. This is another key
>> distinguishing feature.
>>
>> Enhance ROP. I've been looking at Cappuccino lately and am intrigued
>> by the idea of a robust web-based GUI that retrieves and saves all
>> data by JSON. (Yes, there are other Web 2.0 apps that make heavy use
>> of JSON, too.) If the Cayenne Web Service could vend data through
>> JSON instead of Hessian, it might appeal to more people looking to go
>> into Web 2.0.
>>
>> Better integration with Apache projects. The Click framework is now
>> in the Apache Incubator and includes Cayenne support. It would also
>> be nice to see Tapestry and Wicket include it, too. There aren't
>> really robust installers (like what Apple did with WebObjects), but
>> at
>> a minimum it would be nice if there were Maven archetypes for various
>> frameworks that could configure Cayenne support automatically.
>> Google
>> Summer of Code task, possibly?
>>
>> There are many other things (better marketing by having papers
>> published, providing support for larger companies that might be
>> willing to invest in it, etc), but I've been long-winded enough. All
>> of these things take time and effort, but I think having a clear
>> direction and goal would really help that, too.
>>
>> Thanks,
>>
>> mrg
>>
>> PS. I'm hoping for more comments, too ...
>>
>
Re: JPA crossroads
Posted by Andrus Adamchik <an...@objectstyle.org>.
I'll try to reply to the specific non-JPA items in this email in a
separate thread. I should just say that *now* I share Michael's
viewpoint. Below is a long version of the initial email that started
this thread.
A couple of years ago when I started on the JPA effort the dynamics
was different. JPA was the first persistence standard by the Java
Community Process that made any kind of sense, with the possibility to
differentiate the providers behind the standard API facade (kind of
like Tomcat and Jetty are very different beasts, even though both are
standard-compliant servlet containers). My plan was to provide Java
developers with a standard API built on the stable and tested Cayenne
core, convincing enough of the hardcode J2EE crowd to switch to
Cayenne (the audience that has been traditionally in the Hibernate
camp).
So I still think the plan was good, but a little too ambitious. First
I was encouraged by a number of the new "volunteers" who emailed me
privately offering help. And I do not mean people on this list who
were happily using Cayenne for years and had no incentive to switch to
JPA - that I can understand. Those were people totally new to the
project, seemingly excited about the opportunity to work on a new
framework, and at the end not a single person showed up. So there was
a failure in building a developer community. Also I overestimated my
own availability to do coding, which has shrunk significantly in the
last two years. Racing against teams of full-time paid employees of
big companies writing their own JPA providers ended up being a losing
proposition (not complaining, just reflecting on the fact that I
picked the wrong fight).
So now we've gone a full circle back to "Cayenne the way it is
supposed to be" :-). As mentioned elsewhere the time wasn't wasted. It
was spent to compare head to head Cayenne and "mainstream" Java
persistence models (conclusion: Cayenne model still gives the users
the smoothest ride, but we shouldn't be ashamed to borrow the best
ideas from others, and we need to evolve), sync up in a few areas
(EJBQL, etc..), and keep improving our strong sides (ROP, Modeler, etc.)
There's lots of things to look forward to in and after 3.0. So I
wanted to turn this page and move ahead.
Andrus
On Apr 6, 2009, at 7:10 PM, Michael Gentry wrote:
> On Mon, Apr 6, 2009 at 3:55 AM, Andrus Adamchik <andrus@objectstyle.org
> > wrote:
>> Comments?
>
> I fear this will be a bit long-winded, but I hope it will be coherent.
>
> Having JPA in Cayenne has never been a selling point for me
> personally. Chasing the JPA specification feels like a distraction
> and almost like an admission that Cayenne classic (the "real" Cayenne
> -- Cayenne's strength) isn't worthwhile. We may never get there and
> the cost of chasing the JPA specification is that Cayenne classic
> suffers. For people that want JPA, they'll almost always choose
> Hibernate because it is popular and/or because it is driving the
> specification. Even if Cayenne could satisfy someone's JPA checklist
> requirement, they'd most likely find another reason to not use
> Cayenne. That's fine. You can't appeal to everyone. Besides, the
> J2EE world seems to chase a different silver bullet every few years
> and JPA may evaporate as trends change.
>
> I think Cayenne should focus on what separates it from Hibernate/JPA
> and, in my mind, makes it better, plus add new features that make
> sense within the Cayenne world. Apple isn't gaining market share from
> Microsoft by trying to be more like Microsoft.
>
> Some examples:
>
> Improve Cayenne Modeler. This is a huge advantage of Cayenne over
> Hibernate. It is very useful as-is, but has some weaknesses, such as:
> can't open multiple models at the same time, related DbEntity and
> ObjEntity get too spread out in large models (too much scrolling),
> relationship mapping could be easier, no way to browse the database
> (I'm still working on my DBEdit clone, but it isn't close to finished
> yet), getting rid of HSQLDB for the preferences, etc. The better the
> modeler, the better the image of Cayenne -- especially to new users.
> From Gavin King's comments in the past, he thinks GUIs are for wimps
> and I don't think Hibernate will ever have one (in the core
> distribution) as long as he is the driving force behind Hibernate.
> This is a key distinguishing feature of Cayenne and should be
> leveraged. Even Apple has dropped their EOModeler support in OS X
> 10.5.
>
> Hibernate/JPA has nothing like an ObjectContext. This feature should
> be emphasized more. I doubt Hibernate/JPA will incorporate one
> anytime in the near future, either. This is another key
> distinguishing feature.
>
> Enhance ROP. I've been looking at Cappuccino lately and am intrigued
> by the idea of a robust web-based GUI that retrieves and saves all
> data by JSON. (Yes, there are other Web 2.0 apps that make heavy use
> of JSON, too.) If the Cayenne Web Service could vend data through
> JSON instead of Hessian, it might appeal to more people looking to go
> into Web 2.0.
>
> Better integration with Apache projects. The Click framework is now
> in the Apache Incubator and includes Cayenne support. It would also
> be nice to see Tapestry and Wicket include it, too. There aren't
> really robust installers (like what Apple did with WebObjects), but at
> a minimum it would be nice if there were Maven archetypes for various
> frameworks that could configure Cayenne support automatically. Google
> Summer of Code task, possibly?
>
> There are many other things (better marketing by having papers
> published, providing support for larger companies that might be
> willing to invest in it, etc), but I've been long-winded enough. All
> of these things take time and effort, but I think having a clear
> direction and goal would really help that, too.
>
> Thanks,
>
> mrg
>
> PS. I'm hoping for more comments, too ...
>
Re: JPA crossroads
Posted by Mike Kienenberger <mk...@gmail.com>.
I'd agree with Michael, except that I'd say people are starting to
switch to EclipseLink rather than Hibernate since EL is now the
reference implementation for JPA 2.0.
I also agree that JPA has no modeler and nothing equivalent to
ObjectContext (unless you consider manually managing nested
transactions an object context). My primary client is now using JPA,
and these things are painfully obvious to me after using it.
On Mon, Apr 6, 2009 at 12:10 PM, Michael Gentry <mg...@masslight.net> wrote:
> On Mon, Apr 6, 2009 at 3:55 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>> Comments?
>
> I fear this will be a bit long-winded, but I hope it will be coherent.
>
> Having JPA in Cayenne has never been a selling point for me
> personally. Chasing the JPA specification feels like a distraction
> and almost like an admission that Cayenne classic (the "real" Cayenne
> -- Cayenne's strength) isn't worthwhile. We may never get there and
> the cost of chasing the JPA specification is that Cayenne classic
> suffers. For people that want JPA, they'll almost always choose
> Hibernate because it is popular and/or because it is driving the
> specification. Even if Cayenne could satisfy someone's JPA checklist
> requirement, they'd most likely find another reason to not use
> Cayenne. That's fine. You can't appeal to everyone. Besides, the
> J2EE world seems to chase a different silver bullet every few years
> and JPA may evaporate as trends change.
>
> I think Cayenne should focus on what separates it from Hibernate/JPA
> and, in my mind, makes it better, plus add new features that make
> sense within the Cayenne world. Apple isn't gaining market share from
> Microsoft by trying to be more like Microsoft.
>
> Some examples:
>
> Improve Cayenne Modeler. This is a huge advantage of Cayenne over
> Hibernate. It is very useful as-is, but has some weaknesses, such as:
> can't open multiple models at the same time, related DbEntity and
> ObjEntity get too spread out in large models (too much scrolling),
> relationship mapping could be easier, no way to browse the database
> (I'm still working on my DBEdit clone, but it isn't close to finished
> yet), getting rid of HSQLDB for the preferences, etc. The better the
> modeler, the better the image of Cayenne -- especially to new users.
> From Gavin King's comments in the past, he thinks GUIs are for wimps
> and I don't think Hibernate will ever have one (in the core
> distribution) as long as he is the driving force behind Hibernate.
> This is a key distinguishing feature of Cayenne and should be
> leveraged. Even Apple has dropped their EOModeler support in OS X
> 10.5.
>
> Hibernate/JPA has nothing like an ObjectContext. This feature should
> be emphasized more. I doubt Hibernate/JPA will incorporate one
> anytime in the near future, either. This is another key
> distinguishing feature.
>
> Enhance ROP. I've been looking at Cappuccino lately and am intrigued
> by the idea of a robust web-based GUI that retrieves and saves all
> data by JSON. (Yes, there are other Web 2.0 apps that make heavy use
> of JSON, too.) If the Cayenne Web Service could vend data through
> JSON instead of Hessian, it might appeal to more people looking to go
> into Web 2.0.
>
> Better integration with Apache projects. The Click framework is now
> in the Apache Incubator and includes Cayenne support. It would also
> be nice to see Tapestry and Wicket include it, too. There aren't
> really robust installers (like what Apple did with WebObjects), but at
> a minimum it would be nice if there were Maven archetypes for various
> frameworks that could configure Cayenne support automatically. Google
> Summer of Code task, possibly?
>
> There are many other things (better marketing by having papers
> published, providing support for larger companies that might be
> willing to invest in it, etc), but I've been long-winded enough. All
> of these things take time and effort, but I think having a clear
> direction and goal would really help that, too.
>
> Thanks,
>
> mrg
>
> PS. I'm hoping for more comments, too ...
>
Re: JPA crossroads
Posted by Michael Gentry <mg...@masslight.net>.
On Mon, Apr 6, 2009 at 3:55 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
> Comments?
I fear this will be a bit long-winded, but I hope it will be coherent.
Having JPA in Cayenne has never been a selling point for me
personally. Chasing the JPA specification feels like a distraction
and almost like an admission that Cayenne classic (the "real" Cayenne
-- Cayenne's strength) isn't worthwhile. We may never get there and
the cost of chasing the JPA specification is that Cayenne classic
suffers. For people that want JPA, they'll almost always choose
Hibernate because it is popular and/or because it is driving the
specification. Even if Cayenne could satisfy someone's JPA checklist
requirement, they'd most likely find another reason to not use
Cayenne. That's fine. You can't appeal to everyone. Besides, the
J2EE world seems to chase a different silver bullet every few years
and JPA may evaporate as trends change.
I think Cayenne should focus on what separates it from Hibernate/JPA
and, in my mind, makes it better, plus add new features that make
sense within the Cayenne world. Apple isn't gaining market share from
Microsoft by trying to be more like Microsoft.
Some examples:
Improve Cayenne Modeler. This is a huge advantage of Cayenne over
Hibernate. It is very useful as-is, but has some weaknesses, such as:
can't open multiple models at the same time, related DbEntity and
ObjEntity get too spread out in large models (too much scrolling),
relationship mapping could be easier, no way to browse the database
(I'm still working on my DBEdit clone, but it isn't close to finished
yet), getting rid of HSQLDB for the preferences, etc. The better the
modeler, the better the image of Cayenne -- especially to new users.
>From Gavin King's comments in the past, he thinks GUIs are for wimps
and I don't think Hibernate will ever have one (in the core
distribution) as long as he is the driving force behind Hibernate.
This is a key distinguishing feature of Cayenne and should be
leveraged. Even Apple has dropped their EOModeler support in OS X
10.5.
Hibernate/JPA has nothing like an ObjectContext. This feature should
be emphasized more. I doubt Hibernate/JPA will incorporate one
anytime in the near future, either. This is another key
distinguishing feature.
Enhance ROP. I've been looking at Cappuccino lately and am intrigued
by the idea of a robust web-based GUI that retrieves and saves all
data by JSON. (Yes, there are other Web 2.0 apps that make heavy use
of JSON, too.) If the Cayenne Web Service could vend data through
JSON instead of Hessian, it might appeal to more people looking to go
into Web 2.0.
Better integration with Apache projects. The Click framework is now
in the Apache Incubator and includes Cayenne support. It would also
be nice to see Tapestry and Wicket include it, too. There aren't
really robust installers (like what Apple did with WebObjects), but at
a minimum it would be nice if there were Maven archetypes for various
frameworks that could configure Cayenne support automatically. Google
Summer of Code task, possibly?
There are many other things (better marketing by having papers
published, providing support for larger companies that might be
willing to invest in it, etc), but I've been long-winded enough. All
of these things take time and effort, but I think having a clear
direction and goal would really help that, too.
Thanks,
mrg
PS. I'm hoping for more comments, too ...
Re: JPA crossroads
Posted by Andrus Adamchik <an...@objectstyle.org>.
JPA 2.0 spec is out now, so there is some evolution in the JPA space.
And if we are to stay in this race we will definitely have to follow
the spec development.
As for Cayenne JPA provider (which was targeting JSR-220, aka JPA
1.0), we are deceptively close to the finish. "Close" cause all major
parts are there, all bridged to Cayenne main runtime core. From 10000
ft view we are covering all parts of the spec. "Deceptively" cause
there's a lot of small and midsize things needed here and there to
make it fully usable and pass the TCK. Getting there will still
require significant and dedicated effort.
Andrus
On Apr 6, 2009, at 12:18 PM, Andrey Razumovsky wrote:
> 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 <an...@objectstyle.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
>>>
>>>
>>>
>>>
>>
Re: JPA crossroads
Posted by Andrey Razumovsky <ra...@gmail.com>.
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 <an...@objectstyle.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
>>
>>
>>
>>
>
Re: JPA crossroads
Posted by Andrus Adamchik <an...@objectstyle.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
>
>
>
Re: JPA crossroads
Posted by Aristedes Maniatis <ar...@ish.com.au>.
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
Re: JPA crossroads
Posted by Tore Halset <ha...@pvv.ntnu.no>.
Hello.
I am not using nor working on JPA, so this is fine with me as long as
EJBQL stays in the core as lots of us are using that one.
+1
Regards,
- Tore.
On 6. april. 2009, at 09.55, 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.
>
> Comments?
>
> Andrus
>