|
Home > Archive > Apache JDO Project > November 2006 > Logistics for JDO 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 |
Logistics for JDO maintenance release
|
|
| Craig L Russell 2006-11-04, 7:11 pm |
| | |
| Craig L Russell 2006-11-05, 7:11 pm |
| | |
|
| Craig,
Isn=92t it possible to have a jar with dual compatibility? Previous
classes are 1.3 binary compatible and the annotation classes are 1.5?
=20
Erik Bengtson
-----Original Message-----
From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM]=20
Sent: Saturday, November 04, 2006 10:37 PM
To: Apache JDO project
Subject: Logistics for JDO maintenance release
[apologies for the html formatting, needed for the tables below]
Based on the feedback I received for the maintenance release, I'd like
to propose that we put both the jdk1.5 changes as well as the jdk1.3
changes into the specification. When running with jdk1.5 features, the
jdo api jar needs to be different in order to accommodate the new
signatures of the apis that are now generic. Similarly, in order to test
the new jdk1.5 features, the tck jar needs to be different to use the
new signatures. I think the most straightforward way to do this is to
create different jar files that are self-contained. This implies that we
have different artifact names and build them with different svn
workspaces.
Our current workspaces are trunk and branches/2.0.1. I'd like to propose
we create new projects corresponding to api20 and tck20 that contain the
jdk1.5 changes for the maintenance release. When we branch the
workspaces for the release, we can change the version number from
SNAPSHOT to 2.1.
For naming, here's what we currently have:
directory=A0 =A0groupId=A0 =A0 =A0=A0 =A0artifactId version
---------=A0 =A0-------=A0 =A0 =A0=A0 =A0---------- -------
trunk/api20 javax.jdo=A0 =A0=A0 =A0jdo2-api=A0 =A0SNAPSHOT
trunk/tck20 org.apache.jdo jdo2-tck=A0 =A0SNAPSHOT
I think we need to change the project names and the artifact ids for the
new release. [I think it will be confusing to have the maintenance
release with two different release numbers, one reflecting 1.3 and the
other 1.5. I'd like to propose changing the artifact names instead.]
We can work on the 1.3 and 1.5 workspaces at the same time. We need to
migrate any of the 1.3 changes into the 1.5 project also. Changes in the
1.5 don't need to be ported back to the 1.3. Bug fixes of course can be
migrated from the 2.0.1 branch into both the 1.3 and 1.5 projects in
trunk. After release, we can create a new 2.1.1 branch that we use for
maintenance of the 2.1 code line.
Here's my proposal for naming; I just stuck a "5" in the names in an
arbitrary place:
directory=A0 =A0 =A0=A0 =A0=A0 =A0groupId=A0 =A0 =A0=A0 =A0artifactId =
version
---------=A0 =A0 =A0=A0 =A0=A0 =A0-------=A0 =A0 =A0=A0 =A0---------- =
-------
trunk/api205=A0 =A0 =A0=A0 =A0javax.jdo=A0 =A0=A0 =A0jdo2-api5=A0 =
SNAPSHOT
trunk/tck205=A0 =A0 =A0=A0 =A0org.apache.jdo jdo2-tck5=A0 SNAPSHOT
branches/2.1/api205 javax.jdo=A0 =A0=A0 =A0jdo2-api5=A0 2.1
branches/2.1/tck205 org.apache.jdo jdo2-tck5=A0 2.1
branches/2.1/api20=A0 javax.jdo=A0 =A0=A0 =A0jdo2-api=A0 =A02.1
branches/2.1/tck20=A0 org.apache.jdo jdo2-tck=A0 =A02.1
I'm open to other project and artifactId names. Here are a few that
might work. I'd welcome other suggestions. Keep in mind that maven
concatenates the artifactId, "-", and version number to produce the file
name for the artifact jars, signatures, and checksums.
api205 jdo2-api5 =3D=3D> jdo2-api5-2.1.jar
api25 jdo25-api =3D=3D> jdo25-api-2.1.jar
api2-5 jdo2-5-api=A0=A0=3D=3D> jdo2-5-api-2.1.jar
api2-1.5 jdo2-1.5-api=A0=A0=3D=3D> jdo2-1.5-api-2.1.jar
Comments?
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!
| |
| Craig L Russell 2006-11-05, 7:11 pm |
| | |
| Michael Bouschen 2006-11-06, 7:11 pm |
| Hi Craig,
I agree that we should have different artifact names and build them with
different svn workspaces.
JDK 5 is the current version and JDK 6 is about to be released. So would
it make sense to use the current projects for the JDK 5 version and
create new projects for the older versions JDK 1.3/1.4. Is 'legacy' the
right term for this support and is it an idea to used this in the
artifactId? Then we could have the following:
project name artifactId => jar file name
---------------------------------------------------------------
api2 jdo2-api => jdo2-api-2.1.jar
tck2 jdo2-tck => jdo2-tck-2.1.jar
api2-legacy jdo2-legacy-api => jdo2-legacy-api-2.1.jar
tck2-legacy jdo2-legacy-tck => jdo2-legacy-tck-2.1.jar
I'm using api2 instead of api20, because it might have been an error to
put the version number 2.0 into the project name. This is already
covered by the version number 2.0 in the jar file: jdo2-api-2.0.jar.
Regards Michael
> Some more ideas:
>
> project name, artifactId ==> jar file name
>
> api21, jdo21-api ==> jdo21-api-2.1.jar
> tck21, jdo21-tck ==> jdo21-tck-2.1.jar
> api215, jdo21-api5 ==> jdo21-api5-2.1.jar
> tck215, jdo21-tck5 ==> jdo21-tck5.2.1.jar
>
> Craig
>
> On Nov 4, 2006, at 1:37 PM, Craig L Russell wrote:
>
>
> 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!
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
| |
| Craig L Russell 2006-11-07, 1:11 pm |
| |
|
|
|
|