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
<[EMAIL PROTECTED]> 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.
