Community
Participate
Working Groups
For features to be useful on disk, they need to be unzipped. However, the publisher currently has the following logic: if the feature path doesn't exist, or the feature is a dir, (when publishing) then unzip. Otherwise, don't. However, if we publisher from an update site, the features are always zipped, so they don't get unzipped when installed. Is there a case for not unzipping a feature?
Features are only useful to UM unzipped. Are you saying that when we are installing from an old style update site the feature never gets unzipped? Could you please confirm what is going on there? Also could you please look into creating a patch?
I don't know if it is happening with a remote update site, but I have tested it with a local update site action, and features are not being unzipped. I will run with this bug Pascal.
Pascal, I have looked at this, and it is only a problem in "LocalUpdateSiteAction". Also, LocalUpdateSiteAction is never used in p2. (Even when you point to a local update site, it uses the RemoteUpdateSiteAction with a URI). So, this is not actually a problem in the eclipse platform builds, but only a problem if somebody is building on p2. However, the fix affects code that is part of the sdk build (the fix is in features action). The fix is simply to always add the unzip touchpoint to a feature jar. Do we want to do this for 3.5? Or it is safer to have people use the workaround (just use a remote update site with a URI, even if you are using local update sites).
Created attachment 127850 [details] Always unzip features when they are installed This patch always unzips features when they are intalled.
Created attachment 127851 [details] mylyn/context/zip
This needs to be revised in light of discussion from Monday's p2 call.
Yep, and I was wrong. There is a use of it in the SDK, the FeaturesAndBundlesPublisherApplication may suffer from this. I will test this out and report back.
Created attachment 130630 [details] Updated path (with test case) It turns out this is actually a problem (in the UpdateSitePublisherApplicaiton). This patch addresses the problem by always adding the touchpoint data to unzip the features (features need to be unzipped). This patch also includes a test case.
Created attachment 130631 [details] mylyn/context/zip
Pascal, do you think you (or John) can review this?
I can verify that the patch works.
done
*** Bug 276972 has been marked as a duplicate of this bug. ***
I see these messages in my console when running JUnit Plug-in Tests: !ENTRY org.eclipse.update.configurator 4 0 2014-02-04 12:36:57.033 !MESSAGE Unable to find feature.xml in directory: /.../p2-repo/features/org.eclipse.mylyn.docs.intent.exporter.feature_0.8.1.201308291003.jar In my case, the target platform is initialized from a local folder which contains a p2 update site. In there, all features and plug-ins are zipped. Is this the same bug or a new one?
