Bugzilla – Full Text Bug Listing
| Summary: | [dropins] [publisher] Make dependencies to 'org.eclipse.equinox.app' optional | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Petar Petrov <petar.petrov> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | Ed.Merks, georgi.stanev, john.arthorne, katya.stoycheva, pascal |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Petar Petrov
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. |