You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Michelle Caisse <Mi...@Sun.COM> on 2005/12/02 01:08:05 UTC
JDO TCK Conference Call Friday, Dec 2, 9 am PST
Hi,
We will have our regular meeting Friday, December 2 at 9 am PST to
discuss JDO TCK issues and status.
Dial-in numbers are:
866 230-6968 294-0479#
International: +1 865 544-7856
Agenda:
1. Test status (Michael W)
2. Query tests (Michael W)
3. Detached objects (Matthew)
4. getObjectsById tests (Geoff)
5. ri11 enhancer support for jdk 1.5 (Martin)
6. JPOX fixes/issues (Erik)
7. Fieldtypes test status (Michelle)
8. Other issues and status (any and all)
Action Items from weeks past:
[Nov 18 2005] AI: JPOX review bugs JDO-215 and JDO-211.
[Nov 18 2005] AI: Michelle check in patches associated with issues
JDO-215 and JDO-211.
[Nov 18 2005] AI: Erik look at JDO-206.
[Nov 18 2005] AI: BEA to sign the donation paperwork for their test
suite. Review how to merge their test cases into JDO TCK.
[Nov 18 2005] AI: Craig will code review patch for JDO-218.
[Nov 4 2005] AI Martin: Update Martin's wiki with discusion of JDK 1.5
issues.
[Oct 14 2005] AI: Martin will start a Wiki page with 1.5 issues, to be
linked by the web site. [In progress.]
[Oct 14 2005] AI: Michelle distill the mapping support that JPOX has
into a list of features that are/are not supported.
[Oct 14 2005] AI: Craig discuss mapping options with expert group.
[Oct 14 2005] AI: Push jars to Apache repository (Craig) In progress.
Several things need to be updated, including project.properties,
project.xml and maven.xml.
[Sep 2 2005] AI: To recruit members, update the web site. Articles on
TheServerSide directing attention to the site. T-shirts, logo. AI: Craig
write a ServerSide article.
[Aug 12 2005] AI: Craig to propose release of API20 and the entire 11
release (API, RI, TCK). This generated a large response on the incubator
alias.
[Aug 5 2005] AI: Brian McCallister can send info on the instructions how
to sync Apache and ibiblio. Re: Brian Topping needs info on creating a
maven package.
[July 29 2005] AI: Michelle Chapter 18 wiki needs to be updated to
include all JDO metadata elements and attributes. [not done]
[July 29 2005] AI: (Craig, Brian T.) Need some permissions that Brian is
working on.
[Jul 8 2005] AI: Double-check locking in the PMF (Martin) Martin has
implemented and will check in.
[April 15 2005] AI: Brian Topping will update the wiki to tell how to
access our releases area.
[April 15 2005] AI: Brian Topping will do the maven goal for creating
and uploading the snapshots. He will create a directory parallel to
trunk called "releases" and put the snapshots there.
[May 13 2005] AI: Brian Topping will implement pushing SNAPSHOT builds
of the project to ibiblio.
[May 13 2005] AI: Brian Topping will arrange for automated nightly builds.
[May 13 2005] AI: Martin Zaun will investigate JSR 294 (Java 5) to see
impact on enhancer.
[May 20 2005] AI: Craig to define the JCP distributions and see if maven
can help.
Re: collection of subclass-table
Posted by Andy Jefferson <an...@jpox.org>.
Hi Michael,
> I think, the intent of your proposal is to store the runtime type of the
> relationship together with the foreign key value in the database. You
> would replace a foreign key by a set of foreign keys. The set size would
> equal the number of subclasses. This would also apply to 1-1, 1-N
> relationhips not being contained in a jointable, e.g. manager, right?
Yes. This means that the treatment is then the same as how we handle reference
(interface/Object) fields. This is the same situation exactly. The JDO2 spec
says nothing, so the implementation is free to do it like that. It has the
advantage that referential integrity is possible.
> I think, there are several optional ways to compute the runtime type of
> relationships:
> 1) FK per subclass (your proposal).
> 2) Discriminator per FK.
> 3) Union statement involving tables of all subclasses.
There are 2 issues. The first is how to store the information in the
datastore, and the second is how to interpret the stored information (how to
determine the runtime type for the datastore information).
So your option 3 is basically that there is a single column storing the id of
the related object ? That means that referential integrity is not possible -
you can't impose a FK from a single column to multiple element tables.
> I think, options 1) and 2) require the ORM DTD to be extended:
Well that depends if the JDO2 spec imposes what the schema should be with a
1-1/1-N relation using subclass-table field/element. I don't see any need for
a DTD change to use option 1. This is what we already use for reference
fields (and collections of reference fields).
> When we discussed this issue the last time, we decided to go for option
> 3). This would be an optional feature that JDO implementations may
> support. For this reason, a new JDO option would be added to the spec.
> The TCK would check if the option is supported when mapping 2 is used
I agree with it being optional. I've said that for some time.
While it has been mentioned on jdo-dev, Option 3 was certainly not discussed
by the EG. I certainly have no intention of using that. We've already
implemented reference fields using multiple FKs. Implementing subclass-table
the same way is the only way that makes sense to me. They should be
consistent. I will be against any change in this implementation.
--
Andy
Java Persistent Objects - JPOX
Re: Minutes: JDO TCK Conference Call Friday, Dec 2, 9 am PST
Posted by Michael Watzek <mw...@spree.de>.
Hi Craig,
> Hi Michael,
>
> Thanks for your analysis. More comments below.
>
> On Dec 5, 2005, at 4:55 AM, Michael Watzek wrote:
>
>> Hi Andy,
>>
>>>> Inheritance mapping 2 fails. JPOX doesn't
>>>> support it, and the mapping isn't consistent. This needs a few
>>>> things: UNION join strategy plus generating a sequence used in
>>>> multiple tables. JDO-167
>>>>
>>>> Inheritance 3 fails. Optimization of inheritance 1 where there is no
>>>> table for abstract classes. JPOX doesn't support it. AI Craig:
>>>> discuss this mapping with expert group. It might be an optional feature.
>>>
>>> To be specific, JPOX doesn't currently support a 1-N relation with
>>> the element using subclass-table. This doesn't mean that work hasn't
>>> been done to take the implementation of this so far, but the end
>>> result so far is that the support is not complete. One issue I would
>>> have is how a join-table relation like this should be represented in
>>> the datastore (the join table structure). What I am planning to do is
>>> handle it like how we handle collections of interfaces. With this the
>>> join table has a FK column for each possible implementation. So in
>>> the case of a 1-N relation with an element using subclass-table, and
>>> having 2 subclasses then the join table would be
>>> OWNER_ID (FK back to owner table)
>>> SUBCLASS_1_ID (FK to SUBCLASS_1 table)
>>> SUBCLASS_2_ID (FK to SUBCLASS_2 table)
>>> ORDER_ID (part of the PK)
>>> with the SUBCLASS_1_ID, SUBCLASS_2_ID being populated if the element
>>> is of that type. I see nothing in the JDO2 spec to say that this has
>>> to be the way that it is represented, so it becomes the choice of the
>>> JDO implementation.
>
>
> It is true that there is nothing in the spec regarding how these two
> kinds of mappings are implemented. In the joined subclass it's clear
> that a foreign key might be used, but in the two failing cases here,
> there is no foreign key possible since the subclasses are mapped
> to independent tables (there is no common relationship among the tables,
> even though the key values are unique).
>
> So I'm thinking that even if we do have an optional feature to support
> this kind of mapping, there is not a standard mapping that will be
> required. Your idea of having a different FK for each possible subclass
> is interesting. But I think that a different reasonable mapping would
> have one column that has no FK constraint at all but matches the primary
> key value of two different subclass tables.
>
>> I think, the intent of your [Andy's] proposal is to store the runtime
>> type of the relationship together with the foreign key value in the
>> database. You would replace a foreign key by a set of foreign keys.
>> The set size would equal the number of subclasses. This would also
>> apply to 1-1, 1-N relationhips not being contained in a jointable,
>> e.g. manager, right?
>>
>> I think, there are several optional ways to compute the runtime type
>> of relationships:
>>
>> 1) FK per subclass (your proposal).
>> 2) Discriminator per FK.
>> 3) Union statement involving tables of all subclasses.
>>
>> I think, options 1) and 2) require the ORM DTD to be extended:
>> Regarding 1), the column mapping of relationship fields must be
>> capable to specify alternative FKs. Regarding 2), the column mapping
>> of relationship fields must include a discriminator column.
>
>
> We decided that discriminator columns for field mappings was not so
> important for embedded classes, and it seems that this is a similar
> case. I agree that extra ORM metadata would be needed to cater for 1)
> and 2).
>
>>
>> Option 3) requires unique PK values for all instances in an
>> inheritance hierarchy, e.g. Person, PartTimeEmployee, and
>> FullTimeEmployee. An implementation-defined sequence may be used in
>> the ORM for this purpose:
>
>
> I don't think it's necessarily an application-defined sequence. It could
> be any named sequence.
>
>>
>> ...
>> <class name="Person" ...>
>> ...
>> <field name="personid" column="PERSONID" primary-key="true"
>> sequence="org.apache.jdo.tck.pc.PersonSequence"/>
>> ...
>> </class>
>>
>> <class name="PartTimeEmployee" table="parttimeemployees">
>> ...
>> <field name="Person.personid" column="PERSONID"
>> primary-key="true" sequence="org.apache.jdo.tck.pc.PersonSequence"/>
>
>> ...
>> </class>
>>
>> <class name="FullTimeEmployee" table="fulltimeemployees">
>> ...
>> <field name="Person.personid" column="PERSONID"
>> primary-key="true" sequence="org.apache.jdo.tck.pc.PersonSequence"/>
>> ...
>> </class>
>> ...
>> <sequence name="org.apache.jdo.tck.pc.PersonSequence"
>> strategy="nontransactional"/>
>> ...
>>
>> When we discussed this issue the last time, we decided to go for
>> option 3). This would be an optional feature that JDO implementations
>> may support. For this reason, a new JDO option would be added to the
>> spec. The TCK would check if the option is supported when mapping 2 is
>> used.
>>
>> Is this decision still valid?
>
>
> It still gets my vote. The metadata as you've described it makes sense
> for this strategy.
I'll prepare a patch, that adapts the ORM for mapping 2 as described
above and that checks for the new option when mapping 2 is executed. For
now, I'll assume the option name to be "javax.jdo.option.UnionJoin".
Regards,
Michael
>
> Craig
>
>>
>> Regards,
>> Michael
>>
>>> Do either of inheritance2, inheritance3 test this and what do they
>>> assume is the join table structure ?
>>
>>
>>
>> --
>> -------------------------------------------------------------------
>> Michael Watzek Tech@Spree Engineering GmbH
>> mailto:mwa.tech@spree.de Buelowstr. 66
>> Tel.: ++49/30/235 520 36 10783 Berlin - Germany
>> Fax.: ++49/30/217 520 12 http://www.spree.de/
>> -------------------------------------------------------------------
>
>
> 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 Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
Re: Minutes: JDO TCK Conference Call Friday, Dec 2, 9 am PST
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Michael,
Thanks for your analysis. More comments below.
On Dec 5, 2005, at 4:55 AM, Michael Watzek wrote:
> Hi Andy,
>
>>> Inheritance mapping 2 fails. JPOX doesn't
>>> support it, and the mapping isn't consistent. This needs a few
>>> things: UNION join strategy plus generating a sequence used in
>>> multiple tables. JDO-167
>>>
>>> Inheritance 3 fails. Optimization of inheritance 1 where there is no
>>> table for abstract classes. JPOX doesn't support it. AI Craig:
>>> discuss this mapping with expert group. It might be an optional
>>> feature.
>> To be specific, JPOX doesn't currently support a 1-N relation with
>> the element using subclass-table. This doesn't mean that work
>> hasn't been done to take the implementation of this so far, but
>> the end result so far is that the support is not complete. One
>> issue I would have is how a join-table relation like this should
>> be represented in the datastore (the join table structure). What I
>> am planning to do is handle it like how we handle collections of
>> interfaces. With this the join table has a FK column for each
>> possible implementation. So in the case of a 1-N relation with an
>> element using subclass-table, and having 2 subclasses then the
>> join table would be
>> OWNER_ID (FK back to owner table)
>> SUBCLASS_1_ID (FK to SUBCLASS_1 table)
>> SUBCLASS_2_ID (FK to SUBCLASS_2 table)
>> ORDER_ID (part of the PK)
>> with the SUBCLASS_1_ID, SUBCLASS_2_ID being populated if the
>> element is of that type. I see nothing in the JDO2 spec to say
>> that this has to be the way that it is represented, so it becomes
>> the choice of the JDO implementation.
It is true that there is nothing in the spec regarding how these two
kinds of mappings are implemented. In the joined subclass it's clear
that a foreign key might be used, but in the two failing cases here,
there is no foreign key possible since the subclasses are mapped to
independent tables (there is no common relationship among the tables,
even though the key values are unique).
So I'm thinking that even if we do have an optional feature to
support this kind of mapping, there is not a standard mapping that
will be required. Your idea of having a different FK for each
possible subclass is interesting. But I think that a different
reasonable mapping would have one column that has no FK constraint at
all but matches the primary key value of two different subclass tables.
> I think, the intent of your [Andy's] proposal is to store the
> runtime type of the relationship together with the foreign key
> value in the database. You would replace a foreign key by a set of
> foreign keys. The set size would equal the number of subclasses.
> This would also apply to 1-1, 1-N relationhips not being contained
> in a jointable, e.g. manager, right?
>
> I think, there are several optional ways to compute the runtime
> type of relationships:
>
> 1) FK per subclass (your proposal).
> 2) Discriminator per FK.
> 3) Union statement involving tables of all subclasses.
>
> I think, options 1) and 2) require the ORM DTD to be extended:
> Regarding 1), the column mapping of relationship fields must be
> capable to specify alternative FKs. Regarding 2), the column
> mapping of relationship fields must include a discriminator column.
We decided that discriminator columns for field mappings was not so
important for embedded classes, and it seems that this is a similar
case. I agree that extra ORM metadata would be needed to cater for 1)
and 2).
>
> Option 3) requires unique PK values for all instances in an
> inheritance hierarchy, e.g. Person, PartTimeEmployee, and
> FullTimeEmployee. An implementation-defined sequence may be used in
> the ORM for this purpose:
I don't think it's necessarily an application-defined sequence. It
could be any named sequence.
>
> ...
> <class name="Person" ...>
> ...
> <field name="personid" column="PERSONID" primary-key="true"
> sequence="org.apache.jdo.tck.pc.PersonSequence"/>
> ...
> </class>
>
> <class name="PartTimeEmployee" table="parttimeemployees">
> ...
> <field name="Person.personid" column="PERSONID" primary-
> key="true" sequence="org.apache.jdo.tck.pc.PersonSequence"/>
> ...
> </class>
>
> <class name="FullTimeEmployee" table="fulltimeemployees">
> ...
> <field name="Person.personid" column="PERSONID" primary-
> key="true" sequence="org.apache.jdo.tck.pc.PersonSequence"/>
> ...
> </class>
> ...
> <sequence name="org.apache.jdo.tck.pc.PersonSequence"
> strategy="nontransactional"/>
> ...
>
> When we discussed this issue the last time, we decided to go for
> option 3). This would be an optional feature that JDO
> implementations may support. For this reason, a new JDO option
> would be added to the spec. The TCK would check if the option is
> supported when mapping 2 is used.
>
> Is this decision still valid?
It still gets my vote. The metadata as you've described it makes
sense for this strategy.
Craig
>
> Regards,
> Michael
>> Do either of inheritance2, inheritance3 test this and what do they
>> assume is the join table structure ?
>
>
> --
> -------------------------------------------------------------------
> Michael Watzek Tech@Spree Engineering GmbH
> mailto:mwa.tech@spree.de Buelowstr. 66
> Tel.: ++49/30/235 520 36 10783 Berlin - Germany
> Fax.: ++49/30/217 520 12 http://www.spree.de/
> -------------------------------------------------------------------
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!
Re: Minutes: JDO TCK Conference Call Friday, Dec 2, 9 am PST
Posted by Michael Watzek <mw...@spree.de>.
Hi Andy,
>>Inheritance mapping 2 fails. JPOX doesn't
>>support it, and the mapping isn't consistent. This needs a few
>>things: UNION join strategy plus generating a sequence used in
>>multiple tables. JDO-167
>>
>>Inheritance 3 fails. Optimization of inheritance 1 where there is no
>>table for abstract classes. JPOX doesn't support it. AI Craig:
>>discuss this mapping with expert group. It might be an optional feature.
>
>
> To be specific, JPOX doesn't currently support a 1-N relation with the element
> using subclass-table. This doesn't mean that work hasn't been done to take
> the implementation of this so far, but the end result so far is that the
> support is not complete.
>
> One issue I would have is how a join-table relation like this should be
> represented in the datastore (the join table structure). What I am planning
> to do is handle it like how we handle collections of interfaces. With this
> the join table has a FK column for each possible implementation. So in the
> case of a 1-N relation with an element using subclass-table, and having 2
> subclasses then the join table would be
>
> OWNER_ID (FK back to owner table)
> SUBCLASS_1_ID (FK to SUBCLASS_1 table)
> SUBCLASS_2_ID (FK to SUBCLASS_2 table)
> ORDER_ID (part of the PK)
>
> with the SUBCLASS_1_ID, SUBCLASS_2_ID being populated if the element is of
> that type. I see nothing in the JDO2 spec to say that this has to be the way
> that it is represented, so it becomes the choice of the JDO implementation.
I think, the intent of your proposal is to store the runtime type of the
relationship together with the foreign key value in the database. You
would replace a foreign key by a set of foreign keys. The set size would
equal the number of subclasses. This would also apply to 1-1, 1-N
relationhips not being contained in a jointable, e.g. manager, right?
I think, there are several optional ways to compute the runtime type of
relationships:
1) FK per subclass (your proposal).
2) Discriminator per FK.
3) Union statement involving tables of all subclasses.
I think, options 1) and 2) require the ORM DTD to be extended: Regarding
1), the column mapping of relationship fields must be capable to specify
alternative FKs. Regarding 2), the column mapping of relationship fields
must include a discriminator column.
Option 3) requires unique PK values for all instances in an inheritance
hierarchy, e.g. Person, PartTimeEmployee, and FullTimeEmployee. An
implementation-defined sequence may be used in the ORM for this purpose:
...
<class name="Person" ...>
...
<field name="personid" column="PERSONID" primary-key="true"
sequence="org.apache.jdo.tck.pc.PersonSequence"/>
...
</class>
<class name="PartTimeEmployee" table="parttimeemployees">
...
<field name="Person.personid" column="PERSONID"
primary-key="true" sequence="org.apache.jdo.tck.pc.PersonSequence"/>
...
</class>
<class name="FullTimeEmployee" table="fulltimeemployees">
...
<field name="Person.personid" column="PERSONID"
primary-key="true" sequence="org.apache.jdo.tck.pc.PersonSequence"/>
...
</class>
...
<sequence name="org.apache.jdo.tck.pc.PersonSequence"
strategy="nontransactional"/>
...
When we discussed this issue the last time, we decided to go for option
3). This would be an optional feature that JDO implementations may
support. For this reason, a new JDO option would be added to the spec.
The TCK would check if the option is supported when mapping 2 is used.
Is this decision still valid?
Regards,
Michael
>
> Do either of inheritance2, inheritance3 test this and what do they assume is
> the join table structure ?
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------
Re: Minutes: JDO TCK Conference Call Friday, Dec 2, 9 am PST
Posted by Andy Jefferson <an...@jpox.org>.
> Inheritance mapping 2 fails. JPOX doesn't
> support it, and the mapping isn't consistent. This needs a few
> things: UNION join strategy plus generating a sequence used in
> multiple tables. JDO-167
>
> Inheritance 3 fails. Optimization of inheritance 1 where there is no
> table for abstract classes. JPOX doesn't support it. AI Craig:
> discuss this mapping with expert group. It might be an optional feature.
To be specific, JPOX doesn't currently support a 1-N relation with the element
using subclass-table. This doesn't mean that work hasn't been done to take
the implementation of this so far, but the end result so far is that the
support is not complete.
One issue I would have is how a join-table relation like this should be
represented in the datastore (the join table structure). What I am planning
to do is handle it like how we handle collections of interfaces. With this
the join table has a FK column for each possible implementation. So in the
case of a 1-N relation with an element using subclass-table, and having 2
subclasses then the join table would be
OWNER_ID (FK back to owner table)
SUBCLASS_1_ID (FK to SUBCLASS_1 table)
SUBCLASS_2_ID (FK to SUBCLASS_2 table)
ORDER_ID (part of the PK)
with the SUBCLASS_1_ID, SUBCLASS_2_ID being populated if the element is of
that type. I see nothing in the JDO2 spec to say that this has to be the way
that it is represented, so it becomes the choice of the JDO implementation.
Do either of inheritance2, inheritance3 test this and what do they assume is
the join table structure ?
--
Andy
Minutes: JDO TCK Conference Call Friday, Dec 2, 9 am PST
Posted by Craig L Russell <Cr...@Sun.COM>.
Attendees: Michelle Caisse, Michael Bouschen, Michael Watzek, Martin
Zaun, Craig Russell
Agenda:
1. Test status (Michael W) 562 tests: application id 11 failures 19
errors, datastore id 11 failures 21 errors 6 configurations fail.
2. Query tests (Michael W) done. JIRA issues have been filed for
failing tests. Error message in the enhancer log: tag doesn't conform
to the dtd. AI Michelle file a JIRA issue. Is it allowed to have more
actual than formal parameters? No. AI Craig check to see if the spec
disallows this. AI Michael: raise an issue with the experts.
3. Detached objects (Matthew) no change.
4. getObjectsById tests (Geoff) no change.
5. ri11 enhancer support for jdk 1.5 (Martin) no change.
6. JPOX fixes/issues (Erik) no change.
7. Fieldtypes test status (Michelle) Last two JIRA issues have been
fixed and checked in. One last issue: MapStringValueCollection throws
ClassCastException JIRA issue is assigned to Andy. Andy found a typox
in the .orm metadata file which Michelle will fix.
8. Other issues and status (any and all)
Test ThreadSafe has a bug with multiple threads; sometimes two
threads succeed; looks like a timing bug in the test case. AI Michael
file a JIRA and assign it to Martin.
Inheritance mapping again. Inheritance mapping 2 fails. JPOX doesn't
support it, and the mapping isn't consistent. This needs a few
things: UNION join strategy plus generating a sequence used in
multiple tables. JDO-167
Inheritance 3 fails. Optimization of inheritance 1 where there is no
table for abstract classes. JPOX doesn't support it. AI Craig:
discuss this mapping with expert group. It might be an optional feature.
Action Items from weeks past:
[Nov 18 2005] AI: JPOX review bugs JDO-215 and JDO-211. done.
[Nov 18 2005] AI: Michelle check in patches associated with issues
JDO-215 and JDO-211. Almost done.
[Nov 18 2005] AI: Erik look at JDO-206.
[Nov 18 2005] AI: BEA to sign the donation paperwork for their test
suite. Review how to merge their test cases into JDO TCK.
[Nov 18 2005] AI: Craig will code review patch for JDO-218. done.
[Nov 4 2005] AI Martin: Update Martin's wiki with discusion of JDK
1.5 issues. in progress
[Oct 14 2005] AI: Martin will start a Wiki page with 1.5 issues, to
be linked by the web site. done.
[Oct 14 2005] AI: Michelle distill the mapping support that JPOX has
into a list of features that are/are not supported.
[Oct 14 2005] AI: Craig discuss mapping options with expert group.
[Oct 14 2005] AI: Push jars to Apache repository (Craig) In progress.
Several things need to be updated, including project.properties,
project.xml and maven.xml.
[Sep 2 2005] AI: To recruit members, update the web site. Articles on
TheServerSide directing attention to the site. T-shirts, logo. AI:
Craig write a ServerSide article.
[Aug 12 2005] AI: Craig to propose release of API20 and the entire 11
release (API, RI, TCK). This generated a large response on the
incubator alias.
[Aug 5 2005] AI: Brian McCallister can send info on the instructions
how to sync Apache and ibiblio. Re: Brian Topping needs info on
creating a maven package.
[July 29 2005] AI: Michelle Chapter 18 wiki needs to be updated to
include all JDO metadata elements and attributes. [not done]
[July 29 2005] AI: (Craig, Brian T.) Need some permissions that Brian
is working on.
[Jul 8 2005] AI: Double-check locking in the PMF (Martin) Martin has
implemented and will check in.
[April 15 2005] AI: Brian Topping will update the wiki to tell how to
access our releases area.
[April 15 2005] AI: Brian Topping will do the maven goal for creating
and uploading the snapshots. He will create a directory parallel to
trunk called "releases" and put the snapshots there.
[May 13 2005] AI: Brian Topping will implement pushing SNAPSHOT
builds of the project to ibiblio.
[May 13 2005] AI: Brian Topping will arrange for automated nightly
builds.
[May 13 2005] AI: Martin Zaun will investigate JSR 294 (Java 5) to
see impact on enhancer.
[May 20 2005] AI: Craig to define the JCP distributions and see if
maven can help.
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!