Community
Participate
Working Groups
I20050209 The user creates an RCP program plug-in project. Now he wants to create a package for deployment. First thing he tries is he right clicks on the project and selects Export. It's not obvious what to select from here but let's say he picks Deployable plug-ins and fragments. He sepects a Zip file format, and saves the export operation as an Ant build script. That partially works but this way he will not discover the Product Configuration editor, which has very similar functionality but is invoked very differently. These stories need to be unified. (Other things the user might have reasonably picked from the current list are Deployable features or Archive file. Neither of these is correct either.)
I have an idea about how to address this. Perhaps this is what you're planning anyway, I don't know. In the Plug-in Manifest editor, on the first page you have a little exporting section that refers you to the Export Wizard. How about if Products worked the same way. Instead of having exporting be part of the editor, delegate it to a product exporting wizard. The wizard would take its input from the .product file (icons and so forth) and have additional options about where to export, what form to export in, and optionally where to put an ant script, just like the deployable plug-ins export wizard today.
what is the point of a wizard that will have a duplicate (albeit a subset) of content of the editor?
No, no, I was thinking there would not be any duplication in the content. The editor would not say where to export to or the format, it would just describe the product itself (name, plug-ins and/or features, splash, icons, and so forth).
sounds reasonable. I find the idea of keeping all the build settings out of the product file attractive, especially since the export format list are likely to grow soon.
If we do that, then step 1 (the synchronization portion) would be done at the same time.
Nick/Jeff, +/- 1?
forgot to actually cc Nick
Sounds reasonable. My assumptoin here is that all plugin related exporting (features, plugins, products, ...) will go through the same/similar wizard. This gives users the "full power"(tm) to choose if they want signing, jnlp, zipped, update site, ... (the last ones assume we do some other work but you get the idea). so if that is a reasonably accurate description then +1 Note also should be able to right click on a .product file and export
that's what I had in mind, yes. consistency between all exports would be good.
Being consistent in the use of export wizards for export would be good. However, the export options can be complex, and the user should not have to re-enter these each time. This will definitely be an iterative process. If the settings can be captured in the product file, even if presented in the wizard, that would be good. A link from the product editor to the export wizard (not just descriptive text) would be nice.
"If the settings can be captured in the product file, even if presented in the wizard," captured, but not displayed in the editor UI, right? Otherwise, we would have the duplication I was trying to avoid (comment 2)
Yes, I'm fine with that, as long as it's clear which product definition is affected by the wizard.
I can see a need for remembering and reusing export configuration options but why does it need to be stored in the .product file? I see .product as being kind of like .project, it describes a thing. Exports are more like launch configurations, they describe what to do with the thing. ... Would it be practical to use an ant script as the export configuration persistance format? You already have another request to create them from the UI, so why store it twice?
First cut storing them in the .product file would be fine if that's easier. Storing the data in a separate file has benefits. There is precedence for this in the Jar export .jardesc files. The worry here is that it just introduces "yet another file" to quote Wassim. Saving as a build script does not seem like much fun. What happens when the user wants to open it and change one value?! reverse engineer the script and replace values? Other consideration is the password optionally required for signing. Probably have to enter that every time. You know, I'm thinking that there aren't all that many values to enter so perhaps just saving them in the dialog settings store is ok. I use Export quite a bit and the behaviour is not bad. Depends of course if you are switching around a lot bu tif you are exporting pretty much the same thing/style all the time there is little to change. Suggest we do as little as possible here and see what the useabilty is like.
There is now an Eclipse Product which can be invoked from the product editor itself. It will also appear in the Export Wizard list (i.e File > Export...) the wizard has more output formats and will have even more options for M6.
Cool, thanks.
