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 2008/06/18 15:06:33 UTC
Wrapping up Cayenne 3.0
Wanted to float the idea of wrapping up 3.0 release. Contrary to what
I said in the past (3.0 final == certified JPA release), there are a
few considerations that made me change my mind in favor of 3.0 without
full/any JPA:
1. Lack of momentum. We were unable to find any committed volunteers
to work on the JPA provider, even though we had maybe 5 or 6 declared
volunteers, so I ended up doing all work myself. I have a few theories
why, but this is not important for this discussion.
2. My personal availability to do Cayenne work has shrunk
significantly with growing ObjectStyle consulting business. The
remaining time is spent on Cayenne classic API, driven by user
requests and my own needs.
3. The amount of new features developed in Cayenne classic in 3.0
requires some serious catching up to do - add modeler support for many
new features, write tutorials and documentation. In this respect I
think one thing is very important - communicate to our users a clear
definition of "what is Cayenne" now (i.e. the scope of fully supported
features, best practices, etc.). We've done that pretty well in the
past, but it is impossible to do it with a moving target. There are
questions being asked like "is there POJO support?", "how do I
configure cache", etc. All we can do is give a vague answer "it sorta
work, there's no modeler or documentation"). With the amount of cool
new stuff, I wish we could give users more definite answers (or maybe
I am too backwards thinking, and in the post-Web 2.0 world everybody
is comfortable using nightly builds in production, and we are wasting
time with all the cleanup? :-))
Anyways... Regardless of the limited resources we've managed to
advance Cayenne 3.0 very far, and regardless of the lack of docs for
the new features, people love and use them already, so there are lots
of things to be proud of:
http://cayenne.apache.org/doc/guide-to-30-features.html
So here is the suggested plan. The development part of it is presented
from the POV of "Andrus as a Cayenne committer" (i.e. the stuff I will
be working on that does not require PMC consensus and does not require
others to follow). Release plan part will require the PMC consensus.
DEVELOPMENT:
JPA is still on the table, only postponed till the future releases
(3.1). For now concentrate on wrapping up classic API features. Here
is an approximate (and pretty long) list:
* EJBQL missing features (constructors, flattened relationships,
better error reporting)
* Vertical Inheritance
* Multiple cayenne.xml in the project (CAY-943)
* Generating Query and Procedure Access Code (CAY-1070)
* Modeler SoC 2008
* Modeler: support for embeddables
* Modeler: support for EJBQL queries
* Tutorials
* Resolve JPA legal caveat [1]
* (plus lots of smaller features and bug fixes) :
RELEASE PLAN:
* Once major remaining features are in, we change releases suffix from
Mx to Bx ("milestone" to "beta") and go into the code freeze.
* Once we fix all bugs and write docs, we do release candidates
(somewhere here we also branch for 3.1 development)
* We release 3.0-final
* We EOL 1.2 (SourceForge) and 2.0 (Apache) branches.
Thoughts?
Andrus
[1] JPA Legal Caveat: (something to confirm on legal-discuss). We are
not allowed to release a JPA provider until it fully passes the TCK.
Per some interpretations of the JPA spec license it seems to mean that
we can't release a 3.0-final that contains JPA-nonfinal provider jars
(while we can still release milestone non-final releases of JPA). So
we'll likely have to fork JPA stuff in a separate assembly. That's a
minor detail IMO. We can easily comply.
Re: Wrapping up Cayenne 3.0
Posted by Tore Halset <ha...@pvv.ntnu.no>.
Hello.
I am +1 to start wrapping up 3.0. I want to create some modeler
documentation for the merge-stuff.
I volunteered to join in on JPA, but lost motivation. At first it
sounded like fun, but then I discovered that it was a lot of work ...
and that I would probably not use it myself. I have a lot of respect
for the work done and still think it is one of the most important
things for cayenne after joining Apache.
Regards,
- Tore.
On 18. juni. 2008, at 15.06, Andrus Adamchik wrote:
> Wanted to float the idea of wrapping up 3.0 release. Contrary to
> what I said in the past (3.0 final == certified JPA release), there
> are a few considerations that made me change my mind in favor of 3.0
> without full/any JPA:
>
> 1. Lack of momentum. We were unable to find any committed volunteers
> to work on the JPA provider, even though we had maybe 5 or 6
> declared volunteers, so I ended up doing all work myself. I have a
> few theories why, but this is not important for this discussion.
>
> 2. My personal availability to do Cayenne work has shrunk
> significantly with growing ObjectStyle consulting business. The
> remaining time is spent on Cayenne classic API, driven by user
> requests and my own needs.
>
> 3. The amount of new features developed in Cayenne classic in 3.0
> requires some serious catching up to do - add modeler support for
> many new features, write tutorials and documentation. In this
> respect I think one thing is very important - communicate to our
> users a clear definition of "what is Cayenne" now (i.e. the scope of
> fully supported features, best practices, etc.). We've done that
> pretty well in the past, but it is impossible to do it with a moving
> target. There are questions being asked like "is there POJO
> support?", "how do I configure cache", etc. All we can do is give a
> vague answer "it sorta work, there's no modeler or documentation").
> With the amount of cool new stuff, I wish we could give users more
> definite answers (or maybe I am too backwards thinking, and in the
> post-Web 2.0 world everybody is comfortable using nightly builds in
> production, and we are wasting time with all the cleanup? :-))
>
> Anyways... Regardless of the limited resources we've managed to
> advance Cayenne 3.0 very far, and regardless of the lack of docs for
> the new features, people love and use them already, so there are
> lots of things to be proud of:
>
> http://cayenne.apache.org/doc/guide-to-30-features.html
>
> So here is the suggested plan. The development part of it is
> presented from the POV of "Andrus as a Cayenne committer" (i.e. the
> stuff I will be working on that does not require PMC consensus and
> does not require others to follow). Release plan part will require
> the PMC consensus.
>
> DEVELOPMENT:
>
> JPA is still on the table, only postponed till the future releases
> (3.1). For now concentrate on wrapping up classic API features. Here
> is an approximate (and pretty long) list:
>
> * EJBQL missing features (constructors, flattened relationships,
> better error reporting)
> * Vertical Inheritance
> * Multiple cayenne.xml in the project (CAY-943)
> * Generating Query and Procedure Access Code (CAY-1070)
> * Modeler SoC 2008
> * Modeler: support for embeddables
> * Modeler: support for EJBQL queries
> * Tutorials
> * Resolve JPA legal caveat [1]
> * (plus lots of smaller features and bug fixes) :
>
> RELEASE PLAN:
>
> * Once major remaining features are in, we change releases suffix
> from Mx to Bx ("milestone" to "beta") and go into the code freeze.
> * Once we fix all bugs and write docs, we do release candidates
> (somewhere here we also branch for 3.1 development)
> * We release 3.0-final
> * We EOL 1.2 (SourceForge) and 2.0 (Apache) branches.
>
> Thoughts?
>
> Andrus
>
> [1] JPA Legal Caveat: (something to confirm on legal-discuss). We
> are not allowed to release a JPA provider until it fully passes the
> TCK. Per some interpretations of the JPA spec license it seems to
> mean that we can't release a 3.0-final that contains JPA-nonfinal
> provider jars (while we can still release milestone non-final
> releases of JPA). So we'll likely have to fork JPA stuff in a
> separate assembly. That's a minor detail IMO. We can easily comply.
>
Re: Wrapping up Cayenne 3.0
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 19/06/2008, at 1:29 AM, Andrus Adamchik wrote:
>> Maybe now is a good time to create 4.0 and 3.1 milestones and start
>> triaging tasks into those?
>
> You mean like a Wiki page (not an SVN branch)? Yeah sure we can do
> that.
I meant in Jira. I think the most important thing if we want to
release 3.0 is to not let feature creep allow the release to be
sidetracked. And one tool for that is Jira. Having all new tasks drop
into '4.0' by default and only be manually moved down into 3.0 is a
start.
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: Wrapping up Cayenne 3.0
Posted by Malcolm Edgar <ma...@gmail.com>.
+ 1
This sounds like a good plan to me. Now I am a bit biased here in
that our company is a committed user of Cayenne 3.0 classic mode.
regards Malcolm Edgar
On Thu, Jun 19, 2008 at 1:29 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> On Jun 18, 2008, at 4:47 PM, Aristedes Maniatis wrote:
>
>> Since there is no copyright over the concept of JPA itself, could this be
>> satisfied by simply ensuring that nothing mentions that Cayenne is JPA
>> compliant or partially-compliant?
>
> It's worse than that. If you read the license in the JPA PDF, we are not
> allowed to ship anything that implements javax.persistence interfaces unless
> we are certified.
>
>
>>> * (plus lots of smaller features and bug fixes) :
>>
>> * How about the generified SelectQuery? I know it was discussed to death
>> and there was no 100% clean method, but it might be nice to get in given 3.0
>> is the Java 5 release.
>
> I started playing with it and got stuck a bit... Didn't like the stuff that
> came out. I am +1 on having it in 3.0 if we get the design that we like.
>
>> Maybe now is a good time to create 4.0 and 3.1 milestones and start
>> triaging tasks into those?
>
> You mean like a Wiki page (not an SVN branch)? Yeah sure we can do that.
>
>
>>> * We EOL 1.2 (SourceForge) and 2.0 (Apache) branches.
>>
>> Might be good to support the 2.0 branch for critical bug fixes for 12
>> months? Doesn't look like there will be any given its current stable nature,
>> but it might create confidence.
>
> Fine with me. As long as we EOL 1.2 and don't have to deal with SourceForge
> anymore.
>
>> I suspect given your goals above, a few beta releases, etc we might be
>> aiming for a final 3.0 release toward the end of the year.
>
> I won't be giving any time predictions, but I think end of 2008 is likely
> too optimistic. Maybe in the future we'll implement better release scope
> management to ensure shorter cycles, but now we have too many loose ends.
>
> Andrus
>
Re: Wrapping up Cayenne 3.0
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 18, 2008, at 4:47 PM, Aristedes Maniatis wrote:
> Since there is no copyright over the concept of JPA itself, could
> this be satisfied by simply ensuring that nothing mentions that
> Cayenne is JPA compliant or partially-compliant?
It's worse than that. If you read the license in the JPA PDF, we are
not allowed to ship anything that implements javax.persistence
interfaces unless we are certified.
>> * (plus lots of smaller features and bug fixes) :
>
> * How about the generified SelectQuery? I know it was discussed to
> death and there was no 100% clean method, but it might be nice to
> get in given 3.0 is the Java 5 release.
I started playing with it and got stuck a bit... Didn't like the stuff
that came out. I am +1 on having it in 3.0 if we get the design that
we like.
> Maybe now is a good time to create 4.0 and 3.1 milestones and start
> triaging tasks into those?
You mean like a Wiki page (not an SVN branch)? Yeah sure we can do that.
>> * We EOL 1.2 (SourceForge) and 2.0 (Apache) branches.
>
> Might be good to support the 2.0 branch for critical bug fixes for
> 12 months? Doesn't look like there will be any given its current
> stable nature, but it might create confidence.
Fine with me. As long as we EOL 1.2 and don't have to deal with
SourceForge anymore.
> I suspect given your goals above, a few beta releases, etc we might
> be aiming for a final 3.0 release toward the end of the year.
I won't be giving any time predictions, but I think end of 2008 is
likely too optimistic. Maybe in the future we'll implement better
release scope management to ensure shorter cycles, but now we have too
many loose ends.
Andrus
Re: Wrapping up Cayenne 3.0
Posted by Lachlan Deck <la...@gmail.com>.
Hi there,
On 18/06/2008, at 11:47 PM, Aristedes Maniatis wrote:
> On 18/06/2008, at 11:06 PM, Andrus Adamchik wrote:
>
>> DEVELOPMENT:
>>
>> JPA is still on the table, only postponed till the future releases
>> (3.1). For now concentrate on wrapping up classic API features.
>> Here is an approximate (and pretty long) list:
>>
>> * EJBQL missing features (constructors, flattened relationships,
>> better error reporting)
>> * Vertical Inheritance
>
> As I've earlier indicated both Marcin and Lachlan are going to spend
> some ish work hours in the next month on various Cayenne tasks,
> particularly inheritance. That task has been languishing for far too
> long since I had the burst of energy in the planning phase a while
> ago. I'll work with them to get that code tested and committed.
>
>> * Multiple cayenne.xml in the project (CAY-943)
>> * Generating Query and Procedure Access Code (CAY-1070)
>> * Modeler SoC 2008
>> * Modeler: support for embeddables
>> * Modeler: support for EJBQL queries
>> * Tutorials
Nested contexts for ROP would also be nice. That's something we (i.e.,
Ari and I) also talked about having a look at.
with regards,
--
Lachlan Deck
Re: Wrapping up Cayenne 3.0
Posted by Aristedes Maniatis <ar...@ish.com.au>.
On the whole, I agree. For my thinking anyway, the JPA compliance is
somewhat of a distraction from the original design style of Cayenne.
It is an move (to some extent) to make Cayenne have a Hibernate-like
interface. I suspect many people come to Cayenne because it isn't
Hibernate-like.
I think if we leave aside the JPA compliance, there is so much in
Cayenne 3.0 that is worthy of a major release point. It is stable and
very useful. And attempting a roughly yearly release cycle is probably
not a bad thing.
On 18/06/2008, at 11:06 PM, Andrus Adamchik wrote:
> DEVELOPMENT:
>
> JPA is still on the table, only postponed till the future releases
> (3.1). For now concentrate on wrapping up classic API features. Here
> is an approximate (and pretty long) list:
>
> * EJBQL missing features (constructors, flattened relationships,
> better error reporting)
> * Vertical Inheritance
As I've earlier indicated both Marcin and Lachlan are going to spend
some ish work hours in the next month on various Cayenne tasks,
particularly inheritance. That task has been languishing for far too
long since I had the burst of energy in the planning phase a while
ago. I'll work with them to get that code tested and committed.
> * Multiple cayenne.xml in the project (CAY-943)
> * Generating Query and Procedure Access Code (CAY-1070)
> * Modeler SoC 2008
> * Modeler: support for embeddables
> * Modeler: support for EJBQL queries
> * Tutorials
Does this mean cleaning up the examples within the web documentation
now, or updating the projects which are little working demos? To my
mind, effort on the online documentation is more valuable than effort
on the projects.
> * Resolve JPA legal caveat [1]
Since there is no copyright over the concept of JPA itself, could this
be satisfied by simply ensuring that nothing mentions that Cayenne is
JPA compliant or partially-compliant?
> * (plus lots of smaller features and bug fixes) :
* How about the generified SelectQuery? I know it was discussed to
death and there was no 100% clean method, but it might be nice to get
in given 3.0 is the Java 5 release.
Maybe now is a good time to create 4.0 and 3.1 milestones and start
triaging tasks into those?
> RELEASE PLAN:
>
> * Once major remaining features are in, we change releases suffix
> from Mx to Bx ("milestone" to "beta") and go into the code freeze.
> * Once we fix all bugs and write docs, we do release candidates
> (somewhere here we also branch for 3.1 development)
> * We release 3.0-final
> * We EOL 1.2 (SourceForge) and 2.0 (Apache) branches.
Might be good to support the 2.0 branch for critical bug fixes for 12
months? Doesn't look like there will be any given its current stable
nature, but it might create confidence.
I suspect given your goals above, a few beta releases, etc we might be
aiming for a final 3.0 release toward the end of the year. Does that
sound right to you?
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: Wrapping up Cayenne 3.0
Posted by Kevin Menard <km...@servprise.com>.
This is something I had been giving consideration to as well. Cayenne 3.0
is actually quite stable and adds a lot of new features & improvements.
For my part, I apologize for not stepping up with the JPA stuff like I
wanted to. I have a list a mile long of reasons, but none really matter.
One idea I had been toying with is making the JPA provider a separate
module altogether, versioned independently of Cayenne core. I realize we
have this separation a bit with the different modules already. But, this
would allow the provider to grow independently of Cayenne. So, for
example, we're not forced to push a new Cayenne update just because the
provider had been updated.
As for the rest of what you listed, I'm +1, with Ari's modification for
the 2.0 release. At this stage, I think 1.2 can be EOL'd -- the migration
path to 2.0 is fairly straightforward and a good first step to 3.0 upgrade
anyway.
As for me, I'll make sure that the rest of the maven plugins are completed
as well, so we have a whole tool chain there. I'm also obviously working
with Andrey on the SoC project to provide a high quality modeler.
There were still 3 major items I would have loved to see completed. But
alas, I don't have the time and can't ask anyone else to do them:
- Inheritance work (looks like Ari may be able to slip this in 3.0 though)
- Server & client class hierarchy unification
- Unregistered object relationships
As for triaging future work, I would like to see finer granularity in
JIRA. This would help a roadmap considerably.
--
Kevin
On Wed, 18 Jun 2008 09:06:33 -0400, Andrus Adamchik
<an...@objectstyle.org> wrote:
> Wanted to float the idea of wrapping up 3.0 release. Contrary to what I
> said in the past (3.0 final == certified JPA release), there are a few
> considerations that made me change my mind in favor of 3.0 without
> full/any JPA:
>
> 1. Lack of momentum. We were unable to find any committed volunteers to
> work on the JPA provider, even though we had maybe 5 or 6 declared
> volunteers, so I ended up doing all work myself. I have a few theories
> why, but this is not important for this discussion.
>
> 2. My personal availability to do Cayenne work has shrunk significantly
> with growing ObjectStyle consulting business. The remaining time is
> spent on Cayenne classic API, driven by user requests and my own needs.
>
> 3. The amount of new features developed in Cayenne classic in 3.0
> requires some serious catching up to do - add modeler support for many
> new features, write tutorials and documentation. In this respect I think
> one thing is very important - communicate to our users a clear
> definition of "what is Cayenne" now (i.e. the scope of fully supported
> features, best practices, etc.). We've done that pretty well in the
> past, but it is impossible to do it with a moving target. There are
> questions being asked like "is there POJO support?", "how do I configure
> cache", etc. All we can do is give a vague answer "it sorta work,
> there's no modeler or documentation"). With the amount of cool new
> stuff, I wish we could give users more definite answers (or maybe I am
> too backwards thinking, and in the post-Web 2.0 world everybody is
> comfortable using nightly builds in production, and we are wasting time
> with all the cleanup? :-))
>
> Anyways... Regardless of the limited resources we've managed to advance
> Cayenne 3.0 very far, and regardless of the lack of docs for the new
> features, people love and use them already, so there are lots of things
> to be proud of:
>
> http://cayenne.apache.org/doc/guide-to-30-features.html
>
> So here is the suggested plan. The development part of it is presented
> from the POV of "Andrus as a Cayenne committer" (i.e. the stuff I will
> be working on that does not require PMC consensus and does not require
> others to follow). Release plan part will require the PMC consensus.
>
> DEVELOPMENT:
>
> JPA is still on the table, only postponed till the future releases
> (3.1). For now concentrate on wrapping up classic API features. Here is
> an approximate (and pretty long) list:
>
> * EJBQL missing features (constructors, flattened relationships,
> better error reporting)
> * Vertical Inheritance
> * Multiple cayenne.xml in the project (CAY-943)
> * Generating Query and Procedure Access Code (CAY-1070)
> * Modeler SoC 2008
> * Modeler: support for embeddables
> * Modeler: support for EJBQL queries
> * Tutorials
> * Resolve JPA legal caveat [1]
> * (plus lots of smaller features and bug fixes) :
>
> RELEASE PLAN:
>
> * Once major remaining features are in, we change releases suffix from
> Mx to Bx ("milestone" to "beta") and go into the code freeze.
> * Once we fix all bugs and write docs, we do release candidates
> (somewhere here we also branch for 3.1 development)
> * We release 3.0-final
> * We EOL 1.2 (SourceForge) and 2.0 (Apache) branches.
>
> Thoughts?
>
> Andrus
>
> [1] JPA Legal Caveat: (something to confirm on legal-discuss). We are
> not allowed to release a JPA provider until it fully passes the TCK. Per
> some interpretations of the JPA spec license it seems to mean that we
> can't release a 3.0-final that contains JPA-nonfinal provider jars
> (while we can still release milestone non-final releases of JPA). So
> we'll likely have to fork JPA stuff in a separate assembly. That's a
> minor detail IMO. We can easily comply.