| Proposal |
Summary
Deploying an RCP based application involves constructing a complete Eclipse install. As such, any third-party, platform-specific fragments and Eclipse launchers (executables) must be included in the deployment for each target platform. This is in contrast to deploying add-on function typical of tooling scenarios which contain mostly developer written and platform-independent plug-ins. This document describes a deployment pack download which simplifies the construction of complete RCP applications for multiple platforms.Last modified: October 21, 2004
Developers are setup with development and target Eclipse installs for one platform. They merrily configure their target and write their code, launching and debugging as they go. When it comes time however to deploy their application, they face a challenge -- their target includes only the launcher (Eclipse executable) and fragments for their current target platform. This is disappointing because Eclipse, and in fact Java, is platform independent. In general, an application written for one application should at least run on other supported platforms.
Currently the workaround for this is cumbersome, very manual and thus very error-prone. It goes something like this:
To make this easier we propose that Eclipse.org supply a deployment pack download which effectively eliminates steps 1-5 outlined above. The deployment pack is a single zip containing all possible (platform-specific) fragments for all of the Eclipse SDK as well as a special feature which contains launchers and essential root files (e.g., startup.jar) for all supported platforms.
Using this deployment pack allows steps 1-5 to be compressed into
The deployment pack is approximately 15MB in total. The bulk of this is taken up by SWT fragments (8 @ 1.5MB each). Another 2.5MB for all the launchers and a bit here and there for other fragments. The net result however is a setup which allows users to write their applications on one machine and build deployable zips etc. for all possible configurations with the push of a button.
Creating the deployment pack can be reasonably integrated into the current build infrastructure.
The need for deployment packs is felt mostly in RCP scenarios. As such, we could consider including the contents of the deployment pack in the RCP SDK drop proper. Unfortunatly this doubles the size of the SDK drop (currently 17MB) and clutters the target environment. Further there is still a need for platform specific RCP SDK drops to carry the appropriate source. So the additional 15MB would be replicated 8 times in the various RCP SDK zips.