Aha, just found what you need. Check the root pom.xml on trunk. Locate this
section:
<pluginManagement>
<plugins>
<!-- M2Eclipse configuration. Has no effect for command line builds -->
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
…
</plugin>
You will need to drop <plugin>…</plugin> part for lifecycle-mapping plugin into
3.0 root pom. Let me know if you have any trouble with this. I'll do it myself.
Andrus
On Sep 19, 2013, at 5:46 PM, Andrus Adamchik <[email protected]> wrote:
> You can exclude cayenne-legal-unpublished.
>
>> Release Build id: 20120614-1722
>
> I happen to have the same version of Eclipse. What's the m2eclipse (Maven
> plugin) version? Mine is 1.1.0.20120530-0009. And IIRC it allows you to
> ignore all these errors explicitly on import.
>
> Andrus
>
>
>
> On Sep 18, 2013, at 8:27 PM, Mike Kienenberger <[email protected]> wrote:
>
>> 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 <[email protected]>
>> 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 <[email protected]>
>>> 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 <[email protected]> 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 <[email protected]>
>>>>> 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/%[email protected]%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 <[email protected]>
>>>>>> 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.
>>>>>
>>>>
>>
>
>
