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 Craig L Russell <Cr...@Sun.COM> on 2006/03/29 03:43:19 UTC
Release branch of JDO 2.0
Javadogs,
I'm planning on cutting the release branch for JDO 2.0 tomorrow.
There are three open issues that I'm aware of:
1. The test with persistent interfaces doesn't work yet; I believe
that this is a JPOX bug that will be fixed without a new release of
the API or TCK.
2. The TCK only supports datastore identity with strategy="identity".
This is an issue for vendors who cannot use this strategy for
databases that do not support the SQL GENERATED ... AS IDENTITY
construct for schema. I believe that we can resolve this TCK issue
after release of 2.0.
3. Synchronization with JPOX final 1.1.0 release. The JPOX team need
to have an api20 release post-jdo-2.0-rc1 that includes a signature
change for a FetchPlan method. But I think that it's going to have to
either depend on a SNAPSHOT api20 or a renamed api20 release for
testing. Similarly, for testing the jdo 2.0 bits, we will need to
test with SNAPSHOT JPOX bits renamed to jpox-1.1.0.
Please let me know if you feel that it is not appropriate to start
the release process with the api20 and tck20 bits currently checked
into SVN.
Thanks,
Craig
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: Release branch of JDO 2.0
Posted by Martin Zaun <Ma...@Sun.COM>.
Michelle, Craig,
Martin Zaun wrote:
>
>> I'm currently going over the lifecycle spreadsheet, checking the
>> transition-related assertions for coverage by A5.9.1..190 and the
>> newly implemented cases, and preparing a few comments (which I'll
>> send to you soon).
>
> Please, find attached a first batch of comments on the latest
> spreadsheet's lifecycle tab (did an svn update this morning).
> A few more will follow this afternoon (have an appointment).
Attached are my remaining comments on the assertion spreadsheet's
lifecycle, PM, and TX tabs regarding state transitions.
Feel free to pick or discard.
Martin
Re: Release branch of JDO 2.0
Posted by Martin Zaun <Ma...@Sun.COM>.
Michelle, Craig,
Martin Zaun wrote:
> I'm currently going over the lifecycle spreadsheet, checking the
> transition-related assertions for coverage by A5.9.1..190 and the
> newly implemented cases, and preparing a few comments (which I'll
> send to you soon).
Please, find attached a first batch of comments on the latest
spreadsheet's lifecycle tab (did an svn update this morning).
A few more will follow this afternoon (have an appointment).
Martin
Re: Release branch of JDO 2.0
Posted by Craig L Russell <Cr...@Sun.COM>.
Here are comments on the latest spreadsheet.
12.6.8-28 not testable with the RI
12.6.8-29 should be removed. There is no longer such a parameter.
12.5.6-17 tested with
org.apache.jdo.tck.api.persistencemanager.getobject.GetObjectsById
Otherwise, looks good.
Craig
On Mar 29, 2006, at 12:54 PM, Michelle Caisse wrote:
> Done. -- Michelle
>
> Craig L Russell wrote:
>
>> Yes, please check in the worksheet as you have it.
>>
>> Craig
>>
>> On Mar 29, 2006, at 11:43 AM, Michelle Caisse wrote:
>>
>>> Craig L Russell wrote:
>>>
>>>>> What I'd recommend is that
>>>>> - the StateTransition tests only refer to A5.9.1..190, which
>>>>> denotes
>>>>> the global state transition table in the spec and that
>>>>> - we mark all other state-transition related assertions in the
>>>>> lifecycle tab of the spreadsheets as duplicates of
>>>>> A5.9.1..190, as
>>>>> is done for a few (but not all).
>>>>
>>>>
>>>>
>>>> This sounds like a reasonable approach. I don't know if there
>>>> is value in adding duplicate assertions to the test cases. I
>>>> think these can be handled by referring the duplicates to the
>>>> state transition section of the assertion spreadsheet.
>>>
>>>
>>> Would it be best if I check in the spreadsheet with my current
>>> changes so you can then mark the appropriate assertions as
>>> duplicates? I may need to make some further changes after you
>>> are done to update the count of tested assertions.
>>>
>>> -- Michelle
>>
>>
>> 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 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: Release branch of JDO 2.0
Posted by Michelle Caisse <Mi...@Sun.COM>.
Done. -- Michelle
Craig L Russell wrote:
> Yes, please check in the worksheet as you have it.
>
> Craig
>
> On Mar 29, 2006, at 11:43 AM, Michelle Caisse wrote:
>
>> Craig L Russell wrote:
>>
>>>> What I'd recommend is that
>>>> - the StateTransition tests only refer to A5.9.1..190, which denotes
>>>> the global state transition table in the spec and that
>>>> - we mark all other state-transition related assertions in the
>>>> lifecycle tab of the spreadsheets as duplicates of A5.9.1..190, as
>>>> is done for a few (but not all).
>>>
>>>
>>>
>>> This sounds like a reasonable approach. I don't know if there is
>>> value in adding duplicate assertions to the test cases. I think
>>> these can be handled by referring the duplicates to the state
>>> transition section of the assertion spreadsheet.
>>
>>
>> Would it be best if I check in the spreadsheet with my current
>> changes so you can then mark the appropriate assertions as
>> duplicates? I may need to make some further changes after you are
>> done to update the count of tested assertions.
>>
>> -- Michelle
>
>
> 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: Release branch of JDO 2.0
Posted by Craig L Russell <Cr...@Sun.COM>.
Yes, please check in the worksheet as you have it.
Craig
On Mar 29, 2006, at 11:43 AM, Michelle Caisse wrote:
> Craig L Russell wrote:
>
>>> What I'd recommend is that
>>> - the StateTransition tests only refer to A5.9.1..190, which denotes
>>> the global state transition table in the spec and that
>>> - we mark all other state-transition related assertions in the
>>> lifecycle tab of the spreadsheets as duplicates of A5.9.1..190, as
>>> is done for a few (but not all).
>>
>>
>> This sounds like a reasonable approach. I don't know if there is
>> value in adding duplicate assertions to the test cases. I think
>> these can be handled by referring the duplicates to the state
>> transition section of the assertion spreadsheet.
>
> Would it be best if I check in the spreadsheet with my current
> changes so you can then mark the appropriate assertions as
> duplicates? I may need to make some further changes after you are
> done to update the count of tested assertions.
>
> -- Michelle
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: Release branch of JDO 2.0
Posted by Michelle Caisse <Mi...@Sun.COM>.
Craig L Russell wrote:
>> What I'd recommend is that
>> - the StateTransition tests only refer to A5.9.1..190, which denotes
>> the global state transition table in the spec and that
>> - we mark all other state-transition related assertions in the
>> lifecycle tab of the spreadsheets as duplicates of A5.9.1..190, as
>> is done for a few (but not all).
>
>
> This sounds like a reasonable approach. I don't know if there is
> value in adding duplicate assertions to the test cases. I think these
> can be handled by referring the duplicates to the state transition
> section of the assertion spreadsheet.
Would it be best if I check in the spreadsheet with my current changes
so you can then mark the appropriate assertions as duplicates? I may
need to make some further changes after you are done to update the count
of tested assertions.
-- Michelle
Re: Release branch of JDO 2.0
Posted by Craig L Russell <Cr...@Sun.COM>.
On Mar 29, 2006, at 10:50 AM, Martin Zaun wrote:
>
> Michelle, Craig,
>
> Michelle Caisse wrote:
>> I have JDO-293, which is dependent on JDO-273 finishing touches.
>> There's also JDO-64 that is still open. And JDO-349.
>> -- Michelle
I'm going to address all of the issues currently annotated as "fix
for 2.0 final" today. [As soon as JIRA is alive again]
>
> I currently cannot lookup JDO-293 (apache server seems to be down),
> so, I'm not sure about your dependency, but I don't anticipate code
> changes for JDO-273 (and will set it to resolved after my AI below).
>
> Michelle Caisse wrote:
> >
> > It would be great if you could add anything that you know is
> missing, as
> > a range of assertion numbers or a set of ranges. Then I could
> check it
> > against the spreadsheet and make sure we have all tested assertions
> > marked "yes".
>
> What I'd recommend is that
> - the StateTransition tests only refer to A5.9.1..190, which denotes
> the global state transition table in the spec and that
> - we mark all other state-transition related assertions in the
> lifecycle tab of the spreadsheets as duplicates of A5.9.1..190, as
> is done for a few (but not all).
This sounds like a reasonable approach. I don't know if there is
value in adding duplicate assertions to the test cases. I think these
can be handled by referring the duplicates to the state transition
section of the assertion spreadsheet.
>
> I'm currently going over the lifecycle spreadsheet, checking the
> transition-related assertions for coverage by A5.9.1..190 and the
> newly implemented cases, and preparing a few comments (which I'll
> send to you soon).
>
> Now, for the unlikely event that I find any transition assertions not
> covered by the global state transition matrix (A5.9.1..190), Craig
> would propably rather want to complete the matrix in the spec (errata)
> instead of me adding additional assertions to StateTransition*.java.
> But even if I did update StateTransition*.java, it only would be for
> a message string and a comment.
The structure of the StateTransition test class makes it difficult to
identity the specific assertion causing the failure, but the enhanced
messages on failure make it clear that there is a violation of the
lifecycle table and the text indicates the exact scenario that is
failing.
Craig
>
> Martin
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: Release branch of JDO 2.0
Posted by Michelle Caisse <Mi...@Sun.COM>.
Martin Zaun wrote:
>
> Michelle, Craig,
>
> Michelle Caisse wrote:
>
>> I have JDO-293, which is dependent on JDO-273 finishing touches.
>> There's also JDO-64 that is still open. And JDO-349.
>>
>> -- Michelle
>
>
> I currently cannot lookup JDO-293 (apache server seems to be down),
> so, I'm not sure about your dependency, but I don't anticipate code
> changes for JDO-273 (and will set it to resolved after my AI below).
This is just about listing all the assertions tested by the lifecycle
test. Then I can finalize the spreadsheet.
-- Michelle
Re: Release branch of JDO 2.0
Posted by Martin Zaun <Ma...@Sun.COM>.
Michelle, Craig,
Michelle Caisse wrote:
> I have JDO-293, which is dependent on JDO-273 finishing touches.
> There's also JDO-64 that is still open. And JDO-349.
>
> -- Michelle
I currently cannot lookup JDO-293 (apache server seems to be down),
so, I'm not sure about your dependency, but I don't anticipate code
changes for JDO-273 (and will set it to resolved after my AI below).
Michelle Caisse wrote:
>
> It would be great if you could add anything that you know is missing, as
> a range of assertion numbers or a set of ranges. Then I could check it
> against the spreadsheet and make sure we have all tested assertions
> marked "yes".
What I'd recommend is that
- the StateTransition tests only refer to A5.9.1..190, which denotes
the global state transition table in the spec and that
- we mark all other state-transition related assertions in the
lifecycle tab of the spreadsheets as duplicates of A5.9.1..190, as
is done for a few (but not all).
I'm currently going over the lifecycle spreadsheet, checking the
transition-related assertions for coverage by A5.9.1..190 and the
newly implemented cases, and preparing a few comments (which I'll
send to you soon).
Now, for the unlikely event that I find any transition assertions not
covered by the global state transition matrix (A5.9.1..190), Craig
would propably rather want to complete the matrix in the spec (errata)
instead of me adding additional assertions to StateTransition*.java.
But even if I did update StateTransition*.java, it only would be for
a message string and a comment.
Martin
Re: Release branch of JDO 2.0
Posted by Michelle Caisse <Mi...@Sun.COM>.
I have JDO-293, which is dependent on JDO-273 finishing touches.
There's also JDO-64 that is still open. And JDO-349.
-- Michelle
Craig L Russell wrote:
> If we do need checkins to the trunk after the branch is created (the
> branch is an svn activity that sends a message to jdo-commits alias)
> then they will need to be done to both the trunk and branch. Of
> course, there are some branch-only things (changing from SNAPSHOT to
> 2.0 in project.xml). But I don't know of any issues that will require
> branch/trunk checkins.
>
> Craig
>
> On Mar 28, 2006, at 7:40 PM, Michelle Caisse wrote:
>
>> Craig,
>>
>> Does this mean there will be no more check-ins? Or will we just
>> check in to both trunk and release branch for the few remaining issues?
>>
>> -- Michelle
>>
>> Craig L Russell wrote:
>>
>>> Javadogs,
>>>
>>> I'm planning on cutting the release branch for JDO 2.0 tomorrow.
>>> There are three open issues that I'm aware of:
>>>
>>> 1. The test with persistent interfaces doesn't work yet; I believe
>>> that this is a JPOX bug that will be fixed without a new release of
>>> the API or TCK.
>>>
>>> 2. The TCK only supports datastore identity with
>>> strategy="identity". This is an issue for vendors who cannot use
>>> this strategy for databases that do not support the SQL GENERATED
>>> ... AS IDENTITY construct for schema. I believe that we can resolve
>>> this TCK issue after release of 2.0.
>>>
>>> 3. Synchronization with JPOX final 1.1.0 release. The JPOX team need
>>> to have an api20 release post-jdo-2.0-rc1 that includes a signature
>>> change for a FetchPlan method. But I think that it's going to have
>>> to either depend on a SNAPSHOT api20 or a renamed api20 release for
>>> testing. Similarly, for testing the jdo 2.0 bits, we will need to
>>> test with SNAPSHOT JPOX bits renamed to jpox-1.1.0.
>>>
>>> Please let me know if you feel that it is not appropriate to start
>>> the release process with the api20 and tck20 bits currently checked
>>> into SVN.
>>>
>>> Thanks,
>>>
>>> Craig
>>>
>>> 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 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: Release branch of JDO 2.0
Posted by Craig L Russell <Cr...@Sun.COM>.
If we do need checkins to the trunk after the branch is created (the
branch is an svn activity that sends a message to jdo-commits alias)
then they will need to be done to both the trunk and branch. Of
course, there are some branch-only things (changing from SNAPSHOT to
2.0 in project.xml). But I don't know of any issues that will require
branch/trunk checkins.
Craig
On Mar 28, 2006, at 7:40 PM, Michelle Caisse wrote:
> Craig,
>
> Does this mean there will be no more check-ins? Or will we just
> check in to both trunk and release branch for the few remaining
> issues?
>
> -- Michelle
>
> Craig L Russell wrote:
>> Javadogs,
>>
>> I'm planning on cutting the release branch for JDO 2.0 tomorrow.
>> There are three open issues that I'm aware of:
>>
>> 1. The test with persistent interfaces doesn't work yet; I believe
>> that this is a JPOX bug that will be fixed without a new release
>> of the API or TCK.
>>
>> 2. The TCK only supports datastore identity with
>> strategy="identity". This is an issue for vendors who cannot use
>> this strategy for databases that do not support the SQL
>> GENERATED ... AS IDENTITY construct for schema. I believe that we
>> can resolve this TCK issue after release of 2.0.
>>
>> 3. Synchronization with JPOX final 1.1.0 release. The JPOX team
>> need to have an api20 release post-jdo-2.0-rc1 that includes a
>> signature change for a FetchPlan method. But I think that it's
>> going to have to either depend on a SNAPSHOT api20 or a renamed
>> api20 release for testing. Similarly, for testing the jdo 2.0
>> bits, we will need to test with SNAPSHOT JPOX bits renamed to
>> jpox-1.1.0.
>>
>> Please let me know if you feel that it is not appropriate to start
>> the release process with the api20 and tck20 bits currently
>> checked into SVN.
>>
>> Thanks,
>>
>> Craig
>>
>> 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 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: Release branch of JDO 2.0
Posted by Michelle Caisse <Mi...@Sun.COM>.
Craig,
Does this mean there will be no more check-ins? Or will we just check
in to both trunk and release branch for the few remaining issues?
-- Michelle
Craig L Russell wrote:
> Javadogs,
>
> I'm planning on cutting the release branch for JDO 2.0 tomorrow. There
> are three open issues that I'm aware of:
>
> 1. The test with persistent interfaces doesn't work yet; I believe
> that this is a JPOX bug that will be fixed without a new release of
> the API or TCK.
>
> 2. The TCK only supports datastore identity with strategy="identity".
> This is an issue for vendors who cannot use this strategy for
> databases that do not support the SQL GENERATED ... AS IDENTITY
> construct for schema. I believe that we can resolve this TCK issue
> after release of 2.0.
>
> 3. Synchronization with JPOX final 1.1.0 release. The JPOX team need
> to have an api20 release post-jdo-2.0-rc1 that includes a signature
> change for a FetchPlan method. But I think that it's going to have to
> either depend on a SNAPSHOT api20 or a renamed api20 release for
> testing. Similarly, for testing the jdo 2.0 bits, we will need to test
> with SNAPSHOT JPOX bits renamed to jpox-1.1.0.
>
> Please let me know if you feel that it is not appropriate to start the
> release process with the api20 and tck20 bits currently checked into SVN.
>
> Thanks,
>
> Craig
>
> 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!
>
>