Page Comparison

...

• The biggest one is missing modularity. The compiler and generated installers, although optimized in size, are still a monolithic pieces of software. We put all runtime dependencies in an installer to one classpath and cannot handle for example different versions of one and the same framework in several custom implementations a user might want to add. All contents of libraries provided by <jar> tags are merged to the same classpath like the built-in installer code and loaded by one and the same classloader all at once. There is no per-feature separation for them and all is loaded at once regardless of what is actually needed for a given scenario.
• No custom module (features, plugins) which can be added and loaded at once depending on the needs as one piece.
  For example you might want to add a feature to your installer deploying a WAR file to a running Tomcat container. Therefore you need to gather the Tomcat Manager parameters (host, port, credentials), translations, some Tomcat Manager client libraries (maybe also for different versions of Tomcat), a connection validator, a dedicated custom "listener" to do the actual deployment and so on. Currently, all these things, panels, validators, listeners and client libraries must be defined somewhere in the install.xml, UserInputSpec.xml, translation packs and so on in different tags and files. At the end, without good comments you can't recognize any longer which XML elements and libraries actually belong to your initial feature.
  Instead, there should be a way to add a jar containing your own custom implementation including its  dependencies, which can be easily added and automatically integrates to your installer, without the needs of defining additional <jar> and many more tags and resources explicitly.
• We don't use sufficiently modern technologies built-in to the JDK/JRE, like JavaFX/OpenJFX for panel layout, Java Preferences API for registering instead of focusing to native Windows registry methods, NIO etc. There is a lot of code still based on JDK 1.4 and previous Java versions. According to our needs we might also increase the JDK and JRE requirement to throw aboard the support of JDK versions which haven't received (security) updates for ages. Nevertheless, there should be again a long-term support for a defined JDK/JRE.

...

• A prerequisite to use JDK 1.8 at compile and runtime is a very probable option.
• Regarding modularity, OSGI will be probably a "must have". 
  We might use an embedded, auto-started OSGI container based on Apache Felix to , even better in size is Eclipse Concierge to keep it small.
  We might also consider to support external OSGI containers which hold some dependencies on a given system and help to keep the installer jar size small.
  We won't wait for JDK 9 and Jigsaw, furthermore Jigsaw doesn't support versioned bundles. We can combine it later with Jigsaw, but this is not subject to a discussion now.
  OSGI services should provide and consume (to be enhanced later):
  • IzPack variables / dynamic variables
    (add new variables, modify and read values)
  • IzPack conditions
    (add new conditions, verify whether a condition is true)
  • Translations / language packs
  • ...
• Along with the above point there appears the question of whether to support pre-installed IzPack runtimes, regardless whether they would come as standalone libraries, as a OSGI container the installer might start and register to or maybe even in common application containers, like Jetty, Tomcat, etc. This is just a rough idea, because all native installers like MSI on Windows, Snapper, RPM or DEB for Linux profit from a comprehensive pre-installed runtime, scripting engines etc. processing the dedicated package, which then has just content, but no installation code. An IzPack runtime could be installed by the izpack-dist installer as an option. At the moment, it provides just tools for creating an installer, it might also contain a pack with a runtime required to run a dedicated installer.
  Nevertheless, there should be always the possibility to compile a standalone installer jar just requiring a pre-installed JRE.
• Should we use Spring?
  I'm currently in doubt with this. As a plus, Spring offers dependency injection (could replace picocontainer).
  But t's OSGI support is going to be discontinued. Further, it generates a big overhead, not really needed, if you have just a "Hello world" program installer without special features. For example, I've set up the simple example at https://projects.spring.io/spring-boot/, the compiled standalone demo-0.0.1-SNAPSHOT.jar is big, 6,2 MB in size. This is totally uncompetitive to the overhead a clean IzPack 5 installer generates. I wouldn't like to offer such a dinosaurus as compiled installer jar, although most real-world installers are usually much bigger in overhead just due to additional libraries, like JDBC drivers, added as <jar> tag.
  I see Spring still as a set of tools made for web applications and J2EE. I still don't have an idea how to design a reasonable rich client like a software installer with it (except of the useful OSGI support and dependency injection).
  With this state of knowledge I'd rather vote no, but who knows. 
• What is the best rich client framework for our purpose to make it easier to create custom panels? Should it still be plain old Swing, or JavaFX/OpenJFX 8, or even a well-supported 3rd-party one?
  Should the good old Swing-based UserInputPanel be replaced by a new panel type based on JavaFX/OpenJFX 8?
  Or should be use a light-weight browser and HTML, along with a light-weight, embedded servlet container, or support plain HTML and JavaScript? 
• What about picocontainer, will it work in a new architecture described above, especially with OSGI and containers?

...