Community
Participate
Working Groups
The IDE should provide a Java Packager export wizard. This export plugin would be based on the new Packager API, available in Oracle JDK as of JDK 8u20. It would export and package all resources required to run an application, into an installable, self-contained, application bundle. The immediate benefits of the Java Packager wizard would be the following: * provide an easy way to generate from the IDE an installable/executable version of the Java application under development/testing * help the developer get familiar with Java Packaging and its various flavors and options Beyond that, the wizard should ideally also help the developer elaborate automated build instructions. A draft of wireframes of the proposed UI flow for the Java Packager wizard is on this wiki: https://wiki.eclipse.org/JDT_UI/Java_Packager
For WiX ther are already two CQs in IPZilla: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=7693 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=7712
Looks promising. A common problem with multi-page wizards that require a lot of data input is that the user usually needs multiple passes to get the desired result. To avoid repeated configuration work, the "Export > JAR file" wizard offers to create a "*.jardesc" file that stores all user input. There's a "Create JAR" action in the context menu for *.jardesc files, and the the wizard is registered as an editor for these files. This works, but the modal wizard dialog is a bit clumsy. Will the new Packager API define a storage format for packager settings? If yes, then it's probably better to avoid the wizard and create an editor for the package settings file type. Similar to how PDE provides a *.product editor. (In reply to Simon Vienot from comment #0) > Beyond that, the wizard should ideally also help the developer elaborate > automated build instructions. If we have to invent a storage format, then a solution could be to create a well-structured Ant file that could be run standalone, and that could also be used to pre-fill the wizard/editor (assuming that the critical structures have not been deleted).
Thanks for the feedback, Markus. Some general thoughts about editor vs wizard. * IMHO wizards and editors are not alternative : they are complementary -> editor takes in charge the entire complexity ; everything can be done ; but very often the price is a pretty high first step -> wizard help to perform this first step by covering a limiting portion of complexity but in a more guided and didactic fashion * building an editor means specifying a cross-platform file format for packaging ; I suspect it is an uneasy task -> packaging is highly multi-form and dependent of the underlying o/s ; some concepts are similar across o/s but some others are completely specific -> unlike programming language, evolution of packaging process depends on o/s vendors ; this makes maintenance and revision of such a file format quite tough * java packaging API is not a file format -> it's an API which is pretty open-bound (there is a notion of 'Bundler' to help managing extensibility) -> it would probably be the best place to define a file format; unfortunately that's not the plan for now. * a wizard may be designed to limit the "multiple passes" effect -> by providing relevant and default values for all the parameters -> by saving some parameters in user preferences (like the last location in file chooser, the version…) -> by carefully limiting the number of exposed parameters: a wizard is not able to cover the whole complexity (only the editor is); so let's limit the parameters to 80% use case -> by providing some hints for the "next step" : for example, the wizard can provide the underlying command it has used to build the package; developer may copy and patch this command to construct its automation. In the long run, I would be glad to see/help emerging a "common packaging specification" format and develop the corresponding edtor. In the short term, a wizard looks like a good first step: -> I think it can bring a substantial value to developers -> it will help us understanding the "long run" issue -> using the java packaging api, it's a reasonable amount of effort
Following our last tuesday discussions, I updated the proposal in the wiki. - Step #1 now offers ANT script generation in a prominent way (same ui design as Runnable JAR Exporter) - Step #4 now displays ANT script location as part of the summary info; "Extras" popup menu is no longer present.
