Community
Participate
Working Groups
See also bug 85065: Running with plug-ins as JARs We would like to be able to ship and run with features as JAR files instead of expanded withing directories. Here is Dorian's when I asked about features as JARs... --------------- We looked at this sometime during 3.0.0 and it was doable. At the time, we didn't see many benefits to supporting jar'd features, because features only contain a small number of files and are very small compared to plugins. As you point out below, for very large products, there may be some benefit to supporting jar'ed features. As a matter of fact, the best reason to support jar'ed features is that the update manager does not have to unzip the downloaded features anymore. What's on an update site is just moved over, as is. Changes to the code would have to be done primarily in - update.configurator: - feature detection (we already do it for jar'ed plugins, so the code would be similar), - creating the URL for branding properties (like window_image, etc.). - most important: all the issues around platform.xml, as it contains feature url entries of the form features/org.eclipse.featureid_version. We need to support features/org.eclipse.featureid_version.jar as well. - ??? - update core: - installing/uninstalling features - feature detection on a configured site - ???
Created attachment 18421 [details] patch I did some hacking and here is a patch against the update.configurator project. I changed the SiteEntry class to handle reading features from JARs. Based on the comments above, there is still a lot of work to do but this is a start. In the patch I look for the feature.xml file and expand it and then point the parser to it. This method can be improved. One thing that we have to be careful about is open file handles within the zip archive. (that's why I expanded rather than process in-place)
Thanks DJ. I haven't gone through all the details in the patch, but I have two comments: 1. you already mentioned the need to expand the file from zip, as opposed to opening a handle. I don't have a serious objection to this, but we may need to remove the file from the temp dir, which is probably the coding effort as it is to close a handle from the zip (I may not make much sense here, so go with what your experience tells you). 2. feature detection is handled slightly different than plugin detection. The stuff that is missing is timestamp checking, to detect what the newer features were.
just to say that PDE provides an export feature that allows user to bundle a feature as an archive : the check box says Pack Features and Plugin as individual jar archive. This actually build it but in fact does not work, this really is misleading as I thought this was possible. SeB.
Features on an update site have to be packaged as archives. It is only after they are installed that they are unpacked. The support for packaged install features should be looked at in the next release.
No plans to support jarred features. We will be able to omit installing feature jars altogether once UM is no longer in the platform.
