Community
Participate
Working Groups
When exporting a product UI should automatically add the launcher jar and fragment to the product. In the case of products based on plugins, this happens in ProductExportWizard.getPluginModels. In the case of product based on features, there is only FeatureExportOperation.createFeature where the executable feature (getDeltaPackFeature) is added. However, if the deltapack is not in the target then launcher jar and fragments are not added to feature based products. We should fall back and add the individual plugin and fragment when the deltapack is not present.
I encounterd this bug, too. Exporting a product based on features worked in pre 3.5, even if no delta pack was installed... This seems to be a backward compatibility break, does it not?
*** Bug 282221 has been marked as a duplicate of this bug. ***
Andrew, any problems with this potentially going in for 3.5.1? I'm going to look at coming up with a fix
Created attachment 143562 [details] org.eclipse.pde.patch My current line of thinking 1) remove check in ProductExportWizard 2) add everything to FeatureExportOperation What are your thoughts on this approach Andrew? Should I also set the proper os/arch/ws on the launcher fragments?
Chris, is this still in your bucket for 3.5.1? or do we need to move it to 3.5.2/3.6?
I'm going to come up with an updated patch tonight, but there's probably not enough time for 3.5.1 testing if the deadline is indeed tomorrow.
Created attachment 150318 [details] org.eclipse.pde.patch An updated patch. Will let Andrew review.
Created attachment 150319 [details] mylyn/context/zip
Do you see anything wrong with this Andrew? I was able to export the mail app that was feature based.
Looks OK to me, but Andrew will know best/should have the final say.
Created attachment 150391 [details] new patch Even though this is when the deltapack is not present, if the target contains launcher fragments for more than one platform then export would break without the os,ws,arch attributes on the inclusion. Here is a revised patch which gets the launcher fragment corresponding to the configuration being exported. We really expect the configurations array to be length 1 (since multi-platform exit is only enable when the deltapack is present), but the patch works for any number of configurations. Because this works by matching the Eclipse-PlatformFilter of the fragment against the configuration, we also need to be aware of nl fragments so we don't accidentally choose them instead of the real launcher fragment. We wouldn't need to consider nl fragments if we simply built the fragment name from <ws>.<os>.<arch>, but there are special cases there for the mac, so I think it is simpler this way.
Looks good via testing. I committed this to HEAD. Leaving open for 3.5.2 inclusion. We don't need PMC approval for 3.5.2 yet?
I am also ok with this patch for 3.5.2 inclusion.
(In reply to comment #12) > We don't need PMC approval for 3.5.2 yet? I believe at this time we only need the component lead to approve.
(In reply to comment #12) > We don't need PMC approval for 3.5.2 yet? There are no rules pubished yet (that I know of). So we should have component owner approval and a code review by a peer committer. We're good for this bug.
Created attachment 155267 [details] updated updated copyrights on the patch.
Released to 3.5.2
