Discussion :

[alt3]

Bonjour,

J'ai développé quelques plugins (non RPC) qui dépendent entre autre de jlex/cup, log4j, et d'autres.
Je passe par un projet Feature pour déployer les plugins et leurs dépendances mais j'ai des erreurs pendant le build de la feature (les dépendances sous formes de jar ne sont pas utilisées pendant la compilation des plugins déployés).

J'ai utilisé un maximum de lib tierces sous forme de plugins mais elle n'existent pas toutes.
D'autre part, il me semble que mes projets sont correctement configurés:
- debuggables,
- je suis passé par un import des libs sous forme de lien symbolique + mise à jour du classpath par plugin.xml dans l'onglet runtime
- le jar référencé est bien coché en utilisation dans l'onglet Build de mes plugin.xml

Qu'aurais-je loupé ?

Merci d'avance pour votre aide.

[alt3]

Bon, on dirait que la bonne manière de faire est de créer un plugin à partir des JAR que je référence.

Par contre je ne trouve pas l'option qui déploie les dépendances avec mes plugins: est-ce possible ?

[targol]

Bonjour,

Pour répondre à la même problématique (nombreux jar dépendants pour notre appli Rcp), nous avons choisi l'option d'un "wrapper" de jars.
Il s'agit d'un plugin qui ne contient aucun code mais dont le but est d'embarquer et de mettre à disposition des autres plugins les jars externes.

Pour cela, on copie (via ant) tous les jars nécessaires dans le sous dossier "deploy-libs" de celui-ci.
Après, il suffit d'aller faire un tour dans l'onglet "runtime" de l'editeur de plugins (celui qui édite à la fois le plugin.xml, le MANIFEST.MF et le build.properties).

Dans la liste "classpath", rajoute tous les jars que tu veux mettre à dispo puis, dans la liste "exported packages", ajoute tous les packages que tu veux mettre à dispo des plugins dépendants. Tu peux même filtrer quels plugins voient quels packages.

Au final, tu devrais avoir dans ton MANIFEST.MF une clé "Bundle-Classpath" avec une liste de jars derrière et une clé "Export-Package" avec tous les packages mis à disposition....

J'espère que ça t'aide.

[alt3]

Bonjour,

Pour répondre à la même problématique (nombreux jar dépendants pour notre appli Rcp), nous avons choisi l'option d'un "wrapper" de jars.
Il s'agit d'un plugin qui ne contient aucun code mais dont le but est d'embarquer et de mettre à disposition des autres plugins les jars externes.

Pour cela, on copie (via ant) tous les jars nécessaires dans le sous dossier "deploy-libs" de celui-ci.
Après, il suffit d'aller faire un tour dans l'onglet "runtime" de l'editeur de plugins (celui qui édite à la fois le plugin.xml, le MANIFEST.MF et le build.properties).

Dans la liste "classpath", rajoute tous les jars que tu veux mettre à dispo puis, dans la liste "exported packages", ajoute tous les packages que tu veux mettre à dispo des plugins dépendants. Tu peux même filtrer quels plugins voient quels packages.

Au final, tu devrais avoir dans ton MANIFEST.MF une clé "Bundle-Classpath" avec une liste de jars derrière et une clé "Export-Package" avec tous les packages mis à disposition....

J'espère que ça t'aide.

Merci de ta réponse.
Je ne la tenterai cependant pas, puisque je m'en suis sorti en créant un plugin contenant les jar dont j'ai besoin.

Ainsi, les dépendances sont naturellement gérées par Eclipse comme s'il s'agissait de plugin, ce qui lui semble plus naturel.

J'en reviens à ma problématique du moment, qui est maintenant de déployer le tout sous Hudson, pour attaquer mes plugins en shell (je ne livre et ne teste que cette partie des plugins). D'où mon questionnement quant à la capacité d'Eclipse à exporter mes plugins + leurs dépendances.

[Mickael_Istria]

Au final, tu devrais avoir dans ton MANIFEST.MF une clé "Bundle-Classpath" avec une liste de jars derrière et une clé "Export-Package" avec tous les packages mis à disposition....

Petit bonus qui peut sauver la vie lors de build incrémentaux: Lorsqu'on a un bundle de ce type, qui wrappe des jars, il est de tres bon gout de mettre un petit Bundle-Shape: dir dans le Manifest, et de mettre unpack="true" pour ce bundle dans les feature.
Sinon, c'est le bug 111238 qui guette...