Certaines idées que j'avais:
Je m'en fiche de toutes ces fonctionnalités intelligentes de mon produit, mais les utilisateurs n'utilisent pas du tout le mécanisme de mise à jour intégré.
Je voudrais donc embrasser (c'est-à-dire: juste pour démarrer) et ajouter un support plus avancé en cas de besoin .
J'ai demandé cela sur Eclipse Forums < / a>, mais pas de réponse, alors vous en seriez vraiment reconnaissant pour certaines illumination.
Aussi, n'hésitez pas à me corriger sur les hypothèses - je viens de lire le P2 Docs , qui semblent déroutant parfois.
Merci!
osgi.bundles=org.eclipse.equinox.commoun@2: start, org.eclipse.update.configurator@3: Démarrer, org.eclipse.core.Runtime @ Démarrez
3 Réponses :
Peut-être Ce vous aidera (tirer dans le noir)? J'ai trouvé cela lors de la mise à niveau de mon installation Eclipse sur Galileo et d'essayer de conserver mon installation de plug-in Flex.
Merci pour cela, mais c'est un cas d'utilisation différent - il est utile de partager les emplacements de plugin à l'aide de liens. Je ne voudrais pas introduire de telles indirections dans mon produit hors de la boîte.
Oui, je ne suis pas un promoteur Eclipse mais je pensais que je prendrais un coup de feu. Bonne chance.
Même si cela ne répond pas complètement à ce que vous êtes après, vous pouvez spécifier dans un qui spécifie à P2 pour surveiller tout répertoire de votre choix de détecter les plugins dedans. Une autre source d'idée pourrait être cet article: Composition et mise à jour des distributions Eclipse personnalisées Il n'est pas difficile de créer un produit basé sur une fonctionnalité qui inclut ces choses et de faire un Construction de produits pour finir par quelque chose comme ceci:
Remarque: le concept de réconciliation est détaillé dans le Eclipse Wiki . Pour certaines installations d'éclipse, il existe une notion d'installation partagée - ceci peut être dans le cas d'un système Linux dans lequel un ensemble de logiciels de base est installé via des packages (peut-être des toupies), ou peut-être être dans un Le déploiement Maya où les profils partagés sont définis dans un serveur central. Une partie de ce mécanisme est le Cadrage de la récupération des dropins . Bien que Bug 251561 illustre, il n'est pas conseillé de mettre trop beaucoup de plugins là-bas. eclipse.ini (comme celui que je Décrivez ici ):
< HR>
Dans les deux cas,
Acclamations pour cela. Donc, fondamentalement, c'est la voie à mettre en œuvre des «répertoires surveillés» (2e alternative dans mon Q). J'ai vu cette option mentionnée sur divers blogs, mais n'était pas clair si cela fait la bonne chose. Pouvez-vous ajouter plusieurs DIRS là-bas? Pouvez-vous ajouter le plugin dirson lui-même? Est-ce documenté du tout? Rien dans le système d'aide, ni sur le wiki P2 (qui semble avoir des centaines de pages, mais très peu est à jour ou concret au-delà de la rachette sur la manière dont le système est cool. En principe :-) Quoi qu'il en soit Essayez-le - merci un million pour vos indices.
Aussi, pourquoi utiliser le -D vmarg, ce qui ne l'ajoute pas dans config.ini? Selon la ligne directrice, Eclipse.ini est destiné aux paramètres généraux de VM - tout le reste devrait entrer dans la configuration / config.ini. Voir la "ligne inférieure" help.eclipse.org/galileo/index.jsp?topic=/...
@inger: bon point, mais j'ai toujours modifié un fichier de configuration: l'éclipse.ini. Il est toujours distribué avec Eclipse et j'évite de devoir modifier plusieurs fichiers.
@Vonc, merci pour les ajouts supplémentaires à votre réponse, en particulier le lien vers ce bogue - qui dit essentiellement Les dropins sont déjà obsolètes ( bugs.eclipse.org/bugs/show_bug.cgi?id=251561#C18 ). Incroyable..
@Vonc, également le lien vers ce blog de Andrew Niefer est intéressant, mais n'est pas vraiment pertinent pour la question, n'est-ce pas? Notez que je me fiche de la mise à jour de la mise à jour, du moins pas avant que je ne puisse simplement exécuter mon fichu produit (sans réécrire mon système de construction).
Vous pouvez modifier votre fichier configuration / config.ini à pas utiliser l'org.eclipse.equinox.simpleconfigurateur (qui fait la configuration basée sur P2) et utilise plutôt l'org.eclipse.update. Configurateur qui est la voie vieille école de simplement configurer tout ce qui se trouve dans le répertoire des plug-ins. Cela devrait vous donner ce que vous voulez.
Je viens de venir à la même conclusion - ce qui semble fonctionner finalement. Mes essais antérieurs ont échoué à ce sujet: j'ai eu des NCDFES parasites et des accidents mystérieux - ce qui me conduit à croire qu'il n'est pas possible de "retourner à la vieille école". Maintenant que j'ai commencé à partir de zéro (nettoyant probablement le problème racinaire réel de certains autres faisceaux manquants), les choses ont l'air beaucoup mieux :) Quoi qu'il en soit, merci de confirmer cela! J'étais sur le point d'ajouter une réponse pour cela .. Cependant, certains paquets Eclipse (E.g JDT) exigent explicitement le facturateur SimpleConfigurateur (que je trouve un peu étrange). Saisissez-vous que la vieille école va bien avec ceux-ci?
Je ne sais pas ce que vous entendez par un paquet nécessitant le SimpleConfigurateur. Pour autant que je sache, c'est une fonction de l'environnement (comme spécifié dans la configuration), pas quelque chose qui peut être spécifié par un paquet. Pouvez-vous élaborer sur ce que vous voulez dire ici?
Sûr. Il y a paquet org.eclipse.équinox.simpleconfigurator_1.0.200.v20090831.jar et un autre dépend de celui-ci par requis-Bundle dans le manifeste.mf: org.eclipse.jdt.junit_3.6.0.v20091026-1200.jar.
Ah je comprends maintenant. C'est bien parce que les trucs JDT Junit doivent faire référence à quelque chose de SimpleConfigurateur qui n'est pas un problème, car le paquet sera toujours présent, mais c'est complètement indépendant du processus utilisé pour effectuer la configuration initiale.
Il suffit d'ajouter quelques sources d'informations concernant le répertoire P2 Dropins, n Réponse à votre commentaire.