This is possible with something as shown
below. This will result in a new requirement being added to the generated
feature.group metadata for your feature. The requirement is on an
IU named "toolingorg.acme.bundle". This IU is a fragment
(also commonly called CU for configuration unit), it's host is com.acme.bundle.
The rest of the properties generate that toolingorg.acme.bundle CU
(the $version$ will be replaced with the version of the feature).
Start level and installation actions
are generally delivered as CU fragments instead of in the bundle metadata
directly. You need to be careful because currently a bundle IU can
only have one fragment CU attached to it. If there is more than one
CU fragment available, it is unpredictable which one wins.
This is the mechanism that pde/build
uses to generate default product start levels for you. Except in
that case instead of the p2.inf being with a feature, it is with the .product
cwolfing <chase.wolfinger@xxxxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx
05/18/2009 05:28 PM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Re: [equinox-dev] AutoStarting Bundles
in a Feature Definition
Hi Martin - I saw this example and it works when I have access to the
contained bundle's META-INF. The issue I have is that there are a
cases where I do not have access to the contained bundle's META-INF (these
are prepackaged bundles) and I would like to autostart the bundles during
Martin Lippert wrote:
> This is an example that we use for automatically start some of the
> Equinox Aspects bundles after p2 installation:
> instructions.configure = \
> cwolfing wrote:
>> Hello - Is there a way to use the p2.inf configuration on a feature
>> indicate which bundles to mark as started?
> equinox-dev mailing list
View this message in context: http://www.nabble.com/AutoStarting-Bundles-in-a-Feature-Definition-tp23604530p23605733.html
Sent from the Equinox - Dev mailing list archive at Nabble.com.
equinox-dev mailing list