Bugzilla – Full Text Bug Listing
| Summary: | [migration] Invalid assumptions regarding the form of URLs | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Jeff McAffer <jeffmcaffer> |
| Component: | Incubator | Assignee: | User Unknown <unknown1> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | birsan, email, konradk, pascal |
| Version: | unspecified | ||
| Target Milestone: | 3.0 M7 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Jeff McAffer
Updated description/analysis... Who is affected: Plug-ins which make assumptions regarding their installation structure, location and the local file system layout. Description: Methods such as IPluginDescriptor.getInstallURL() return URLs of a particular form. Despite this form not being specified, various plug-ins make assumptions based on the current implementation. For example, they may expect to get a file: URL and use URL.getFile() and use java.io.File manipulation on the result. To date, this has been a workable but rather unsafe approach. For example, if a plug-in is installed on a web server, it is possible that an http: URL would be returned. The OSGi runtime opens more possibilities for execution configurations (e.g., maintaining whole plugins in JARs rather than exploded in directories). Analysis: The new runtime does not actually break current behaviour but as described above, it exposes more cases where current assumptions are invalid. Plug-in writers should ensure that the information to which they need access is available via getResource(), use the relevant API for accessing the contents of a bundle/plug-in. Is there some documentation available, how the equinox can be used to "maintain whole plugins in JARs rather than exploded in directories" as mentioned in comment 1? [BTW: The Equinox migration guide http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equinox- home/alternateRuntimes/migration.html incorrectly links to Bug 43658 instead of this one] the work to put whole plugins in jars will be done in January. At this point various parts of Eclipse are likely making assumptions of the form discussed here. We will be going through and finding/fixing those assumptions. The general idea is that one could take the update site plugin jar and install it without exploding. We will also likely investigate alternative structurings so that we don't have to extract the code jars out of the plugin jar (or pay some performance cost). Stay tuned to this space. Thanks for the pointer on the doc. That one is actually obsolete now. I will put in a forwarding pointer. the new doc does not have the bug references but the bug titles are generally the same as the doc section titles so a query will find them. Thank you, Jeff, for explaining. I am not sure however, if we talk about the same thing. I am not asking, whether the existing Eclipse plugins can be launched from JARs, but rather whether the runtime itself allows to run plugins from JARs by now. I'd like to take the runtime and write some _new_ plugins, extending the org.eclipse.core.runtime.applications extension Point. I am asking whether these yet to write plugins could be run from a JAR. As of today the runtime does not support running plugins out of jars (everything in one jar instead of exploded on disk). This capability will be explored in january. Just to be brutally clear on this, the actual OSGi framework underneath does support running from jars today. The Eclipse runtime layered on top and adaptor inserted underneath makes some assumptions that preclude this from working. Thank you, very much, for the clarification. Looking forward to January :-) support for running from jars is well underway and on track for M7 release. The original topic of this bug is resolved and documented in the porting guide. Closing. Any chance of posting a link to the porting guide you speak of? I have looked at the Eclipse 3.0 Migration guide, but didnt read anything related to this issue... Maybe I missed it? |