Dans Equinox Est-il possible de marquer un groupe OSGi comme démarré à partir de p2.inf?

Question

J'ai une fonction Eclipse qui comprend plusieurs bundles. Je veux dire à p2 de marquer l'un de ces paquets comme démarré lorsque la fonction est installée. Ceci est possible en utilisant les faisceaux propres META-INF/p2.inf comme si,

instructions.configure = markStarted(started: true) 

mais je veux le faire au niveau des fonctions plutôt que le niveau du faisceau (le faisceau en question est un tiers , et je préférerais ne pas le modifier de quelque façon que ce soit, si possible).

Certaines recherches m'ont conduit à this document, ce qui suggère qu'il devrait être possible de déplacer les instructions de configuration vers le fichier p2.inf de la fonction contenant. Je l'ai essayé toutes les choses évidentes comme,

units.0.id = <bundle symbolic name> 
units.0.instructions.configure = \ 
    org.eclipse.equinox.p2.touchpoint.eclipse.markStarted(started: true) 

mais jusqu'à présent, aucun des permutations que j'ai essayé d'effet: comme dans rien ne se passe, le paquet est pas marqué comme démarré et aucune erreur sont signalées).

Les pointeurs seraient les bienvenus. L'est avec Eclipse Equinox Galileo (3.5.2) ... les réponses relatives à Helios seraient également très utiles.

Answer 1

Les "unités #." Les entrées p2.inf créent un nouveau Installable Unit, elles ne modifient pas les autres UI existantes.

Vous devez créer un Installable Unit fragment entier. Le fragment contient les instructions appropriées et se rattache à l'IU de votre bundle. Ensuite, vous devez ajouter une exigence de votre fonctionnalité à cette nouvelle UI.

PDE/Build le fait automatiquement lors de la construction de produits. Vous pouvez voir le p2.inf généré en créant une petite compilation de produit rcp qui a un niveau de démarrage pour votre bundle.
Le p2.inf généré dans une version du produit sera buildDirectory/features/org.eclipse.pde.build.container.feature/product/p2.inf

Voici un exemple que je modifié à partir d'une construction qui définit le niveau de départ pour org.eclipse.equinox.common. Le $version$ sera remplacé par la version de la fonctionnalité à laquelle appartient le p2.inf. Remarquez les "hostRequirements", qui spécifient le bundle dont nous sommes un fragment.

#create a requirement on the IU fragment we are creating 
requires.2.namespace=org.eclipse.equinox.p2.iu 
requires.2.name=configure.org.eclipse.equinox.common 
requires.2.range=[$version$,$version$] 
requires.2.greedy=true 

#create a IU frament named configure.org.eclipse.equinox.common 
units.0.id=configure.org.eclipse.equinox.common 
units.0.version=$version$ 
units.0.provides.1.namespace=org.eclipse.equinox.p2.iu 
units.0.provides.1.name=configure.org.eclipse.equinox.common 
units.0.provides.1.version=$version$ 
units.0.instructions.install=installBundle(bundle:${artifact}); 
units.0.instructions.uninstall=uninstallBundle(bundle:${artifact}); 
units.0.instructions.unconfigure=setStartLevel(startLevel:-1);markStarted(started:false); 
units.0.instructions.configure=setStartLevel(startLevel:2);markStarted(started:true); 
units.0.hostRequirements.1.namespace=osgi.bundle 
units.0.hostRequirements.1.name=org.eclipse.equinox.common 
units.0.hostRequirements.1.range=[3.6.0.v20100503,3.6.0.v20100503] 
units.0.hostRequirements.1.greedy=false 
units.0.hostRequirements.2.namespace=org.eclipse.equinox.p2.eclipse.type 
units.0.hostRequirements.2.name=bundle 
units.0.hostRequirements.2.range=[1.0.0,2.0.0) 
units.0.hostRequirements.2.greedy=false 
units.0.requires.1.namespace=osgi.bundle 
units.0.requires.1.name=org.eclipse.equinox.common 
units.0.requires.1.range=[3.6.0.v20100503,3.6.0.v20100503] 
units.0.requires.1.greedy=false 

Réponses aux questions:

1. 0 de, de 1, 2 de

   Ces chiffres sont quelque peu arbitraires, ils ne servent qu'à séparer un ensemble de propriétés (requires ou units ou autre) de un autre. Le requires ici utilisé un «2» simplement parce que je l'ai copié à partir d'un grand p2.inf qui a été généré par pde.build et j'ai oublié de le changer comme je l'ai fait l'units.0.

2. Est-ce que tout cela est nécessaire?

   Oui. Le deuxième hostRequirements sur le type = bundle est nécessaire. Dans Helios, à l'exception des fragments de traduction, un seul fragment peut être attaché à une UI. Généralement, une UI par défaut est disponible qui définit le niveau de démarrage par défaut pour tous les ensembles osgi. Pour que notre fragment personnalisé soit choisi sur le fragment par défaut, il doit avoir une "spécificité" plus élevée qui correspond au nombre d'exigences satisfaites pour l'hôte.

   Pour "installer"

   units.0.instructions.install = installBundle (paquet: {artefact} $); units.0.instructions.uninstall = uninstallBundle (bundle: $ {artefact}); Les instructions.install et instructions.uninstall se réfèrent aux phases du processus P2. Les installBundle et uninstallBundle se réfèrent à l'installation/désinstallation au sens OSGi. Votre bundle doit être installé dans le système OSGi avant de pouvoir faire quoi que ce soit d'autre. Cela implique essentiellement de l'ajouter aux fichiers config.ini ou org.eclipse.equinox.simpleconfigurator/bundles.info.

   La plupart des installations p2 contiendront déjà une UI de configuration par défaut qui installera et définira le niveau de démarrage par défaut (4) pour les offres groupées. Cependant, actuellement, un seul fragment de configuration peut être appliqué à chaque bundle. Ainsi, lorsque vous ajoutez le vôtre, la valeur par défaut ne s'applique plus à votre bundle.

3. hostRequirements. La page de fragments d'unité installable décrit simplement ce qu'est un fragment sans référence sur la façon de créer un fragment. Il est biefly mentionné sur la page Customizing Metadata, mais pas expliqué.

   Documentation, il y a un tas de choses sur le wiki sous le p2 category. la page sur le touchpoint instructions pourrait être intéressante. Il y a un peu d'aide sur help.eclipse.org, mais en général, je pense que c'est un peu plus avancé que ce qu'il y a de la documentation.