Markus Knauer wrote:
Dan, could you provide insight which requirements would be met by the
technology you are thinking about to contribute to the project?
Yes... see below. For more, see the discussion and links in my reply on
this newsgroup to "Questions to Dan - installers?".
> - Check the availability of a suitable Java environment,
Yes, the native wrapper for the java based installer locates a suitable JVM
> potentially packaging a run-time environment
Yes the native wrapper could bundle and install a JVM, but this is not
currently implemented. We are planning on adding this, but have not
gotten to it yet. If it is determined that this is needed for EPP, then
we can add it in short order.
> - Check the integrity of the download archive
Not currently but easily added.
> - Reducing the download size, e.g. with pack200
Not currently. This is a great idea and easily added *if* we can locate
an appropriately licensed library implementing pack200.
> - Provide the user with a well known and easy to use mechanism for
> installing: executable, start-up menu entries, ...
Much of this is already part of the installer framework. We already have
platform-agnostic install operations (descriptions) that dynamically
morph to platform-specific behavior (behavior) when executed. For
example, the RegisterProductOperation is platform-agnostic, describing
the desire of the installer to register particular information about the
product. When the installer executes, it resolves this operation to
platform specific behavior such as updating the Windows registry, or
updating Linux directory structures according to Ready-for-Rational
Certification Specifications. Other platform specific behavior can be
added in a similar way.
> And some non-functional requirements:
>
> - It must be really really stable and reliable as this will be the
first
> thing a new user will see
We (Instantiations) use this installer framework to deliver all of our
products... 100's of customers per day are downloading and installing
one or another of our Eclipse based products. These aspects of the
installer are very very stable. As with any framework, there are things
we have not implemented (see various discussions above) because we have
not needed them and this is the first time anyone has requested them.
These would need to be built carefully and tested throughly.
> - Small and simple to use
It is simple to use... a traditional simple wizard based installer
experience. The installer framework itself is small, but the wizard
based interface requires bundling SWT/JFace which adds aprox 2 Meg to
the overhead.
> - We can reuse our system of download mirrors
It is completely self contained and works well with mirrors, bit
torrent, FTP, whatever.
Are you also interested in committing heads to the project?
Most likely, but lets first determine
(1) the suitability of our installer framework for EPP (see my reply on
this newsgroup to "Questions to Dan - installers?") and
(2) whether we (Instantiations) are donating the installer framework to
Eclipse (we are seriously considering it but have not decided yet).