|
Home > Archive > Apache JDO Project > October 2006 > [DISCUSS] JDO 2.1 maintenance release
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[DISCUSS] JDO 2.1 maintenance release
|
|
| Craig L Russell 2006-10-13, 7:11 pm |
| | |
| Andy Jefferson 2006-10-14, 1:11 pm |
| Hi Craig,
To ChangeLog I would like to see the addition of support for Calendar.
> One rather large decision is whether to require JDK 1.5 for the
> release. I think there are three options, since part of the change
> requires JDK 1.5: annotations, Enum, and signature changes for generics.
>
> 1. Require JDK 1.5 for the 2.1 maintenance release.
-1
I personally like the fact that JDO is JDK agnostic technology (and JPA
isn't).
> 2. Split the current maintenance release into two maintenance
> releases. Do the first maintenance release with no JDK 1.5 changes,
> and follow up in six months with another release that includes the
> 1.5 content.
So you have 2.1 (JDK 1.3+) and 2.2 (JDK 1.5+). And this effectively says that
from 2.2 you must have JDK 1.5+ to use JDO ? So this is like option 3 except
that you use SVN to handle the different API/TCK trees in separate branches
rather than having them both present in the same branch (which option 3
implies) ? The end result is the same ... we have a JDK1.3+ jar and TCK, and
we have a JDK1.5 jar and TCK
Therefore the JDO 2.1 branch can still be developed further in maintenance
revisions as 2.1.1, 2.1.2 etc just like any software project so those who use
JDK 1.3/1.4 can still use a developing technology whilst retaining their JDK,
and those who use JDK 1.5+ can use the JDO2.2 branch.
Future development beyond 2.2 will be for JDK 1.5+ only (which by the time
that happens there will be more than the current 20-30% of developers using
it). Implementations could easily put out a JDO2.1 version and a JDO2.2
version and claim compliance with either standard.
The only other issue to decide would be whether to use namings of JDO 2.1 and
JDO 2.2 for these 2 branches, or whether to use 2.1 and 3.0,
..... or maybe JDO 5 perhaps? muahahahaha
> 3. Split the maintenance release into two parts, one of which only
> requires JDK 1.3, and the other part which requires 1.5. Ship two
> sets of jar files for at least the api20 jar and tck20 jar, with
> different dependencies.
I'd guess most work would be to use the same TCK core in 2 different TCK maven
projects.
Using option 2 seems like a better compromise to me.
> Please let me know which of these options you are willing to help with.
I'm "willing to help" on 2 or 3, since writing an RI qualifies as help IMHO.
Also on the splitting of annotations between JDO and ORM.
--
Andy
| |
| Craig L Russell 2006-10-14, 7:11 pm |
| | |
| Ilan Kirsh 2006-10-14, 7:11 pm |
| I agree. After reading only the header of every option I though that 3 is the best and 1 is the worst, but after reading the cons of 2 and 3 it seems that 1 is the only feasible option. I am afraid that plans for 6-8 months might eventually take much longer and because the project is under resourced the amount of work should be a main consideration. Adding support for sub queries for existing users of JDK 1.4 is a minor issue IMO, that might be resolved as an extension to JDO 2.01 by vendors that are interested.
Ilan
----- Original Message -----
From: Wesley Biggs
To: JDO Expert Group
Cc: Apache JDO project
Sent: Sunday, October 15, 2006 1:56 AM
Subject: Re: [DISCUSS] JDO 2.1 maintenance release
-- Users want 1.5 features ASAP
-- Vendors need to support existing customers who cannot upgrade to 1.5
I suggest:
-- Target the maintenance release against 1.5 only (option 1 below). Update the TCK to require 1.5 only.
-- Allow vendors to backport JDO 2.1 changes from ChangeLog (not ChangeLog15) to their own JAR distribution for JDK versions < 1.5.
Pros: benefits of option 1 as laid out by Craig
Cons: no such thing as being certified as JDO 2.1 compliant against JDK <= 1.4.x. But I don't think this really matters to users.
Wes
Craig L Russell wrote:
Javadogs,
Please refer to http://wiki.apache.org/jdo/ChangeLog and http://wiki.apache.org/jdo/ChangeLog15
It's time to decide the broad outline of the JDO 2 maintenance release. I have put into the ChangeLogs all the features that I know of that we have discussed including. If there are any missing items, please reply.
One rather large decision is whether to require JDK 1.5 for the release. I think there are three options, since part of the change requires JDK 1.5: annotations, Enum, and signature changes for generics.
1. Require JDK 1.5 for the 2.1 maintenance release.
Pro: Least amount of work for everyone. Easiest to explain, package, and document.
Con: All the users who want the features of JDO 2.1 and can't move to JDK 1.5 (actually, the only significant feature that doesn't require 1.5 is subqueries).
2. Split the current maintenance release into two maintenance releases. Do the first maintenance release with no JDK 1.5 changes, and follow up in six months with another release that includes the 1.5 content.
Pro: Users get subqueries without going to JDK 1.5
Con: No annotation, enum, or JPA support for another 6 to 8 months
3. Split the maintenance release into two parts, one of which only requires JDK 1.3, and the other part which requires 1.5. Ship two sets of jar files for at least the api20 jar and tck20 jar, with different dependencies.
Pro: Users get exactly what they want, and only have a dependency on 1.5 if they want to use 1.5 features
Con: A lot more work, harder to package, document, and use, more maven dependencies, more packages and jar files. The project is under-resourced to do this in a timely way.
Please let me know which of these options you are willing to help with.
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
| |
| Andy Jefferson 2006-10-15, 1:11 am |
| > I agree. After reading only the header of every option I though that 3 is
> the best and 1 is the worst, but after reading the cons of 2 and 3 it seems
> that 1 is the only feasible option. I am afraid that plans for 6-8 months
> might eventually take much longer and because the project is under
> resourced the amount of work should be a main consideration. Adding support
> for sub queries for existing users of JDK 1.4 is a minor issue IMO, that
> might be resolved as an extension to JDO 2.01 by vendors that are
> interested.
I still fail to see any significant change in the "amount of work" between 1
and 2. You have these features
A. You have to support subqueries.
B. You have to support the minor API updates for JDK1.3+
C. You have to support annotations and enums.
With Option 1 you just dump it all (A,B,C) into a single SVN branch.
With Option 2 you put A, B into branch 2.1 now, you then start branch 2.2 and
put C into that (since it already has A,B). Work on C can start now. You
don't have to start when A,B are done. I fail to see why the second part
should take 6 months. What is there ? Splitting annotations into JDO and
ORM ? I'll do that next week if someone is prepared to add it to the spec ;-)
It only took 3 days to write them in the first place.
So the *only* difference in amount of work is making 2 releases (and releasing
a project should not be time consuming). The benefit of 2 is that you get a
JDK1.3+ standard and a JDK1.5+
--
Andy
| |
| Andy Jefferson 2006-10-15, 7:11 am |
| Hi Craig,
> I believe that you cannot map a Calendar to a single column in the
> datastore because Calendar has a few features that you don't want to
> lose:
Thanks. I only had the storage of time and timezone in mind ... ie. part 1,
forgetting the strangeness of Calendar.
Withdraw the request for Calendar please :-)
--
Andy
| |
| Craig L Russell 2006-10-15, 7:11 pm |
| |
|
|
|
|