Re: [equinox-dev] AutoStarting Bundles in a Feature Definition

[Andrew Niefer <aniefer@xxxxxxxxxx>]

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
file.

requires.1.namespace=org.eclipse.equinox.p2.iu
requires.1.name=toolingorg.acme.bundle
requires.1.range=[$version$,$version$]
requires.1.greedy=true

units.1.id=toolingorg.org.acme.bundle
units.1.version=$version$
units.1.provides.1.namespace=org.eclipse.equinox.p2.iu
units.1.provides.1.name=toolingorg.acme.bundle
units.1.provides.1.version=$version$
units.1.provides.2.namespace=org.eclipse.equinox.p2.flavor
units.1.provides.2.name=tooling
units.1.provides.2.version=1.0.0
units.1.instructions.install=installBundle(bundle:${artifact});
units.1.instructions.uninstall=uninstallBundle(bundle:${artifact});
units.1.instructions.unconfigure=setStartLevel(startLevel:-1);markStarted(started:false);
units.1.instructions.configure=setStartLevel(startLevel:3);markStarted(started:true);
units.1.hostRequirements.1.namespace=osgi.bundle
units.1.hostRequirements.1.name=org.acme.bundle
units.1.hostRequirements.1.range=[1.0.100.v20090520-1905,1.0.100.v20090520-1905]
units.1.hostRequirements.1.greedy=false
units.1.hostRequirements.2.namespace=org.eclipse.equinox.p2.eclipse.type
units.1.hostRequirements.2.name=bundle
units.1.hostRequirements.2.range=[1.0.0,2.0.0)
units.1.hostRequirements.2.greedy=false
units.1.requires.1.namespace=osgi.bundle
units.1.requires.1.name=org.acme.bundle
units.1.requires.1.range=[1.0.100.v20090520-1905,1.0.100.v20090520-1905]
units.1.requires.1.greedy=false
units.1.requires.2.namespace=org.eclipse.equinox.p2.eclipse.type
units.1.requires.2.name=bundle
units.1.requires.2.range=[1.0.0,2.0.0)
units.1.requires.2.greedy=false

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>

To	equinox-dev@xxxxxxxxxxx
cc
Subject	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
number of
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
feature definition.

Chase

Martin Lippert wrote:
> 
> Hi!
> 
> This is an example that we use for automatically start some of the
> Equinox Aspects bundles after p2 installation:
> 
> instructions.configure = \
>                  setStartLevel(startLevel:4);
\
>                  markStarted(started:
true);
> 
> HTH,
> -Martin
> 
> 
> 
> 
> cwolfing wrote:
>> Hello - Is there a way to use the p2.inf configuration on a feature
to
>> indicate which bundles to mark as started?
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> 
> 

-- 
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
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev