Community
Participate
Working Groups
Fup of bug 303214. Load the projects from the project team set attached to bug 303214 comment 1. You can see that org.eclipse.ui.editors is specified after org.eclipse.ltk.ui.refactoring in the build order. org.eclipse.ltk.ui.refactoring has org.eclipse.compare as a dependent and org.eclipse.compare has org.eclipse.ui.editors as a dependent. So I would expect org.eclipse.ui.editors to be built before org.eclipse.ltk.ui.refactoring. API Tooling has a bug because it tries to load a .class file from a dependent and with the actual build order the .class file doesn't exist yet. The only workaround is to manually change the build order.
You can see that if you add org.eclipse.compare into the workspace, suddenly the build order is right between org.eclipse.ui.editors and org.eclipse.ltk.ui.refactoring.
From Olivier's description, in general terms he is saying: - A depends on B which depends on C. - A and C are in your workspace, B is a binary in your target - when we calculate the order of project dependencies we only take into account the ones in the workspace - so A and C are built in the wrong order
Created attachment 161928 [details] Fix typo
Olivier, I wonder how JDT Core was able to compile the stuff then in the first place?
If org.eclipse.ltk.ui.refactoring and org.eclipse.ui.editors actually have no direct dependency on each other, I suspect from the Java compiler's point of view it doesn't matter what order they are compiled in?
>If org.eclipse.ltk.ui.refactoring and org.eclipse.ui.editors actually have no >direct dependency on each other, I suspect from the Java compiler's point of >view it doesn't matter what order they are compiled in? Right,I didn't check that there's no direct dependency. So, the question for the builder is how the default build order is defined: is it only using direct dependencies or should it also take indirect dependencies into account. I guess so far the former is the case and changing that could potential lead to more being built.
Build order is calculated based on projects references. If indirect dependencies should be taken into consideration method IProjectDescription.setDynamicReferences(IProject[]) should be called. Removing the target as there will probably no changes on the Resources side.
>If indirect >dependencies should be taken into consideration method >IProjectDescription.setDynamicReferences(IProject[]) should be called. PDE would probably have to do that.
(In reply to comment #8) > PDE would probably have to do that. This is what I think too.
*** Bug 303214 has been marked as a duplicate of this bug. ***
We are crunched for time and this feels like a risky change to be putting in during an RC build. Moving to 3.8
I'm pretty sure we are getting bitten by this problem too (or at least, something similar). We are developing a fairly large RCP application, often have to work with a large workspace (the entire project is around 580 workspace plugins, and a similar number of plugins in the target platform). Eclipse appears to get the build order completely wrong for plugins. If we create a new plugin, with the default two dependencies, and then change the dependencies in any way (say remove one), Eclipse seems to start a build of our entire workspace which takes a considerable amount of time. This is despite the fact that no plugins depend on the new plugin yet, so it shouldn't have to rebuild everything. We attempted to debug this a few months ago with a workspace with just three plugins in, and got completely confused as to how the order was determined for PDE (pretty much any change to a manifest file resulted in a complete rebuild of the workspace). If we used just plain Java projects with project level dependencies, Eclipse built the right things and in the right order. Is this behaviour expected, or is it related to this bug?
*** This bug has been marked as a duplicate of bug 532264 ***
