PDE Jenkins build broken, API tools report errors #888
Comments
This doesn't fix the problem, but may be gives some hints See eclipse-pde#888
This doesn't fix the problem, but may be gives some hints See #888
|
@laeubi : do you see anything useful in https://ci.eclipse.org/pde/job/eclipse.pde/job/PR-887/2/console ? This reminds me on #782. |
|
The debug output looks normal: so maybe the project is special (e.g. unusual output folders, ant involved, ...) |
|
Looking at the pde.build bundle, I see that it is built/deployed as a directory (not as jar), and the classes that API tools is missing are inside a jar inside the directory. So I wonder if the tycho build fails to consider that jar during API analysis?
|
|
I think the missing "magic" might either be |
|
Or that the tycho uses wrong output folder, while project has two output folders configured:
I mean this line: |
|
|
|
Okay it is not actually the ant_bin to blame here, BUT the build is configuring in contrast to a "usual" this results in a complete empty |
Yes, because the classes will go in a dedicated jar in the bundle directory, not in the "usual" jar. |
|
We have few platform bundles that do that, if I remember it right. Ant/debug etc bundles that need dedicated jars. |
|
Yes but these jars are not then embedded and exported as API :-\ |
|
Why not, it was/is fully transparent from OSGI point of view how bundle supplies API packages. |
Because API Tools != OSGi, if API tools would be able to work on the OSGi jar we won't have any problems her and elsewhere, see these open issues: |
API Tooling allows you to get API analysis without OSGI supplying the classes, immediately on the workspace build. This is a nice feature, otherwise one would need to run a full deployment cycle (building and packaging bundle) on every change in the IDE. |
|
Here we have a jar and can't use it what makes things quite worse as we actually not check what is deployed and we must "emulate" the final jar.. Anyways I think I got a fix, but noticed that this dirty the |
Not that I know, but my knowledge is surely limited. But looking at what the patch is doing, why do you change project classpath at all - is this because you don't want to build the imported project? Wouldn't be easier to keep default settings and build it? Or, as you commented, if you are goimg to fake everything to make PDE consume pre-built classes, why not copy the "faked" project to a temp location? |
correct
Building the project is very time consuming, beside that it has lead to unpredictable behavior in the past as usually there is no way to say "only compile this", there are maybe other Builders involved what the can trigger things that might result in another compilation and then we see these instabilities we also have with the PDE tests itself.
That was my first idea, but copy large projects can again take time and therefore modify some config file to point to the right location seems a bit less intrusive, for example the |
|
Fix for this is on the pipeline and should approach in about 2hrs: |
|
Great, thanks! |
|
Build succeeded: #886. Thanks, closing. |
See
The text was updated successfully, but these errors were encountered: