The general issue was that the director wouldn't install my product because of an unsatisfied requirement. It wasn't clear to me where this requirement was even coming from. Somewhere, there was some metadata in my plugins/features that expressed a dependency that had worked fine in 3.4 but failed in 3.5. My theory was that if I could capture when the publisher was generating the requirement, I'd be able to see the source of that requirement and squash it.
First attempt was to turn on tracing for the p2 components. I managed to find the
org.eclipse.equinox.internal.p2.core.helpers.Tracingclass which listed out the different options. I stuffed those into a .options file:
Then the trick was to pass along those options to the
AntRunnerapp which drives PDE build. I added
-debug path/to/.optionsinto my arguments to
AntRunner. Running the build again I got two things, neither of which were helpful:
-debugto the Platform also passes
-debugonto Ant, thanks to
AntRunner. So my Ant ran in debug mode which really clouded the issue with about 8mb of debug output.
- The publisher only outputs two trace statements: start and finish. Nothing about what it is publishing. This may be a candidate for enhancement.
Based on these results, I reasoned that nobody else must be using this technique to solve their p2 problems. Moving on.
Stepping through the publisher
Next up: run
AntRunnerwith Java debug enabled so that I could connect remotely and set breakpoints in the publisher actions. I added the appropriate JVM args to enable the Java wire debug protocol. Started the build again, connected up and started setting breakpoints in various publisher actions.
Since the rogue requirement was getting added to my product feature IU, I added a conditional breakpoint in
FeaturesActionto look for that feature being processed.
Then, since the problematic requirement was
org.eclipse.core.resources [3.4.0,3.5.0)I added another conditional breakpoint in
getVersionRangeto watch for incoming feature entries with 3.4.0 as their minimum version.
I did finally discover the problem: I had a bunch of old, outdated entries in my product feature's feature.xml, which included references to several different versions of o.e.core.resources. After I ripped those out, I had a successful build and director install.
- Do not pass the debug flag to
AntRunnerfor purposes of debugging platform code unless you are prepared to wade through volumes of output. (I guess this is a feature of AntRunner - https://bugs.eclipse.org/bugs/show_bug.cgi?id=5672)
- It was not at all apparent to me to debug p2 actions by setting up a "remote" debug session with PDE build running inside of
AntRunner. But it was sure as heck helpful once I figured it out.
- I am actually glad that I ran across this problem, and that p2 is enforcing these types of constraints, because it helped me clean up outdated dependencies in my feature.
How are you debugging your p2 builds??