[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] AutoStarting Bundles in a Feature Definition


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