Community
Participate
Working Groups
A couple of time now in Lune I observed the following behavior: 1. Open a target definition with p2 repository entries in the target editor. 2. Let it resolve. 3. Select a p2 repository entry which has newer IUs available. 4. Perform an update via the update button) Outcome: 1. The IUs in the target definition are updated to the latest available versions. 2. Resolution of the target definition fails with "unable to locate IU ..." for the latest version although the IU is present in the p2 repository. It seems that PDE (p2) discovers the new metadata in the p2 repository but fails to discover the actual new artifact. A video of the behavior can be seen here: http://youtu.be/nzrl21YcvWs Workaround: 1. close Eclipse 2. delete folder <workspace>/metadata/.plugins/org.eclipse.pde.core/.p2 3. start Eclipse and try again
Curtis, I believe the cause is rooted in changed done for bug 283731. The change removed the dirty handling from P2TargetUtil. As a result, when an IUBundleContainer is updated, the P2TargetUtil#checkProfile method will return true. This forces a re-use of an now old profile. I suspect that due to some heavy caching internally, the conflict occurs. A way to force creation of a new profile is incrementing the target platform sequence number when an update is done. One potential fix is here: ### Eclipse Workspace Patch 1.0 #P org.eclipse.pde.ui diff --git src/org/eclipse/pde/internal/ui/shared/target/UpdateTargetJob.java src/org/eclipse/pde/internal/ui/shared/target/UpdateTargetJob.java index bb4beef..770628d 100644 --- src/org/eclipse/pde/internal/ui/shared/target/UpdateTargetJob.java +++ src/org/eclipse/pde/internal/ui/shared/target/UpdateTargetJob.java @@ -19,6 +19,7 @@ import org.eclipse.pde.core.target.ITargetLocation; import org.eclipse.pde.internal.core.PDECore; import org.eclipse.pde.internal.core.target.IUBundleContainer; +import org.eclipse.pde.internal.core.target.TargetDefinition; import org.eclipse.pde.ui.target.ITargetLocationUpdater; /** @@ -121,7 +122,12 @@ progress.done(); if (noChange) { return new Status(IStatus.OK, PDECore.PLUGIN_ID, ITargetLocationUpdater.STATUS_CODE_NO_CHANGE, Messages.UpdateTargetJob_TargetUpdateSuccessStatus, null); - } else if (!errors.isOK()) { + } + + // bug 439011: increment of sequence number to force a new profile being created + ((TargetDefinition) fTarget).incrementSequenceNumber(); + + if (!errors.isOK()) { return errors; } else { return Status.OK_STATUS; ------------- However, I'm unsure if this is the correct approach.
The steps to produce should be as follow: 1. Deploy a p2 repository containing IU "a.b" version "1.0.0.v1" 2. Create a target definition referencing the IU "a.b" in version "1.0.0.v1" from the p2 repository 3. Close Eclipse 4. Deploy new p2 repository with IU "a.b" version "1.0.0.v2" at same location 5. Start Eclipse and open Target Definition in Target Editor 6. Wait for Target Definition to resolve. 7. Select p2 repository and click "Update" 8. Wait for Target Definition to resolve. If my assumptions are correct, step 6 should run fine and step 8 should fail (i.e. Target Definition should not resolve). Step 6 probably runs fine because of some caching. But I believe this is incorrect, too. Whenever there is a change in the remote repository, PDE should detect that and report the error immediately. BTW, Tycho does not do any caching with target definition resolution. Therefore, any Tycho build using the same target definition will fail after step 4 was done because the old IU is no longer available in the repository.
Another observation: IUBundleContainer, line 368: if (!updated) { // Things have changed so mark the container as unresolved clearResolutionStatus(); } The comment does not match the if clause. Could the '!' be a typo here? If not then I think it should be re-phrased.
Are you using proxies?
No proxies configured in the OS. Active provider in Eclipse is set to "direct".
I've also encountered this bug on Windows, so I suppose it is platform independent. As a workaround, I've incremented the sequenceNumber attribute manually. This is the only workaround that I found to work reliably. An Eclipse restart didn't help.
I think the fix to https://bugs.eclipse.org/bugs/show_bug.cgi?id=436950 should have fixed this issue. I suspect this fix is not there in the eclipse you are using. It should be in 4.4.1 build when the build starts.
So I suppose this bug is a duplicate. *** This bug has been marked as a duplicate of bug 436950 ***
*** Bug 439122 has been marked as a duplicate of this bug. ***
