Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 321368 - p2.context.repos necessary to complete a PDE build (p2.gathering=true) that eclipse 3.5 was able to previously complete
Summary: p2.context.repos necessary to complete a PDE build (p2.gathering=true) that e...
Status: RESOLVED WONTFIX
Alias: None
Product: PDE
Classification: Eclipse Project
Component: Build (show other bugs)
Version: 4.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: pde-build-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-30 11:37 EDT by Eddie Galvez CLA
Modified: 2018-12-03 09:04 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eddie Galvez CLA 2010-07-30 11:37:26 EDT
Build Identifier: 3.6 (org.eclipse.pde.build_3.6.0.v20100603)

We've been having a headless pde build issue preventing is from adopting Eclipse 3.6; we had a build setup that worked fine with eclipse 3.5, and then we try to use eclipse 3.6 and we would get the p2 director fail complaining it couldn't find some equinox "concurrent" osgi.bundle (my translation: "i cant find the base eclipse plug-ins").

We're using headless PDE build, pretty much just as the docs explain things, and in this particular case a product based build, where p2.gathering is set to true.

The non-p2 stuff is able to compile everything thanks to:
 a) baseLocation (if indeed that's used to find plug-ins)
 b) pluginPath (where other stuff can be found, including the delta pack)

But then the product build hands things off to the p2 director, which goes ahead and fails.

After many many many days of trying things, I look closely at "p2.context.repos" and was looking at how org.eclipse.pde.build_3.6.0.v20100603/scripts/genericTargets.xml calls the p2 director, and looked at p2.repo ... and realized that it was only putting in the repo where the build ended, that is, I believe, the repo carrying only the stuff that was compiled.

Specifically, shouldn't P2 "honor" the PDE build properties and at least have the courtesy to, say, translate baseLocation (or whichever property is the correct "this is where base eclipse is") into the list at p2.repo when calling the director?

To restate it, the fix we have in hand now is to set p2.context.repos to the exact same value (well, as a uri using file:) we set baseLocation to! (our baseLocation is an eclipse that we place in a *read-only* location, as a build dependency for our build machines to use. That eclipse is a base eclipse that we p2 install features our product uses (say GEF, EMF, etc.).


I fail to understand why eclipse 3.5 was tolerant of the previous build setup (I could just turn up -debug and look closely at how the director was invoked)... but something was changed in 3.6 that affected us hard.


Reproducible: Always
Comment 1 Eddie Galvez CLA 2010-08-06 10:38:47 EDT
A note (for others) -- it was through reading http://www.eclipse.org/forums/index.php?t=rview&goto=539230&th=169695 that I figured out that this p2.context.repos was likely to be what I needed...
Comment 2 Lars Vogel CLA 2018-12-03 09:04:10 EST
Currently we are not actively enhancing PDE build anymore. Therefore, I close this bug as WONTFIX. 

Please reopen, if you plan to provide a fix.