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.
-- KevinOn Wed, 18 Jun 2008 09:06:33 -0400, Andrus Adamchik <andru..bjectstyle.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.
This archive was generated by hypermail 2.0.0 : Wed Jun 18 2008 - 20:31:02 EDT