Hi Michael,
Looks good
Craig
On Oct 10, 2005, at 1:49 PM, Michael Bouschen wrote:
Hi,
Multiproject build - Michelle proposes that we should create a new
multiproject goal that invokes the default goal of each TCK
subproject.
This will compile all code, but not install the schema or run
Hi Karan,
On Oct 14, 2005, at 7:10 AM, Karan Malhi wrote:
Hi,
First of all, I am sorry, I could not contribute much in the past
two or
three weeks. Hopefully, I should be able to start contributing some
things
this weekend.
I had a question regarding queries.
I have two classes , Address
Hi,
Just one comment. When mapping using PC key, serialized-key doesn't
make sense. (In fact, I wonder why it's in the spec. except for
completeness).
Craig
On Oct 14, 2005, at 2:20 PM, Apache Wiki wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Jdo Wiki"
Attendees: Michelle Caisse, Martin Zaun, Michael Bouschen, Michael
Watzek, Craig Russell
1. Test status (Michael W) 6 configurations of 28 fail; Alltests
status: 405 tests; 8 failures; 15 errors.
2. Query tests (Michael W) Patches for 156, 157, 158, 159 and 168
have been reviewed and the
Javadogs,
I've reviewed this material and agree with the general conclusion,
that we can add the ability to include detached objects in the
closure of instances for both makePersistent and attachCopy.
The spec as of today requires treating these three types of objects
in the closure diffe
Hi Andy, Erik,
Can you please let us know when JPOX has the "new" Query method? I
didn't see it in the SNAPSHOT that I have.
Thanks,
Craig
Hi Michael,
I talked to Michael Bouschen about these and we think that there is
some clarification needed in the specification.
On Oct 18, 2005, at 8:02 AM, Michael Watzek wrote:
Hi Craig,
I have 3 questions concerning named queries:
1) Assertion A14.5-13 specifies:
[...
The order is base
Javadogs,
I'd like to get feedback from jdo vendors who have implemented detach
and attach. I'm really keen on getting user feedback or use-cases for
attach.
In particular, how do implementations handle transient instances? Are
there use-cases that demand that transient instances are copi
Hi,
I'm still waiting to check in the setRange(String) into api20.
Is JPOX ready?
Craig
On Oct 19, 2005, at 3:02 AM, Michael Watzek wrote:
Hi Erik,
the JPOX images in the maven repository are fine again:
We have 6 of 28 failing configurations. The results on
alltests.conf are:
derby-ap
Hi Erik,
Ok, here it comes.
Craig
On Oct 19, 2005, at 3:23 PM, [EMAIL PROTECTED] wrote:
Craig,
I guess the easiest way to go is to commit everything and jpox team
will catch
up next day. I can't keep track mails/patches anymore.
Quoting Craig L Russell <[EMAIL PROTECTED]>:
Hi,
There is no test in the TCK for this condition, as there is no
specific behavior required in the specification. As you can see from
JPOX, the enhancer might fail or the runtime might fail. So it is a
requirement, just not a requirement that can be tested. :-(
Craig
On Oct 20, 2005, a
Hi Michael,
On Oct 20, 2005, at 3:27 AM, Michael Watzek wrote:
Hi Craig,
assertion A14.5-15 specifies:
"The Query instance returned from this method can be modified by
the application, just like any other Query instance."
The metadata for named queries might contain a boolean attribute
Hi Michael,
Actually, we decided that setUnmodifiable should not take an
argument, sort of like setRollbackOnly. You can only set unmodifiable
to true...
Craig
On Oct 20, 2005, at 4:24 AM, Michael Bouschen wrote:
Hi Michael,
the unmodifiable attribute in the metadata corresponds to meth
Hi Michael,
The relevant bit of the specification is regarding jdoPostLoad.
A10.1-2 [This method is not modified by the enhancer.]
So whatever is done in jdoPostLoad, the implementation will not be
called "transparently".
But the spec doesn't require jdoPostLoad to be called if only fetch
Attendees: Michelle Caisse, Martin Zaun, Karan Malhi, Craig Russell
1. Test status (Michelle)
2. Query tests (Michael) new tests have been checked in along with
some JPOX bugs filed in JIRA.
3. Detached objects (Matthew) no change.
4. getObjectsById tests (Geoff) no change.
5. ri11 enhance
Hi,
Nice analysis, Andy. I agree that the test should be changed as you
suggest.
Thanks,
Craig
On Oct 22, 2005, at 3:01 AM, Andy Jefferson (JIRA) wrote:
[ http://issues.apache.org/jira/browse/JDO-144?page=all ]
Andy Jefferson reassigned JDO-144:
--
Hi Andy,
Thanks for the analysis and the fix.
You're right that the relevant part of the spec for the detach
ordering doesn't specify the order of the callback and the listener.
The intent is for all the listeners and callbacks to use the same
order: the pre-listener is called; the pre-cal
Hi Andy,
This is similar to the detach listener issue. All the other listeners
are specified to be called "around" the corresponding callbacks. The
lack of text describing the listener/callback ordering is a bug in
the spec.
Here's the proposed update.
package javax.jdo.listener;
public
Hi Michael,
Craig
On Oct 25, 2005, at 5:55 AM, Michael Watzek wrote:
Hi Craig,
Hi Michael,
The relevant bit of the specification is regarding jdoPostLoad.
A10.1-2 [This method is not modified by the enhancer.]
So whatever is done in jdoPostLoad, the implementation will not
be called "
Hi Andy,
On Oct 23, 2005, at 2:25 AM, Andy Jefferson wrote:
Hi Michelle,
I've been through the issues with the various TCK Map tests, and
have the
following comments :-
1. The key-type, value-type are currently being defined as things
like Object,
String, SimpleClass whereas the Collecti
Hi Andy,
On Oct 23, 2005, at 2:25 AM, Andy Jefferson wrote:
Hi Michelle,
I've been through the issues with the various TCK Map tests, and
have the
following comments :-
3. JPOX also supports Maps where there is no join table and the key
is a field
in the value class. Is there a TCK test
Hi Michael,
Thanks for the reminder. I've updated it.
Craig
On Oct 26, 2005, at 7:35 AM, Michael Watzek wrote:
Hi Craig,
you filed JIRA http://issues.apache.org/jira/browse/JDO-190 which
has no component. Probably it should be tck20.
Regards,
Michael
--
--
Hi,
I asked Michelle to add a discussion of JDO-188 to the agenda for
tomorrow.
I'd like to get the implementation into api20 quickly, so if we have
a volunteer to do this, great. But since it's an api20 issue, if no
one is going to work on it soon, I'll take it.
Please update the JIRA
Javadogs,
This should be non-controversial. There is a method missing from the
JDOHelper chapter that is already implemented in the current working
version used in the Apache project. I propose to fix the
specification as follows:
A8.6-21[public static PersistenceManagerFactory
getPers
Javadogs,
In the specification, the get/setDetachAllOnCommit methods were
defined on both PersistenceManager and Transaction. This was an
oversight; the method belongs only on PersistenceManager. The
following text will be moved from the specification in chapter 13 to 12:
Detach all inst
hey are
first checked to see if they are in the package in which they are
used, and if not, assumed to be in the java.lang package.
Craig
On Oct 26, 2005, at 5:20 AM, [EMAIL PROTECTED] wrote:
Quoting Craig L Russell <[EMAIL PROTECTED]>:
The only other interpretation that I would su
Javadogs,
Please comment on this proposal.
There are so few differences between makePersistent and attachCopy,
it's confusing. The only significant differences between the APIs is
in the treatment of transient instances. MakePersistent makes
transient instances transition to persistent-new
Hi Michael,
On Nov 2, 2005, at 6:12 AM, Michael Bouschen wrote:
Hi,
the JDO spec allows public final static fields being used in JDOQL.
Chapter 14.6.2 says: "Identifiers that are persistent field names
or public final static field names are required to be supported by
JDO implementations
low
copy persistent instances. Maybe something like copyForAttachment or
something like it.
Regards Michael
Regards,
Craig
Craig L Russell schrieb:
With this change, there is no standard way to attach the same
object graph to multiple persistence managers. So a method is
added to JDOH
Hi Michael,
On Nov 2, 2005, at 7:13 AM, Michael Bouschen wrote:
Hi Craig,
+1!
The current spec has a section called "Attaching Instances" (at the
end of 12.6.8 Detaching and attaching instances). I assume this
section will then describe how to use makePersistent to attach
detached insta
Hi Martin,
This might be just a JDK 1.5 issue. Earlier VMs might really ignore
all comments instead of validating them.
Since our objective is to be able to compile/test/run on any VM from
1.3 to 1.5, this is indeed good to fix.
Craig
On Nov 3, 2005, at 1:11 PM, Martin Zaun wrote:
Com
Javadogs,
Currently there is no metadata that allows deployment to specify a
more specific type for the elements of an array. This is needed in
cases where the array is a generic type or an interface type and the
actual type is known at deployment time.
Proposal:
Craig Russell
Archi
Javadogs,
We need a way to determine whether a JDO implementation supports
various mapping features. Specifically:
Heterogeneous collections with new-class mapping of subclasses
Mapping fields of Object type and interface types
Craig Russell
Architect, Sun Java Enterprise System http://java
Javadogs,
Did we really intend for the single string version of JDOQL to
include "IMPORTS import..."?
setFilter("SELECT e FROM EMPLOYEE e WHERE e.grade <
HardClass.HIGHEST_GRADE");
declareImports("import org.apache.jdo.tck.SimpleClass; import
org.apache.jdo.tck.HardClass";
pm.newQuery("
Hi Michael,
On Nov 7, 2005, at 7:43 AM, Michael Watzek wrote:
Hi Craig,
assertion A14.6.9-7 specifies:
"A14.6.9-7 [If the returned value from a query specifying a result
is null, this indicates that the expression specified as the result
was null.] Note that the semantics of this result a
Hi,
Is the behavior of COUNT(manager) (please see below) specified in SQL?
"SELECT COUNT(manager) FROM Employee"
Thanks,
Craig
Begin forwarded message:
From: Michael Watzek <[EMAIL PROTECTED]>
Date: November 9, 2005 7:12:45 AM PST
To: [email protected]
Subject: COUNT queries
Reply-To:
Hi Christian,
In JDO 1, we allowed the implementation to decide how to store fields
of type Object and interfaces. Most compliant implementations simply
serialized the instances. Job done. But in JDO 2, there is more
explicit control over the mapping, and not all mappings can be used
port
- the following query eliminates rows with null in column "a"
select count( a ) from foo;
-- the following query eliminates rows with null in column "a"
-- and eliminates duplicates
select count( distinct a ) from foo;
Cheers,
-Rick
Craig L Russell wrote:
Hi,
Is the behavior
Attendees: Michelle Caisse, Michael Bouschen, Michael Watzek, Martin
Zaun, Karan Mahli, Craig Russell
Agenda:
1. Test status (Michael W) 6 of 28 configurations fail; 470 tests 5
failures 9 errors for both application and datastore identity.
Progress is being made in both the number of test
Javadogs,
We have an issue with the TCK in mapping fields of type Object and
interface types to RDBMS. I don't know of a reasonable mapping that
allows an Object to be mapped either as a reference or as embedded,
while mapping it to serialized makes sense. In order to map these
fields as
Hi Jörg,
On Nov 3, 2005, at 1:49 AM, Jörg von Frantzius wrote:
Hello,
the specification currently is somewhat confusing where it defines
the meta-data attributes "dependent" and "element-dependent".
Concerning "dependent" it says:
"The dependent attribute indicates that the field cont
Hi Michael,
Yes, an implementation must return the proper instance (including its
class) at all times. That's why the SELECT statement must include the
discriminator column if it exists. If there is a discriminator column
and it's not included in the SELECT statement, it's a JDOUserExceptio
Hi Andy,
On Nov 11, 2005, at 10:52 PM, Andy Jefferson wrote:
Hi Craig,
Proposal:
I'm in total agreement on the need for a MetaData attribute for
this, and for
arrays, and collections, and maps.
My only issue is with the name(s) chosen.
You have "element-type" being added for arrays of
Javadogs,
Here's a proposal for 18.21:
The jdoquery Document Type Descriptor
This describes files stored as .jdoquery files.
Note: The document type descriptors are to be descriptive, not
normative. In the final specification, these will be replaced with
proper xml schema.
The document type
Javadogs,
Please reply if you have an issue with this.
Currently the spec does not appear to support an element that allows
mapping a collection (duplicates allowed) to a table with a column
specifically to allow duplicates. We have an element but it
seems to be just for ordering.
I'd l
Javadogs,
Please reply if you have an issue with this.
Class names for Java language classes must be qualified with
java.lang currently. This proposal changes the default package name
for certain java.lang classes.
The key-type, value-type are currently being defined as things like
Objec
Javadogs,
Please reply if you have an issue with this.
A method is missing from the specification. It is in the JDOHelper
class currently in the Apache repository.
A8.6-21[public static PersistenceManagerFactory
getPersistenceManagerFactory(String propsResourceName, ClassLoader
propsLoad
Javadogs,
There is a duplicate get/setDetachAllOnCommit in Transaction that
belongs only on PersistenceManager.
In the specification, the get/setDetachAllOnCommit methods were
defined on both PersistenceManager and Transaction. This was an
oversight; the method belongs only on Persistence
Javadogs,
If you have an issue with this please reply.
Currently there is no metadata that allows deployment to specify a
more specific type for the elements of an array. This is needed in
cases where the array is a generic type or an interface type and the
actual type is known at deployme
Javadogs,
If you have any issues with the proposal please reply.
This proposal adds property to the metadata where only field
previously was mentioned.
Craig
Issue 141
H
Add support for persistent properties
Erik Bengtson noticed that the metadata doesn't include enough
metadata to map p
Javadogs,
If you have any issues with the proposal please reply.
This proposal adds the jdoquery document type to the specification.
Craig
Issue 140
H
Add jdoquery document type descriptor and schema
The jdoquery Document Type Descriptor
Note: The document type descriptors are to be descripti
Javadogs,
This is the specification update to implement Issue 136, which
removes attachCopy and changes the signature of makePersistent to
return the instances made persistent.
Please comment.
Make instances persistent
Object makePersistent (Object pc);
Object [] makePersistentAll (Object[
Javadogs,
Currently, there is no standard way to describe the mapping of
embedded instances that use a discriminator column.
Issue 142
H
Allow embedded discriminator column
This proposal adds the discriminator element to the embedded element
for both .jdo and .orm mappings.
extension*)>
Javadogs,
Please comment if you have any issues with the proposal.
Issue 143
H
Treatment of null values in JDOQL COUNT
JDOQL currently says nothing about the treatment of null values in
the COUNT clause of a query. Based on the SQL treatment, and the fact
that JDOQL is intended to be execut
is FROM MyClass". Acceptable?
Primary keys cannot be null. So I don't think this is an issue.
Craig
Wes
Craig L Russell wrote:
Javadogs,
Please comment if you have any issues with the proposal.
Issue 143
H
Treatment of null values in JDOQL COUNT
JDOQL currently says nothing about
Hi Geoff,
Good catch. It is resolved by changing the semantics of
NonTransactionalWrite.
Thanks,
Craig
On Nov 16, 2005, at 10:27 PM, Geoff hendrey wrote:
Issue 88 is resolved via some changed language in the
spec, no?
-geoff
--- Craig L Russell <[EMAIL PROTECTED]> wrote:
Ja
Hi Erik,
On Nov 8, 2005, at 3:58 PM, [EMAIL PROTECTED] wrote:
Hi,
The element property in DTD misses the persistence-modifier attribute.
On the same suject, I don't know the purpose of field-name in
property. Can
someone give me a light?
The purpose of field-name in property is to allow
Attendees: Michelle Caisse, Michael Bouschen, Michael Watzek, Martin
Zaun, Erik Bengtson, Craig Russell
Agenda:
1. Test status (Michael W) 471 tests in alltests 6 configurations
failing of 28 application id 7 failures 4 errors datastore id 4
failures 8 errors. Differences in errors/failure
my_table" may incorrectly
omit a valid instance, meaning that "SELECT COUNT(this) FROM
MyClass" returns a different value than Collection.size() when
invoked on "SELECT this FROM MyClass". Acceptable?
Primary keys cannot be null. So I don't think this is an
t to the spec if you think it would help.
Regards,
Craig
Regards,
Erik Bengtson
Quoting Craig L Russell <[EMAIL PROTECTED]>:
Hi Erik,
On Nov 8, 2005, at 3:58 PM, [EMAIL PROTECTED] wrote:
Hi,
The element property in DTD misses the persistence-modifier
attribute.
On the sam
FYI.
Craig
Begin forwarded message:
From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
Date: November 18, 2005 8:11:44 AM PST
To: [email protected]
Cc: [EMAIL PROTECTED]
Subject: [discussion] JDO out of incubation
Reply-To: [email protected]
I'd like to propose that the JDO
Hi Erik,
On Nov 18, 2005, at 4:00 PM, [EMAIL PROTECTED] wrote:
See inline...
1 - Should the field-name attribute be used to generate the field
in the class?
No. The intent of the persistent interface is that the JDO
implementation creates an "anonymous" implementation class. There is
no req
Javadogs,I'd like to add a line to the specification that a portable mapping for arrays, collections, and maps will include a primary key on the join table. There is not always a way for the JDO implementation to guess what the primary key constraints should be for a join table.The issue came up wi
Hi Abe,
On Nov 21, 2005, at 12:59 PM, Abe White wrote:
The issue came up with the TCK where we were trying to get JPOX to
recognize that an embedded PersistenceCapable in a join table can
have a unique identifying field. In the case of datastore
identity, this doesn't work because there is
regardless of whether there is a field that is unique. So I
don't see the need for arbitrarily restricting the use case simply
because there is no persistent identity for the key instances.
Craig
On Nov 21, 2005, at 2:43 PM, Craig L Russell wrote:
Hi Abe,
On Nov 21, 2005, at 12:59 PM
Hi Abe,
I think I now understand your point, which I missed earlier. You
don't see a need for a primary key to be defined on a join table.
The issue is whether a compliant JDO implementation can require that
a join table must have a primary key if it is used to implement a
multi-valued fi
Hi Erik,
The reason for disallowing anything but queries in the SQL statement
is that when using the JDO query facility, the JDO implementation is
expected to understand the effect of the query on the underlying
datastore and to make sure that the user doesn't accidentally hurt
herself. T
Hi,
I've reviewed the spec and I'm inclined to agree with Andy about the
intent, and with both Andy and Michael about the exact wording of the
specification, which does appear to disallow the negative test case
as written. Although there is some ambiguity that I think we should
clean up r
Hi Michael,
I agree that requiring someone's idea of best practice for
portability should not be a requirement, so I am inclined to withdraw
the proposal. But I think we do need to add words to the
specification that says how to interpret the lack of a
element inside a element.
I prop
Hi,
It might be better to have this discussion attached to a JIRA issue.
Is the test case checked in?
Craig
On Nov 23, 2005, at 2:56 AM, Michael Watzek wrote:
Hi Andy,
I'm implementing test cases for deletion by query. Assertion
A14.8-4 specifies (amongst others) that dirty instances ar
Hi Michael,
I'd expect a JDOUserException to be thrown.
The spec says
void setUnique(boolean unique);
A14.6.11-1 [When the value of the Unique flag is true, then the
result of a query is a single value, with null used to indicate that
none of the instances in the candidates satisfied the f
Hi Andy,
Could you please file a JIRA?
Thanks,
Craig
On Nov 26, 2005, at 7:52 AM, Andy Jefferson wrote:
The test ResultClassRequirements.testConstructor has a query
SELECT new LongString(personid, lastname) FROM
org.apache.jdo.tck.pc.company.FullTimeEmployee
This is missing an "import" of L
Hi Michael,
Sounds good.
I was thinking some more about this issue and would like some feedback.
I think that we should make the query.execute and
query.deletePersistentAll methods as similar as possible, meaning
that they both should throw an exception if the cardinality of the
results
Hi Michael,
Test class DeleteQueryElements has INVALID_QUERIES for which the
comments are incorrect. They should all start with "The query is
invalid because...". I suspect that you copied some of these from
other query tests, but there are more requirements for delete.
For example, I sug
Hi Tony,
Here are the questions:
1. Should the fetch-depth="0" defined in the class->field work?
Both the field-defined fetch-depth and the group1-defined fetch-depth
are 0. So it's not clear what you mean.
It does not have any effect right now in JPOX, but again, the spec
does not say
Hi Christian,
Actually, the persistence-capable-superclass attribute is a leftover
from JDO 1. It's no longer needed in JDO2. Since it's confusing,
could you enter a JIRA to remove it from wherever it appears?
Craig
On Nov 30, 2005, at 9:49 AM, Christian Ernst wrote:
Sorry, should be:
Hi Michael,
On Nov 29, 2005, at 2:02 AM, Michael Watzek wrote:
Hi Craig,
Hi Michael,
Test class DeleteQueryElements has INVALID_QUERIES for which the
comments are incorrect. They should all start with "The query is
invalid because...". I suspect that you copied some of these from
oth
Hi,
On Nov 30, 2005, at 9:41 AM, Andy Jefferson wrote:
Is there a reason why
test/datastoreidentity/org/apache/jdo/tck/pc/company/package.jdo
don't define any persistence-capable-superclass
but
test/datastoreidentity/org/apache/jdo/tck/pc/company/package.jdo
defines them correctly ?
Is this no
Hi Michael,
On Dec 1, 2005, at 3:22 AM, Michael Bouschen wrote:
Hi Craig,
Hi Michael,
On Nov 29, 2005, at 2:02 AM, Michael Watzek wrote:
Hi Craig,
Hi Michael,
I'd also suggest making two test cases from the test case"The
query may fail because there is a result, or because there is
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 file
Hi Andy,On Dec 3, 2005, at 12:54 AM, Andy Jefferson wrote:The DeleteCallback test when using relationships is apparently insisting that no [pre/post]Store event is ever fired after the first [pre/post]Delete event. I'd like to confirm why this is the case. JPOX does the following :-1. Query.deleteP
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'tsupport it, and the mapping isn't consistent. This needs a fewthings: UNION join strategy plus generating a sequence used inmultiple tables. JD
Hi,On Dec 5, 2005, at 7:40 AM, Michael Watzek wrote:Hi Craig, AndyI think there is a portability issue with this test case:The test case assumes that a JDO implementation supports managed relationships, because it deletes instances which are referenced by other instances. Due to the fact that it do
I agree. If there are more actual parameters, regardless of whether it's in an array or map, they should be ignored. I'll propose wording for the specification.CraigOn Dec 5, 2005, at 5:16 PM, Bin Sun wrote:+1In some cases a developer tends to preset serveralparameters first in a Map, and choose to
Hi Michael,You're right. I swear I looked for this.events.add(event) and missed it from postStore. :-(Thanks,CraigOn Dec 6, 2005, at 1:42 AM, Michael Watzek wrote:Hi Craig, Hi,On Dec 5, 2005, at 7:40 AM, Michael Watzek wrote: Hi Craig, AndyI think there is a portability issue with this test case:Th
Javadogs,I'd like to tally the vote on this issue by close of business Thursday 8-Dec-2005.This issue was renamed to highlight the interface change. Please vote to adopt this proposal or offer a reason to reject it. It's the most significant change for a few months, as it modifies the core method o
Hi Michael,Thanks. I've updated the spec with new assertion numbers.JDO instances that represent specific persistent data in the datastore, whose values may be currently loaded but not transactionally consistent, and have been modified since the last commit, are persistent-nontransactional-dirty. A
Hi Michelle,I removed A5.6.2-3 because it was redundant, and renamed all of the following assertions.CraigOn Dec 8, 2005, at 8:42 PM, Michelle Caisse wrote:Hi Craig,Am I missing something or was there maybe a cut and paste error from the spec? I don't see Michael's A5.6.2-8 in your spec text.-- Mi
Attendees: Michelle Caisse, Michael Bouschen, Michael Watzek, Martin Zaun, Craig RussellAgenda:1. Test status (Michael W) 562 tests; datastore id 9 failures 20 errors; application id 9 failures 19 errors; 6 of 28 configurations failing. 2. Query tests (Michael W) All query test cases have been impl
Javadogs,I've slightly redone the assertions because some are related just to life cycle changes (tested in the life cycle test) and others are related to behavior. Here's the updated spec (only assertions are changed).CraigPersistent-nontransactional-dirty (Optional)JDO instances that represent sp
Congratulations to all on the team. We're now officially part of the DB top level project. Next milestone: completion of JSR 243 with a successful vote from the JCP.CraigBegin forwarded message:From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>Date: December 9, 2005 10:12:41 AM PSTTo: general@incubator
Hi,What will happen is that at some point soon, the repository will be changed, leaving the old repository in place.When this happens, we will publicize it and hopefully lock the incubator repo so that no more checkins will be done to the incubator alias. The idea is that we will do an svn cp from
Hi Jörg,Thanks for your comments.On Dec 13, 2005, at 5:18 AM, Jörg von Frantzius wrote:Alright, does anybody know if there is some rationale behind that? I'll try to answer this one.The TCK tests are designed to test the functionality of JDO in J2SE environments, as this is where the spec is focuse
Hi Andy,This raises some interesting questions. Thanks for persevering.CraigOn Dec 14, 2005, at 3:41 AM, Andy Jefferson (JIRA) wrote: [ http://issues.apache.org/jira/browse/JDO-243?page=comments#action_12360413 ] Andy Jefferson commented on JDO-243:OK, so lets
Hey,We're going to be moving the repo from incubator to db so the url for checkout and commit will change. We (Apache infra) are planning on using the svn move command so all the history will be preserved. Once the change takes place the old repo won't work any more. You can check out from the new
Brian mentioned this to me.How does Saturday, 20:00 US/Eastern time sound?Hen[ASF SVN gopher]On Wed, 14 Dec 2005, Craig L Russell wrote: Hey,We're going to be moving the repo from incubator to db so the url for checkout and commit will change. We (Apache infra) are planning on using the svn mov
Attendees: Michelle Caisse, Michael Bouschen, Craig RussellAgenda:1. Test status (Michael B) 562 tests in alltests; 6 of 28 configurations fail; 9 failures 18 errors datastore id; 9 failures 18 errors application id. Still more tests to write.2. Graduation issues, changes to the repository (Craig)
Hi,I've got a change in my sandbox updating the JDO site. I'm having trouble committing it though. Hope it's a temporary glitch.Craig Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Des
Yo, Brian, Geir,Could you take care of this please?And do the incubator jdo committers need to be part of the db group as well?Thanks,Craig On Dec 18, 2005, at 12:45 PM, Garrett Rooney wrote:On 12/18/05, Craig L Russell <[EMAIL PROTECTED]> wrote: Hi Garrett,Sadly, it still doesn't work,
Hi Geir,I just committed changes to the jdo site, so it's working for me.I logged into people, went to the web site at /www/db.apache.org, created the jdo directory, copied the UPDATE file from incubator, and did the checkout into db.apache.org. I assume that within a few hours, this will be pushed
1 - 100 of 1840 matches
Mail list logo
