Home » Archived » EPP » Welcome to eclipse.technology.packaging
| |
| Re: Welcome to eclipse.technology.packaging [message #1728 is a reply to message #1720] |
Thu, 14 December 2006 10:07   |
|
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 |
 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 |
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 #2125 is a reply to message #1825] |
Thu, 04 January 2007 21:32 |
| 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 |
|
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 #571614 is a reply to message #1720] |
Thu, 14 December 2006 10:07 |
|
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 |
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 #572239 is a reply to message #1825] |
Thu, 04 January 2007 21:32 |
|
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
--
Twitter: @mknauer23 and @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 |
|
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
|
|
|
Goto Forum:
Current Time: Tue Apr 16 04:50:18 GMT 2024
Powered by FUDForum. Page generated in 0.06255 seconds |
] 
Search
Help
Register
Login
Home
