System packages not found by validation #429
Comments
|
Note: The product starts normally when I click on "continue". |
|
This is a resolution error in the Target-Platform. I noticed that as well already. I can try to have a look at this soon. |
|
I'd be great if you can find some time to look into this. |
|
I started to dig into this problem with a simple target: Note (to myself, took me far too much time), the osgi system.package is important so that other bundles can resolve osgi.ee capabilities and JRE-packages! That Workspace-Plugin is a stripped-down variant of xml.resolver and shows the same errors in the Target-Platform state view. When changing the required Looking at the profile for the Consequently I think this is not a bug in PDE or but in the meta-data of the xml.resolver bundle. I wonder why xml.resolver does not require JavaSE 1.4 or later (which should be more than sufficient nowadays). |
|
The metadata are generated in Eclipse-Orbit at https://git.eclipse.org/c/orbit/orbit-recipes.git/tree/apache/org.apache.xml.resolver_1.2.0, which uses the maven-bundle-plugin, which under the hood uses bnd-tools to generate the metadata. Therefore maybe @bjhargrave knows immediately why |
|
Well the class file version are Java 1.1 (45), so the EE makes sense since it is computed from the highest class file version encountered. As for any imports, if some class in the bundle uses a package which is not in the bundle, then you get an import. None of the imported packages above are Bnd itself does not have a list of the non- |
I don't think thats true, the bundle should not resolve against its declared profile but against the profile of the target, I really doubt your target has an effective EE of 1.1 of as So unless you have your IDE using Java 1.1 as the default JRE, or have configured your target using EE 1.1 (then So I assume the real EE should be 11 and that does not contain |
|
I am also seeing this error after updating to 2022-12 IDE with (This is using xmlrpc from Orbit.) |
Is it really necessary in OSGi import non- java packages that are/can be provided by the JVM, for example
Looks similar to Equinox. :) But yes I agree that Java 1.1 is way to old. I wonder if there is anybody besides museums that run such old JREs? 😄 Because this profile is empty, the resolver is actually right, when it complains about unsatisfied imports.
No question a Java 1.1 JRE will not be used eventually. On the other hand it actually works well at the moment and in the future. Only such really old configs (that are IMHO flawed) don't work. My first impulse was actually to suggest to use the noee instruction and specify the EE 'manually' to Java-1.4 (so that those that use really old Java-versions can use it). EE's for higher java versions than the one of the target are probably not a concern since those bundles will not resolve due to the EE requirement (then packages are not the biggest problem). On the other hand IIRC all installed VMs known in the workspace are currently considered when setting up the properties of each profile. Therefore a bundle that requires Java-17 will probably resolve successfully even if the target's EE is Java-11 as long as there is a java-17 VM installation known to the workspace. But I have to check that. However I'm in doubt that this is a reasonable choice.
My JDK (GraalVM for Java-11 in this case) contains those packages. |
Yes, only packages starting with
This sadly is a (default enabled) legacy option of Equinox, you can enable true OSGi mode
The default is the eclipse default JRE.
That's why I think it is wrong :-D
That's what is to be expected as far as I know if you not configure it differently.
What do you mean by resolve? Probabbly the pre-run check will succeed but such a bundle can never resolve against a Java11 target and will just remain in installed state. |
|
Has this also be fixed by HannesWell@e6ce4a3 At least for me that javax.xml is not reported as missing in one of my clients projects which the recent I-build while the last release reports it as missing. |
I am still experiencing this particular validation error when launching products in Eclipse 2023-06. Are there further improvements that can be made here or should we look at using a custom version of this plugin with modified metadata? |
|
I noticed problems like this the other day too setting up launchers to run BIRT's tests... |
|
This now also poped up in Xtext with Guice 7: eclipse/xtext#2717 Guice 7 uses The So I see two options.
|
The content of the provided Java 1.2 download looks quite promising and listing all packages from the But the Java 1.1 download has much less packages in its rt.jar: An alternative to fix this problem would probably be to either to re-generate the OSGi metadata for the xml.resolver artifactin Orbit or to get rid of org.apache.xml.resolver. At least in my M2E workspace I only see the following bundles that depend on xml.resolver: Maybe @merks can tell more about the entire SimRel? :) The JDK already provides an XPath library: https://www.baeldung.com/java-xpath and AFAIK the Xerces parser is also part of the JDK. If those alternatives can be used, it would already allow |
I don't think there is something particular to fix here (but @tjwatson @bjhargrave can correct me if I'm wrong), but the profile has to list the officially specified packages that are provided by all compliant JVMs, So I think those manifests are generated automatically but no one has really tested them (e.g. on Java 1.1 OSGi framework/JVM) for that purpose or with other JVMs, regarding the Guice package I would simply mark the sun package as optional and take some actions to get rid of it altogether if running on different JVMs is a goal of the project. |
In Theorie yes, but in practice I assume that this package is provided by most, if not all VMs. It is also in the OpenJDK.
That's probably right, but from my experience projects that are not mainly intended to run in OSGi are not much interested in putting much effort in testing with OSGi.
I cannot mirgate guice of sun.misc(.Unsafe probably). If a good way would exist already I assume the guice-devs would have used it. However, can anyone tell if there is other Code that is using the list in |
|
Here are direct dependencies I see in SimRel:
|
I just wanted to note that the profile is not necessarily "wrong" and only
So every other package has to be imported and either be provided by extra system packages or other bundles, even though PDE still has the
I think JDT has some way to find the available packages, if one know them its not that hard to create a profile from that, that's actually what we do at Tycho already. |
|
To split hairs, that section also says "For Java platform versions prior to Java SE 9, the Framework must also set the org.osgi.framework.system.packages launching property to the list of Java platform packages generally known to be available at runtime." In the end, the org.osgi.framework.system.packages must/should be all the packages available in the Java runtime, i.e., packages that can be imported but are necessarily available via contributing bungles. Ideally it would be those actually available in the actual runtime being launched. Certainly all the profiles contain more than just java.* things, and if you look at any JustJ JRE https://download.eclipse.org/justj/jres/11/downloads/latest/ It shows information about the actual value of org.osgi.framework.system.packages as computed by OSGi running on that runtime:
When PDE is launching something with Java 17, does it matter that some bundle says it runs with Java 1.1 and that the profile for 1.1 doesn't contain some specific package imported by that bundle? It seems to me that doesn't matter if Java 17 provides that package because that package will them be available for sure, even if it's not in Java 1.1... |
|
@merks correct but the important part is "the list of Java platform packages generally known to be available at runtime", so a fixed profile list can not satisfy this and therefore I have suggested to use the ones from the actual used JRE (thats closest to runtime we get I think), and JDT should help us somehow to get all packages from a JDK (@iloveeclipse ?) somehow as the compiler obviously knows there is such a package... |
|
Yes, that makes very good sense. For JustJ I just kind of cheat and run this Ant script using the Ant runner in an Eclipse that is launched with each particular VM, letting OSGi compute its value: In this case it's indeed better to reuse what JDT must have already computed somehow... |
|
a dumb question - will the resolver ever be able to know what packages are available in the target JVM that is not yet spwawned? even if it knows the JVM version? |
|
JDT knows that when it compiles code with any specific JRE... |
The JVM version is meaningless as of the support for modular JVMs (9+) anyways, but you add a JREs(!) in eclipse and that is the JVM used to execute it inside Eclipse, if you use another in your final product this might then produce failures to resolve but that's nothing solvable by the tooling. |
The Java compiler knows because you can use |
|
Note too though that one can create a JRE that reduces or expands the available modules so in the most general case, one can't hard code what OSGi computes when actually running in a particular JRE... |
Maybe I didn't read the spec well enough, but I cannot see a paragraph that states that the org.osgi.framework.system.packages must only contain But besides that I would like to recap what we are discussing about, because at least for me this issue is about two things:
For the Pre-Launch Validation it indeed makes sense to use the packages available in the For the second point, the PDE-State for the workspace build, API-tools and Plugin/Product exports from the IDE, we need the system-packages per Java-version, because as it was said by others we don't know at which Java version or even JDK flavour/Vendor the Plug-in eventually runs. So if there is a Plug-in project in the workspace that requires a non-modular (e.g. has BREE
The good thing is that devs that targets Java 1.8 or earlier likely have a corresponding |
A Target Platform is what PDE builds / checks against, and a target Platform always specify a JRE (most of the the workspace default) see here:
So this is the one that should be used and not some profile files for a completely different one. Also I would highly discourage to write an own parser for packages, JDT should already offer anything we need here. |
I know that this exists, but in this point I have to say that I disagree. Using the same list of system-bundles for all Bundles in the PDE State (Target+Workspace) would contradict the flexibility OSGi offers with regard to the required EE. Personally I also have never used a Target-EE/JRE and I have not seen anyone using it. Therefore I assume that this is not widely used and therefore often not carefully set up. The description also indicates this purpose. I don't think it is a good idea to change its purpose.
Yes definitely, I just mentioned that for more clarity. Nevertheless I don't know if JDT offers everything exactly as we need it since even in TargetPlatformHelper.querySystemPackages needs to do some work. I already suggested to improve JDT in this regard (eclipse-jdt/eclipse.jdt.debug#175) but didn't have the time to complete that yet. |
There is only one state so there should only be one VM that contributes system packages, I don't see how this would contradict any flexibility? Also as said the required EE only contributes This already created some problems in the past where So if one really wants to improve something, then one needs have one PDE state per project and then use the JRE of the project, but using different JREs across a global state can only lead to false results as we already see here.
This is not really an argument, as said often people are happy with the default JVM in their Eclipse and this is used to run and verify everything, beside that Tycho is already reading this value and using it for target resolution. |
- Only consider EE of running VM in launch validation to match the behavior later at runtime - For the PDEState the EE's system-package is computed with the following distinction: - for a EE that corresponds to a Java-9 or higher release, get the 'best matching' VMInstall and query the system-packages for the EE's java release version (which is possible for modular JVMs) - for a Java-8 or lower release check if there is a VMInstall selected/strictly compatible to that version and query the system-packages from that VM (i.e. its rt.jar and other libraries) - if there is no VMInstall for a for a Java-8 or lower release, combine the hard-coded list of 'java.*' packages with the set of non-java packages provided by the default VMInstall of the workspace. The default VMInstall of the WS is at the same time the JVM selected in the active target definition (which sets its selection as WS default upon loading). Fixes eclipse-pde#429
- Only consider EE of running VM in launch validation to match the behavior later at runtime - For the PDEState the EE's system-package is computed with the following distinction: - for a EE that corresponds to a Java-9 or higher release, get the 'best matching' VMInstall and query the system-packages for the EE's java release version (which is possible for modular JVMs) - for a Java-8 or lower release check if there is a VMInstall selected/strictly compatible to that version and query the system-packages from that VM (i.e. its rt.jar and other libraries) - if there is no VMInstall for a for a Java-8 or lower release, combine the hard-coded list of 'java.*' packages with the set of non-java packages provided by the default VMInstall of the workspace. The default VMInstall of the WS is at the same time the JVM selected in the active target definition (which sets its selection as WS default upon loading). Fixes eclipse-pde#429
- Only consider EE of running VM in launch validation to match the behavior later at runtime - For the PDEState the EE's system-package is computed with the following distinction: - for a EE that corresponds to a Java-9 or higher release, get the 'best matching' VMInstall and query the system-packages for the EE's java release version (which is possible for modular JVMs) - for a Java-8 or lower release check if there is a VMInstall selected/strictly compatible to that version and query the system-packages from that VM (i.e. its rt.jar and other libraries) - if there is no VMInstall for a for a Java-8 or lower release, combine the hard-coded list of 'java.*' packages with the set of non-java packages provided by the default VMInstall of the workspace. The default VMInstall of the WS is at the same time the JVM selected in the active target definition (which sets its selection as WS default upon loading). Fixes eclipse-pde#429
- Only consider EE of running VM in launch validation to match the behavior later at runtime - For the PDEState the EE's system-package is computed with the following distinction: - for a EE that corresponds to a Java-9 or higher release, get the 'best matching' VMInstall and query the system-packages for the EE's java release version (which is possible for modular JVMs) - for a Java-8 or lower release check if there is a VMInstall selected/strictly compatible to that version and query the system-packages from that VM (i.e. its rt.jar and other libraries) - if there is no VMInstall for a for a Java-8 or lower release, combine the hard-coded list of 'java.*' packages with the set of non-java packages provided by the default VMInstall of the workspace. The default VMInstall of the WS is at the same time the JVM selected in the active target definition (which sets its selection as WS default upon loading). - Listen to changes of available VMInstalls and ExecutionEnvironment defaults. Re-read them on changes and re-resolve the PDE-State again with a subsequent re-validation of all Plugin projects. Fixes eclipse-pde#429
- Only consider EE of running VM in launch validation to match the behavior later at runtime - For the PDEState the EE's system-package is computed with the following distinction: - for a EE that corresponds to a Java-9 or higher release, get the 'best matching' VMInstall and query the system-packages for the EE's java release version (which is possible for modular JVMs) - for a Java-8 or lower release check if there is a VMInstall selected/strictly compatible to that version and query the system-packages from that VM (i.e. its rt.jar and other libraries) - if there is no VMInstall for a for a Java-8 or lower release, combine the hard-coded list of 'java.*' packages with the set of non-java packages provided by the default VMInstall of the workspace. The default VMInstall of the WS is at the same time the JVM selected in the active target definition (which sets its selection as WS default upon loading). - In general the available system-packages are only really known at runtime. Therefore at any other time, e.g. in the workspace one can only guess/assume what packages are available and the implemented algorithm seems to be the best trade-off between probable accuracy, convenience and the possibility to let the user control the result. - Listen to changes of available VMInstalls and ExecutionEnvironment defaults. Re-read them on changes and re-resolve the PDE-State again with a subsequent re-validation of all Plugin projects. Fixes eclipse-pde#429
|
The PR #693, which aims to fix this issue is now almost ready. |
|
If nobody objects I plan to submit the PR latest on Saturday. |
- Only consider EE of running VM in launch validation to match the behavior later at runtime - For the PDEState the EE's system-package is computed with the following distinction: - for a EE that corresponds to a Java-9 or higher release, get the 'best matching' VMInstall and query the system-packages for the EE's java release version (which is possible for modular JVMs) - for a Java-8 or lower release check if there is a VMInstall selected/strictly compatible to that version and query the system-packages from that VM (i.e. its rt.jar and other libraries) - if there is no VMInstall for a for a Java-8 or lower release, combine the hard-coded list of 'java.*' packages with the set of non-java packages provided by the default VMInstall of the workspace. The default VMInstall of the WS is at the same time the JVM selected in the active target definition (which sets its selection as WS default upon loading). - In general the available system-packages are only really known at runtime. Therefore at any other time, e.g. in the workspace one can only guess/assume what packages are available and the implemented algorithm seems to be the best trade-off between probable accuracy, convenience and the possibility to let the user control the result. - Listen to changes of available VMInstalls and ExecutionEnvironment defaults. Re-read them on changes and re-resolve the PDE-State again with a subsequent re-validation of all Plugin projects. - Adapt existing test-cases that expected some packages to be reported as present although were not. Fixes eclipse-pde#429
- In the Product or OSGi-app launch validation only consider EE of the VM that will run the app, match the later runtime-behavior - For the PDEState the EE's system-package is computed with the following distinction: - for a EE that corresponds to a Java-9 or higher release, get the 'best matching' VMInstall and query the system-packages for the EE's java release version (which is possible for modular JVMs) - for a Java-8 or lower release check if there is a VMInstall selected/strictly compatible to that version and query the system-packages from that VM (i.e. its rt.jar and other libraries) - if there is no VMInstall for a for a Java-8 or lower release, combine the hard-coded list of 'java.*' packages with the set of non-java packages provided by the default VMInstall of the workspace. The default VMInstall of the WS is at the same time the JVM selected in the active target definition (which sets its selection as WS default upon loading). - In general the available system-packages are only really known at runtime. Therefore at any other time, e.g. in the workspace, one can only guess/assume what packages are available and the implemented algorithm seems to be the best trade-off between probable accuracy, convenience and the possibility to let the user control the result. - Listen to changes of available VMInstalls and ExecutionEnvironment defaults. Re-read them on changes and re-resolve the PDE-State again with a subsequent re-validation of all Plugin projects. - Adapt existing test-cases that expected some packages to be reported as present although were not. Fixes eclipse-pde#429
- In the Product or OSGi-app launch validation only consider EE of the VM that will run the app, match the later runtime-behavior - For the PDEState the EE's system-package is computed with the following distinction: - for a EE that corresponds to a Java-9 or higher release, get the 'best matching' VMInstall and query the system-packages for the EE's java release version (which is possible for modular JVMs) - for a Java-8 or lower release check if there is a VMInstall selected/strictly compatible to that version and query the system-packages from that VM (i.e. its rt.jar and other libraries) - if there is no VMInstall for a for a Java-8 or lower release, combine the hard-coded list of 'java.*' packages with the set of non-java packages provided by the default VMInstall of the workspace. The default VMInstall of the WS is at the same time the JVM selected in the active target definition (which sets its selection as WS default upon loading). - In general the available system-packages are only really known at runtime. Therefore at any other time, e.g. in the workspace, one can only guess/assume what packages are available and the implemented algorithm seems to be the best trade-off between probable accuracy, convenience and the possibility to let the user control the result. - Listen to changes of available VMInstalls and ExecutionEnvironment defaults. Re-read them on changes and re-resolve the PDE-State again with a subsequent re-validation of all Plugin projects. - Adapt existing test-cases that expected some packages to be reported as present although were not. Fixes #429
|
I've tested the latest nightly build and can confirm, the dialog no longer shows up. Thank you a lot for working on this! |
|
I have just submitted another refinement via #714 that aims to handle the case of a malformed VM being selected and queried initially. |
After updating to the Eclipse 4.26 (from 4.25), I get the following error when trying to launch our product:
Those packages come from the JDK, so they should be available to the product.
Tested with:
OpenJDK 17.0.4+7 & 17.0.5+8
Eclipse SDK 4.26 & 4.27.I20230102-1800
Example:
eclipse4.26-validation-error..zip
The text was updated successfully, but these errors were encountered: