You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by Craig L Russell <Cr...@Sun.COM> on 2008/03/18 17:12:45 UTC
Clarification of TCK policy
I'd like to get a bit more clarity as to acceptable use of TCK in
Apache projects. The latest official word, from http://www.apache.org/jcp/
:
<official-word>
Projects must keep the official TCK materials confidential. Use your
best judgement. For the elimination of doubt, public discussion about
using the TCK, bugs found while using the TCK, and any project-created
frameworks or assisting software or documentation that do not reveal
the official confidential TCK material is acceptable.
</official-word>
My best judgement says any of the below is subject to the TCK NDA (as
strictly interpreted by others in the past) but the information is
extremely useful to help project members who have not signed the NDA.
Here are some specific questions that have come up before:
1. Can a project publicly post statistical results of a TCK run?
e.g. [java] Total tests run: 1593. Failures: 0, Errors: 5.
2. Can a project publicly post the names of the tests that failed? e.g.
[java] RUN Jdoconfig.testGetPMFEmptyStringOverrides ERROR
[java] RUN Jdoconfig.testGetPMFNullOverrides ERROR
[java] RUN Jdoconfig.testGetPMFStringSpaceOverrides ERROR
[java] RUN Jdoconfig.testGetPMFNamedOverrides ERROR
[java] RUN Jdoconfig.testGetPMFNamedSpacesOverrides ERROR
3. Can a project publicly post the exception that caused the failure?
e.g. [java] 5)
testGetPMFNamedSpacesOverrides
(org
.apache
.jdo
.tck
.api
.persistencemanagerfactory
.config.Jdoconfig)javax.jdo.JDOFatalInternalException: Unexpected
exception caught.
3. Can a project publicly post the full stack trace for a failure?
e.g. [1]
4. Can a project publicly post a source snippet of the failure? e.g. [2]
Thanks in advance,
Craig
[1] [java] 5)
testGetPMFNamedSpacesOverrides
(org
.apache
.jdo
.tck
.api
.persistencemanagerfactory
.config.Jdoconfig)javax.jdo.JDOFatalInternalException: Unexpected
exception caught.
[java] at
javax
.jdo
.JDOHelper
.invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:1024)
[java] at
javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:714)
[java] at
javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:967)
[java] at
javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:836)
[java] at
org
.apache
.jdo
.tck
.api
.persistencemanagerfactory
.config.Jdoconfig.testGetPMFNamedSpacesOverrides(Jdoconfig.java:145)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[java] at
sun
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
[java] at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
[java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:259)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
[java] NestedThrowablesStackTrace:
[java] java.lang.reflect.InvocationTargetException
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[java] at
sun
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
[java] at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
[java] at javax.jdo.JDOHelper$16.run(JDOHelper.java:1763)
[java] at java.security.AccessController.doPrivileged(Native
Method)
[java] at javax.jdo.JDOHelper.invoke(JDOHelper.java:1758)
[java] at
javax
.jdo
.JDOHelper
.invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:1002)
[java] at
javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:714)
[java] at
javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:967)
[java] at
javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:836)
[java] at
org
.apache
.jdo
.tck
.api
.persistencemanagerfactory
.config.Jdoconfig.testGetPMFNamedSpacesOverrides(Jdoconfig.java:145)
[java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[java] at
sun
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
[java] at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
[java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:259)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
[java] at
org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
[java] Caused by: java.lang.ClassCastException:
org.jpox.PersistenceConfiguration$20
[java] at
org
.jpox
.PersistenceConfiguration.setOptions(PersistenceConfiguration.java:4658)
[java] at
org
.jpox
.jdo
.JDOPersistenceManagerFactory
.setPMFOptions(JDOPersistenceManagerFactory.java:381)
[java] at
org
.jpox
.jdo
.JDOPersistenceManagerFactory
.getPersistenceManagerFactory(JDOPersistenceManagerFactory.java:188)
[java] ... 30 more
[2]
public void testGetPMFNamedSpacesOverrides() {
String name = "namedPMF1";
privatePmf = JDOHelper.getPersistenceManagerFactory(overrides,
" \t" + name + " \n");
assertEquals("Incorrect value for RestoreValues",
privatePmf.getRestoreValues(), true);
checkPersistent(name);
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: Clarification of TCK policy
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Scott,
On Mar 18, 2008, at 9:47 AM, Scott O'Bryan wrote:
> I would additionally also like to clarify whether this applies to
> TCK's that might happen to be developed in the OpenSource.
>
> I've got a new sub-project of MyFaces that's being developed by that
> community as the R.I. We're still trying to work out the legalities
> of the TCK (because of dependent liscences from sun), but Oracle
> (the spec lead) is interested in letting the TCK be developed though
> Apache.
>
> This would be legal, would it not?
Both legal and encouraged, I'd say. As Geir notes, the JDO TCK's (for
jsr-12 and jsr-243) were both developed at Apache. Having the
community participate in developing TCK's avoids a lot of problems
later.
Craig
>
>
> Scott
>
>
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: Clarification of TCK policy
Posted by Danese Cooper <da...@gmail.com>.
Hey Onno! Just saying howdy :-)
Danese
On Mar 18, 2008, at 10:07 AM, Geir Magnusson Jr. wrote:
> Welcome Onno! All - Onno is the past Director and Chair of the PMO
> of the JCP. A generally nice guy, but a fierce debater about all
> things JCP. Although we've battled bitterly, I consider him a friend.
>
> Onno, feel free to answer Craig's questions :)
>
> geir
>
>
> On Mar 18, 2008, at 12:54 PM, Onno Kluyt wrote:
>
>> Yes, it would.
>>
>> I believe Craig's questions pertain to Sun's TCKs.
>>
>> Onno.
>>
>> On Mar 18, 2008, at 9:47 AM, Scott O'Bryan wrote:
>>> I would additionally also like to clarify whether this applies to
>>> TCK's that might happen to be developed in the OpenSource.
>>>
>>> I've got a new sub-project of MyFaces that's being developed by
>>> that community as the R.I. We're still trying to work out the
>>> legalities of the TCK (because of dependent liscences from sun),
>>> but Oracle (the spec lead) is interested in letting the TCK be
>>> developed though Apache.
>>>
>>> This would be legal, would it not?
>>>
>>> Scott
>>>
>>> On Tue, Mar 18, 2008 at 10:12 AM, Craig L Russell
>>> <Cr...@sun.com> wrote:
>>> I'd like to get a bit more clarity as to acceptable use of TCK in
>>> Apache projects. The latest official word, from http://
>>> www.apache.org/jcp/
>>> :
>>>
>>> <official-word>
>>> Projects must keep the official TCK materials confidential. Use your
>>> best judgement. For the elimination of doubt, public discussion
>>> about
>>> using the TCK, bugs found while using the TCK, and any project-
>>> created
>>> frameworks or assisting software or documentation that do not reveal
>>> the official confidential TCK material is acceptable.
>>> </official-word>
>>>
>>> My best judgement says any of the below is subject to the TCK NDA
>>> (as
>>> strictly interpreted by others in the past) but the information is
>>> extremely useful to help project members who have not signed the
>>> NDA.
>>>
>>> Here are some specific questions that have come up before:
>>>
>>> 1. Can a project publicly post statistical results of a TCK run?
>>> e.g. [java] Total tests run: 1593. Failures: 0, Errors: 5.
>>>
>>> 2. Can a project publicly post the names of the tests that
>>> failed? e.g.
>>> [java] RUN Jdoconfig.testGetPMFEmptyStringOverrides
>>> ERROR
>>> [java] RUN Jdoconfig.testGetPMFNullOverrides ERROR
>>> [java] RUN Jdoconfig.testGetPMFStringSpaceOverrides
>>> ERROR
>>> [java] RUN Jdoconfig.testGetPMFNamedOverrides ERROR
>>> [java] RUN Jdoconfig.testGetPMFNamedSpacesOverrides
>>> ERROR
>>>
>>> 3. Can a project publicly post the exception that caused the
>>> failure?
>>> e.g. [java] 5)
>>> testGetPMFNamedSpacesOverrides
>>> (org
>>> .apache
>>> .jdo
>>> .tck
>>> .api
>>> .persistencemanagerfactory
>>> .config.Jdoconfig)javax.jdo.JDOFatalInternalException: Unexpected
>>> exception caught.
>>>
>>> 3. Can a project publicly post the full stack trace for a failure?
>>> e.g. [1]
>>>
>>> 4. Can a project publicly post a source snippet of the failure?
>>> e.g. [2]
>>>
>>> Thanks in advance,
>>>
>>> Craig
>>>
>>>
>>> [1] [java] 5)
>>> testGetPMFNamedSpacesOverrides
>>> (org
>>> .apache
>>> .jdo
>>> .tck
>>> .api
>>> .persistencemanagerfactory
>>> .config.Jdoconfig)javax.jdo.JDOFatalInternalException: Unexpected
>>> exception caught.
>>> [java] at
>>> javax
>>> .jdo
>>> .JDOHelper
>>> .invokeGetPersistenceManagerFactoryOnImplementation
>>> (JDOHelper.java:1024)
>>> [java] at
>>> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:714)
>>> [java] at
>>> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:967)
>>> [java] at
>>> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:836)
>>> [java] at
>>> org
>>> .apache
>>> .jdo
>>> .tck
>>> .api
>>> .persistencemanagerfactory
>>> .config.Jdoconfig.testGetPMFNamedSpacesOverrides(Jdoconfig.java:145)
>>> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0
>>> (Native
>>> Method)
>>> [java] at
>>> sun
>>> .reflect.NativeMethodAccessorImpl.invoke
>>> (NativeMethodAccessorImpl.java:
>>> 39)
>>> [java] at
>>> sun
>>> .reflect
>>> .DelegatingMethodAccessorImpl.invoke
>>> (DelegatingMethodAccessorImpl.java:
>>> 25)
>>> [java] at org.apache.jdo.tck.JDO_Test.runBare
>>> (JDO_Test.java:259)
>>> [java] at
>>> org.apache.jdo.tck.util.BatchTestRunner.doRun
>>> (BatchTestRunner.java:108)
>>> [java] at
>>> org.apache.jdo.tck.util.BatchTestRunner.start
>>> (BatchTestRunner.java:148)
>>> [java] at
>>> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:
>>> 123)
>>> [java] NestedThrowablesStackTrace:
>>> [java] java.lang.reflect.InvocationTargetException
>>> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0
>>> (Native
>>> Method)
>>> [java] at
>>> sun
>>> .reflect.NativeMethodAccessorImpl.invoke
>>> (NativeMethodAccessorImpl.java:
>>> 39)
>>> [java] at
>>> sun
>>> .reflect
>>> .DelegatingMethodAccessorImpl.invoke
>>> (DelegatingMethodAccessorImpl.java:
>>> 25)
>>> [java] at javax.jdo.JDOHelper$16.run(JDOHelper.java:1763)
>>> [java] at java.security.AccessController.doPrivileged(Native
>>> Method)
>>> [java] at javax.jdo.JDOHelper.invoke(JDOHelper.java:1758)
>>> [java] at
>>> javax
>>> .jdo
>>> .JDOHelper
>>> .invokeGetPersistenceManagerFactoryOnImplementation
>>> (JDOHelper.java:1002)
>>> [java] at
>>> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:714)
>>> [java] at
>>> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:967)
>>> [java] at
>>> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:836)
>>> [java] at
>>> org
>>> .apache
>>> .jdo
>>> .tck
>>> .api
>>> .persistencemanagerfactory
>>> .config.Jdoconfig.testGetPMFNamedSpacesOverrides(Jdoconfig.java:145)
>>> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0
>>> (Native
>>> Method)
>>> [java] at
>>> sun
>>> .reflect.NativeMethodAccessorImpl.invoke
>>> (NativeMethodAccessorImpl.java:
>>> 39)
>>> [java] at
>>> sun
>>> .reflect
>>> .DelegatingMethodAccessorImpl.invoke
>>> (DelegatingMethodAccessorImpl.java:
>>> 25)
>>> [java] at org.apache.jdo.tck.JDO_Test.runBare
>>> (JDO_Test.java:259)
>>> [java] at
>>> org.apache.jdo.tck.util.BatchTestRunner.doRun
>>> (BatchTestRunner.java:108)
>>> [java] at
>>> org.apache.jdo.tck.util.BatchTestRunner.start
>>> (BatchTestRunner.java:148)
>>> [java] at
>>> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:
>>> 123)
>>> [java] Caused by: java.lang.ClassCastException:
>>> org.jpox.PersistenceConfiguration$20
>>> [java] at
>>> org
>>> .jpox
>>> .PersistenceConfiguration.setOptions
>>> (PersistenceConfiguration.java:4658)
>>> [java] at
>>> org
>>> .jpox
>>> .jdo
>>> .JDOPersistenceManagerFactory
>>> .setPMFOptions(JDOPersistenceManagerFactory.java:381)
>>> [java] at
>>> org
>>> .jpox
>>> .jdo
>>> .JDOPersistenceManagerFactory
>>> .getPersistenceManagerFactory(JDOPersistenceManagerFactory.java:188)
>>> [java] ... 30 more
>>>
>>> [2]
>>> public void testGetPMFNamedSpacesOverrides() {
>>> String name = "namedPMF1";
>>> privatePmf = JDOHelper.getPersistenceManagerFactory
>>> (overrides,
>>> " \t" + name + " \n");
>>> assertEquals("Incorrect value for RestoreValues",
>>> privatePmf.getRestoreValues(), true);
>>> checkPersistent(name);
>>>
>>>
>>> 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: Clarification of TCK policy
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Welcome Onno! All - Onno is the past Director and Chair of the PMO of
the JCP. A generally nice guy, but a fierce debater about all things
JCP. Although we've battled bitterly, I consider him a friend.
Onno, feel free to answer Craig's questions :)
geir
On Mar 18, 2008, at 12:54 PM, Onno Kluyt wrote:
> Yes, it would.
>
> I believe Craig's questions pertain to Sun's TCKs.
>
> Onno.
>
> On Mar 18, 2008, at 9:47 AM, Scott O'Bryan wrote:
>> I would additionally also like to clarify whether this applies to
>> TCK's that might happen to be developed in the OpenSource.
>>
>> I've got a new sub-project of MyFaces that's being developed by
>> that community as the R.I. We're still trying to work out the
>> legalities of the TCK (because of dependent liscences from sun),
>> but Oracle (the spec lead) is interested in letting the TCK be
>> developed though Apache.
>>
>> This would be legal, would it not?
>>
>> Scott
>>
>> On Tue, Mar 18, 2008 at 10:12 AM, Craig L Russell <Craig.Russell@sun.com
>> > wrote:
>> I'd like to get a bit more clarity as to acceptable use of TCK in
>> Apache projects. The latest official word, from http://www.apache.org/jcp/
>> :
>>
>> <official-word>
>> Projects must keep the official TCK materials confidential. Use your
>> best judgement. For the elimination of doubt, public discussion about
>> using the TCK, bugs found while using the TCK, and any project-
>> created
>> frameworks or assisting software or documentation that do not reveal
>> the official confidential TCK material is acceptable.
>> </official-word>
>>
>> My best judgement says any of the below is subject to the TCK NDA (as
>> strictly interpreted by others in the past) but the information is
>> extremely useful to help project members who have not signed the NDA.
>>
>> Here are some specific questions that have come up before:
>>
>> 1. Can a project publicly post statistical results of a TCK run?
>> e.g. [java] Total tests run: 1593. Failures: 0, Errors: 5.
>>
>> 2. Can a project publicly post the names of the tests that failed?
>> e.g.
>> [java] RUN Jdoconfig.testGetPMFEmptyStringOverrides
>> ERROR
>> [java] RUN Jdoconfig.testGetPMFNullOverrides ERROR
>> [java] RUN Jdoconfig.testGetPMFStringSpaceOverrides
>> ERROR
>> [java] RUN Jdoconfig.testGetPMFNamedOverrides ERROR
>> [java] RUN Jdoconfig.testGetPMFNamedSpacesOverrides
>> ERROR
>>
>> 3. Can a project publicly post the exception that caused the failure?
>> e.g. [java] 5)
>> testGetPMFNamedSpacesOverrides
>> (org
>> .apache
>> .jdo
>> .tck
>> .api
>> .persistencemanagerfactory
>> .config.Jdoconfig)javax.jdo.JDOFatalInternalException: Unexpected
>> exception caught.
>>
>> 3. Can a project publicly post the full stack trace for a failure?
>> e.g. [1]
>>
>> 4. Can a project publicly post a source snippet of the failure?
>> e.g. [2]
>>
>> Thanks in advance,
>>
>> Craig
>>
>>
>> [1] [java] 5)
>> testGetPMFNamedSpacesOverrides
>> (org
>> .apache
>> .jdo
>> .tck
>> .api
>> .persistencemanagerfactory
>> .config.Jdoconfig)javax.jdo.JDOFatalInternalException: Unexpected
>> exception caught.
>> [java] at
>> javax
>> .jdo
>> .JDOHelper
>> .invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:
>> 1024)
>> [java] at
>> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:714)
>> [java] at
>> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:967)
>> [java] at
>> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:836)
>> [java] at
>> org
>> .apache
>> .jdo
>> .tck
>> .api
>> .persistencemanagerfactory
>> .config.Jdoconfig.testGetPMFNamedSpacesOverrides(Jdoconfig.java:145)
>> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> [java] at
>> sun
>> .reflect
>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
>> 39)
>> [java] at
>> sun
>> .reflect
>> .DelegatingMethodAccessorImpl
>> .invoke(DelegatingMethodAccessorImpl.java:
>> 25)
>> [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:
>> 259)
>> [java] at
>> org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:
>> 108)
>> [java] at
>> org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:
>> 148)
>> [java] at
>> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:
>> 123)
>> [java] NestedThrowablesStackTrace:
>> [java] java.lang.reflect.InvocationTargetException
>> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> [java] at
>> sun
>> .reflect
>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
>> 39)
>> [java] at
>> sun
>> .reflect
>> .DelegatingMethodAccessorImpl
>> .invoke(DelegatingMethodAccessorImpl.java:
>> 25)
>> [java] at javax.jdo.JDOHelper$16.run(JDOHelper.java:1763)
>> [java] at java.security.AccessController.doPrivileged(Native
>> Method)
>> [java] at javax.jdo.JDOHelper.invoke(JDOHelper.java:1758)
>> [java] at
>> javax
>> .jdo
>> .JDOHelper
>> .invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:
>> 1002)
>> [java] at
>> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:714)
>> [java] at
>> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:967)
>> [java] at
>> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:836)
>> [java] at
>> org
>> .apache
>> .jdo
>> .tck
>> .api
>> .persistencemanagerfactory
>> .config.Jdoconfig.testGetPMFNamedSpacesOverrides(Jdoconfig.java:145)
>> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> [java] at
>> sun
>> .reflect
>> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
>> 39)
>> [java] at
>> sun
>> .reflect
>> .DelegatingMethodAccessorImpl
>> .invoke(DelegatingMethodAccessorImpl.java:
>> 25)
>> [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:
>> 259)
>> [java] at
>> org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:
>> 108)
>> [java] at
>> org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:
>> 148)
>> [java] at
>> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:
>> 123)
>> [java] Caused by: java.lang.ClassCastException:
>> org.jpox.PersistenceConfiguration$20
>> [java] at
>> org
>> .jpox
>> .PersistenceConfiguration.setOptions(PersistenceConfiguration.java:
>> 4658)
>> [java] at
>> org
>> .jpox
>> .jdo
>> .JDOPersistenceManagerFactory
>> .setPMFOptions(JDOPersistenceManagerFactory.java:381)
>> [java] at
>> org
>> .jpox
>> .jdo
>> .JDOPersistenceManagerFactory
>> .getPersistenceManagerFactory(JDOPersistenceManagerFactory.java:188)
>> [java] ... 30 more
>>
>> [2]
>> public void testGetPMFNamedSpacesOverrides() {
>> String name = "namedPMF1";
>> privatePmf =
>> JDOHelper.getPersistenceManagerFactory(overrides,
>> " \t" + name + " \n");
>> assertEquals("Incorrect value for RestoreValues",
>> privatePmf.getRestoreValues(), true);
>> checkPersistent(name);
>>
>>
>> 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: Clarification of TCK policy
Posted by Onno Kluyt <On...@Sun.COM>.
Yes, it would.
I believe Craig's questions pertain to Sun's TCKs.
Onno.
On Mar 18, 2008, at 9:47 AM, Scott O'Bryan wrote:
> I would additionally also like to clarify whether this applies to
> TCK's that might happen to be developed in the OpenSource.
>
> I've got a new sub-project of MyFaces that's being developed by that
> community as the R.I. We're still trying to work out the legalities
> of the TCK (because of dependent liscences from sun), but Oracle
> (the spec lead) is interested in letting the TCK be developed though
> Apache.
>
> This would be legal, would it not?
>
> Scott
>
> On Tue, Mar 18, 2008 at 10:12 AM, Craig L Russell <Craig.Russell@sun.com
> > wrote:
> I'd like to get a bit more clarity as to acceptable use of TCK in
> Apache projects. The latest official word, from http://www.apache.org/jcp/
> :
>
> <official-word>
> Projects must keep the official TCK materials confidential. Use your
> best judgement. For the elimination of doubt, public discussion about
> using the TCK, bugs found while using the TCK, and any project-created
> frameworks or assisting software or documentation that do not reveal
> the official confidential TCK material is acceptable.
> </official-word>
>
> My best judgement says any of the below is subject to the TCK NDA (as
> strictly interpreted by others in the past) but the information is
> extremely useful to help project members who have not signed the NDA.
>
> Here are some specific questions that have come up before:
>
> 1. Can a project publicly post statistical results of a TCK run?
> e.g. [java] Total tests run: 1593. Failures: 0, Errors: 5.
>
> 2. Can a project publicly post the names of the tests that failed?
> e.g.
> [java] RUN Jdoconfig.testGetPMFEmptyStringOverrides
> ERROR
> [java] RUN Jdoconfig.testGetPMFNullOverrides ERROR
> [java] RUN Jdoconfig.testGetPMFStringSpaceOverrides
> ERROR
> [java] RUN Jdoconfig.testGetPMFNamedOverrides ERROR
> [java] RUN Jdoconfig.testGetPMFNamedSpacesOverrides
> ERROR
>
> 3. Can a project publicly post the exception that caused the failure?
> e.g. [java] 5)
> testGetPMFNamedSpacesOverrides
> (org
> .apache
> .jdo
> .tck
> .api
> .persistencemanagerfactory
> .config.Jdoconfig)javax.jdo.JDOFatalInternalException: Unexpected
> exception caught.
>
> 3. Can a project publicly post the full stack trace for a failure?
> e.g. [1]
>
> 4. Can a project publicly post a source snippet of the failure? e.g.
> [2]
>
> Thanks in advance,
>
> Craig
>
>
> [1] [java] 5)
> testGetPMFNamedSpacesOverrides
> (org
> .apache
> .jdo
> .tck
> .api
> .persistencemanagerfactory
> .config.Jdoconfig)javax.jdo.JDOFatalInternalException: Unexpected
> exception caught.
> [java] at
> javax
> .jdo
> .JDOHelper
> .invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:
> 1024)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:714)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:967)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:836)
> [java] at
> org
> .apache
> .jdo
> .tck
> .api
> .persistencemanagerfactory
> .config.Jdoconfig.testGetPMFNamedSpacesOverrides(Jdoconfig.java:145)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [java] at
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> [java] at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:
> 25)
> [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:
> 259)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:
> 108)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:
> 148)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
> [java] NestedThrowablesStackTrace:
> [java] java.lang.reflect.InvocationTargetException
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [java] at
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> [java] at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:
> 25)
> [java] at javax.jdo.JDOHelper$16.run(JDOHelper.java:1763)
> [java] at java.security.AccessController.doPrivileged(Native
> Method)
> [java] at javax.jdo.JDOHelper.invoke(JDOHelper.java:1758)
> [java] at
> javax
> .jdo
> .JDOHelper
> .invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:
> 1002)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:714)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:967)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:836)
> [java] at
> org
> .apache
> .jdo
> .tck
> .api
> .persistencemanagerfactory
> .config.Jdoconfig.testGetPMFNamedSpacesOverrides(Jdoconfig.java:145)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [java] at
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> [java] at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:
> 25)
> [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:
> 259)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:
> 108)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:
> 148)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
> [java] Caused by: java.lang.ClassCastException:
> org.jpox.PersistenceConfiguration$20
> [java] at
> org
> .jpox
> .PersistenceConfiguration.setOptions(PersistenceConfiguration.java:
> 4658)
> [java] at
> org
> .jpox
> .jdo
> .JDOPersistenceManagerFactory
> .setPMFOptions(JDOPersistenceManagerFactory.java:381)
> [java] at
> org
> .jpox
> .jdo
> .JDOPersistenceManagerFactory
> .getPersistenceManagerFactory(JDOPersistenceManagerFactory.java:188)
> [java] ... 30 more
>
> [2]
> public void testGetPMFNamedSpacesOverrides() {
> String name = "namedPMF1";
> privatePmf = JDOHelper.getPersistenceManagerFactory(overrides,
> " \t" + name + " \n");
> assertEquals("Incorrect value for RestoreValues",
> privatePmf.getRestoreValues(), true);
> checkPersistent(name);
>
>
> 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: Clarification of TCK policy
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Yes, of course. :) JDO's TCK is done here at the ASF.
geir
On Mar 18, 2008, at 12:47 PM, Scott O'Bryan wrote:
> I would additionally also like to clarify whether this applies to
> TCK's that might happen to be developed in the OpenSource.
>
> I've got a new sub-project of MyFaces that's being developed by that
> community as the R.I. We're still trying to work out the legalities
> of the TCK (because of dependent liscences from sun), but Oracle
> (the spec lead) is interested in letting the TCK be developed though
> Apache.
>
> This would be legal, would it not?
>
> Scott
>
> On Tue, Mar 18, 2008 at 10:12 AM, Craig L Russell <Craig.Russell@sun.com
> > wrote:
> I'd like to get a bit more clarity as to acceptable use of TCK in
> Apache projects. The latest official word, from http://www.apache.org/jcp/
> :
>
> <official-word>
> Projects must keep the official TCK materials confidential. Use your
> best judgement. For the elimination of doubt, public discussion about
> using the TCK, bugs found while using the TCK, and any project-created
> frameworks or assisting software or documentation that do not reveal
> the official confidential TCK material is acceptable.
> </official-word>
>
> My best judgement says any of the below is subject to the TCK NDA (as
> strictly interpreted by others in the past) but the information is
> extremely useful to help project members who have not signed the NDA.
>
> Here are some specific questions that have come up before:
>
> 1. Can a project publicly post statistical results of a TCK run?
> e.g. [java] Total tests run: 1593. Failures: 0, Errors: 5.
>
> 2. Can a project publicly post the names of the tests that failed?
> e.g.
> [java] RUN Jdoconfig.testGetPMFEmptyStringOverrides
> ERROR
> [java] RUN Jdoconfig.testGetPMFNullOverrides ERROR
> [java] RUN Jdoconfig.testGetPMFStringSpaceOverrides
> ERROR
> [java] RUN Jdoconfig.testGetPMFNamedOverrides ERROR
> [java] RUN Jdoconfig.testGetPMFNamedSpacesOverrides
> ERROR
>
> 3. Can a project publicly post the exception that caused the failure?
> e.g. [java] 5)
> testGetPMFNamedSpacesOverrides
> (org
> .apache
> .jdo
> .tck
> .api
> .persistencemanagerfactory
> .config.Jdoconfig)javax.jdo.JDOFatalInternalException: Unexpected
> exception caught.
>
> 3. Can a project publicly post the full stack trace for a failure?
> e.g. [1]
>
> 4. Can a project publicly post a source snippet of the failure? e.g.
> [2]
>
> Thanks in advance,
>
> Craig
>
>
> [1] [java] 5)
> testGetPMFNamedSpacesOverrides
> (org
> .apache
> .jdo
> .tck
> .api
> .persistencemanagerfactory
> .config.Jdoconfig)javax.jdo.JDOFatalInternalException: Unexpected
> exception caught.
> [java] at
> javax
> .jdo
> .JDOHelper
> .invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:
> 1024)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:714)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:967)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:836)
> [java] at
> org
> .apache
> .jdo
> .tck
> .api
> .persistencemanagerfactory
> .config.Jdoconfig.testGetPMFNamedSpacesOverrides(Jdoconfig.java:145)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [java] at
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> [java] at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:
> 25)
> [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:
> 259)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:
> 108)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:
> 148)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
> [java] NestedThrowablesStackTrace:
> [java] java.lang.reflect.InvocationTargetException
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [java] at
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> [java] at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:
> 25)
> [java] at javax.jdo.JDOHelper$16.run(JDOHelper.java:1763)
> [java] at java.security.AccessController.doPrivileged(Native
> Method)
> [java] at javax.jdo.JDOHelper.invoke(JDOHelper.java:1758)
> [java] at
> javax
> .jdo
> .JDOHelper
> .invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:
> 1002)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:714)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:967)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:836)
> [java] at
> org
> .apache
> .jdo
> .tck
> .api
> .persistencemanagerfactory
> .config.Jdoconfig.testGetPMFNamedSpacesOverrides(Jdoconfig.java:145)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [java] at
> sun
> .reflect
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> [java] at
> sun
> .reflect
> .DelegatingMethodAccessorImpl
> .invoke(DelegatingMethodAccessorImpl.java:
> 25)
> [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:
> 259)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:
> 108)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:
> 148)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
> [java] Caused by: java.lang.ClassCastException:
> org.jpox.PersistenceConfiguration$20
> [java] at
> org
> .jpox
> .PersistenceConfiguration.setOptions(PersistenceConfiguration.java:
> 4658)
> [java] at
> org
> .jpox
> .jdo
> .JDOPersistenceManagerFactory
> .setPMFOptions(JDOPersistenceManagerFactory.java:381)
> [java] at
> org
> .jpox
> .jdo
> .JDOPersistenceManagerFactory
> .getPersistenceManagerFactory(JDOPersistenceManagerFactory.java:188)
> [java] ... 30 more
>
> [2]
> public void testGetPMFNamedSpacesOverrides() {
> String name = "namedPMF1";
> privatePmf = JDOHelper.getPersistenceManagerFactory(overrides,
> " \t" + name + " \n");
> assertEquals("Incorrect value for RestoreValues",
> privatePmf.getRestoreValues(), true);
> checkPersistent(name);
>
>
> 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: Clarification of TCK policy
Posted by Scott O'Bryan <da...@gmail.com>.
I would additionally also like to clarify whether this applies to TCK's that
might happen to be developed in the OpenSource.
I've got a new sub-project of MyFaces that's being developed by that
community as the R.I. We're still trying to work out the legalities of the
TCK (because of dependent liscences from sun), but Oracle (the spec lead) is
interested in letting the TCK be developed though Apache.
This would be legal, would it not?
Scott
On Tue, Mar 18, 2008 at 10:12 AM, Craig L Russell <Cr...@sun.com>
wrote:
> I'd like to get a bit more clarity as to acceptable use of TCK in
> Apache projects. The latest official word, from http://www.apache.org/jcp/
> :
>
> <official-word>
> Projects must keep the official TCK materials confidential. Use your
> best judgement. For the elimination of doubt, public discussion about
> using the TCK, bugs found while using the TCK, and any project-created
> frameworks or assisting software or documentation that do not reveal
> the official confidential TCK material is acceptable.
> </official-word>
>
> My best judgement says any of the below is subject to the TCK NDA (as
> strictly interpreted by others in the past) but the information is
> extremely useful to help project members who have not signed the NDA.
>
> Here are some specific questions that have come up before:
>
> 1. Can a project publicly post statistical results of a TCK run?
> e.g. [java] Total tests run: 1593. Failures: 0, Errors: 5.
>
> 2. Can a project publicly post the names of the tests that failed? e.g.
> [java] RUN Jdoconfig.testGetPMFEmptyStringOverrides ERROR
> [java] RUN Jdoconfig.testGetPMFNullOverrides ERROR
> [java] RUN Jdoconfig.testGetPMFStringSpaceOverrides ERROR
> [java] RUN Jdoconfig.testGetPMFNamedOverrides ERROR
> [java] RUN Jdoconfig.testGetPMFNamedSpacesOverrides ERROR
>
> 3. Can a project publicly post the exception that caused the failure?
> e.g. [java] 5)
> testGetPMFNamedSpacesOverrides
> (org
> .apache
> .jdo
> .tck
> .api
> .persistencemanagerfactory
> .config.Jdoconfig)javax.jdo.JDOFatalInternalException: Unexpected
> exception caught.
>
> 3. Can a project publicly post the full stack trace for a failure?
> e.g. [1]
>
> 4. Can a project publicly post a source snippet of the failure? e.g. [2]
>
> Thanks in advance,
>
> Craig
>
>
> [1] [java] 5)
> testGetPMFNamedSpacesOverrides
> (org
> .apache
> .jdo
> .tck
> .api
> .persistencemanagerfactory
> .config.Jdoconfig)javax.jdo.JDOFatalInternalException: Unexpected
> exception caught.
> [java] at
> javax
> .jdo
> .JDOHelper
> .invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:1024)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:714)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:967)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:836)
> [java] at
> org
> .apache
> .jdo
> .tck
> .api
> .persistencemanagerfactory
> .config.Jdoconfig.testGetPMFNamedSpacesOverrides(Jdoconfig.java:145)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [java] at
> sun
> .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> [java] at
> sun
> .reflect
> .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
> 25)
> [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:259)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
> [java] NestedThrowablesStackTrace:
> [java] java.lang.reflect.InvocationTargetException
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [java] at
> sun
> .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> [java] at
> sun
> .reflect
> .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
> 25)
> [java] at javax.jdo.JDOHelper$16.run(JDOHelper.java:1763)
> [java] at java.security.AccessController.doPrivileged(Native
> Method)
> [java] at javax.jdo.JDOHelper.invoke(JDOHelper.java:1758)
> [java] at
> javax
> .jdo
> .JDOHelper
> .invokeGetPersistenceManagerFactoryOnImplementation(JDOHelper.java:1002)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:714)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:967)
> [java] at
> javax.jdo.JDOHelper.getPersistenceManagerFactory(JDOHelper.java:836)
> [java] at
> org
> .apache
> .jdo
> .tck
> .api
> .persistencemanagerfactory
> .config.Jdoconfig.testGetPMFNamedSpacesOverrides(Jdoconfig.java:145)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [java] at
> sun
> .reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> [java] at
> sun
> .reflect
> .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
> 25)
> [java] at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:259)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148)
> [java] at
> org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123)
> [java] Caused by: java.lang.ClassCastException:
> org.jpox.PersistenceConfiguration$20
> [java] at
> org
> .jpox
> .PersistenceConfiguration.setOptions(PersistenceConfiguration.java:4658)
> [java] at
> org
> .jpox
> .jdo
> .JDOPersistenceManagerFactory
> .setPMFOptions(JDOPersistenceManagerFactory.java:381)
> [java] at
> org
> .jpox
> .jdo
> .JDOPersistenceManagerFactory
> .getPersistenceManagerFactory(JDOPersistenceManagerFactory.java:188)
> [java] ... 30 more
>
> [2]
> public void testGetPMFNamedSpacesOverrides() {
> String name = "namedPMF1";
> privatePmf = JDOHelper.getPersistenceManagerFactory(overrides,
> " \t" + name + " \n");
> assertEquals("Incorrect value for RestoreValues",
> privatePmf.getRestoreValues(), true);
> checkPersistent(name);
>
>
> 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: Clarification of TCK policy
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
No - we actually get Lance annoyed because we forget to tell them
sometimes and the read about it on our site :)
On Mar 18, 2008, at 2:21 PM, Alan Cabrera wrote:
>
> On Mar 18, 2008, at 10:54 AM, Geir Magnusson Jr. wrote:
>
>>
>> On Mar 18, 2008, at 1:45 PM, Alan Cabrera wrote:
>>
>>>
>>> On Mar 18, 2008, at 10:43 AM, Alan Cabrera wrote:
>>>
>>>>
>>>> On Mar 18, 2008, at 9:12 AM, Craig L Russell wrote:
>>>>
>>>>> I'd like to get a bit more clarity as to acceptable use of TCK
>>>>> in Apache projects. The latest official word, from http://www.apache.org/jcp/
>>>>> :
>>>>>
>>>>> <official-word>
>>>>> Projects must keep the official TCK materials confidential. Use
>>>>> your best judgement. For the elimination of doubt, public
>>>>> discussion about using the TCK, bugs found while using the TCK,
>>>>> and any project-created frameworks or assisting software or
>>>>> documentation that do not reveal the official confidential TCK
>>>>> material is acceptable.
>>>>> </official-word>
>>>>>
>>>>> My best judgement says any of the below is subject to the TCK
>>>>> NDA (as strictly interpreted by others in the past) but the
>>>>> information is extremely useful to help project members who have
>>>>> not signed the NDA.
>>>>>
>>>>> Here are some specific questions that have come up before:
>>>>>
>>>>> 1. Can a project publicly post statistical results of a TCK run?
>>>>> e.g. [java] Total tests run: 1593. Failures: 0, Errors: 5.
>>>>
>>>> I can speak about the J2EE TCK. We are not allowed to publish
>>>> statistical results of a TCK run. We cannot publish the progress
>>>> of a specific version with regards to its passing the TCK. We
>>>> can only state wether a specific version passes the TCK or not.
>>>
>>> A little more detail. We can only state that a specific version
>>> passes the TCK after we have notified Sun and they have ACK'd.
>>
>> I don't know where that comes from. We self-certify and then tell
>> Sun afterwards. There's no requirement to get that ack.
>
>
> Ahh, ok. I was always under the impression that Sun had to ACK
> after we self-certify and tell Sun before we make a public
> announcement. My bad.
>
>
> Regards,
> Alan
>
>
Re: Clarification of TCK policy
Posted by Alan Cabrera <ad...@toolazydogs.com>.
On Mar 18, 2008, at 10:54 AM, Geir Magnusson Jr. wrote:
>
> On Mar 18, 2008, at 1:45 PM, Alan Cabrera wrote:
>
>>
>> On Mar 18, 2008, at 10:43 AM, Alan Cabrera wrote:
>>
>>>
>>> On Mar 18, 2008, at 9:12 AM, Craig L Russell wrote:
>>>
>>>> I'd like to get a bit more clarity as to acceptable use of TCK in
>>>> Apache projects. The latest official word, from http://www.apache.org/jcp/
>>>> :
>>>>
>>>> <official-word>
>>>> Projects must keep the official TCK materials confidential. Use
>>>> your best judgement. For the elimination of doubt, public
>>>> discussion about using the TCK, bugs found while using the TCK,
>>>> and any project-created frameworks or assisting software or
>>>> documentation that do not reveal the official confidential TCK
>>>> material is acceptable.
>>>> </official-word>
>>>>
>>>> My best judgement says any of the below is subject to the TCK NDA
>>>> (as strictly interpreted by others in the past) but the
>>>> information is extremely useful to help project members who have
>>>> not signed the NDA.
>>>>
>>>> Here are some specific questions that have come up before:
>>>>
>>>> 1. Can a project publicly post statistical results of a TCK run?
>>>> e.g. [java] Total tests run: 1593. Failures: 0, Errors: 5.
>>>
>>> I can speak about the J2EE TCK. We are not allowed to publish
>>> statistical results of a TCK run. We cannot publish the progress
>>> of a specific version with regards to its passing the TCK. We can
>>> only state wether a specific version passes the TCK or not.
>>
>> A little more detail. We can only state that a specific version
>> passes the TCK after we have notified Sun and they have ACK'd.
>
> I don't know where that comes from. We self-certify and then tell
> Sun afterwards. There's no requirement to get that ack.
Ahh, ok. I was always under the impression that Sun had to ACK after
we self-certify and tell Sun before we make a public announcement. My
bad.
Regards,
Alan
Re: Clarification of TCK policy
Posted by Onno Kluyt <On...@Sun.COM>.
That's right. It's self-certify.
To Alan's comment about statistical results, we are indeed not
interested in that. It is not interesting to developers trying to use
your software that you are 75, 85 or 98% compatible because that's
going to be different for everybody. Sun is only interested in
implementers going all the way and pass the TCK which is why our
licenses clamp down on what you can say publicly. We want to
discourage "good enough" scenarios. Having said that, I can see that
can be informative to be able to inform your developers how much more
work you still have to do - ie, how much longer do they need to wait.
Onno.
On Mar 18, 2008, at 10:54 AM, Geir Magnusson Jr. wrote:
>
> On Mar 18, 2008, at 1:45 PM, Alan Cabrera wrote:
>
>>
>> On Mar 18, 2008, at 10:43 AM, Alan Cabrera wrote:
>>
>>>
>>> On Mar 18, 2008, at 9:12 AM, Craig L Russell wrote:
>>>
>>>> I'd like to get a bit more clarity as to acceptable use of TCK in
>>>> Apache projects. The latest official word, from http://www.apache.org/jcp/
>>>> :
>>>>
>>>> <official-word>
>>>> Projects must keep the official TCK materials confidential. Use
>>>> your best judgement. For the elimination of doubt, public
>>>> discussion about using the TCK, bugs found while using the TCK,
>>>> and any project-created frameworks or assisting software or
>>>> documentation that do not reveal the official confidential TCK
>>>> material is acceptable.
>>>> </official-word>
>>>>
>>>> My best judgement says any of the below is subject to the TCK NDA
>>>> (as strictly interpreted by others in the past) but the
>>>> information is extremely useful to help project members who have
>>>> not signed the NDA.
>>>>
>>>> Here are some specific questions that have come up before:
>>>>
>>>> 1. Can a project publicly post statistical results of a TCK run?
>>>> e.g. [java] Total tests run: 1593. Failures: 0, Errors: 5.
>>>
>>> I can speak about the J2EE TCK. We are not allowed to publish
>>> statistical results of a TCK run. We cannot publish the progress
>>> of a specific version with regards to its passing the TCK. We can
>>> only state wether a specific version passes the TCK or not.
>>
>> A little more detail. We can only state that a specific version
>> passes the TCK after we have notified Sun and they have ACK'd.
>
> I don't know where that comes from. We self-certify and then tell
> Sun afterwards. There's no requirement to get that ack.
>
> geir
>
>>
>>
>>
>>
>> Regards,
>> Alan
>>
>
Re: Clarification of TCK policy
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Mar 18, 2008, at 1:45 PM, Alan Cabrera wrote:
>
> On Mar 18, 2008, at 10:43 AM, Alan Cabrera wrote:
>
>>
>> On Mar 18, 2008, at 9:12 AM, Craig L Russell wrote:
>>
>>> I'd like to get a bit more clarity as to acceptable use of TCK in
>>> Apache projects. The latest official word, from http://www.apache.org/jcp/
>>> :
>>>
>>> <official-word>
>>> Projects must keep the official TCK materials confidential. Use
>>> your best judgement. For the elimination of doubt, public
>>> discussion about using the TCK, bugs found while using the TCK,
>>> and any project-created frameworks or assisting software or
>>> documentation that do not reveal the official confidential TCK
>>> material is acceptable.
>>> </official-word>
>>>
>>> My best judgement says any of the below is subject to the TCK NDA
>>> (as strictly interpreted by others in the past) but the
>>> information is extremely useful to help project members who have
>>> not signed the NDA.
>>>
>>> Here are some specific questions that have come up before:
>>>
>>> 1. Can a project publicly post statistical results of a TCK run?
>>> e.g. [java] Total tests run: 1593. Failures: 0, Errors: 5.
>>
>> I can speak about the J2EE TCK. We are not allowed to publish
>> statistical results of a TCK run. We cannot publish the progress
>> of a specific version with regards to its passing the TCK. We can
>> only state wether a specific version passes the TCK or not.
>
> A little more detail. We can only state that a specific version
> passes the TCK after we have notified Sun and they have ACK'd.
I don't know where that comes from. We self-certify and then tell Sun
afterwards. There's no requirement to get that ack.
geir
>
>
>
>
> Regards,
> Alan
>
Re: Clarification of TCK policy
Posted by Alan Cabrera <ad...@toolazydogs.com>.
On Mar 18, 2008, at 10:43 AM, Alan Cabrera wrote:
>
> On Mar 18, 2008, at 9:12 AM, Craig L Russell wrote:
>
>> I'd like to get a bit more clarity as to acceptable use of TCK in
>> Apache projects. The latest official word, from http://www.apache.org/jcp/
>> :
>>
>> <official-word>
>> Projects must keep the official TCK materials confidential. Use
>> your best judgement. For the elimination of doubt, public
>> discussion about using the TCK, bugs found while using the TCK, and
>> any project-created frameworks or assisting software or
>> documentation that do not reveal the official confidential TCK
>> material is acceptable.
>> </official-word>
>>
>> My best judgement says any of the below is subject to the TCK NDA
>> (as strictly interpreted by others in the past) but the information
>> is extremely useful to help project members who have not signed the
>> NDA.
>>
>> Here are some specific questions that have come up before:
>>
>> 1. Can a project publicly post statistical results of a TCK run?
>> e.g. [java] Total tests run: 1593. Failures: 0, Errors: 5.
>
> I can speak about the J2EE TCK. We are not allowed to publish
> statistical results of a TCK run. We cannot publish the progress of
> a specific version with regards to its passing the TCK. We can only
> state wether a specific version passes the TCK or not.
A little more detail. We can only state that a specific version
passes the TCK after we have notified Sun and they have ACK'd.
Regards,
Alan
Re: Clarification of TCK policy
Posted by Alan Cabrera <ad...@toolazydogs.com>.
On Mar 18, 2008, at 9:12 AM, Craig L Russell wrote:
> I'd like to get a bit more clarity as to acceptable use of TCK in
> Apache projects. The latest official word, from http://www.apache.org/jcp/
> :
>
> <official-word>
> Projects must keep the official TCK materials confidential. Use your
> best judgement. For the elimination of doubt, public discussion
> about using the TCK, bugs found while using the TCK, and any project-
> created frameworks or assisting software or documentation that do
> not reveal the official confidential TCK material is acceptable.
> </official-word>
>
> My best judgement says any of the below is subject to the TCK NDA
> (as strictly interpreted by others in the past) but the information
> is extremely useful to help project members who have not signed the
> NDA.
>
> Here are some specific questions that have come up before:
>
> 1. Can a project publicly post statistical results of a TCK run?
> e.g. [java] Total tests run: 1593. Failures: 0, Errors: 5.
I can speak about the J2EE TCK. We are not allowed to publish
statistical results of a TCK run. We cannot publish the progress of a
specific version with regards to its passing the TCK. We can only
state wether a specific version passes the TCK or not.
> 2. Can a project publicly post the names of the tests that failed?
> e.g.
> [java] RUN Jdoconfig.testGetPMFEmptyStringOverrides ERROR
> [java] RUN Jdoconfig.testGetPMFNullOverrides ERROR
> [java] RUN Jdoconfig.testGetPMFStringSpaceOverrides ERROR
> [java] RUN Jdoconfig.testGetPMFNamedOverrides ERROR
> [java] RUN Jdoconfig.testGetPMFNamedSpacesOverrides ERROR
We cannot publicly post the names of the tests since these names are
proprietary.
> 3. Can a project publicly post the exception that caused the
> failure? e.g. [java] 5)
> testGetPMFNamedSpacesOverrides
> (org
> .apache
> .jdo
> .tck
> .api
> .persistencemanagerfactory
> .config.Jdoconfig)javax.jdo.JDOFatalInternalException: Unexpected
> exception caught.
ditto
> 3. Can a project publicly post the full stack trace for a failure?
> e.g. [1]
ditto
> 4. Can a project publicly post a source snippet of the failure? e.g.
> [2]
ditto
Regards,
Alan