Dans Equinox Est-il possible de marquer un faisceau de OSGi Démarré à partir du p2.inf de sa fonction contenant?

Question

J'ai une fonction Eclipse qui comprend plusieurs faisceaux. Je veux dire p2 à une marque de ces faisceaux 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 faisceau de niveau (le paquet en question est une tierce partie, et je préfère ne pas le modifier en aucune façon, si possible).

Des recherches m'a conduit à ce document qui suggère qu'il devrait être possible de déplacer les instructions de configure au p2.inf de la fonction contenant. J'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. Que rien ne se passe dans le paquet est pas marqué comme commencé et aucune erreur sont signalées)

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

Answer 1

Les "unités. #." p2.inf entrées créer une nouvelle installable Unité , ils ne modifient pas les autres IUs existantes.

Vous avez essentiellement à créer un ensemble installable fragment Unité . Le fragment a les instructions pertinentes et se fixe à UI de votre paquet. Ensuite, vous devez ajouter une exigence de votre fonction à cette nouvelle UI.

PDE / Construire le fait automatiquement lors de la construction des produits. Vous pouvez voir le p2.inf généré en créant une petite version du produit rcp qui a un niveau de départ de votre paquet.
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 I exemple modifié à partir d'une construction qui définit le niveau de départ pour org.eclipse.equinox.common. Le $version$ va se remplacé par la version de la fonction que le p2.inf appartient. Remarquez les « hostRequirements », qui spécifie le faisceau que nous sommes un fragment de.

#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 1'S, de 2

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

2. Tout cela est-il nécessaire?

   Oui. La deuxième hostRequirements du type = paquet est nécessaire. Dans Helios, à l'exception des fragments de la traduction, un seul fragment peut être attaché à une UI. En général, un défaut IU est disponible qui définit le niveau de démarrage par défaut pour tous les faisceaux OSGI. Pour que le notre fragment personnalisé à choisir sur une par défaut, il doit avoir une « spécificité » plus élevé qui est le nombre d'exigences hôtes satisfaits.

   Pour "installer"

   units.0.instructions.install = installBundle (paquet: $ {artifact}); units.0.instructions.uninstall = uninstallBundle (paquet: $ {artifact});

   Le instructions.install et instructions.uninstall se réfèrent à des phases du processus p2. Le installBundle et uninstallBundle se réfèrent à installer / désinstaller dans le sens OSGi. Votre paquet doit être installé dans le système OSGi avant de pouvoir faire quoi que ce soit d'autre. En gros, cela invovles ajouter à config.ini ou org.eclipse.equinox.simpleconfigurator / bundles.info fichiers.

   La plupart p2 contiendra déjà les installations d'une configuration par défaut UI qui installera et régler le niveau de démarrage par défaut (4) pour les lots. Cependant, actuellement un seul fragment de configuration peut être appliquée à chaque faisceau, de sorte que lorsque vous ajoutez votre propre comme celui-ci par défaut ne plus appliquée à votre paquet.

3. hostRequirements. La page fragments Unité installable décrit tout ce qu'un fragment est sans référence sur la façon de créer un. Il est biefly mentionné sur le Personnalisation de la page de métadonnées, mais pas expliqué.

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