Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend StateBuilder to handle EE from Require-Capability header #645

Closed
wants to merge 1 commit into from

Conversation

ptziegler
Copy link

With this change, the BundleDescription instance that is returned by the StateBuilder now also contains the execution environments that are required by the Require-Capability header, rather than only the Bundle-RequireExecutionEnvironment header.

Previously, a call to getExecutionEnvironments() would always return an empty array, if a bundle lacks the Bundle-RequireExecutionEnvironment header, even though a minimum version is required as a capability.

Resolves #643

return ee + '-' + version;
}
} catch (InvalidSyntaxException e) {
// TODO Special handling needed?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The filter here is checked in org.eclipse.osgi.internal.resolver.StateBuilder.createOSGiRequires(ManifestElement[], List<GenericSpecification>) when we create the GenericSpecification objects. So I think we can ignore the syntax error here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated the comment.

@@ -128,7 +131,7 @@ static BundleDescription createBundleDescription(StateImpl state, Dictionary<Str
}
result.setLocation(location);
result.setPlatformFilter(manifest.get(StateImpl.ECLIPSE_PLATFORMFILTER));
String[] brees = ManifestElement.getArrayFromList(manifest.get(Constants.BUNDLE_REQUIREDEXECUTIONENVIRONMENT));
String[] brees = getDeclaredRequiredEE(manifest);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding to the local brees object here will end up creating duplicate requires below when the brees is passed to createGenericRequires. Somehow we need to split this up such that the originally specified brees used for the call to createGenericRequires.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the BREEs are converted to generic capabilities, then it probably makes more sense go in the other direction:

To extract the EE once the generic capabilities have been created. Then we get the elements from both the Bundle-RequiredExecutionEnvironment and Require-Capability header and don't risk duplicate entries.

@HannesWell
Copy link
Member

It would be good if the code to extract the BREEs would be made available from a place independent from org.eclipse.eclipse.osgi.compatibility.state. Then it could be re-used in PDE for example to display the BREE in the Manifest Editor of bundles in the target-platform that only require an EE capability or to validate EE requirements like in eclipse-pde/eclipse.pde#1000.
I didn't have the time yet to look into your issue in detail, but because such code could be usable in multiple places in PDE but I think nowhere else in the platform I still think it maybe would be better to handle this only in PDE.

@tjwatson
Copy link
Contributor

I didn't have the time yet to look into your issue in detail, but because such code could be usable in multiple places in PDE but I think nowhere else in the platform I still think it maybe would be better to handle this only in PDE.

PDE could do the conversion to BREE and add the header (if missing) to the Map used to create the BundleDescription. That would result in duplicate requires on the osgi.ee namespace also, unless you also removed the element for osgi.ee from the Require-Capability header.

@ptziegler
Copy link
Author

I didn't have the time yet to look into your issue in detail, but because such code could be usable in multiple places in PDE but I think nowhere else in the platform I still think it maybe would be better to handle this only in PDE.

So how should we proceed with this item? Fixing this in either Equinox or PDE should take roughly the same amount of effort. However, I believe that this should be decided before investing more time into this issue.

I don't have a deep understanding of either projects, so I would leave it up to you (or any other committer).

@tjwatson
Copy link
Contributor

I don't have a deep understanding of either projects, so I would leave it up to you (or any other committer).

Seems more simple to fix in Equinox (and correct?). But Hannes has a better understanding of PDE usage of the resolver. I'm fine either way.

@ptziegler ptziegler force-pushed the issue643 branch 2 times, most recently from dad90af to 8b8c2eb Compare June 20, 2024 15:15
With this change, the BundleDescription instance that is returned by the
StateBuilder now also contains the execution environments that are
required by the Require-Capability header, rather than only the
Bundle-RequireExecutionEnvironment header.

Previously, a call to getExecutionEnvironments() would always return an
empty array, if a bundle lacks the Bundle-RequireExecutionEnvironment
header, even though a minimum version is required as a capability.

Resolves eclipse-equinox#643
@HannesWell
Copy link
Member

I didn't have the time yet to look into your issue in detail, but because such code could be usable in multiple places in PDE but I think nowhere else in the platform I still think it maybe would be better to handle this only in PDE.

So how should we proceed with this item? Fixing this in either Equinox or PDE should take roughly the same amount of effort. However, I believe that this should be decided before investing more time into this issue.

For now I think it is better added to PDE since it allows us to reuse it in multiple places in PDE while keeping it internal and consequently kind of incubate, fix, etc. it there. If more users show up we can still move this at a more general place.
In general the resolver is intended to be faded out (although the time to fully clean up the usage is often missing).

Sorry for the delayed reply but this is a busy week. I intend to look into your issue in more detail to give a more detailed advice at the weekend.

@HannesWell
Copy link
Member

Since eclipse-pde/eclipse.pde#1302 is submitted I think this is obsolete.
Closing.

@HannesWell HannesWell closed this Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

StateBuilder should consider Constant.REQUIRE_CAPABILITY when calculating BREE for BundleDescription
3 participants