Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » EPP » Welcome to eclipse.technology.packaging
Welcome to eclipse.technology.packaging [message #1708] Tue, 12 December 2006 21:36 Go to next message
Karl Matthias is currently offline Karl Matthias
Messages: 2
Registered: July 2009
Junior Member
This new newsgroup has been setup to support discussion of the Packaging
proposal under the Technology project. If you have comments or ideas,
or interest in contributing to the project, this is the place to do it.
Further information on this project can be found at its proposal page:

http://www.eclipse.org/proposals/packaging/

Welcome!

Eclipse Webmaster
Re: Welcome to eclipse.technology.packaging [message #1720 is a reply to message #1708] Wed, 13 December 2006 13:52 Go to previous messageGo to next message
Ed Burnette is currently offline Ed Burnette
Messages: 279
Registered: July 2009
Senior Member
I think this is a great idea, especially the part about native
installers. You can put me down as an interested party.

An install program could make the package size much smaller by using
pack200 or other compression techniques, and help eliminate one of the
complaints often heard about Eclipse (it's too big).

Also an install program could look to see what JRE you have, make sure
it's a good enough version, and add VM specific options, for example to
increase the max permgen size.

It could also do things like set up file associations to support
double-clicking on a file in the Explorer/Finder and tickling Eclipse to
open that file (starting Eclipse if necessary). And it could set update
sites and auto-update policies.

Another thing you could do is create an installer for "The Eclipse Rich
Client Platform" that could be reused by all Eclipse-based applications,
including the IDE. We do that at SAS to avoid re-shipping those bits in
every product. It works kind of like the Microsoft .NET Framework
installer. (A .NET program requires a certain version of the Framework
to be installed first, and thus every .NET program doesn't have to
include the Framework.) Programs and frameworks can also be distributed
on different schedules if you're careful about backwards compatibility
or can do side-by-side installs.

--Ed
Re: Welcome to eclipse.technology.packaging [message #1728 is a reply to message #1720] Thu, 14 December 2006 10:07 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
I also think this sounds like a great idea. So great in fact, that I've already implemented
some of the technology :-)

Buckminster comes with a small installer consisting of a command-line framework, the eclipse
runtime, and the eclipse update manager. It's about two megabytes in size. It can configure
itself using the Eclipse update manager.

I think we have other synergies as well so please put me as an interested party.

Kind Regards,

Thomas Hallgren
The Buckminster Project

Ed Burnette wrote:
> I think this is a great idea, especially the part about native
> installers. You can put me down as an interested party.
>
> An install program could make the package size much smaller by using
> pack200 or other compression techniques, and help eliminate one of the
> complaints often heard about Eclipse (it's too big).
>
> Also an install program could look to see what JRE you have, make sure
> it's a good enough version, and add VM specific options, for example to
> increase the max permgen size.
>
> It could also do things like set up file associations to support
> double-clicking on a file in the Explorer/Finder and tickling Eclipse to
> open that file (starting Eclipse if necessary). And it could set update
> sites and auto-update policies.
>
> Another thing you could do is create an installer for "The Eclipse Rich
> Client Platform" that could be reused by all Eclipse-based applications,
> including the IDE. We do that at SAS to avoid re-shipping those bits in
> every product. It works kind of like the Microsoft .NET Framework
> installer. (A .NET program requires a certain version of the Framework
> to be installed first, and thus every .NET program doesn't have to
> include the Framework.) Programs and frameworks can also be distributed
> on different schedules if you're careful about backwards compatibility
> or can do side-by-side installs.
>
> --Ed
Re: Welcome to eclipse.technology.packaging [message #1738 is a reply to message #1728] Thu, 14 December 2006 13:23 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 112
Registered: July 2009
Senior Member
I am also interested.

Regards
Henrik Lindberg
The Buckminster Project

"Thomas Hallgren" <thomas@tada.se> skrev i meddelandet
news:45812277.9000005@tada.se...
>I also think this sounds like a great idea. So great in fact, that I've
>already implemented some of the technology :-)
>
> Buckminster comes with a small installer consisting of a command-line
> framework, the eclipse runtime, and the eclipse update manager. It's about
> two megabytes in size. It can configure itself using the Eclipse update
> manager.
>
> I think we have other synergies as well so please put me as an interested
> party.
>
> Kind Regards,
>
> Thomas Hallgren
> The Buckminster Project
>
> Ed Burnette wrote:
>> I think this is a great idea, especially the part about native
>> installers. You can put me down as an interested party.
>>
>> An install program could make the package size much smaller by using
>> pack200 or other compression techniques, and help eliminate one of the
>> complaints often heard about Eclipse (it's too big).
>>
>> Also an install program could look to see what JRE you have, make sure
>> it's a good enough version, and add VM specific options, for example to
>> increase the max permgen size.
>>
>> It could also do things like set up file associations to support
>> double-clicking on a file in the Explorer/Finder and tickling Eclipse to
>> open that file (starting Eclipse if necessary). And it could set update
>> sites and auto-update policies.
>>
>> Another thing you could do is create an installer for "The Eclipse Rich
>> Client Platform" that could be reused by all Eclipse-based applications,
>> including the IDE. We do that at SAS to avoid re-shipping those bits in
>> every product. It works kind of like the Microsoft .NET Framework
>> installer. (A .NET program requires a certain version of the Framework to
>> be installed first, and thus every .NET program doesn't have to include
>> the Framework.) Programs and frameworks can also be distributed on
>> different schedules if you're careful about backwards compatibility or
>> can do side-by-side installs.
>>
>> --Ed
Re: Welcome to eclipse.technology.packaging [message #1784 is a reply to message #1720] Mon, 18 December 2006 22:27 Go to previous messageGo to next message
Eclipse User
Originally posted by: jkrause.innoopract.com

Ed,

Great that you are interested. We will follow up.

Jochen


Ed Burnette wrote:
> I think this is a great idea, especially the part about native
> installers. You can put me down as an interested party.
>
> An install program could make the package size much smaller by using
> pack200 or other compression techniques, and help eliminate one of the
> complaints often heard about Eclipse (it's too big).
>
> Also an install program could look to see what JRE you have, make sure
> it's a good enough version, and add VM specific options, for example to
> increase the max permgen size.
>
> It could also do things like set up file associations to support
> double-clicking on a file in the Explorer/Finder and tickling Eclipse to
> open that file (starting Eclipse if necessary). And it could set update
> sites and auto-update policies.
>
> Another thing you could do is create an installer for "The Eclipse Rich
> Client Platform" that could be reused by all Eclipse-based applications,
> including the IDE. We do that at SAS to avoid re-shipping those bits in
> every product. It works kind of like the Microsoft .NET Framework
> installer. (A .NET program requires a certain version of the Framework
> to be installed first, and thus every .NET program doesn't have to
> include the Framework.) Programs and frameworks can also be distributed
> on different schedules if you're careful about backwards compatibility
> or can do side-by-side installs.
>
> --Ed
Re: Welcome to eclipse.technology.packaging [message #1825 is a reply to message #1708] Wed, 03 January 2007 19:43 Go to previous messageGo to next message
John Cooney is currently offline John Cooney
Messages: 2
Registered: July 2009
Junior Member
I was glad to see this project proposal, but have a few questions that
don't appear to be in scope based on the proposal. Are there guidelines
or standards on how workspaces can be packaged/shared? My usecase is that
I have a set of features/plugins to roll out to some new users. I'd like
to get them started as soon as possible with a configuration that is tuned
to a new user. Examples of some things included; other s/w distributions
like the JDK and Tomcat, a sample project so people can kick the tires on
the plugins, and some customizations like having some snippets
prepoulated. Is there something better than workspaces to manage this?

We fixed the location and included the workspace, but this isn't very
flexible. We didn't want to force the users through steps like updating
the preferences to point to the proper location for the Tomcat
installation and change the project properties to set JSF library
references. How is this handled elsewhere? Installing the workspace and
then making changes for a new install location appeared to be messy.
Importing the projects didn't do the trick because the users would still
have a decent amount of configuration to take care of on their own.

Any comments would be appreciated.

Thanks,
John
Re: Welcome to eclipse.technology.packaging [message #2125 is a reply to message #1825] Thu, 04 January 2007 21:32 Go to previous messageGo to next message
Eclipse User
Originally posted by: mknauer.innoopract.com

Thanks, John - and yes, you are right, some of these questions are out of
scope of this project.

But to give you answers to your questions:

(1) A set of features/plugins could be bundled in a zip/tar archive and
distributed to your users. A tooling for this is one goal of this project.

(2) Special configurations are not included in our project proposal, but it
should be easy to put them in the 'plugin_customization.ini' file. In your
case it is probably in your org.eclipse.platform plugin.

(3) Example projects: In my opinion the easiest way is a project import from
a central location (CVS, a zip file, ...)

Hope this helps...

Regards,
Markus


John Cooney wrote:

> I was glad to see this project proposal, but have a few questions that
> don't appear to be in scope based on the proposal. Are there guidelines
> or standards on how workspaces can be packaged/shared? My usecase is that
> I have a set of features/plugins to roll out to some new users. I'd like
> to get them started as soon as possible with a configuration that is tuned
> to a new user. Examples of some things included; other s/w distributions
> like the JDK and Tomcat, a sample project so people can kick the tires on
> the plugins, and some customizations like having some snippets
> prepoulated. Is there something better than workspaces to manage this?
>
> We fixed the location and included the workspace, but this isn't very
> flexible. We didn't want to force the users through steps like updating
> the preferences to point to the proper location for the Tomcat
> installation and change the project properties to set JSF library
> references. How is this handled elsewhere? Installing the workspace and
> then making changes for a new install location appeared to be messy.
> Importing the projects didn't do the trick because the users would still
> have a decent amount of configuration to take care of on their own.
>
> Any comments would be appreciated.
>
> Thanks,
> John
Re: Welcome to eclipse.technology.packaging [message #2407 is a reply to message #1825] Fri, 12 January 2007 08:30 Go to previous message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
Hi John,

John Cooney wrote:
> I was glad to see this project proposal, but have a few questions that
> don't appear to be in scope based on the proposal. Are there guidelines
> or standards on how workspaces can be packaged/shared? My usecase is
> that I have a set of features/plugins to roll out to some new users.
> I'd like to get them started as soon as possible with a configuration
> that is tuned to a new user. Examples of some things included; other
> s/w distributions like the JDK and Tomcat, a sample project so people
> can kick the tires on the plugins, and some customizations like having
> some snippets prepoulated. Is there something better than workspaces to
> manage this?

Indeed there is. What you need is a tool that is able to materialize workspaces based on
component specifications. This is the exact problem that Buckminster
(www.eclipse.org/buckminster) aims to solve. Buckminster can extract a Component
Specification with all dependencies that a certain component (feature or plugin in your
case) from the component meta-data. With this definition in conjunction with a Resource Map
that maps component to locations, Buckminster can do transitive resolutions and create a
BillOfMaterials (BOM). The BOM in turn is used in order to materialize a workspace. The BOM
will appoint components that resides in source code control repositories (we currently
support SVN, CVS, and Perforce), at Eclipse Update sites, in repositories such as Maven (or
Maven2), ftp servers, etc.

All definitions are in XML and can be shared between different members of a team. Please
take a look at Buckminster and don't hesitate to ask more questions on our newsgroup
eclipse.technology.buckminster

Kind Regards,

Thomas Hallgren
The Buckminster Project
Re: Welcome to eclipse.technology.packaging [message #571584 is a reply to message #1708] Wed, 13 December 2006 13:52 Go to previous message
Ed Burnette is currently offline Ed Burnette
Messages: 279
Registered: July 2009
Senior Member
I think this is a great idea, especially the part about native
installers. You can put me down as an interested party.

An install program could make the package size much smaller by using
pack200 or other compression techniques, and help eliminate one of the
complaints often heard about Eclipse (it's too big).

Also an install program could look to see what JRE you have, make sure
it's a good enough version, and add VM specific options, for example to
increase the max permgen size.

It could also do things like set up file associations to support
double-clicking on a file in the Explorer/Finder and tickling Eclipse to
open that file (starting Eclipse if necessary). And it could set update
sites and auto-update policies.

Another thing you could do is create an installer for "The Eclipse Rich
Client Platform" that could be reused by all Eclipse-based applications,
including the IDE. We do that at SAS to avoid re-shipping those bits in
every product. It works kind of like the Microsoft .NET Framework
installer. (A .NET program requires a certain version of the Framework
to be installed first, and thus every .NET program doesn't have to
include the Framework.) Programs and frameworks can also be distributed
on different schedules if you're careful about backwards compatibility
or can do side-by-side installs.

--Ed
Re: Welcome to eclipse.technology.packaging [message #571614 is a reply to message #1720] Thu, 14 December 2006 10:07 Go to previous message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
I also think this sounds like a great idea. So great in fact, that I've already implemented
some of the technology :-)

Buckminster comes with a small installer consisting of a command-line framework, the eclipse
runtime, and the eclipse update manager. It's about two megabytes in size. It can configure
itself using the Eclipse update manager.

I think we have other synergies as well so please put me as an interested party.

Kind Regards,

Thomas Hallgren
The Buckminster Project

Ed Burnette wrote:
> I think this is a great idea, especially the part about native
> installers. You can put me down as an interested party.
>
> An install program could make the package size much smaller by using
> pack200 or other compression techniques, and help eliminate one of the
> complaints often heard about Eclipse (it's too big).
>
> Also an install program could look to see what JRE you have, make sure
> it's a good enough version, and add VM specific options, for example to
> increase the max permgen size.
>
> It could also do things like set up file associations to support
> double-clicking on a file in the Explorer/Finder and tickling Eclipse to
> open that file (starting Eclipse if necessary). And it could set update
> sites and auto-update policies.
>
> Another thing you could do is create an installer for "The Eclipse Rich
> Client Platform" that could be reused by all Eclipse-based applications,
> including the IDE. We do that at SAS to avoid re-shipping those bits in
> every product. It works kind of like the Microsoft .NET Framework
> installer. (A .NET program requires a certain version of the Framework
> to be installed first, and thus every .NET program doesn't have to
> include the Framework.) Programs and frameworks can also be distributed
> on different schedules if you're careful about backwards compatibility
> or can do side-by-side installs.
>
> --Ed
Re: Welcome to eclipse.technology.packaging [message #571647 is a reply to message #1728] Thu, 14 December 2006 13:23 Go to previous message
Henrik Lindberg is currently offline Henrik Lindberg
Messages: 112
Registered: July 2009
Senior Member
I am also interested.

Regards
Henrik Lindberg
The Buckminster Project

"Thomas Hallgren" <thomas@tada.se> skrev i meddelandet
news:45812277.9000005@tada.se...
>I also think this sounds like a great idea. So great in fact, that I've
>already implemented some of the technology :-)
>
> Buckminster comes with a small installer consisting of a command-line
> framework, the eclipse runtime, and the eclipse update manager. It's about
> two megabytes in size. It can configure itself using the Eclipse update
> manager.
>
> I think we have other synergies as well so please put me as an interested
> party.
>
> Kind Regards,
>
> Thomas Hallgren
> The Buckminster Project
>
> Ed Burnette wrote:
>> I think this is a great idea, especially the part about native
>> installers. You can put me down as an interested party.
>>
>> An install program could make the package size much smaller by using
>> pack200 or other compression techniques, and help eliminate one of the
>> complaints often heard about Eclipse (it's too big).
>>
>> Also an install program could look to see what JRE you have, make sure
>> it's a good enough version, and add VM specific options, for example to
>> increase the max permgen size.
>>
>> It could also do things like set up file associations to support
>> double-clicking on a file in the Explorer/Finder and tickling Eclipse to
>> open that file (starting Eclipse if necessary). And it could set update
>> sites and auto-update policies.
>>
>> Another thing you could do is create an installer for "The Eclipse Rich
>> Client Platform" that could be reused by all Eclipse-based applications,
>> including the IDE. We do that at SAS to avoid re-shipping those bits in
>> every product. It works kind of like the Microsoft .NET Framework
>> installer. (A .NET program requires a certain version of the Framework to
>> be installed first, and thus every .NET program doesn't have to include
>> the Framework.) Programs and frameworks can also be distributed on
>> different schedules if you're careful about backwards compatibility or
>> can do side-by-side installs.
>>
>> --Ed
Re: Welcome to eclipse.technology.packaging [message #571867 is a reply to message #1720] Mon, 18 December 2006 22:27 Go to previous message
Jochen Krause is currently offline Jochen Krause
Messages: 72
Registered: July 2009
Member
Ed,

Great that you are interested. We will follow up.

Jochen


Ed Burnette wrote:
> I think this is a great idea, especially the part about native
> installers. You can put me down as an interested party.
>
> An install program could make the package size much smaller by using
> pack200 or other compression techniques, and help eliminate one of the
> complaints often heard about Eclipse (it's too big).
>
> Also an install program could look to see what JRE you have, make sure
> it's a good enough version, and add VM specific options, for example to
> increase the max permgen size.
>
> It could also do things like set up file associations to support
> double-clicking on a file in the Explorer/Finder and tickling Eclipse to
> open that file (starting Eclipse if necessary). And it could set update
> sites and auto-update policies.
>
> Another thing you could do is create an installer for "The Eclipse Rich
> Client Platform" that could be reused by all Eclipse-based applications,
> including the IDE. We do that at SAS to avoid re-shipping those bits in
> every product. It works kind of like the Microsoft .NET Framework
> installer. (A .NET program requires a certain version of the Framework
> to be installed first, and thus every .NET program doesn't have to
> include the Framework.) Programs and frameworks can also be distributed
> on different schedules if you're careful about backwards compatibility
> or can do side-by-side installs.
>
> --Ed
Re: Welcome to eclipse.technology.packaging [message #572183 is a reply to message #1708] Wed, 03 January 2007 19:43 Go to previous message
John Cooney is currently offline John Cooney
Messages: 2
Registered: July 2009
Junior Member
I was glad to see this project proposal, but have a few questions that
don't appear to be in scope based on the proposal. Are there guidelines
or standards on how workspaces can be packaged/shared? My usecase is that
I have a set of features/plugins to roll out to some new users. I'd like
to get them started as soon as possible with a configuration that is tuned
to a new user. Examples of some things included; other s/w distributions
like the JDK and Tomcat, a sample project so people can kick the tires on
the plugins, and some customizations like having some snippets
prepoulated. Is there something better than workspaces to manage this?

We fixed the location and included the workspace, but this isn't very
flexible. We didn't want to force the users through steps like updating
the preferences to point to the proper location for the Tomcat
installation and change the project properties to set JSF library
references. How is this handled elsewhere? Installing the workspace and
then making changes for a new install location appeared to be messy.
Importing the projects didn't do the trick because the users would still
have a decent amount of configuration to take care of on their own.

Any comments would be appreciated.

Thanks,
John
Re: Welcome to eclipse.technology.packaging [message #572239 is a reply to message #1825] Thu, 04 January 2007 21:32 Go to previous message
Markus Knauer is currently offline Markus Knauer
Messages: 109
Registered: July 2009
Senior Member

Thanks, John - and yes, you are right, some of these questions are out of
scope of this project.

But to give you answers to your questions:

(1) A set of features/plugins could be bundled in a zip/tar archive and
distributed to your users. A tooling for this is one goal of this project.

(2) Special configurations are not included in our project proposal, but it
should be easy to put them in the 'plugin_customization.ini' file. In your
case it is probably in your org.eclipse.platform plugin.

(3) Example projects: In my opinion the easiest way is a project import from
a central location (CVS, a zip file, ...)

Hope this helps...

Regards,
Markus


John Cooney wrote:

> I was glad to see this project proposal, but have a few questions that
> don't appear to be in scope based on the proposal. Are there guidelines
> or standards on how workspaces can be packaged/shared? My usecase is that
> I have a set of features/plugins to roll out to some new users. I'd like
> to get them started as soon as possible with a configuration that is tuned
> to a new user. Examples of some things included; other s/w distributions
> like the JDK and Tomcat, a sample project so people can kick the tires on
> the plugins, and some customizations like having some snippets
> prepoulated. Is there something better than workspaces to manage this?
>
> We fixed the location and included the workspace, but this isn't very
> flexible. We didn't want to force the users through steps like updating
> the preferences to point to the proper location for the Tomcat
> installation and change the project properties to set JSF library
> references. How is this handled elsewhere? Installing the workspace and
> then making changes for a new install location appeared to be messy.
> Importing the projects didn't do the trick because the users would still
> have a decent amount of configuration to take care of on their own.
>
> Any comments would be appreciated.
>
> Thanks,
> John


--
Markus Knauer

Twitter: @EclipseRAP
Blog: http://eclipsesource.com/blogs/

Professional services for RAP and RCP?
http://eclipsesource.com/services/rap/
Re: Welcome to eclipse.technology.packaging [message #572671 is a reply to message #1825] Fri, 12 January 2007 08:30 Go to previous message
Thomas Hallgren is currently offline Thomas Hallgren
Messages: 3229
Registered: July 2009
Senior Member
Hi John,

John Cooney wrote:
> I was glad to see this project proposal, but have a few questions that
> don't appear to be in scope based on the proposal. Are there guidelines
> or standards on how workspaces can be packaged/shared? My usecase is
> that I have a set of features/plugins to roll out to some new users.
> I'd like to get them started as soon as possible with a configuration
> that is tuned to a new user. Examples of some things included; other
> s/w distributions like the JDK and Tomcat, a sample project so people
> can kick the tires on the plugins, and some customizations like having
> some snippets prepoulated. Is there something better than workspaces to
> manage this?

Indeed there is. What you need is a tool that is able to materialize workspaces based on
component specifications. This is the exact problem that Buckminster
(www.eclipse.org/buckminster) aims to solve. Buckminster can extract a Component
Specification with all dependencies that a certain component (feature or plugin in your
case) from the component meta-data. With this definition in conjunction with a Resource Map
that maps component to locations, Buckminster can do transitive resolutions and create a
BillOfMaterials (BOM). The BOM in turn is used in order to materialize a workspace. The BOM
will appoint components that resides in source code control repositories (we currently
support SVN, CVS, and Perforce), at Eclipse Update sites, in repositories such as Maven (or
Maven2), ftp servers, etc.

All definitions are in XML and can be shared between different members of a team. Please
take a look at Buckminster and don't hesitate to ask more questions on our newsgroup
eclipse.technology.buckminster

Kind Regards,

Thomas Hallgren
The Buckminster Project
Previous Topic:Question to Dan - installers?
Next Topic:Conference Call: January 18 at 8amPT/11amET/5pmCET
Goto Forum:
  


Current Time: Mon Oct 20 08:08:19 GMT 2014

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

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