Community
Participate
Working Groups
Build Identifier: 3.6 Hi, In short: I propose to make the dependencies from reconsiler.dropins and publisher to app optional. I tested it without Eclipse (in OSGi+p2 only) and it works just fine. And for the Eclipse there is already the app bundle there so it will still work as before. With more words: Currently both reconsiler.dropins and publisher have mandatory dependencies to org.eclipse.equinox.app. This is fine in Eclipse. But in my case OSGi-and-p2-only they are unneeded but still requires me 4 more bundles: 1. reconsiler.dropins --> app 2. publisher --> app 3. app --> registry (+fragment compatibility.registry) --> jobs If 1 and 2 are made optional and app is not installed at all, everything works as before except the Eclipse-specific Applications. And if someone wants to install Applications, s/he will already has Eclipse (which has the apps bundle) and everything will work. Reproducible: Always Steps to Reproduce: 1. Edit reconsiler.dropins MANIFEST.MF, add ";resolution:=optional" to "Import-Package: org.eclipse.equinox.app" 2. Edit publisher MANIFEST.MF, add ";resolution:=optional" to "Import-Package: org.osgi.service.application". Note the "org.eclipse.equinox.app" import is already optional. 3. Uninstall org.eclipse.equinox.app 4. Put something in /dropins directory and watch it being installed. For plain OSGi+p2 you can use p2-standalone that Katya sent some time ago: https://sapmats-de.sap-ag.de/download/download.cgi?id=5YBCYHAKL9DG29TQCBIU5GDTWL7IJVAST2TDSTUEUTWDFE7G0Z There is no publisher or reconsiler.dropins in this small zip, you need to add them manually. Note dropins also require extensionlocation and directorywatcher bundles so add these too.
I'm very surprised by the desire to use these two bundles in the environment that Katya has been describing. Are you you sure that want to bring those? They seem to defeat the purpose of small, lean and fully automated / managed, and definitely bloat the size. Otherwise I can't think of any reason why not to perform the refactoring suggested.
I've suggested the lean p2 zip only for testing, e.g. an environment w/o Eclipse bundles. I don't need the dropins in the small zip but in a larger scenario. Still the Eclipse bundles are not part of it. Should I attach a MANIFEST.MF diff or you will click the "optional" checkboxes in the IDE?
I don't think we can do this without refactoring the bundles in question. Specifically, we would have to remove the reconciler application and the applications in the publisher and put them in their own bundle/fragments. Otherwise people would be able to call the apps and if they didn't have the right bundles in their environment, it would crash. The optional import is meant to support the case where bundles can function ok without everything but provide extra support if there are certain bundles added in the configuration. On example of this is the preference bundle. It can function on its own (and you won't get any errors) but if you add the optionally required registry bundle, then you get more functionality and can extend the registry and scopes yourself, etc etc.
Sorry, I don't understand. How people would be able to call the apps if they don't have the 'org.eclipse.equinox.app' bundle in their environment? More specificly, which bundle will invoke start() and stop() methods of the Application classes in reconciler or publisher or try to classload an Application implementation class? IMO the philosophy of optional imports is honored: if there is 'org.eclipse.equinox.app' in the environment the reconsiler and the publisher can be used also as applications.
That's sort of my point. I'm talking about the backwards compatibility for people who already use these bundles. If people leave their build scripts and configurations the same as they are now and they try and run Eclipse with a publisher or reconciler application then it will fail and they will get an error saying the application isn't available. Changing the requirements to be optional is a subtle difference and will require all current clients to change their build scripts. If we move the applications to a different bundle, it is more of an explicit change which might be easier to explain to users, etc.
(In reply to comment #5) > That's sort of my point. I'm talking about the backwards compatibility for > people who already use these bundles. If people leave their build scripts and > configurations the same as they are now and they try and run Eclipse with a > publisher or reconciler application then it will fail and they will get an > error saying the application isn't available. > > Changing the requirements to be optional is a subtle difference and will > require all current clients to change their build scripts. If we move the > applications to a different bundle, it is more of an explicit change which > might be easier to explain to users, etc. But changing imports as optional will not change anything in the usage of the publisher or reconsiler. The only difference is just that we will be able to run the same components w/o Eclipse runtime. In the code the org.eclipse.equinox.app package is used only in the classes registered as an extensions of Eclipse Application extension point, so when we run w/o Eclipse registry they are not loaded. In same time the classes are still in the bundles, so there should not be a problem to be loaded if somebody try to run Eclipse with a publisher or reconsiler application.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
I think this issue has died.
