Bug 567864 - Dependency resolution erroneously resolve Import-Package to TP bundle instead of JDK module
Summary: Dependency resolution erroneously resolve Import-Package to TP bundle instead...
Status: RESOLVED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.17   Edit
Hardware: All All
: P3 critical (vote)
Target Milestone: 4.18 M3   Edit
Assignee: Thomas Watson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-14 03:49 EDT by Mickael Istria CLA
Modified: 2021-02-08 09:17 EST (History)
7 users (show)

See Also:


Attachments
Reproducer (import in IDE) (3.94 KB, application/zip)
2020-10-14 03:49 EDT, Mickael Istria CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mickael Istria CLA 2020-10-14 03:49:43 EDT
Created attachment 284451 [details]
Reproducer (import in IDE)

Using the attached example, see PDE/JDT complaining about the org.w3c.dom.css package being imported twice. This is caused by PDE wrongly adding javax.xml bundle to dependencies while the org.w3c.dom.css package is already provided by the JDK as a standard module.
p2 and OSGi seems to behave properly, so if you try to build the bundle with Tycho, no error happens and compilation is fine, as expected.
Comment 1 Julian Honnen CLA 2020-10-14 07:08:36 EDT
This issue may be a caused by bug 566772
Comment 2 Mickael Istria CLA 2020-10-14 07:52:24 EDT
(In reply to Julian Honnen from comment #1)
> This issue may be a caused by bug 566772

Although I agree bug 566772 is a cause, there is room for workarounds in this specific cases: Import-Packages which are already satisfied by current JRE Library (and that we can know with JDT) could simply be ignored.
Comment 3 Julian Honnen CLA 2020-10-15 02:49:48 EDT
I've tried integrating tycho's mechanism to pick up system packages, but the package import is still wired to the javax.xml bundle.

Also switching the execution environment to java 9 (where a system profile still exists) doesn't fix this issue.

So it's not dependent on bug 566772.
Comment 4 Mickael Istria CLA 2020-11-02 05:20:00 EST
I also see an issue with org.eclipse.e4.ui.workbench.renderer.swt: when opening/importing the project from master in my IDE, I get issues about the javax.inject classes not being resolved.
Indeed, javax.annotation bundle is not part of the required bundles. That seems to be a major issue, and I have the impression that PDE wrongly assumes this package is provided by JavaSE-11 and does ignore it from resolution.
I try putting a RequireBundle: javax.inject, and javax.inject is added, but PDE sets an access rule to hide its content. I need to remove the access rule manually in the current project build path to get something working. That symptom also gives the impression that PDE assumes javax.inject is provided by the JRE, so it hides the classes from the bundle.
Comment 5 Mickael Istria CLA 2020-11-06 13:01:48 EST
Marking as critical, as this is making migration of bundles to JavaSE-11 much more complex than it should be.
Comment 6 Eclipse Genie CLA 2020-11-06 17:28:31 EST
New Gerrit change created: https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/171931
Comment 7 Julian Honnen CLA 2020-11-09 03:12:53 EST
Thanks for the test Mickael, I'll look at it this week.
Comment 8 Mickael Istria CLA 2020-11-09 03:26:04 EST
(In reply to Julian Honnen from comment #7)
> Thanks for the test Mickael, I'll look at it this week.

I'm also working on a patch.
My current analysis is that this is not a regression; it's just a long standing bug which was not annoying enough so far: PDE never took into account the JRE packages in the resolution and has always added irrelevant extra bundles to classpath.
For example, you cna create a bundle with JavaSE-1.8 as BREE, this EE has javax.annoation; add `Import-Package: javax.annotation` and the javax.annotation bundle gets imported for no good reason.
What's new with JavaSE-11 is that such case is now reported as an error by the compiler, while they used to be ignored pre-modular. That's a change for the better, PDE needed to be fixed anyway, now there is a compelling reason to do it.
Comment 9 Julian Honnen CLA 2020-11-09 03:47:22 EST
(In reply to Mickael Istria from comment #8)
> I'm also working on a patch.
Happy to review your patch then ;)
Comment 10 Thomas Watson CLA 2020-11-09 08:59:24 EST
I was also taking a look at this. I'll push up my gerrit to show my thinking.  But it currently is not working because the profile PDE uses claims the package org.w3c.dom.css is not available fir JavaSE-11 execution environment.
Comment 11 Eclipse Genie CLA 2020-11-09 09:25:48 EST
New Gerrit change created: https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/171997
Comment 12 Thomas Watson CLA 2020-11-09 09:32:16 EST
(In reply to Eclipse Genie from comment #11)
> New Gerrit change created:
> https://git.eclipse.org/r/c/pde/eclipse.pde.ui/+/171997

Notice that this would work, but JavaSE-11 profile that PDE uses claims the package is not available on JavaSE-11 so the following method prevents the package from being used:

org.eclipse.osgi.internal.resolver.ImportPackageSpecificationImpl.isSatisfiedBy(BaseDescription, boolean)

In particular this code at the end of the method:

		int eeIndex = ((Integer) pkgDes.getDirective(ExportPackageDescriptionImpl.EQUINOX_EE)).intValue();
		return eeIndex < 0 || eeIndex == ((BundleDescriptionImpl) getBundle()).getEquinoxEE();

It appears PDE is getting the profiles for Java > 9 from JDT somewhere and that profile claims this package is not available.  But then JDT complains that it is when compiling the workspace.  That is strange.
Comment 13 Julian Honnen CLA 2020-11-09 09:37:22 EST
(In reply to Thomas Watson from comment #12)
> It appears PDE is getting the profiles for Java > 9 from JDT somewhere and
> that profile claims this package is not available.  But then JDT complains
> that it is when compiling the workspace.  That is strange.
I'm currently working on that, see bug 566772.
Comment 14 Mickael Istria CLA 2020-11-09 09:41:01 EST
(In reply to Thomas Watson from comment #12)
> Notice that this would work

Do you think this patch is a good improvement in general? Ie should it be merged anyway because it makes things better and more correct (eg fix the issue for Java 8 as described in comment #8 with javax.annotation) ?
Comment 15 Thomas Watson CLA 2020-11-09 09:56:25 EST
(In reply to Mickael Istria from comment #14)
> (In reply to Thomas Watson from comment #12)
> > Notice that this would work
> 
> Do you think this patch is a good improvement in general? Ie should it be
> merged anyway because it makes things better and more correct (eg fix the
> issue for Java 8 as described in comment #8 with javax.annotation) ?

Yes, I am fine with this going in AS-IS.
Comment 18 Mickael Istria CLA 2020-11-10 07:18:50 EST
Thanks Thomas and Julian!
Comment 19 Eduardo Moreira CLA 2021-01-04 07:25:07 EST
It don't work to resolve some of my imports:

javax.xml.bind.JAXBContext;
javax.xml.bind.JAXBException
javax.xml.bind.Marshaller;
javax.xml.bind.Unmarshaller

javax.annotation.Generated



I'm using java-11-openjdk-amd64 as default of my worksapce and "org.eclipse.jdt.launching.JRE_CONTAINER" as Execution Environment of my project

The packages are provided by jakart libs into my target plataform definition.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=569905
Comment 20 Eclipse Genie CLA 2021-02-08 09:05:35 EST
New Gerrit change created: https://git.eclipse.org/r/c/tycho/org.eclipse.tycho/+/175983
Comment 21 Mickael Istria CLA 2021-02-08 09:17:55 EST
(In reply to Eclipse Genie from comment #20)
> New Gerrit change created:
> https://git.eclipse.org/r/c/tycho/org.eclipse.tycho/+/175983

Not related, sorry for the mistake.