2010-06-19 12 views
8

Tengo una función Eclipse que incluye varios paquetes. Quiero decirle a p2 que marque uno de esos paquetes como se inició cuando se instala la característica. Esto es posible mediante los lotes propia META-INF/p2.inf como tal,En Equinox ¿Es posible marcar un paquete OSGi como iniciado desde la función que contiene p2.inf?

instructions.configure = markStarted(started: true) 

pero yo quiero hacer esto a nivel de función en lugar del nivel de paquete (el paquete en cuestión es de terceros , y preferiría no modificarlo de ninguna manera, si es posible).

Algunas investigaciones me han llevado al this document que sugiere que debería ser posible mover las instrucciones de configuración a la función que contiene p2.inf. He intentado todas las cosas obvias como,

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

pero hasta ahora ninguna de las permutaciones que he probado tiene ningún efecto: como en no pasa nada, el paquete no está marcado como iniciado y no se encuentren errores)

Cualquier apuntador sería muy bienvenido. El es con Eclipse Equinox Galileo (3.5.2) ... las respuestas relacionadas con Helios también serían muy útiles.

Respuesta

9

Las "unidades. #." Las entradas p2.inf crean un nuevo Installable Unit, no modifican otras IU existentes.

Básicamente tiene que crear un Installable Unit fragment completo. El fragmento tiene las instrucciones relevantes y se adjunta a la IU de su paquete. Luego, debe agregar un requisito de su función a esta nueva IU.

PDE/Build hace esto automáticamente al crear productos. Puede ver el p2.inf generado al crear una compilación de producto de rcp pequeña que tiene un nivel de inicio para su paquete.
El p2.inf generado en una compilación del producto será buildDirectory/features/org.eclipse.pde.build.container.feature/product/p2.inf

Aquí hay un ejemplo que he modificado producido por una acumulación que establece el nivel inicial de la org.eclipse.equinox.common. El $version$ será reemplazado por la versión de la función a la que pertenece p2.inf. Observe los "requisitos de host", que especifican el paquete del que somos un fragmento.

#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 

Las respuestas a las preguntas:

  1. 0 de hasta un 1 de, de 2

    Estos números son un tanto arbitrarias, que sólo sirven para separar un conjunto de propiedades (requires o units o lo que sea) a partir de otro. El requires aquí usé un '2' simplemente porque lo copié de un p2.inf grande que fue generado por pde.build y olvidé cambiarlo como lo hice con las unidades.0.

  2. ¿Es todo esto necesario?

    Sí. Se necesita el segundo hostRequirements en el paquete type =. En Helios, con la excepción de los fragmentos de traducción, solo se puede adjuntar un fragmento a una IU. En general, está disponible una IU predeterminada que establece el nivel de inicio predeterminado para todos los paquetes de osgi. Para que nuestro fragmento personalizado se elija sobre el predeterminado, debe tener una "especificidad" mayor, que es la cantidad de requisitos de host satisfechos.

    para "instalar"

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

    El instructions.install y instructions.uninstall se refieren a las fases del proceso p2. El installBundle y uninstallBundle se refieren a la instalación/desinstalación en el sentido OSGi. Su paquete debe estar instalado en el sistema OSGi antes de poder hacer cualquier otra cosa. Esto básicamente implica agregarlo a los archivos config.ini u org.eclipse.equinox.simpleconfigurator/bundles.info.

    La mayoría de las instalaciones de p2 ya contendrán una IU de configuración predeterminada que instalará y establecerá el nivel de inicio predeterminado (4) para los paquetes. Sin embargo, en la actualidad, solo se puede aplicar un fragmento de configuración a cada paquete, de modo que cuando agrega el suyo de esta manera, el valor predeterminado ya no se aplica a su paquete.

  3. hostRequirements. La página de fragmentos de unidades instalables solo describe qué es un fragmento sin referencia sobre cómo crear uno. Se mencionó brevemente en la página Customizing Metadata, pero no se explicó.

    Documentación, hay un montón de cosas en la wiki bajo el p2 category. la página en el touchpoint instructions podría ser interesante. Hay alguna ayuda en help.eclipse.org, pero en general, creo que esto es un poco más avanzado de lo que hay documentación.

+0

Parece que hay un poco de magia aquí. ¿Puedes explicar la importancia de los 0, 1 y 2 ... son arbitrarios (en cuyo caso, ¿por qué comenzar con require.2 en lugar de requires.0?) O determinados por el contexto? Además, ¿son necesarios todos estos elementos? Por ejemplo, units.0.instructions.install me parece redundante. Más en general, ¿dónde está documentada esta información? Por ejemplo, usted dice que es la entrada hostRequirements la que especifica de qué paquete se trata, pero en ningún lugar de la página que enlaza con la descripción de los fragmentos de la Unidad Instalable se menciona. –

+0

Solo para asegurarme de haber entendido correctamente la arbitrariedad de la numeración, el significado seguiría siendo el mismo si "requires.2" se reemplazara con "requires.0" en todo; "units.0.provides.1" reemplazado por "units.0.provides.0"; "units.0.hostRequirements.1" reemplazado por "units.0.hostRequirements.0"; "units.0.hostRequirements.2" reemplazado por "units.0.hostRequirements.1"; "units.0.requires.1" by "units.0.requires.0" –

+0

Sí, debería ser equivalente. –

Cuestiones relacionadas