Re: JDO TCK Conference Call Friday, June 16, 9 am PST

[Craig L Russell]

Hi Andy,

On Jun 18, 2006, at 10:59 AM, Andy Jefferson wrote:

We need more documentation to make JDO more accessible.
One option is to use EJB3 annotations for metadata. JPOX.

The JPOX community is looking for more members, and so is
the Apache JDO project. We need to brainstorm how to get
the two communities to work closer together.

Hi,


class-level annotations so far but I have
detachable
requires-extent
identity-type


issue of annotations in JDO. To quote from the JDO2 spec
<spec>

annota-
tions will be made.
</spec>
We're at this point aren't we ? ;-)

whilst implementing annotations for JPOX I find that I need to implement some of my own to map those JDO2 attributes that JPA1 doesnt have :-). Only covered the I've implemented these as JPOX annotations, but it would make sense (to me) to have these as part of Apache JDO (in some way). Clearly this would open up the Metadata annotations for persistence are being developed in JSR 220. When that speci- fication is final, an update to the JDO specification to specify support for the

Yes, we are. With both 243 and 220 approved, we have achieved the milestone called out here.

 Is there any interest in standardising these

and using the JPA annotation where there is one).

in a JDK1.5 part of Apache JDO (since the spec already defines what the attributes are, and its just a case of having an associated annotation for them,

2. Add support for enums and highly concurrent collections.



<T> T makePersistent(T pc);
<T> Collection<T> makePersistent(Collection<T> pcs);
<T> T[ ] makePersistent(T[ ] pcs);

We should have a discussion about how to add JDK 1.5 support to JDO 2.0.1. I'd like consensus on how we do the following: 1. Add annotations to persistence capable classes. I think there are at least three alternatives here: 1a. Use the 220 annotations including the package names and add JDO- specific annotations to them. 1b. Use just the 220 annotation names but repackage them from javax.persistence to javax.jdo.annotations or something similar. This would give us the opportunity (and the danger) of redefining the semantics of some of the annotations without conflicting with the 220 spec. For example, we could redefine the default behavior of fetching relationship fields from eager to lazy, which cannot be done with 1a. 1c. Completely redefine annotations to align completely with JDO xml metadata. With this approach, you would not be able to take advantage of tools that generate 220 annotations. 3. Change signatures of interface methods to be 1.5 friendly. For example, the signatures of the makePersistent methods should be changed to: 4. Distribute multiple jar files that represent the 1.5 interfaces. The interfaces that are 1.5-specific cannot be packaged in a jar file with the 1.3 declarations of the interfaces. Right now, the jar is named: javax.jdo/jars/jdo2-api-2.0.jar. What needs to change for 1.5? Perhaps javax.jdo/jars/jdo2-1.5-api-2.0.1.jar would work.

The other issue is whether

more familiar with that than me :-)

OpenJPA has already done this - but then thats also a part of Apache so you'll be

Craig

There is nothing yet checked into the OpenJPA repository that would inform our decision here.

Comments?

--
Andy

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature