Home » Archived » EPP » Eclipse Install Manager
| Eclipse Install Manager [message #2170] |
Fri, 05 January 2007 14:21  |
Eclipse User |
|
|
|
Originally posted by: mknauer.innoopract.com
Hi all,
I would like to state an initial set of requirements for an Eclipse
installer that eventually could be part of the packaging project. Please
feel free to add your points to this discussion.
- Check the availability of a suitable Java environment, potentially
packaging a run-time environment
- Check the integrity of the download archive
- Reducing the download size, e.g. with pack200
- Provide the user with a well known and easy to use mechanism for
installing: executable, start-up menu entries, ...
- ...
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
- Small and simple to use
- We can reuse our system of download mirrors
More input is welcome ...
An installer would be one option for users that download eclipse packages,
zip / tar archives would remain the other option.
Dan, could you provide insight which requirements would be met by the
technology you are thinking about to contribute to the project? Are you
also interested in committing heads to the project?
Thanks and regards,
Markus
--
Markus Knauer
INNOOPRACT Informationssysteme GmbH
-
|
|
|
| Re: Eclipse Install Manager [message #2319 is a reply to message #2170] |
Tue, 09 January 2007 02:32  |
 Dan Rubel
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
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).
|
|
|
| Re: Eclipse Install Manager [message #2349 is a reply to message #2319] |
Wed, 10 January 2007 07:52 |
| Eclipse User |
|
|
|
Originally posted by: jkrause.innoopract.com
Dan,
This looks very promising to me. And thanks for providing the links. We
will dig some deeper into it, but I think your installer framework would
be a great addition to the packaging project.
Jochen
Dan Rubel wrote:
> 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).
|
|
|
| Re: Eclipse Install Manager [message #3885 is a reply to message #2319] |
Wed, 21 February 2007 05:35 |
| Eclipse User |
|
|
|
Originally posted by: ureupke.innoopract.com
Hi Dan,
in response to Markus you wrote:
> > - 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.
I'm currently working on the basics of the eclipse installer.
To avoid reinventing the wheel, I'd like to come back to the Start Menu
part of Markus' question: Does the installer framework as provided on
your website include a pre-implemented step for any kind of start menu
operation?
Regards
-Urs
|
|
| |
| Re: Eclipse Install Manager [message #572550 is a reply to message #2170] |
Tue, 09 January 2007 02:32 |
Dan Rubel
Messages: 17
Registered: July 2009 |
Junior Member |
|
|
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).
|
|
|
| Re: Eclipse Install Manager [message #572617 is a reply to message #2319] |
Wed, 10 January 2007 07:52 |
Jochen Krause
Messages: 72
Registered: July 2009 |
Member |
|
|
Dan,
This looks very promising to me. And thanks for providing the links. We
will dig some deeper into it, but I think your installer framework would
be a great addition to the packaging project.
Jochen
Dan Rubel wrote:
> 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).
|
|
| | |
Goto Forum:
Current Time: Sat Nov 09 03:19:39 GMT 2024
Powered by FUDForum. Page generated in 0.03388 seconds |
] 
Search
Help
Register
Login
Home
