Home » Eclipse Projects » Equinox » how to prevent certain bundles from being resolved?
| how to prevent certain bundles from being resolved? [message #73973] |
Wed, 04 October 2006 12:36  |
Eclipse User |
|
|
|
Hi ppl,
I have RCP and two products installed in the same location:
<a location>
plugins/
product1.plugin
product2.plugin
rcp plugins
...
features/
product1 feature
product2 feature
product1 config/
config.ini
product2 config/
config.ini
where config.ini files look like this (for first product):
....
osgi.bundles=
org.eclipse.equinox.common@2:start,
org.eclipse.update.configurator@3:start,
org.eclipse.core.runtime@start,
product1.plugin,
...
eclipse.product=product1
the problem is - when the first product is launched, the
update configurator resolves the product2.plugin, too,
and adds its help files, actions, etc. (declared in
plugin.xml file) to product1. Question 1 - how to prevent this?
--
another possibility is to specify all the plugins
manually without the configurator. But, some of rcp
plugins (e.g. swt) are platform dependent, and if I
specify
osgi.bundles = ... org.ecl.swt.win32,org.ecl.swt.linux.motif,
.... (other platforms)
then I get errors when linux bundle is not found on win32,
and so on.
Question 2: is it possible to use wildcards, like
osgi.bundles = ...,org.ecl.swt.*, ...
or, use variables here, like
osgi.bundles = ...,org.ecl.swt.{os}.{ws}, ...
?
thanks
/Sergey
|
|
| | | | |
| Re: how to prevent certain bundles from being resolved? [message #74881 is a reply to message #74415] |
Mon, 16 October 2006 06:15  |
| Eclipse User |
|
|
|
Hi Jeff,
I'm too stupid to get this to run :-(
I have an installation with a few extension locations
added using the "Product Configuration".
I want to create a new configuration with none
of the extension location.
I started eclipse with
-configuration C:\xxxxx
Some years ago this would have created a virgin
configuration. With 3.2 it creates a new
config.ini with essentially one line:
osgi.sharedConfiguration.area=file\:configuration/
The plugin.xml is essentially one line too:
<?xml version="1.0" encoding="UTF-8"?>
<config date="1160992704181" shared_ur="file:configuration/org.eclipse.update/platform.xml " transient="false" version="3.0">
</config>
Now I see all plugins and extension locations. Well, I
thought: I copied the config.ini from the original eclipse
installation, into a new configuration location. However,
this did not help either. Now the plugin.xml still the
same. Do I have to create the plugin.xml by hand???
My plugin.xml has 502 lines.
Unfortunately, there's no way to drop extension locations.
I have the feeling messing around in the plugin.xml file
will cause all kinds of problems.
Now I am really stuck.
How to work with different configurations?
Michael
> no wildcards. you can install naything you want. It may not resolve
> and you may (or may not) see warnings but the system will run.
>
> To the original post. Config.ini is just the bootstrap part of the
> configuration. Alex described how the update configurator was
> discovering all the plugins an installing them. It does this because it
> does not have a plaform.xml file (look in
> configuration/org.eclipse.update). If it doesn't have one of these it
> promiscuously searches all known locations for one.
>
> In your case what you want is two separate configuration locations each
> with a platform.xml that you craft. This can list features, plugins,
> ... By manipulating the policies you can also prevent update
> configurator from scanning and adding more pluigns. See
> http://help.eclipse.org/help32/topic/org.eclipse.platform.do c.isv/reference/misc/update_platform_xml.html
>
>
> Jeff
>
> Alex Blewitt wrote:
>> I don't believe you can use wildcards in the config.ini, no. However,
>> it should be fairly easy to construct such a config.ini dynamically
>> yourself, either as part of the build process or prior to runtime
>> (e.g. via a custom launcher).
>>
>> I'm not sure what happens to the runtime if it tries to install a
>> bundle/fragment that's not valid for that OS; it probably just
>> generates a warning and is otherwise ignored. So you could try having
>> org.eclipse.swt.win32...,org.eclipse.swt.motif... etc.
>>
>> Alex.
--
Michael Scharf
Wind River Systems GmbH
http://www.WindRiver.com
http://MichaelScharf.blogspot.com/
|
|
|
| Re: how to prevent certain bundles from being resolved? [message #75188 is a reply to message #74881] |
Sat, 21 October 2006 09:10 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Michael,
Yes, you have to create platform.xml files by hand. It is not a great
story but it does not have to be traumatic. Basically a "configuration"
consists of a config.ini that tells Equinox how to run and what to
install to boot (the osgi.bundles list). That list typically includes
o.e.update.configurator. The configurator is the thing that
read/writes/manages the platform.xml file. The format/content of
platform.xml is documented here
http://help.eclipse.org/help32/topic/org.eclipse.platform.do c.isv/reference/misc/update_platform_xml.html
Basically you have a "site" entry for each extension location. In each
site you can list features and/or plugins. Rather than listing all your
plugins, hopefully they are listed in features somewhere and you can
just enumerate the features.
Note also that there are some site policy settings you can use to limit
update.configurators rather permiscuous default behaviour of finding and
installing all possible plugins. See the first site in the platform.xml
snippet below.
<config date="1161436030889" transient="false" version="3.0">
<site enabled="true" policy="MANAGED-ONLY" updateable="true"
url="file:some/location/eclipse/">
</site>
<site enabled="true" policy="USER-EXCLUDE" updateable="true"
url="platform:/base/">
<feature id="org.eclipse.rcp" plugin-version="3.2.0.v20060605"
....
The theory behind this model was that installers would be the ones
updating the platform.xml file by adding in sites and features to sites.
It turns out to be a bit cumbersome for normal use and we are looking
at ways of simplifying matters in 3.3.
Hope that helps.
Jeff
Michael Scharf wrote:
> Hi Jeff,
>
> I'm too stupid to get this to run :-(
>
> I have an installation with a few extension locations
> added using the "Product Configuration".
>
> I want to create a new configuration with none
> of the extension location.
>
> I started eclipse with
> -configuration C:\xxxxx
> Some years ago this would have created a virgin
> configuration. With 3.2 it creates a new
> config.ini with essentially one line:
>
> osgi.sharedConfiguration.area=file\:configuration/
>
> The plugin.xml is essentially one line too:
> <?xml version="1.0" encoding="UTF-8"?>
> <config date="1160992704181"
> shared_ur="file:configuration/org.eclipse.update/platform.xml "
> transient="false" version="3.0">
> </config>
>
> Now I see all plugins and extension locations. Well, I
> thought: I copied the config.ini from the original eclipse
> installation, into a new configuration location. However,
> this did not help either. Now the plugin.xml still the
> same. Do I have to create the plugin.xml by hand???
> My plugin.xml has 502 lines.
>
> Unfortunately, there's no way to drop extension locations.
>
> I have the feeling messing around in the plugin.xml file
> will cause all kinds of problems.
>
> Now I am really stuck.
>
> How to work with different configurations?
>
> Michael
>
>
>> no wildcards. you can install naything you want. It may not resolve
>> and you may (or may not) see warnings but the system will run.
>>
>> To the original post. Config.ini is just the bootstrap part of the
>> configuration. Alex described how the update configurator was
>> discovering all the plugins an installing them. It does this because
>> it does not have a plaform.xml file (look in
>> configuration/org.eclipse.update). If it doesn't have one of these it
>> promiscuously searches all known locations for one.
>>
>> In your case what you want is two separate configuration locations
>> each with a platform.xml that you craft. This can list features,
>> plugins, ... By manipulating the policies you can also prevent update
>> configurator from scanning and adding more pluigns. See
>>
>> http://help.eclipse.org/help32/topic/org.eclipse.platform.do c.isv/reference/misc/update_platform_xml.html
>>
>>
>> Jeff
>>
>> Alex Blewitt wrote:
>>> I don't believe you can use wildcards in the config.ini, no. However,
>>> it should be fairly easy to construct such a config.ini dynamically
>>> yourself, either as part of the build process or prior to runtime
>>> (e.g. via a custom launcher).
>>>
>>> I'm not sure what happens to the runtime if it tries to install a
>>> bundle/fragment that's not valid for that OS; it probably just
>>> generates a warning and is otherwise ignored. So you could try having
>>> org.eclipse.swt.win32...,org.eclipse.swt.motif... etc.
>>>
>>> Alex.
>
>
|
|
|
Goto Forum:
Current Time: Sat May 03 17:04:43 EDT 2025
Powered by FUDForum. Page generated in 0.04367 seconds |
Home