Bug 578968 - java classpath: unstable plug-in dependencies order
Summary: java classpath: unstable plug-in dependencies order
Status: CLOSED DUPLICATE of bug 578564
Alias: None
Product: PDE
Classification: Eclipse Project
Component: Build (show other bugs)
Version: 4.22   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: pde-build-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-02-25 05:33 EST by Jörg Kubitz CLA
Modified: 2022-02-28 08:21 EST (History)
2 users (show)

See Also:

Attachments
Screenshot.png (33.18 KB, image/png)
2022-02-25 05:33 EST, Jörg Kubitz CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jörg Kubitz CLA 2022-02-25 05:33:41 EST 
Created attachment 288122 [details]
Screenshot.png

starting with 2021-12 (4.22) we experience a nasty behaviour that eclipse is autobuilding the whole workspace on ever startup. As far as i have debugged that happens because PDEs classpath seems to be different on every startup.

see screenshot

jdt detects that change in dependencies and requests a new build in
org.eclipse.jdt.internal.core.JavaModelManager.containerPutIfInitializingWithSameEntries(IPath, IJavaProject[], IClasspathContainer[]):798
Comment 1 Jörg Kubitz CLA 2022-02-25 07:24:53 EST 
problem is the use of

org.eclipse.osgi.service.resolver.BundleDescription.getFragments()

in 

org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.addDependency(BundleDescription, HashSet<BundleDescription>, Map<BundleDescription, ArrayList<Rule>>, ArrayList<IClasspathEntry>, boolean)

.getFragments() returns a list without specific order - and in case of osgi seems to depend on the race conditions which class was loaded first
Comment 2 Eclipse Genie CLA 2022-02-25 07:27:00 EST 
New Gerrit change created: https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/191218
Comment 3 Hannes Wellmann CLA 2022-02-25 08:05:32 EST 
This problem has already been addressed in Equinox with Bug 578564 and was fixed in 2022-03 M3.
Marking as duplicate therefore. Please re-open if the problem persists.

*** This bug has been marked as a duplicate of bug 578564 ***
Comment 4 Lars Vogel CLA 2022-02-28 08:13:59 EST 
Reloading the target platform still triggers a full build even though the target platform did not change. Is this expected?
Comment 5 Jörg Kubitz CLA 2022-02-28 08:21:09 EST 
(In reply to Lars Vogel from comment #4)
> Reloading the target platform still triggers a full build even though the
> target platform did not change. Is this expected?

If a single dependency changed a full build would be necessary. If nothing changed there would not have been a reason to update target platform. So even though it is unnecessary to full build then, it is not a likely usecase.