Bugzilla – Full Text Bug Listing
| Summary: | [osgi] running on shared install mode should be easier | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Rafael Chaves <eclipse> |
| Component: | Framework | Assignee: | equinox.framework-inbox <equinox.framework-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bogofilter+eclipse.org, irbull, jeffmcaffer, jimisola, manahan, simon_kaegi, tjwatson |
| Version: | 3.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Rafael Chaves
this is a good idea. perhaps -configuration @local (or some flavour thereof) would be more inline with what we have now and what users are thinking? Sound good to me. Is there not a way to solve this without command line parameters? In general, you shouldn't have to use command line parameters unless you are doing something unusual, and I don't consider sharing a Eclipse install to be unusual. Not only that, but if you require command line parameters to make this work, you are guaranteed that someone will forget to use them or get them wrong, and now you have a config directory in the Eclipse install that others will end up loading and stomping on someone else's workspace. What about storing the config in the user's home directory? Or store the config in the same place as the workspace, and store a file in the user's home directory pointing to the config/workspace location? Many of the location related options have two versions: a command-line option and a system property. The system property version can be passed to Eclipse as a VM arg, or it can be declared in the config.ini file. For a product scenario, an installer can ask the user if the install is to be shared or not, and then tweak the config.ini accordingly. Users would not have to pass any command line arguments. There is a separate question as to what is the default setting. The @local setting makes available the possibitliy for someone to positively set the mode they want. As Rafael points out, if that is to be the default then it would likely appear in a configuration file somewhere but then it would be possible to override this from the command line if someone wanted something different. Run out of time. Jeff, if you believe we should try supporting this for 3.1, please re-set the target milestone accordingly. consider as part of the scenario review. If something amazing springs to mind, lets look at it. Investigation on this space should be done for 3.3 as we want to see how sharability can be improved. I don't see us doing anything drastic here for 3.3. no promises for 3.4 either... What improvements have we done in 3.5 and 3.6 for shared installs? Do we expect more work to be done? Does the bulk of this work belong to p2 and is there another bug report handling shared install in p2? 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. No plans to address this. |