Community
Participate
Working Groups
Currently, using the markStarted(started:true) action from the Eclipse touchpoint on an OSGi fragment bundle results in simpleconfigurator trying to start the fragment bundle. This causes a BundleException to occur, which simpleconfigurator then logs to the console (e.printStackTrace() in ConfigApplier#installBundles). For console based applications, this is problematic, as there's no way to hide the exception. While it might seem nonsensical to use the markStarted action on a fragment bundle, consider the use case where a metadata author wants to mark a set of bundles started using an IU fragment (similar to the tooling.osgi.bundle.default IU fragment). As far as I know, there's no way to author an IU fragment's host requirements such that it excludes OSGi fragment bundles. This feature request could be addressed in a number of ways: - Modify the metadata generator to include a property in a bundle's IU properties that specifies that it is an OSGi fragment bundle. This would allow IU fragment authors the expressiveness to exclude bundle fragments from their IU fragments. - Modify the markStarted touchpoint action to ignore requests to start fragment bundle. - Modify simpleconfigurator's ConfigApplier#installBundles method so that it ignores requests to start fragment bundles. - Modify simpleconfigurator's ConfigApplier#installBundles method so that it does not log bundle exceptions using exception.printStackTrace().
Michael, you seem to be fairly familiar with the code, would you have some time to provide a patch, both in the touchpoint action and the maybe in the ConfigApplier#installBundles?
Created attachment 123849 [details] Workspace patch Patch attached. I updated both MarkStartedAction and ConfigApplier. The MarkStartedAction fix will prevent fragment bundles from having mark started set to true. The ConfigApplier change ignores the start flag for fragment bundles. Some notes: - MarkStartedActionTest may want to be refactored to reduce very similar code. - I did not see any unit tests for ConfigApplier so I tested this manually. BundlesTxtTest could be used but (1) it uses a hand-built version of simpleconfigurator, not the one from the workspace and (2) we'd have to capture stderr and check to see if there's a stack trace present. Requires a new JAR file in org.eclipse.equinox.p2.tests/testData/eclipseTouchpoint/bundles/org.eclipse.osgi.fragment_1.0.0.jar Will attach JAR contents as a separate attachment. If it doesn't come through, the JAR should be empty with this as the manifest: Manifest-Version: 1.0 Fragment-Host: org.eclipse.osgi Bundle-Version: 1.0.0 Bundle-Name: Test Fragment Bundle Bundle-ManifestVersion: 2 Bundle-SymbolicName: org.eclipse.osgi.fragment
Created attachment 123850 [details] JAR needed by patch Should be put in org.eclipse.equinox.p2.tests/testData/eclipseTouchpoint/bundles/org.eclipse.osgi.fragment_1.0.0.jar
Fixed in HEAD. Thanks Michael. I've also done similar logic for the start level side of the house.
Just tested with 3.5m7 and noticed a problem. Since the fix was made to SetStartLevelAction as well, there's no way to specify the start level of a fragment bundle. This seems okay intuitively, but as far as I know, that's the only way to control whether a bundle is put in to config.ini (if startLevel < startLevel of simpleconfigurator) or bundles.info (if startLevel >= bundles.info). So for example, let's say you have the SLF4J API bundle and a fragment bundle SLF4J/Log4j Binding. You might want both of these bundles listed in config.ini so that they are installed/resolved before simpleconfigurator is started. Any chance of removing the following lines form SetStartLevelAction [52:53]? if (bundleInfo.getFragmentHost() != null) return Status.OK_STATUS;
I don't think we want ot change the StartLevelAction as this seems like a chain of coincidences. Your use-case is reasonable however you should open a specific bug for that case and describe it there instead of re-using this bug.
Opened https://bugs.eclipse.org/276243. Thanks for the consideration.
