| [epp-dev] EPP Installer and Eclipse SFX archive proposal |
|
Hi Folks, Below are some aspects of the installer I’d
like to mention before going further: 1) Installer and OSGi Contributed EPP installer from Instantiations
was designed from the beginning to be general purpose framework and targets to
wide audience of Java developers. In fact current installer do not utilize anything
of OSGi, which is great for general purpose solution but looks not very good
for Eclipse Foundation project… Especially Installer could benefit a lot
from OSGi/eclipse at least in following: ·
Utilize eclipse extensibility
instead of home-made registry of contributed installer actions, steps, etc ·
Utilize OSGi multiplatform support
·
Utilize eclipse native
launchers ·
Painless use of OSGi bundles (i.e.
SWT) from end-user installer code ·
etc 2) Installer build process and Europa Installer
Current problem with EPP Installer that Markus
mentioned (besides IP) related only to build process. Since Installer is not
OSGi based it do not fits well into releng/PDE build and requires custom
build/packaging process. According to (1) & (2) and in order to make
build process and whole Installer more clear I’d like to propose
Installer transition to OSGi. Minimal efforts required for this task mainly replacing
Installer extensibility mechanism with eclipse extensibility. After such a
transition installers could be developed, tested and deployed with Eclipse as
an Eclipse Application (product). 3) Native Launcher If EPP packages to be distributed as single
executable binaries, Installer Native launcher could be used. Current
launcher is also general purpose and duplicates a lot of eclipse native launcher
(eclipse.exe) tasks (searching for JRE, showing splash, etc), which are
redundant if we’re moving ahead with OSGi transition. Only one unique and
required functionality of current Installer’s native launcher is an
ability to extract files from archive and launch extracted file(s). 4) Linux, Vista, OSX There are a lot of talks regarding OS specifics
and end-user expectations on different platforms. Definitely the best way for
Vista is to provide MSI package, deb for Debian and so on… Probably
future EPP-based installers would be defined in a kind of domain-specific language
and translated to target install environments (like MSI or deb), in this case
current java-based installer code and corresponding frameworks would be
eliminated. After looking at 1-4 I’d like to come
with quick and dirty Eclipse SFX proposal. == Eclipse SFX Proposal == Description: Eclipse SFX is an archive of
files packaged as executable for the target platform. If executed, behavior is simple
as possible and following: according to SFX manifest extract some files into
temporary directory and launch one of extracted files (eclipse.exe for most
scenarios). No java search, no splashes, etc… Besides native launcher SFX
would provide code and tools to work with SFX archives, and (probably)
mechanisms for SFX to act as bundle repository (Equinox provisioning/Repository?).
I do not propose anything related to compression algorithms, SFX manifest schema,
etc. I just assume SFX format would be cool enough to fulfill all current and
future requirements from the community. Why not “standard” SFX (i.e.
Zip SFX): There are several reasons why widely available tools seems to be not
good as an Eclipse SFX, mainly because of uncontrolled native extractor behavior.
In interesting cases (“installer use case”, or “SFX as bundle
repository”) only small set of bootstrapping OSGi plugins and files needs
to be extracted. After OSGi application forked, it would be able to process all
archived files itself (extract bundles to the installation directory or deploy
and run bundles from SFX archive). More info: current Installer SFX archive file
format: http://wiki.eclipse.org/index.php/Installer_SFX
EPP Installer and SFX: From the EPP
installer point of view I’d like to propose splitting and refactoring current
Installer code in two parts: SFX code/tools and OSGi-based installer framework
with following benefits: ·
Potentially some other projects
might be interested in Eclipse SFX archives. I believe this correlate very much
with some parts of Maya project (native bootstrap) but I’m not sure if we
have a time to coordinate efforts. Also some ecosystem projects might be
interested in SFX archives, for example small RCP applications (Eclipse
WordPad) may be interested to be distributed as single executable and to be
launched without installation process. SFX archives seems to be targeted to
wider audience and would be still actual if Installer architecture will change significantly,
see (2). ·
Having SFX layer separated and
after transition to OSGi, EPP Installer would be an Eclipse Application, which
would be clearly built and developed with Eclipse PDE by any eclipse developer
without diving into current Installer API, contracts and launching specifics. ·
This separation do not mean elimination
of Installer Framework, which is good for most especially Windows-based installers
and provides a lot of useful code like installation log, rollback operations,
utility operations (like Add/Remove program), UI, etc ·
End-users are flexible to
choose how to develop their installers: they could rely on the Installer
Framework or just write simple installer as Eclipse Application and deploy it
as an SFX archive. Folks, please share your thoughts, interest
or contras to Eclipse SFX. EPP leads, xored is ready to split
installer and finish transition to OSGi during this week of 21. Tools and
eclipse releng-friendly scripts for automated building of current EPP packages together
with installer bundles as an Eclipse SFX would be provided as well. Please
share your objections if any. Thank you, and Kind Regards, Andrey Platov on behalf of Alexander
Kazantsev xored software, Inc. |