API error on SWT "execution environments have been changed since" #1283
Comments
|
The API baseline I find to be notoriously hard to update. If you to to the preference, double click it and refresh it, does that help? If not, restart, and do that again maybe helps? |
|
Does it mean, you can't reproduce? I see it on both my Linux/Windows workspaces, so I assume this should be reproducible. |
|
I’m driving around so not tried yet. So it was just a thought. |
|
Yes, I have that error too:
The thing doesn't have a BREE though and never did. Last release cycle it was version bumped without a reason... |
|
Debugging, here is the problem:
The API reference indicates there is no EE at all, but from the bundle description the current project computes that it has EE Java-17 even though that value is not present in the MANIFEST.MF. While building the description, the entry is in the map, but not in the file itself:
And finally, we see here that PDE is adding the EE property, computed from the JRE associated with the project, to the manifest properties as if it were present in the loaded resource:
It's not entirely clear to me how to fix this problem. For validation would need to should be able to distinguish between a computed/implicit default value versus an explicitly-present value... I don't think it makes so much sense that the baseline ought to record some value not actually present and one that depends on the workspace's JRE. Note in particular that if one associates the JavaSE-17 EE with a Java 21 JRE/JDK, the computed value changes:
What to do... |
So this is not stored somewhere anymore? Where was it stored and which change broke that? |
|
It seems to me that every release I have this problem in SWT, and then it soon goes away. In hindsight now, I expect it goes away because the first change to SWT increments versions and then presto, all is good again. And then the next release cycle the problem comes back for a whoel while. That's my theory. Also please read carefully what I wrote though. The computed value depends on which JDK/JRE version is bound which which EE in the user's workspace. So it is not correct, in my opinion, to store a EE compute value when none is specified. Of course PDE must have some good reason to inject an EE as if one were specified for some appropriate reasons, but the validation step should know the difference between such a computed value (that may be different from workspace to workspace) versus an actual specified value that may be deliberated changed over time. I looked at the whole call chain that is producing the description and see nothing that would allow such information to be recorded easily. Perhaps via org.eclipse.osgi.service.resolver.BaseDescription.setUserObject(Object) if there isn't something else already using that "slot". Of course another way to make this problem go away is to specify an EE. 😱 |
|
Ed, I haven't looked into debugger / git history yet, but what I can't understand: why was it working before? |
|
Yes, those are good question. If I restore a 4.31 baseline I can see if the baseline reference in that case was returned as non-null. It just seems to me that any non-null value is bogus because it's unspecified. Moreover the workspace the value will definitely be non-null but not a value that is the same across all machines. So even if JavaSE-17 was stored for the baseline, if you only have a Java 21 JRE for the workspace JRE, you'd also get an error that the EE was changed when nothing was changed. Anyway, more investigation is required and I'm not sure when next I will find time. But it's super annoying to have a workspace with errors. 😱 |
|
Maybe the EE check was disabled but now that we have shared preferences maybe it's no longer disabled?
|
|
I can't launch anymore now either. 😱
|
Probably due to eclipse-platform/eclipse.platform.releng.aggregator#2085 (comment) ff |
Not probably, for sure because of missing SWT native libraries. |
|
I hope tomorrow is a better day. |
My hope almost every day :) |
|
It's a little tricky to test the older baseline because the logic is preempted by many earlier guards, but if I force it to reach the logic where it checks the BREEs, it's clear that the baseline for Eclipse 4.31 for this fragment also has no BREE in the baseline reference:
So I don't think anything new is wrong nor that there was some regression. The bottom line is that the API baseline reads purely the bundle in the API baseline and used purely the contents of the actual MANIFEST.MF which has no BREE to create the bundle description. The workspace bundles are created using the manifest as returned by org.eclipse.pde.internal.core.MinimalState.loadWorkspaceBundleManifest(File, IResource) which adds a synthetic computed BREE. So the baseline will generally never have a BREE if there is no explicit BREE while the workspace bundle will generally always have a BREE even when there is no explicit BREE. So my conclusion is that this can only be fixed in the API tools if there is somewhere, somehow, recorded information about whether the BREE the workspace bundle is implicit versus explicit. |
|
I'll leave this open until I verify that the actual update tomorrow fixes this problem. |
|
The update fixed the problem (after forcing it to rebuild). |
I've set my baseline to 4.32RC2a build and see now this API error on SWT:
The minor version should be incremented in version 3.126.0, since execution environments have been changed since version 3.126.0I'm not aware about any execution environment change in SWT, so why do we have that error now?
Is something broken again with API descriptions, like we had it in 4.31 (se #1187)?
The text was updated successfully, but these errors were encountered: