Home » Eclipse Projects » Equinox » Plugin & RCP organization advice
|
| Re: Plugin & RCP organization advice [message #35932 is a reply to message #35894] |
Fri, 27 February 2004 17:29   |
Eclipse User |
|
|
|
Originally posted by: manahan.NOSPAM.ca.ibm.com
Probably the best way is to provide different configurations with the
-configuration flag. This is still being worked on afaik so I don't know
how solid it is.
In theory this would allow you to have all the features and plugins
together but have different configs which enable and disable specific
sets of function depending on the configuration provided.
Peter
Stephen Goldbaum wrote:
> Hey,
>
> I've been developing a number of features and plugins for use with the
> RCP.
> I have a number of "main" features (with application extensions) that do
> not coexist. I run these in separate installations of the RCP. In
> addition, I have a few "optional" features that, depending on the
> functionality, can be loaded into either all or a subset of these RCPs.
> Currently I force the user to install a separate RCP installations for
> each "main" feature and then make them install the optional plugins into
> each of these instances. This has the drawback of having many duplicates
> of the Eclipse and "optional" plugins peppered throughout the user's
> machine.
>
> Is there a better way to manage all of this? I've looked at the "-data"
> and "-workspace" parameters, but have found limited documentation on them.
> Using links seems like another option if I could configure them behind
> the scenes (the users are low tech with no patience for managing such
> complexity).
>
> Thanks,
> Stephen
>
|
|
|
| Re: Plugin & RCP organization advice [message #35965 is a reply to message #35932] |
Sat, 28 February 2004 22:04 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
-configuration (or set osgi.configuration.area System property) is
definitely the way to go. Your scenario is exactly what it was designed
for. Basically the eclipse runtime needs to be told what plugins to run.
These are the ones that are "configured". Each configuration can be
completely different or differ by a few plugins are just some settings.
Each will have its own storage for the various caches etc.
From the user's point of view running
eclipse.exe -configuration c:/foo
eclipse.exe -configuration c:/bar
would be completely differnet things. Potentially different splash screens
(up to you), different applications, ...
While the -configuration option has been there for a long time (PDE uses it
when launching your runtime workspaces) Peter is right that it is in flux.
As I say, PDE uses it every time you run the target so it is reasonably
solid. I just put in a mess o changes for this weeks I build and that
should be the last of the big changes. Update has to catch up to these but
they are pretty fast so definitely by M8 it will have shaped up. Go ahead
and give it a look and give feedback. Now is the best time since it is in
play.
BTW, there are some "in progress" docs on the Core's runtime pages
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/plat form-core-home/runtime/index.html
Jeff
"Peter Manahan" <manahan@NOSPAM.ca.ibm.com> wrote in message
news:c1nuja$seq$1@eclipse.org...
> Probably the best way is to provide different configurations with the
> -configuration flag. This is still being worked on afaik so I don't know
> how solid it is.
>
> In theory this would allow you to have all the features and plugins
> together but have different configs which enable and disable specific
> sets of function depending on the configuration provided.
>
> Peter
>
> Stephen Goldbaum wrote:
> > Hey,
> >
> > I've been developing a number of features and plugins for use with the
> > RCP.
> > I have a number of "main" features (with application extensions) that do
> > not coexist. I run these in separate installations of the RCP. In
> > addition, I have a few "optional" features that, depending on the
> > functionality, can be loaded into either all or a subset of these RCPs.
> > Currently I force the user to install a separate RCP installations for
> > each "main" feature and then make them install the optional plugins into
> > each of these instances. This has the drawback of having many
duplicates
> > of the Eclipse and "optional" plugins peppered throughout the user's
> > machine.
> >
> > Is there a better way to manage all of this? I've looked at the "-data"
> > and "-workspace" parameters, but have found limited documentation on
them.
> > Using links seems like another option if I could configure them behind
> > the scenes (the users are low tech with no patience for managing such
> > complexity).
> >
> > Thanks,
> > Stephen
> >
>
|
|
|
| Re: Plugin & RCP organization advice [message #36035 is a reply to message #35965] |
Tue, 02 March 2004 20:40 |
 Stephen Goldbaum
Messages: 75
Registered: July 2009 |
Member |
|
|
So in this scenario, both configurations share the same directory but use
different subsets of the features/plugins stored there. Correct? Given
that, installing a new application could entail providing a custom
installer with each of the "application" features. This installer would
create and populate the configuration directory and create an executable
to invoke eclipse with the appropriate -configuration setting. Sound
reasonable?
So how do you inform eclipse what features to use (at least initially)? I
see the "platform.cfg" file has a comma-separated list of plugins. Is
this the right place? Is there an equivalent setting for features? Given
that features reference the required plugins, it seems like it would be
convenient to allow this to be feature driven.
Thanks,
Stephen
Jeff McAffer wrote:
> -configuration (or set osgi.configuration.area System property) is
> definitely the way to go. Your scenario is exactly what it was designed
> for. Basically the eclipse runtime needs to be told what plugins to run.
> These are the ones that are "configured". Each configuration can be
> completely different or differ by a few plugins are just some settings.
> Each will have its own storage for the various caches etc.
> From the user's point of view running
> eclipse.exe -configuration c:/foo
> eclipse.exe -configuration c:/bar
> would be completely differnet things. Potentially different splash screens
> (up to you), different applications, ...
> While the -configuration option has been there for a long time (PDE uses it
> when launching your runtime workspaces) Peter is right that it is in flux.
> As I say, PDE uses it every time you run the target so it is reasonably
> solid. I just put in a mess o changes for this weeks I build and that
> should be the last of the big changes. Update has to catch up to these but
> they are pretty fast so definitely by M8 it will have shaped up. Go ahead
> and give it a look and give feedback. Now is the best time since it is in
> play.
> BTW, there are some "in progress" docs on the Core's runtime pages
>
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/plat form-core-home/runtime/index.html
> Jeff
> "Peter Manahan" <manahan@NOSPAM.ca.ibm.com> wrote in message
> news:c1nuja$seq$1@eclipse.org...
> > Probably the best way is to provide different configurations with the
> > -configuration flag. This is still being worked on afaik so I don't know
> > how solid it is.
> >
> > In theory this would allow you to have all the features and plugins
> > together but have different configs which enable and disable specific
> > sets of function depending on the configuration provided.
> >
> > Peter
> >
> > Stephen Goldbaum wrote:
> > > Hey,
> > >
> > > I've been developing a number of features and plugins for use with the
> > > RCP.
> > > I have a number of "main" features (with application extensions) that do
> > > not coexist. I run these in separate installations of the RCP. In
> > > addition, I have a few "optional" features that, depending on the
> > > functionality, can be loaded into either all or a subset of these RCPs.
> > > Currently I force the user to install a separate RCP installations for
> > > each "main" feature and then make them install the optional plugins into
> > > each of these instances. This has the drawback of having many
> duplicates
> > > of the Eclipse and "optional" plugins peppered throughout the user's
> > > machine.
> > >
> > > Is there a better way to manage all of this? I've looked at the "-data"
> > > and "-workspace" parameters, but have found limited documentation on
> them.
> > > Using links seems like another option if I could configure them behind
> > > the scenes (the users are low tech with no patience for managing such
> > > complexity).
> > >
> > > Thanks,
> > > Stephen
> > >
> >
|
|
|
| Re: Plugin & RCP organization advice [message #36100 is a reply to message #36035] |
Wed, 03 March 2004 02:50 |
| Eclipse User |
|
|
|
Originally posted by: dorian.birsan.net
"Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
news:c22rg5$23g$1@eclipse.org...
> So in this scenario, both configurations share the same directory but use
> different subsets of the features/plugins stored there. Correct? Given
> that, installing a new application could entail providing a custom
> installer with each of the "application" features. This installer would
> create and populate the configuration directory and create an executable
> to invoke eclipse with the appropriate -configuration setting. Sound
> reasonable?
>
> So how do you inform eclipse what features to use (at least initially)? I
> see the "platform.cfg" file has a comma-separated list of plugins. Is
> this the right place? Is there an equivalent setting for features? Given
> that features reference the required plugins, it seems like it would be
> convenient to allow this to be feature driven.
Install the latest integration build and look at
eclipse/configuration/platform.xml. This is the replacement for platform.cfg
and its syntax may be exposed as API. At a minimum, it is possible to write
a simple tool (as a plugin) to generate platform.xml, the way PDE does. You
need to call IPlatformConfiguration.configureSite/Feature() and then
save(url).
-Dorian
>
> Thanks,
> Stephen
>
>
> Jeff McAffer wrote:
>
> > -configuration (or set osgi.configuration.area System property) is
> > definitely the way to go. Your scenario is exactly what it was designed
> > for. Basically the eclipse runtime needs to be told what plugins to
run.
> > These are the ones that are "configured". Each configuration can be
> > completely different or differ by a few plugins are just some settings.
> > Each will have its own storage for the various caches etc.
>
> > From the user's point of view running
> > eclipse.exe -configuration c:/foo
> > eclipse.exe -configuration c:/bar
> > would be completely differnet things. Potentially different splash
screens
> > (up to you), different applications, ...
>
> > While the -configuration option has been there for a long time (PDE uses
it
> > when launching your runtime workspaces) Peter is right that it is in
flux.
> > As I say, PDE uses it every time you run the target so it is reasonably
> > solid. I just put in a mess o changes for this weeks I build and that
> > should be the last of the big changes. Update has to catch up to these
but
> > they are pretty fast so definitely by M8 it will have shaped up. Go
ahead
> > and give it a look and give feedback. Now is the best time since it is
in
> > play.
>
> > BTW, there are some "in progress" docs on the Core's runtime pages
> >
>
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/plat form-core-home/runtime/index.html
>
> > Jeff
>
>
> > "Peter Manahan" <manahan@NOSPAM.ca.ibm.com> wrote in message
> > news:c1nuja$seq$1@eclipse.org...
> > > Probably the best way is to provide different configurations with the
> > > -configuration flag. This is still being worked on afaik so I don't
know
> > > how solid it is.
> > >
> > > In theory this would allow you to have all the features and plugins
> > > together but have different configs which enable and disable specific
> > > sets of function depending on the configuration provided.
> > >
> > > Peter
> > >
> > > Stephen Goldbaum wrote:
> > > > Hey,
> > > >
> > > > I've been developing a number of features and plugins for use with
the
> > > > RCP.
> > > > I have a number of "main" features (with application extensions)
that do
> > > > not coexist. I run these in separate installations of the RCP. In
> > > > addition, I have a few "optional" features that, depending on the
> > > > functionality, can be loaded into either all or a subset of these
RCPs.
> > > > Currently I force the user to install a separate RCP installations
for
> > > > each "main" feature and then make them install the optional plugins
into
> > > > each of these instances. This has the drawback of having many
> > duplicates
> > > > of the Eclipse and "optional" plugins peppered throughout the user's
> > > > machine.
> > > >
> > > > Is there a better way to manage all of this? I've looked at the
"-data"
> > > > and "-workspace" parameters, but have found limited documentation on
> > them.
> > > > Using links seems like another option if I could configure them
behind
> > > > the scenes (the users are low tech with no patience for managing
such
> > > > complexity).
> > > >
> > > > Thanks,
> > > > Stephen
> > > >
> > >
>
>
|
|
|
| Re: Plugin & RCP organization advice [message #36134 is a reply to message #36035] |
Wed, 03 March 2004 03:18 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Both configurations share the same INSTALL location but identify potentially
different feature/plugin subsets to use.
The custom installer deal sounds reasonable.
If you want to be able to use the Eclipse update/install technology then you
should do what Dorian mentioned in another post and write a platform.xml.
You can likely ship with one that the custom installer places into the
configuration area or your custom installer may be able to build it on the
fly.
Note that if you don't want install/update support (why not?!) then you can
either write a simple configurator which installs the desired plugins
directly (e.g., hard coded list, reading the list from a properties file,
....) or simply list them all in the osgi.bundles property in config.ini (in
the configuration area). These options are pretty lowtech but make sense in
some very constrained scenarios.
Jeff
"Stephen Goldbaum" <stephen.goldbaum@lehman.com> wrote in message
news:c22rg5$23g$1@eclipse.org...
> So in this scenario, both configurations share the same directory but use
> different subsets of the features/plugins stored there. Correct? Given
> that, installing a new application could entail providing a custom
> installer with each of the "application" features. This installer would
> create and populate the configuration directory and create an executable
> to invoke eclipse with the appropriate -configuration setting. Sound
> reasonable?
>
> So how do you inform eclipse what features to use (at least initially)? I
> see the "platform.cfg" file has a comma-separated list of plugins. Is
> this the right place? Is there an equivalent setting for features? Given
> that features reference the required plugins, it seems like it would be
> convenient to allow this to be feature driven.
>
> Thanks,
> Stephen
>
>
> Jeff McAffer wrote:
>
> > -configuration (or set osgi.configuration.area System property) is
> > definitely the way to go. Your scenario is exactly what it was designed
> > for. Basically the eclipse runtime needs to be told what plugins to
run.
> > These are the ones that are "configured". Each configuration can be
> > completely different or differ by a few plugins are just some settings.
> > Each will have its own storage for the various caches etc.
>
> > From the user's point of view running
> > eclipse.exe -configuration c:/foo
> > eclipse.exe -configuration c:/bar
> > would be completely differnet things. Potentially different splash
screens
> > (up to you), different applications, ...
>
> > While the -configuration option has been there for a long time (PDE uses
it
> > when launching your runtime workspaces) Peter is right that it is in
flux.
> > As I say, PDE uses it every time you run the target so it is reasonably
> > solid. I just put in a mess o changes for this weeks I build and that
> > should be the last of the big changes. Update has to catch up to these
but
> > they are pretty fast so definitely by M8 it will have shaped up. Go
ahead
> > and give it a look and give feedback. Now is the best time since it is
in
> > play.
>
> > BTW, there are some "in progress" docs on the Core's runtime pages
> >
>
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/plat form-core-home/runtime/index.html
>
> > Jeff
>
>
> > "Peter Manahan" <manahan@NOSPAM.ca.ibm.com> wrote in message
> > news:c1nuja$seq$1@eclipse.org...
> > > Probably the best way is to provide different configurations with the
> > > -configuration flag. This is still being worked on afaik so I don't
know
> > > how solid it is.
> > >
> > > In theory this would allow you to have all the features and plugins
> > > together but have different configs which enable and disable specific
> > > sets of function depending on the configuration provided.
> > >
> > > Peter
> > >
> > > Stephen Goldbaum wrote:
> > > > Hey,
> > > >
> > > > I've been developing a number of features and plugins for use with
the
> > > > RCP.
> > > > I have a number of "main" features (with application extensions)
that do
> > > > not coexist. I run these in separate installations of the RCP. In
> > > > addition, I have a few "optional" features that, depending on the
> > > > functionality, can be loaded into either all or a subset of these
RCPs.
> > > > Currently I force the user to install a separate RCP installations
for
> > > > each "main" feature and then make them install the optional plugins
into
> > > > each of these instances. This has the drawback of having many
> > duplicates
> > > > of the Eclipse and "optional" plugins peppered throughout the user's
> > > > machine.
> > > >
> > > > Is there a better way to manage all of this? I've looked at the
"-data"
> > > > and "-workspace" parameters, but have found limited documentation on
> > them.
> > > > Using links seems like another option if I could configure them
behind
> > > > the scenes (the users are low tech with no patience for managing
such
> > > > complexity).
> > > >
> > > > Thanks,
> > > > Stephen
> > > >
> > >
>
>
|
|
|
Goto Forum:
Current Time: Tue Sep 24 17:01:25 GMT 2024
Powered by FUDForum. Page generated in 0.04252 seconds |
] 
Search
Help
Register
Login
Home
