After closing the modeler, doc, and tutorial projects, I am left with these unresolved errors:
Description Resource Path Location Type Plugin execution not covered by lifecycle configuration: org.apache.cayenne.build-tools:maven-cayenne-build-plugin:3.2M1:date (execution: date, phase: initialize) pom.xml /cayenne-jdk1.6-unpublished line 78 Maven Project Build Lifecycle Mapping Problem Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-remote-resources-plugin:1.4:bundle (execution: default, phase: generate-resources) pom.xml /cayenne-legal-unpublished line 65 Maven Project Build Lifecycle Mapping Problem Plugin execution not covered by lifecycle configuration: org.apache.cayenne.build-tools:maven-cayenne-build-plugin:3.2M1:date (execution: date, phase: initialize) pom.xml /cayenne-legal-unpublished line 53 Maven Project Build Lifecycle Mapping Problem Plugin execution not covered by lifecycle configuration: org.objectstyle.woproject.maven2:maven-japplication-plugin:2.0.17:japplication (execution: default, phase: generate-resources) pom.xml /cayenne-modeler-java line 77 Maven Project Build Lifecycle Mapping Problem Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-antrun-plugin:1.3:run (execution: default, phase: process-sources) pom.xml /cayenne-jdk1.5-unpublished line 214 Maven Project Build Lifecycle Mapping Problem Plugin execution not covered by lifecycle configuration: org.codehaus.mojo:javacc-maven-plugin:2.5:javacc (execution: javacc-ejbql, phase: generate-sources) pom.xml /cayenne-jdk1.5-unpublished line 172 Maven Project Build Lifecycle Mapping Problem Plugin execution not covered by lifecycle configuration: org.codehaus.mojo:javacc-maven-plugin:2.5:jjtree (execution: jjtree-ejbql, phase: generate-sources) pom.xml /cayenne-jdk1.5-unpublished line 156 Maven Project Build Lifecycle Mapping Problem Plugin execution not covered by lifecycle configuration: org.apache.cayenne.build-tools:maven-cayenne-build-plugin:3.2M1:date (execution: date, phase: initialize) pom.xml /cayenne-jdk1.5-unpublished line 263 Maven Project Build Lifecycle Mapping Problem On Wed, Sep 18, 2013 at 1:25 PM, Mike Kienenberger <mkien...@gmail.com> wrote: > All 2100+ tests for my own project now pass under my modified 3.0.2. > > However, I'm having problems getting a STABLE-3.0 development > environment set up under Eclipse so that I can investigate the failing > cayenne tests. > > I tried following the directions under > http://cayenne.apache.org/dev/eclipse.html using Eclipse Version: Juno > Release Build id: 20120614-1722 but after the process created 37 > projects in the workspace, I'm still left with 243 java compile errors > and 13 maven problems. > > The java errors seem like tutorial or modeler errors which I can > probably ignore. (like no com.apple imports). > > I'm not sure what to make of the maven errors as some of these are in > primary modules. > > Description Resource Path Location Type > Plugin execution not covered by lifecycle configuration: > org.apache.cayenne.build-tools:maven-cayenne-build-plugin:3.2M1:date > (execution: date, phase: initialize) pom.xml > /cayenne-jdk1.6-unpublished line 78 Maven Project Build > Lifecycle Mapping Problem > Plugin execution not covered by lifecycle configuration: > org.apache.maven.plugins:maven-remote-resources-plugin:1.4:bundle > (execution: default, phase: generate-resources) pom.xml > /cayenne-legal-unpublished line 65 Maven Project Build Lifecycle > Mapping Problem > Plugin execution not covered by lifecycle configuration: > org.apache.cayenne.build-tools:maven-cayenne-build-plugin:3.2M1:date > (execution: date, phase: initialize) pom.xml > /cayenne-legal-unpublished line 53 Maven Project Build Lifecycle > Mapping Problem > Plugin execution not covered by lifecycle configuration: > org.objectstyle.woproject.maven2:maven-japplication-plugin:2.0.17:japplication > (execution: default, phase: generate-resources) pom.xml > /cayenne-modeler-java line 77 Maven Project Build Lifecycle > Mapping Problem > Plugin execution not covered by lifecycle configuration: > org.apache.maven.plugins:maven-antrun-plugin:1.3:run (execution: > default, phase: process-sources) pom.xml > /cayenne-jdk1.5-unpublished line 214 Maven Project Build > Lifecycle Mapping Problem > Plugin execution not covered by lifecycle configuration: > org.codehaus.mojo:javacc-maven-plugin:2.5:javacc (execution: > javacc-ejbql, phase: generate-sources) pom.xml > /cayenne-jdk1.5-unpublished line 172 Maven Project Build > Lifecycle Mapping Problem > Plugin execution not covered by lifecycle configuration: > org.codehaus.mojo:javacc-maven-plugin:2.5:jjtree (execution: > jjtree-ejbql, phase: generate-sources) pom.xml > /cayenne-jdk1.5-unpublished line 156 Maven Project Build > Lifecycle Mapping Problem > Plugin execution not covered by lifecycle configuration: > org.apache.cayenne.build-tools:maven-cayenne-build-plugin:3.2M1:date > (execution: date, phase: initialize) pom.xml > /cayenne-jdk1.5-unpublished line 263 Maven Project Build > Lifecycle Mapping Problem > > > > > > On Sun, Sep 15, 2013 at 3:59 AM, Andrus Adamchik <and...@objectstyle.org> > wrote: >> Hi Mike, >> >> So looks like you are on top of it… Let me know if you need any help. >> >> Andrus >> >> >> >> On Sep 14, 2013, at 8:22 AM, Mike Kienenberger <mkien...@gmail.com> wrote: >>> I remembered to update the subject this time. >>> >>> So if I replace >>> >>> arcSnapshot.put(property.getName(), target); >>> >>> with >>> >>> if (property.getRelationship().isUsedForLocking()) { >>> arcSnapshot.put(property.getName(), target); >>> } >>> >>> then the primary key qualifier is correct: "WHERE USER_ID = 2" instead >>> of "WHERE USER_ID is null." >>> >>> Unfortunately, this also causes several unit tests to fail. I haven't >>> yet investigated why this might be. >>> >>> Failed tests: >>> >>> testReadToOneRelationship(org.apache.cayenne.access.NestedDataContextReadTest) >>> testRemoveToMany(org.apache.cayenne.CDOSetRelationshipTest) >>> testRemove(org.apache.cayenne.CDOMany2OneTest) >>> testNullifyToOne(org.apache.cayenne.access.NestedDataContextWriteTest) >>> testMultipleToOneDeletion(org.apache.cayenne.unit.jira.CAY_901Test) >>> testRemoveToMany(org.apache.cayenne.CDOMapRelationshipTest) >>> >>> testPhantomRelationshipModificationValidate(org.apache.cayenne.access.DataContextExtrasTest) >>> testRemove1(org.apache.cayenne.CDOOne2ManyTest) >>> testRemove2(org.apache.cayenne.CDOOne2ManyTest) >>> testIsToOneTargetModified(org.apache.cayenne.access.DataRowUtilsTest) >>> testRemoveToMany(org.apache.cayenne.CDOCollectionRelationshipTest) >>> >>> So far, basic functionality for my app seems working. >>> >>> On Fri, Sep 13, 2013 at 4:46 PM, Mike Kienenberger <mkien...@gmail.com> >>> wrote: >>>> As I mentioned earlier, I'm upgrading my ancient Cayenne project from >>>> 1.1 to 3.x, currently 3.0.2. >>>> >>>> I started by upgrading to 1.2 and 2.0, unfortunately hitting the old >>>> null-relationship-breaks-optimistic-locking error. >>>> >>>> http://mail-archives.apache.org/mod_mbox/cayenne-dev/200803.mbox/%3c8f985b960803271232s5018a5a9hbf0f731f82666...@mail.gmail.com%3E >>>> >>>> Since most everything else seemed to be working, and the the >>>> workaround I had for 1.1 wasn't possible in 1.2/2.0, I decided to skip >>>> ahead to 3.0 and hope it was fixed there, or that it'd be more >>>> relevant to fix there. >>>> >>>> But the same behavior I see in 1.2 and 2.0 still occurs in 3.0.2. For >>>> 1.1, the fix was to retain a new snapshot when resolving faults, but >>>> the problem here seems to be slightly different. >>>> >>>> My model has a "User" object and a "PotentialCustomer" object. The >>>> PotentialCustomer is an optional one-to-one relationship with the >>>> User, where they both have the same primary key. In the past I have >>>> left the PotentialCustomer relationship as "Used for Locking", >>>> although I've set it both ways without changing the resulting error. >>>> >>>> Committing an unrelated attribute change to the "User" object when it >>>> has no corresponding "PotentialCustomer" object generates a "where >>>> USER_ID is null" clause. >>>> >>>> Writing a property change eventually generates an arcSnapshot for all >>>> to-one relationships, even if they are not marked for locking. >>>> org.apache.cayenne.access.ObjectDiff.java - line 114: >>>> >>>> public boolean visitToOne(ToOneProperty property) { >>>> >>>> // eagerly resolve optimistically locked relationships >>>> Object target = lock ? >>>> property.readProperty(object) : property >>>> .readPropertyDirectly(object); >>>> >>>> if (target instanceof Persistent) { >>>> target = ((Persistent) target).getObjectId(); >>>> } >>>> // else - null || Fault >>>> >>>> arcSnapshot.put(property.getName(), target); >>>> return true; >>>> } >>>> >>>> The problem is that with a relationship which is optional, the target >>>> is going to be null. And later on, when we generate optimistic >>>> locking qualifiers in >>>> org.apache.cayenne.access.DataNodeSyncQualifierDescriptor, we store >>>> this null value as the matching value for the record's primary key. >>>> >>>> To me, part of the fix would seem to be to not do anything if we're >>>> not locking on this column. Why do we need to resolve a relationship >>>> or store a snapshot for a column not involved in optimistic locking? >>>> >>>> Second, even if this column is involved with optimistic locking, it >>>> should not be used as a replacement value for the modified object's >>>> primary key. It's probably a model error to specify a relationship >>>> based on the modified object's primary key as a locking column. >>>> However, I can correct this by removing the "Used for Locking" value. >>>> >>>> >>>> On Thu, Mar 27, 2008 at 3:32 PM, Mike Kienenberger <mkien...@gmail.com> >>>> wrote: >>>>> Here's an interesting situation I'm debugging now for Cayenne 1.1. >>>>> It seems to be related to CAY-213 "NullPointerException in >>>>> ContextCommit with locking". I suspect that it's true of 1.2 and >>>>> could very well be true for 3.0 as well, although I don't have that >>>>> handy to test with. >>>>> >>>>> http://issues.apache.org/cayenne/browse/CAY-213 >>>>> >>>>> My testing seems to reveal that the same problem occurs when you set a >>>>> to-one relationship to null. Line 291 in removeToManyTarget() sets >>>>> the state of the previous to-one relationship object to MODIFIED, but >>>>> doesn't retain a snapshot for that object. >>>>> >>>>> Here's some simple test code that shows the problem. And switching >>>>> the scalar setter with the relationship setter works around the >>>>> problem. >>>>> >>>>> It seems to me that the the fix is to add >>>>> >>>>> dataContext.getObjectStore().retainSnapshot(this); >>>>> >>>>> as was done for writeProperty(). >>>>> >>>>> >>>>> public void run() throws Exception >>>>> { >>>>> initCayenne("cayenne.xml"); >>>>> >>>>> // Set up database >>>>> >>>>> createSchemaForObjEntityName(Configuration.getSharedConfiguration(), >>>>> "PotentialCustomer"); >>>>> DataContext dc = DataContext.createDataContext(); >>>>> >>>>> // Set up test data >>>>> PotentialCustomer pc = >>>>> (PotentialCustomer)dc.createAndRegisterNewObject(PotentialCustomer.class); >>>>> Premise premise = >>>>> (Premise)dc.createAndRegisterNewObject(Premise.class); >>>>> pc.setToOneTarget("premise", premise, true); >>>>> dc.commitChanges(); >>>>> >>>>> // Force failure: >>>>> pc.setToOneTarget("premise", null, true); >>>>> premise.writeProperty("altitude", new Integer(0)); >>>>> >>>>> // On commitChanges(), no snapshot available for building locking >>>>> // java.lang.NullPointerException >>>>> // at >>>>> org.objectstyle.cayenne.access.ContextCommit.appendOptimisticLockingAttributes(ContextCommit.java:564) >>>>> >>>>> dc.commitChanges(); >>>>> } >>>>> >>>>> >>>>> java.lang.NullPointerException >>>>> at >>>>> org.objectstyle.cayenne.access.ContextCommit.appendOptimisticLockingAttributes(ContextCommit.java:564) >>>>> at >>>>> org.objectstyle.cayenne.access.ContextCommit.prepareUpdateQueries(ContextCommit.java:426) >>>>> at >>>>> org.objectstyle.cayenne.access.ContextCommit.commit(ContextCommit.java:156) >>>>> at >>>>> org.objectstyle.cayenne.access.DataContext.commitChanges(DataContext.java:1266) >>>>> at >>>>> org.objectstyle.cayenne.access.DataContext.commitChanges(DataContext.java:1236) >>>>> at >>>>> com.gvea.cayenne.TestOptimisticLockingFailureOnSingleTargetNull.run(TestOptimisticLockingFailureOnSingleTargetNull.java:110) >>>>> at >>>>> com.gvea.cayenne.TestOptimisticLockingFailureOnSingleTargetNull.main(TestOptimisticLockingFailureOnSingleTargetNull.java:24) >>>>> >>>>> Note that some of these line numbers may vary as my version of Cayenne >>>>> 1.1 has local mods. >>> >>
