Community
Participate
Working Groups
Let's say you have a plug-in project importing the bundle org.eclipse.osgi. Your target platform (which is a directory of plug-ins) also includes three fragments, each with org.eclipse.osgi as its host. (In our case the three fragments are org.eclipse.equinox.region, org.eclipse.equinox.weaving.hook, com.diffplug.osgi.extension.sun.misc.) Therefore the classpath consists of org.eclipse.osgi and the three fragments. The fragments are resolved and added to the classpath here: org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.addDependency(BundleDescription, HashSet<BundleDescription>, Map<BundleDescription, ArrayList<Rule>>, ArrayList<IClasspathEntry>, boolean): (...) BundleDescription[] fragments = hasExtensibleAPI(desc) ? desc.getFragments() : new BundleDescription[0]; (...) The order of the fragments coming from desc.getFragments() dependes on the order of the TargetBundles coming from DirectoryBundleContainer.resolveBundles. Because of the added parallelization (https://bugs.eclipse.org/bugs/show_bug.cgi?id=535325) the order is de facto different every time you start Eclipse. JDT notices the changed order of the classpath entries and produces a REORDER change event (flag org.eclipse.jdt.core.IJavaElementDelta.F_REORDER). In our case the plug-in project importing org.eclipse.osgi is an Xtext project. Because of the reordering Xtext subsequently triggers a full build, which, in our case, happens nearly every time we start Eclipse.
New Gerrit change created: https://git.eclipse.org/r/158873
Gerrit change https://git.eclipse.org/r/158873 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=1355e000b699a124f48ec26578d5418276ab2800
Julian, can you please verify this fix?
verified by debugging Version: 2020-06 (4.16) Build id: I20200407-1800
Shouldn't the same be done for features in the 'resolveFeatures()' method? I did not encountered any issues with it, I only recognized it from reading the code. If you agree, I can open another bug and provide a patch.
(In reply to Hannes Wellmann from comment #5) > Shouldn't the same be done for features in the 'resolveFeatures()' method? > I did not encountered any issues with it, I only recognized it from reading > the code. > > If you agree, I can open another bug and provide a patch. Julian, can you please respond to this!
(In reply to Hannes Wellmann from comment #5) > Shouldn't the same be done for features in the 'resolveFeatures()' method? > I did not encountered any issues with it, I only recognized it from reading > the code. > > If you agree, I can open another bug and provide a patch. Yes, please do so. I don't see any functional problem if the feature order is not stable, but we should make the code consistent.
I just created Bug 570963 and submitted a patch.
