Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EPP » Eclipse Install Manager
Eclipse Install Manager [message #2170] Fri, 05 January 2007 14:21 Go to next message
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 Go to previous messageGo to next message
Dan Rubel is currently offline 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 Go to previous messageGo to next message
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 Go to previous messageGo to next message
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 #4869 is a reply to message #3885] Thu, 01 March 2007 12:36 Go to previous message
Dan Rubel is currently offline Dan Rubel
Messages: 17
Registered: July 2009
Junior Member
Urs Reupke wrote:
> 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?

No. It has various operations for modifying the Windows registry to "register"
the product just installed, but not to "register" a start menu. That should not
be very hard to add.

- Dan
Re: Eclipse Install Manager [message #572550 is a reply to message #2170] Tue, 09 January 2007 02:32 Go to previous message
Dan Rubel is currently offline 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 Go to previous message
Jochen Krause is currently offline 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).
Re: Eclipse Install Manager [message #573879 is a reply to message #2319] Wed, 21 February 2007 05:35 Go to previous message
Urs Reupke is currently offline Urs Reupke
Messages: 8
Registered: July 2009
Junior Member
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 #574328 is a reply to message #3885] Thu, 01 March 2007 12:36 Go to previous message
Dan Rubel is currently offline Dan Rubel
Messages: 17
Registered: July 2009
Junior Member
Urs Reupke wrote:
> 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?

No. It has various operations for modifying the Windows registry to "register"
the product just installed, but not to "register" a start menu. That should not
be very hard to add.

- Dan
Previous Topic:Re: Strawpack package proposal for Java Enterprise Developer
Next Topic:Question to Dan - installers?
Goto Forum:
  


Current Time: Tue Oct 21 18:23:37 GMT 2014

Powered by FUDForum. Page generated in 0.03380 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software