Eclipse, Now You Can ! 21 octobre 2008 à Paris, Trocadéro

Je tiens à informer la toile de l'événement Eclipse Now You Can qui se déroulera le 21 octobre 2008 à Paris au Trocadéro. Cet événement est organisé par la société Geensys (anciennement TNI-Software) pour la 3ème année consécutive. L'inscription en tant que participant est gratuite et les intervenants principaux sont des acteurs majeurs de la communauté Eclipse.

C'est un symposium sur le thème de la sphère Eclipse.

Qu'est ce qu'un Symposium ?
C'est un congrès, un rassemblement autour d'un thème particulier: Eclipse en l'occurrence. Contrairement aux conférences, ce n'est pas uniquement des présentations sur un sujet donné, mais ce sont aussi des échanges, des débats et des discussions. Le groupe des participants est hétérogène par ses connaissances et ses expériences sur le sujet; on y retrouve novices, confirmés et experts. Chaque participant peut intervenir à sa guise en respectant de simples règles de courtoisie. Cela apporte de la richesse à la présentation et beaucoup d'interaction entre les participants, la difficulté étant de canaliser et d'animer les groupes.

Qu'est ce que la sphère Eclipse ?
La sphère Eclipse regroupe tous les projets qui gravitent autour d'Eclipse. Ce sont donc les projets de la communauté Eclipse ainsi que tous les projets qui s'interfacent avec ces derniers. Par exemple, le projet BIRT fait partie intégrante des projets de la communauté Eclipse et le projet subclipse est un plugin pour Eclipse réalisé en dehors de la communauté (pour le moment?).

Durant cet évènement, différents thèmes seront abordés lors de plusieurs "présentations".
Les thèmes autours d'Eclipse sont les suivants:

• La productivité
• La collaboration
• Une plate-forme outils
• IHM orienté métier
• La sécurité

Aie... Le choix risque d'être compliqué. Même si les thèmes de la plate-forme outils, de la collaboration et de la sécurité m'intriguent un peu plus. (Qui a dit que ma productivité et mes IHMs auraient besoin d'un coup de pouce ?)

De toute façon, tant que le programme complet n'est pas publié, il est difficile de prévoir quels vont être les thèmes clés. Alors c'est dans l'attente qu'on rafraîchit frénétiquement la page du programme qui l'annonce pour début septembre.

L'équipe qui organise cet évènement est dès plus rigoureuse, pour preuve, près d'un an après avoir échangé quelques mails avec un organisateur, j'ai été recontacté pour m'informer de l'ouverture des inscriptions. Certains diront que c'était juste pour me vendre un stand, je rétorquerai que c'est du travail bien fait ! De plus, j'ai eu de très bons échos de l'édition précédente et c'est ce qui me pousse à y m'y intéresser cette année.

Mon employeur, Empeiria, SSII sur la métropole lilloise, a décidé de permettre à certains des collaborateurs de participer à cet évènement. C'est une excellente manière de se tenir informer de l'actualité dans la sphère Eclipse car, à part internet avec les flux RSS et le carnet d'adresse ,il est difficile de savoir qu'elle est la mouvance actuelle dans ce domaine. De plus, c'est la possibilité d'échanger directement avec des pointures afin d'obtenir des informations et des réponses à nos questions. Et pour finir, c'est aussi l'occasion de rencontrer de futurs clients et d'hypothétiques partenaires et ça, c'est la cerise sur le gâteau...

J'espère que cet article fera naître en vous un intérêt sans précédant pour la sphère Eclipse et cet événement : Eclipse Now You Can !

Qu'en pensez-vous ? Comptez-vous y participer ? Donnez votre avis concernant cet événement !

Mise en place de Maven sur des plugins Eclipse RCP

On n'a plus besoin de vanter les mérite de l'utilisation de maven et de l'intégration continue car ils ont fait leur preuves sur des applicatifs conséquents et cela commence être intéressant de les mettre en place même sur des "petits" projets.

Il est maintenant possible de gérer des projets type plugins Eclipse RCP avec Maven 2 et quelques plugins tierces. Certains diront "Et alors, on pouvait pas avant ?" Eh bien NON ! Enfin, pas depuis bien longtemps...

Environnement technique : Maven 2.0.9, Eclipse 3.3, utilisation d'une target platform, plugin Maven pour Eclipse 0.9.5

Alors tout n'est pas encore parfait mais ça vaut le détours !

Prenons un plugins Eclipse RCP et ajoutons lui des dépendances vers des projets type Maven 2. Par exemple, si votre plugin Eclipse RCP est le client pour un serveur applicatif distant et si des classes java doivent être communes au client et au serveur, alors il est possible d'ajouter certains projets comme dépendances du plugin RCP au sein du fichier pom.xml comme on le ferait pour un projet Maven 2 "normal".

Le fait d'ajouter ces projets en dépendance permet d'utiliser ses classes dans le plugin mais un soucis persiste lors de l'exécution du plugin, les jars dépendants ne se trouvent pas dans le classpath. Heureusement une commande maven existe pour y remédier: mvn eclipse:eclipse mais celle ci fonctionnera uniquement si le fichier pom.xml aura été modifié en ajoutant l'équivalent des balises suivantes:

<build>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>process-sources</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>
${basedir}
</outputDirectory>
<overWriteReleases>false</overWriteReleases>
<overWriteSnapshots>
false
</overWriteSnapshots>
<overWriteIfNewer>true</overWriteIfNewer>
<includeScope>compile</includeScope>
<excludeTypes>pom</excludeTypes>
<!--
<classifier>sources</classifier>
<failOnMissingClassifierArtifact>
false
</failOnMissingClassifierArtifact>
-->
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<configuration>
<filesets>
<fileset>
<directory>${basedir}</directory>
<includes>
<include>*.jar</include>
</includes>
<followSymlinks>false</followSymlinks>
</fileset>
</filesets>
</configuration>
</plugin>
<plugin>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<pde>true</pde>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>pde-maven-plugin</artifactId>
<version>1.0-alpha-2-SNAPSHOT</version>
<extensions>true</extensions>
<!-- Custom lifecycle configuration -->
<configuration>
<eclipseInstall>C:/eclipse</eclipseInstall>
<pdeProductFilename>avecMaven.product</pdeProductFilename>
<pdeBuildVersion>3.3.2.R331_v20071019</pdeBuildVersion>
<buildProperties>
<base>C:</base>
<baseLocation>C:/target</baseLocation>
<buildDirectory>target/build.directory</buildDirectory>
</buildProperties>
</configuration>
<!-- Also bind to mvn clean -->
<executions>
<execution>
<id>clean-pde</id>
<phase>clean</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

Pour que cette version 1.0-alpha-2-SNAPSHOT du pde-maven-plugin soit trouvée, il vous faudra ajouter un pluginrepository dans votre settings.xml :

<pluginRepository>
<id>codehausSnapshots</id>
<name>Codehaus Snapshots</name>
<releases>
<enabled>false</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
<url>http://snapshots.maven.codehaus.org/maven2</url>
<layout>default</layout>
</pluginRepository>

Ou bien ajouter ce repository directement dans votre pom.xml...

Cette version du plugin a le mérite de fonctionner avec eclipse 3.2 et 3.3 mais si seul Eclipse 3.2 vous intéresse, utilisez la version 1.0-alpha-1-SNAPSHOT et ce repository est alors inutile.

Pour réussir à construire le projet par Maven, il faut ajouter un répertoire buildConfiguration à la racine du projet. Puis dans ce répertoire, copier coller le fichier build.properties du répertoire eclipse/plugins/org.eclipse.pde.build_*/template/headless-build
Une fois ce fichier copier, il faut modifier certaines de ces propriétés :

product=avecMaven.product
archivePrefix=avecMaven
configs=win32,win32,x86
buildDirectory=target/eclipse.build
buildId=withMaven
base=C:/target
baseLocation=C:/target/eclipse
pluginPath=.

Ce fichier permet de spécifier comment faire le build headless, comment générer l'application en somme.

Il est important d'être sensibilisé à l'utilisation d'une target platform dans Eclipse: http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tools/preference_pages/target_platform.htm
Très pratique pour builder ses plugins dans des versions différentes de la platforme eclipse de développement utilisée ou pour paramétrer les plugins utilisés.

Ajouter le fichier customBuildCallbacks.xml à la racine du projet, fichier que l'on peut trouver ici dans le répertoire
eclipse\plugins\org.eclipse.pde.build_*\templates\plugins

Ajouter customBuildCallbacks=customBuildCallbacks.xml au fichier build.properties à la racine du projet (ne pas confondre avec le build.properties de buildConfiguration)

Modifier le fichier customBuildCallbacks.xml comme suit:

<target name="post.gather.bin.parts">
<copy todir="${target.folder}">
<fileset dir=".">
<include name="*.jar"/>
</fileset>
</copy>
</target>

Le but de cette modification étant de permettre l'export (la génération) du product dans Eclipse via l'assistant. Si cette étape est n'est pas effectuée, l'export ne fonctionnera plus. Cele permet de recopier l'ensemble des jars à la racine du projet dans le répertoire de travail de la génération, à la racine également. Ainsi les dépendances seront présentes au runtime... Cela évite de devoir réaliser une build de l'application via maven (mvn install) à chaque fois que l'on souhaite générer l'application... tout reste possible dans Eclipse.


A noter:
-Le projet plugin doit être dans un répertoire "plugins" et non directement dans le workspace pour des raisons assez obscures quu ne seront pas détaillées ici.
-Il reste des points noirs dans l'utilisation de maven avec des plugin RCP (product) et ce même après être passé sur Eclipse 3.3, m2eclipse 0.9.5 et maven 2.0.9 ! Par exemple, si un projet en dépendance maven est modifié (ajout de classe, de méthode...), le plugin sera incapable de voir ces modifications automatiquement, il faudra builder le projet modifié (mvn install) et relancer la commande mvn eclipse:eclipse sur le plugin... assez rébarbatif non ?

Sources: http://aspsp.blogspot.com/2008/02/maven-eclipse-rcp-product-build-at-last.html

Empeiria: SSII sur la métropole Lilloise

Actuellement en poste en tant qu'ingénieur d'études et développement au sein d'Empeiria, SSII sur la métropole Lilloise qui a bientôt 4 ans d'existence, il est grand temps que je m'exprime un peu à ce sujet: Empeiria !

Pas simple d'écrire un billet sur la société pour laquelle on travaille actuellement mais c'est quelque chose qui me tient à cœur, c'est l'occasion d'écrire ma pensée pour la partager et la figer sur la toile.

Empeiria fut créée en 2004 par deux collaborateurs de longue date aux compétences complémentaires et dont le réseau peut faire pâlir certains de jalousie. Ces atouts sont à l'origine de sa réussite ou plutôt de la place que la société tient actuellement sur le marché IT de la métropole Lilloise.

Attention il faut prendre tout ça avec objectivité car de part sa taille, on ne peut pas prétendre qu'Empeiria soit un acteur majeur sur la région nord et qu'elle régie la pluie et le beau temps mais dans certains domaines on peut dire à présent qu'Empeiria est un incontournable, un sérieux challenger et un leader.

Dans le sillage de cette création, et fort d'expériences réussies avec d'anciens collaborateurs, des recrutements piliers ont été réalisés afin de doter rapidement la structure de profils expérimentés pour canaliser, former, suivre et motiver les troupes. Des troupes qui se composent de profils plutôt jeunes (25-35 ans) et dont la formation et les aptitudes permettent de s’intégrer pleinement dans des projets à haute teneur en technicité et aux processus métiers complexes.

Sur cette base, l'équipe tente d'ériger un édifice digne de la signification du mot Empeiria qui est "Expérience" en grec. Suivant plusieurs axes les troupes s'articulent. Tout d'abord, il faut appréhender les métiers des clients pour être force de proposition et devenir l'accompagnateur privilégié, celui qui est systématiquement consulté. En parallèle, il est primordial de se constituer un pool de clients pour lesquels il va être possible de réaliser des missions diverses de consulting, d'architecture, de développement et d'assistance à maitrise d'ouvrage par exemple.

Avec le contexte économique du secteur IT on pourrait croire à une progression fulgurante de la masse salariale afin de répondre à la forte demande des clients mais il n’en est rien. En effet, une politique « élitiste » n’est pas compatible avec des embauches par dizaines et le marché de l’emploi IT rend très difficile de trouver des profils susceptibles d’être recrutés. Il faut absolument éviter les travers du service informatique qui pousse certaines sociétés à se transformer en loueur de viande, celles la même qui ternissent l’image qu’ont les SSII auprès des JD.
L’objectif premier est de constituer une équipe performante avec un pool de clients satisfaits et non d’atteindre (trop) rapidement un effectif de 50 avec tous les problèmes que cela peut poser. Vous l’aurez compris, chez Empeiria on privilégie la qualité !

Voilà pour le tableau, mon tableau. Passons aux détails.

Mon expérience chez Empeiria est très positive puisque en peu de temps (<2ans) j'ai pu passer du niveau de novice à un niveau intermédiaire en nouvelles technologies J2EE et à un niveau d'expert dans des domaines/outils spécifiques. Le contrat de départ a toujours été tenu, j'ai signé chez Empeiria pour évoluer dans l'environnement des nouvelles technos et j'ai été servi !

J'ai choisi comme premier employeur une entreprise jeune et petite de part son nombre de collaborateurs par rapport aux mastodontes concurrents de la place et ce n'était pas sans raison. J'avais le sentiment qu'en évoluant au sein d'une structure à taille humaine, il serait plus facile de faire des taches diverses et je ne me suis pas trompé sur ce point ! J'en suis certain, chez Empeiria j'ai pu m'atteler à la réalisation de taches qu'on n'aurait jamais pu me confier au sein d'une lourde structure.

L'inconvénient majeur de ce choix reste la sensation que les moyens mis à disposition sont moindre comparés aux connaissances et amis évoluant dans de grandes structures. Budgets, voyages, CE, sport, structure, organisation, salaires et projets peuvent paraître en dessa des équivalents chez les mastodontes... Cela peut être particulièrement frustrant par moment, mais la considération qu'on nous porte dans une entreprise comme Empeiria est bien plus intéressante puisque nous ne sommes pas réduits à un simple matricule, notre voix compte et elle a même un poids important dans l'entreprise !

Chez Empeiria, je suis venu chercher l'expérience dans les NTIC et c'est sûrement la meilleure école dans ce domaine. Maintenant, je vais devoir négocier mon premier virage de carrière, le tout étant de tourner dans la bonne direction tout en manœuvrant au sein de la même structure, Pourquoi changer une équipe qui gagne ?! Consultant NTIC, Chef de projet fonctionnel ou technique, Responsable d'application... la suite dans le prochain épisode...

Optimisation de la mémoire de la JVM pour Eclipse

En voila un sujet qui fache !! La mémoire utilisée par Eclipse. Et c'est légitime que ce sujet déchaine les passions tant il est important de se pencher sur ce problème pour augmenter la productivité des utilisateurs eclipse.

En effet, avec une configuration par défaut, Eclipse est parfaitement adapté pour des projets simple de taille moyenne diront nous, cad sans dépendances complexes, sans avoir besoin de 1000 et 1 plugins et frameworks en tout genre.

Dès qu'il sagit de developper dans un environnement projet complexe (+ de 10 projets, + de 5 frameworks, RCP + WTP + Hibernate + Spring + Junit + BIRT + etc...) une configuration adaptée s'impose ! Car sinon on frole le drame ! Un environnement de développement instable et une machine qui "rame" comme jamais...
Symptomes: Des temps de chargement, de lancement, de build, de compilation ou de déploiement extrèmement longs et surtout une floppée de messages d'erreurs désagréables indiquant grossomodo qu'Eclipse manque de mémoire et vous incitant à redémarrer Eclipse (et la JVM par la même occasion).
Et quand on voit des popup "Eclipse need more memory... Do you want to exit the workbench now ? Yes. No." ou des OutOfMemoryException toutes les 2 heures d'utilisation, il y a de quoi s'arracher les cheveux !!!
Car redémarrer Eclipse implique premièrement d'arreter la tache en cours, d'attendre 2 minutes qu'il redémarre puis accessoirement de relancer le serveur d'application en cours (environ 2 minutes) et de redémarrer le client RCP puis de se remettre dans la configuration avant le re-démarrage "forcé"... Environ 5 minutes de perdu seulement diront certains... mais a raison de 4 fois par jour, ca représente 20 minutes minimum par développeur au sein d'un équipe ! Charge non négligeable AMHA !

Premièrement, il n'y a pas de secret, dans une configuration complexe il faudra un minimum de 1Go de RAM, 2Go de préférence voir 3 à 4Go pour les plus gourmands ! (Ceux qui font de la médélisation UML + des jeux en LAN + Eclipse...) Sans oublier une machine performante tant au niveau processeur (Intel Core 2 Duo / AMD Athlon 64) que pour le reste...

Deuxièment, le lanceur Eclipse (raccourci ou bat ou cmd) doit comporter des arguments spécifiques à la JVM pour paramètrer l'utilisation de la mémoire vive. Pour cela on peut ajouter le paramètre "-vmargs" suivi de propriétés à passer à la machine virtuelle java.

Pour info, dans "vmargs" on trouve "vm" soit "virtual machine" et "args" soit "arguments"... rien de bien compliqué.

Ensuite les propriétés que l'on peut passer à la machine virtuelle dépendent de votre configuration matérielle et de votre utilisation d'Eclipse... Voici des préconisations qui correspondent à un besoin particulier (le mien)... à vous d'adapter et de tester si cela vous convient au mieux ou pas.

On a pour habitude d'utiliser la propriété "-Xmx256m" pour augmenter la mémoire maximum utilisable par la JVM (Mx = Max et 256m = 256Mo de mémoire) mais il y est des cas ou cela ne suffit pas comme vu ci dessus.

Il est aussi possible de spécifier à la JVM la mémoire minimum allouée par la propriété "-Xmx256m" par exemple.

Et pour finir on peut imposer la taille du permGen Space* avec les propriétés "-XX:PermSize=64m" et "-XX:MaxPermSize=64m" par exemple, respectivement la taille par défaut allouée pour le permGen Space et sa taille maximum. (* terme défini et expliqué à la fin de cet article)

EDIT: Après étude, il faut ajouter "-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled" à la liste des paramètres afin d'autoriser le garbage collector à décharger des classes dynamiquement et de nettoyer les objets...

Toutes ces propriétés combinées permettant d'optimiser la gestion de la mémoire par la JVM en charge de faire fonctionner Eclipse ! Ce ne sont pas les seules existantes... mais les seules dont on parle dans cet article.

Voici quelques préconisation fonction de la mémoire RAM de votre machine.

Pour 512Mo de Ram: -vmargs -Xms256m -Xmx256m -XX:PermSize=64m -XX:MaxPermSize=64m -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

Pour 1Go de Ram: -vmargs -Xms512m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

Pour 2Go de Ram: -vmargs -Xms768m -Xmx768m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

Après, n'ayant pas testé les configurations supérieures à 2Go, il vaut mieux ne pas se mouiller ! Chacun son opinion sur la question... on a tous des sensibilités différentes quand aux réactions de sa machine.

Qu'est ce que le heap space de la JVM:
Les propriétés -Xms768m et -Xmx768m permettent de spécifier la taille du heap space de la JVM, la taille de la mémoire utilisée pour faire vivre les objets java, la taille du dépot où sont stockés les objets en vie, les objets morts et la mémoire libre. C'est le Garbage Collector (GC) de la JVM qui s'occupe de nettoyer tout ca en fonction de la taille allouée à la mémoire. Un objet inutilisé (aucun pointeur (variable) qui y fait référence) est théoriquement supprimé de la mémoire par le GC quand celui ci se charge de nettoyer la mémoire.

Qu'est ce que le permGen space de la JVM:
Spécifique à la JVM Sun, cette zone mémoire contient tout ce qui n'est pas géré par le GC; tout ce qui est relatif au classes (leur structure: méthodes, champs, annotations...), les champs static, les chaines littérales... On spécifie le permGen space avec les propriétés -XX:PermSize=256m et -XX:MaxPermSize=256m par exemple. Plus on a de classes différentes plus il faut augmenter la taille de cette zone mémoire.

-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled ?

Ressources:
http://www.eclipsezone.com/eclipse/forums/t61618.html
http://edocs.bea.com/wls/docs61/perform/JVMTuning.html
http://www.developpez.net/forums/showthread.php?t=438282
http://java.sun.com
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html
http://java.sun.com/docs/hotspot/HotSpotFAQ.html
http://java.sun.com/performance/reference/whitepapers/6_performance.html
http://wiki.eclipse.org/FAQ_How_do_I_increase_the_permgen_size_available_to_Eclipse%3F
etc...

Eclipse-BuddyPolicy: registered et Eclipse-RegisterBuddy: com.provider.team.project

Eclipse-BuddyPolicy: registered et Eclipse-RegisterBuddy: com.provider.team.project

Aie cet article commence directement par des insanités de configuration... On va tenter d'expliquer tout ça !

Le but étant de répondre à la question : comment configurer les plugins eclipse pour permettre à un plugin d'accéder aux "classpath" d'un autre plugin qui est dépendant du premier plugin.

Si vous avez un plugin 1 et un plugin 2 avec le plugin 1 qui dépend du plugin 2 et par exemple un accès aux ressources du plugin 1 par le plugin 2... oui oui c'est incompréhensible mais c'est possible comme situation !

Par exemple, en ce qui concerne la gestion des fichiers ressources. Vous avez une classe Bundle1 dans le plugin 1 qui se charge d'accéder au fichier bundle1.properties se trouvant aussi dans plugin 1. Cette classe étend AbstractBundle dans le plugin 2 qui est un facilitant pour coder des classes d'accès aux fichiers ressources. Toutes les méthodes d'accès au fichier de ressource se trouvent dans AbstractBundle et pourtant le plugin 2 n'a pas accès aux ressources du plugin 1 car la dépendance va dans l'autre sens... Et donc pendant l'exécution vous avez des erreurs types filenotfound ou autre.

On peut aussi très bien avoir le même problème pour des accès à des classes à la place des fichiers ressources et le problème est le même. Un plugin ne sait pas accéder au classpath des plugins qui dépendent de lui, il faut le configurer pour cela.

Dans ce cas précis, il faut spécifier au plugin 1 quels sont les plugins qui sont autorisés en ajoutant dans son MANIFEST.MF la ligne suivante:

Eclipse-RegisterBuddy: com.provider.team.plugin2

Avec com.provider.team.plugin2 qui correspond à l'ID du plugin 2.

Puis dans le MANIFEST.MF du plugin 2 il faut spécifier la politique de gestion du classloading en ajoutant la ligne:

Eclipse-BuddyPolicy: registered

Ce qui signifie que seuls les plugins s'enregistrant comme autorisant le plugin 2 à accéder à leur classpath seront accessibles par le plugin 2... Ouf !

Certains diront qu'il suffit de mettre une dépendance du plugin 2 vers le plugin1 pour résoudre le problème mais les dépendances cycliques ne sont pas recommandées et surtout ce n'est pas forcément possible car le plugin 2 peut très bien être un plugin de type framework/utilitaire (log4j, spring, hibernate etc...) et on ne va pas modifier une plugin de ce type pour lui spécifier tous les plugins auxquels il peut accéder.

Références:
http://wiki.improve.fr/wiki/moni/trucs
http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html
http://www.ibm.com/developerworks/library/os-ecl-osgi/index.html (Buddy class loader options)
et Google :D

(partie 2) Intégration de Maven dans un projet Java J2EE Hibernate/Spring/Eclipse RCP: pas une mince affaire mais une bonne affaire tout de même !

Intégration de Maven dans un projet Java J2EE Hibernate, Spring, Eclipse RCP: pas une mince affaire mais une bonne affaire tout de même ! (partie 2)

Voici la suite de l'article concernant l'utilisation de Maven avec WTP d'Eclipse.

Le but étant de trouver une solution pour utiliser à la fois Maven et ainsi bénéficier de l'avantage de la gestion de la configuration des dépendances tout en restant WTP "compliant" et ainsi être capable de debugger le serveur dans l'environnement Eclipse.

En fait c'est assez simple, vous prenez votre projet "assembly" maven, celui qui vous permet via maven de générer votre archive web, votre war par exemple et vous exécutez la commande suivante dans son répertoire :

mvn -Dwtpversion=1.0 eclipse:eclipse

Bien entendu vous remplacez "1.0" par R7, 1.5 ou 2.0 en fonction de votre version WTP.

Après ça, un répertoire .settings va être créé à la racine du projet avec un fichier ".component" dans notre cas (version 1.0). Dans ce fichier on va retrouver toutes les dépendances du projet que ce soit les librairies ou les projets dont il dépend. Toutes les dépendances apparaissent sous forme de jars situés dans le dépôt maven.

Problème: en mettant les projets dépendants via leur archive jar sous maven, il n'est pas possible de les modifier en debug sous eclipse. Il faut supprimer les références vers les projets dépendants dans le fichier ".component" pour ne laisser que les librairies utilisées. Ensuite il faut faire un clic droit sur le projet et sélectionner "properties" puis dans la fenêtre qui apparaît il faut cliquer sur "modules dependencies". La prochaine fenêtre permet de sélectionner les projets dépendants, il faut alors cocher tous les projets que vous avez supprimé du fichier .component à l'étape précédente et terminer en validant en cliquant sur OK.

Après quoi il faut vérifier que le fichier .component contient bien les nouvelles dépendances vers les projets fraîchement supprimés puis ajoutés, mais cette fois avec des dépendances de type module ! (et non jar)

Après quoi, il faut ajouter un serveur à WTP si ce n'est pas déjà fait puis ajouter le projet ainsi modifié au serveur WTP... puis le lancer, mettre des points d'arrêts et s'y rendre, modifier le code source "en live", sauvegarder la classe modifiée et prendre soin de builder via eclipse (Ctrl + B ou build auto) et là: contempler le debugger d'Eclipse continuer de debugger normalement.

En fait il n'y a rien de magique dans tout ça, c'est simplement un projet assembly Maven auquel on ajoute la fonctionnalité WTP permettant de debugger... Cette solution à un inconvénient MAJEUR !!! La maintenabilité !!! A chaque dépendance maven ajoutée qu'elle soit de type librairie ou projet... il faudra l'ajouter manuellement (via clic droit properties modules dependencies...)

Je compte me pencher sur ce point ASAP... des pistes ? utiliser WTP 2, tester le nouveau plugin eclipse pour maven, utiliser un script de synchronisation, réécrire WTP... etc...

Fight For Kisses (www.ffk-wilkinson.com)

Quand les calinoutchs viennent à manquer, tous les moyens sont bons !

Désolé mais en voyant ce trailer j'ai eu envie de le partager avec le plus grand nombre...

(partie 1) Intégration de Maven dans un projet Java J2EE Hibernate, Spring, Eclipse RCP: pas une mince affaire mais une bonne affaire tout de même !

Intégration de Maven dans un projet Java J2EE Hibernate, Spring, Eclipse RCP: pas une mince affaire mais une bonne affaire tout de même ! (partie 1)

Il existe des projets qui ne ressemblent pas aux "Hello World" que l'on trouve habituellement sur chaque site de framework digne de ce nom ! En effet, dans certains cas (qui a dit tous les cas ?) les projets sont complexes et leurs ramifications de dépendance font penser à une grande forêt de projet...

Dressons le tableau:
-un serveur web avec Spring, Hibernate, Birt et JMS (entre autre) découpé en couches suivant 2 axes. D'un côté un découpage fonction du type de manipulation des données traitées: DAOs, services métier et services applicatifs et de l'autre un découpage suivant les briques métiers ou les catégories de services (ex: brique "commune" ou "de base", brique achat, brique financière...).
-un client type Eclipse RCP avec des dépendances vers certains projets communs avec le serveur.

Maintenant ajoutons maven pour gérer les dépendances des différents projets serveurs et la c'est le drame ! En effet, les projets communs qui sont à la fois en dépendance maven et en dépendance plugin eclipse posent problème. En effet si un projet A à une dépendance via maven vers un projet B dans le pom.xml ainsi qu'une dépendance vers le plugin B via le MANIFEST.MF alors Eclipse mettra le projet en erreur avec une erreur du type : "Build path contains duplicate entry: 'pluginB' for pluginA"

Aucun problème pour la partie serveur via maven; les scripts maven type clean, package, install etc fonctionneront parfaitement... c'est dans Eclipse que ca se corse. Mais à quoi bon écrire un article s'il n'y a pas de solution ? Aucun et c'est bien pour ça que j'écris ces lignes !

Pour résoudre cette erreur, il faudra utiliser une fonctionnalité quelque peu cachée du plugin maven pour Eclipse:
-Un clic droit sur l'élément "Maven Dependencies" du projet qui a à la fois une dépendance maven et plugin pour laisser apparaitre le menu contextuel.
-Puis cliquez sur "Properties" ce qui permet d'afficher une fenêtre de configuration.
-Décochez la case à cocher "Resolve dependencies from workspace project".
-Validez cette fenêtre en cliquant sur "OK".

On en parle ici: http://docs.codehaus.org/display/M2ECLIPSE/Dependency+Management

Image:

A noter: Eclipse 3.2, plugin maven pour eclipse en 0.0.11 (le 0.0.9 et le 0.0.12 posent problème actuellement dans notre environnement) et maven 2.

Maintenant on se trouve dans un environnement Eclipse qui compile et surtout qui permet de lancer le client en debug ainsi que le serveur via WTP tout en utilisant la gestion des dépendances maven. Enfin l'utilisation du Web Tool Platform d'Eclipse avec Maven mérite un second article car ce n'est pas une mince affaire de les méler tout en permettant au developpeur de debugger le serveur "à chaud" sans avoir à re-builder la totalité de l'application serveur via des scripts maven... en ayant pris soin d'avoir arrêté le serveur et en le démarrant après tout ça.

>> suite >>

La gestion des sauts de page dans un tableau BIRT (pageBreakInside)

Juste un petit message pour noter un point "négatif" dans le framework BIRT, ou plutôt dans une certaine version de BIRT à savoir la 2.1.x !!! (version archaïque diront certains)

En effet, ceux qui se sont déjà confrontés aux problèmes de gestion des sauts de page dans BIRT savent qu'il y a de quoi s'arracher les cheveux !

Mettez nous en situation, vous avez 2 tableaux imbriqués, appelons les T1 et T2 et vous souhaitez que le tableau (T2) qui est contenu dans le tableau principal(T1) s'affiche si possible sur une nouvelle page dans le cas ou il ne peut s'afficher dans la page courante. Attention, vous ne voulez pas que T2 soit systématiquement sur une nouvelle page, mais bien uniquement lorsqu'il ne peut s'afficher sur la page courante. Plutôt simple à priori mais c'est sans compter sur le fait qu'on ne peut gérer les sauts de page que suivant le début et/ou la fin d'un tableau et non en spécifiant le comportement des sauts de page au sein du tableau.

Exemple des données à afficher :

----------------------------
- HEADER T1
----------------------------
- T2: INFO 1
- T2: nom 1
- T2: prénom 1
----------------------------
- T2: INFO 2
- T2: nom 2
- T2: prénom 2
----------------------------
- T2: INFO 3
- T2: nom 3
- T2: prénom 3
----------------------------

Ce que je ne veux pas voir s'afficher : (Ce que génère BIRT 2.1.x)

########## PAGE 1 ##########
----------------------------
- HEADER T1
----------------------------
- T2: INFO 1
- T2: nom 1
- T2: prénom 1
----------------------------
- T2: INFO 2
- T2: nom 2


########## PAGE 2 ##########

- T2: prénom 2
----------------------------
- T2: INFO 3
- T2: nom 3
- prénom 3
----------------------------

Et ce que je souhaite afficher : (Ce que génère BIRT 2.2.x bien configuré)

########## PAGE 1 ##########
----------------------------
- HEADER T1
----------------------------
- T2: INFO 1
- T2: nom 1
- T2: prénom 1
----------------------------

########## PAGE 2 ##########
----------------------------
- T2: INFO 2
- T2: nom 2
- T2: prénom 2
----------------------------
- T2: INFO 3
- T2: nom 3
- T2: prénom 3
----------------------------

Une propriété "pageBreakInside" est sensée résoudre tous nos problèmes, pour plus d'info:
https://bugs.eclipse.org/bugs/attachment.cgi?id=36165
et
http://www.eclipse.org/birt/phoenix/ref/rom/elements/Style.html#Property-pageBreakInside)

Elle va de paire avec les propriétés pageBreakBefore et pageBreakAfter qui elles fonctionnent parfaitement. Le pageBreakInside n'est pas disponibles dans le BIRT Designer 2.1.x et si on ajoute la propriété directement dans le xml elle n'est pas interprétée.

Après avoir étudié de nombreuses pistes diverses et variées... aucunes solution n'a été trouvé enfin si une seule la montée de version de BIRT de 2.1.x vers 2.2.x ! Et donc si vous êtes en Eclipse 3.2 vous serez forcez de passer en Eclipse 3.3 ! Et si vous étiez en Java 1.4, vous serez forcez de passer en Java 5 ! Aie dirons certains, tant mieux dirons d'autres et tant pis pour les derniers.

Java Scripted Datasets avec BIRT: une solution souple et pratique !

BIRT est un projet open-source de la communauté Eclipse.org permettant de réaliser des états (reports) à partir d'un fichier de mise en forme (rptdesign xml), de données diverses (base de données) et d'un moteur de génération des éditions (BIRT engine) le tout dans un monde J2EE.

La plupart du temps, BIRT est présenté comme une solution orientée BI (Business Intelligence)... du décisionnel. Et pourtant, c'est aussi une solution très adaptée pour réaliser des documents pour des applications métiers qui necessitent la réalisation de documents à partir de grappes d'objet métier java et non à partir de bases de données directement.

Je m'explique... dans les exemples BIRT on voit toujours des data sources pour se connecter directement à une base de données or ce n'est pas forcément pratique quand doit réaliser un document qui correspond à un écran pour lequel il existe déjà un service métier permettant de récupérer les données à afficher dans le document.

Pour ce faire, il existe les scripted data sources et les scripted data sets. Ils permettent d'utiliser des objets java pour les afficher dans le document. Par défaut, le data set est codé en javascript au sein de l'éditeur BIRT dans Eclipse. Le code javascript est stocké dans le document BIRT (rptdesign ou rptlibrary). Cela peut poser plusieurs problèmes lors de la réalisation du document.

Premièrement, le javascript est simple certe mais l'éditeur BIRT actuel ne permet pas d'apporter beaucoup d'aide au developpeur (autocompletion, verificateur de syntaxe...).

Deuxièmement, il n'est pas possible de mettre des points d'arrêt pour débugger le document lors de la génération avec le moteur BIRT.

Troisièmement, le code du data set est stocket dans le document BIRT de description de l'édition avec tous les désagréments que cela comporte.

Mais heureusement il existe une ultime solution pour pallier à ces trois problèmes les java scripted data sets ! Ils permettent tout simplement de remplacer les javascripted data sets par une classe java.

La classe java doit implémenter ScriptedDataSetEventAdapter avec les méthodes :

public boolean fetch(IDataSetInstance set, IUpdatableDataSetRow row) { ... }
public void beforeOpen(IDataSetInstance dataSet, IReportContext reportContext) { ... }
public boolean describe(IDataSetInstance arg0, IScriptedDataSetMetaData arg1) { ... }

Exemple:

import org.eclipse.birt.report.engine.api.script.eventadapter.ScriptedDataSetEventAdapter;
import org.eclipse.birt.report.engine.api.script.instance.IDataSetInstance;
import org.eclipse.birt.report.engine.api.script.IUpdatableDataSetRow;
import org.eclipse.birt.report.engine.api.script.IScriptedDataSetMetaData;


public class MyScriptedDataSetEventAdapter extends ScriptedDataSetEventAdapter {

private static final String COLUMN_FOO = "Foo";
private static final String COLUMN_BAR = "Bar";

private int index = 0;
private int size;

private MyObject test;

public boolean fetch(IDataSetInstance set, IUpdatableDataSetRow row) {
if( index >= size){
return false;
}
try{
row.setColumnValue(COLUMN_FOO, test.getListToFetch().get(index).getFoo());
row.setColumnValue(COLUMN_BAR, test.getListToFetch().get(index).getBar());
}catch (Exception e){
//myLogger.log(e) you know wtf to do here ;-)
}
index += 1;
return true;
}

public void beforeOpen(IDataSetInstance dataSet, IReportContext reportContext) {
test = (MyObject) reportContext.getGlobalVariable("myObjectName");
size= test.getListToFetch().size();
}

public boolean describe(IDataSetInstance arg0, IScriptedDataSetMetaData arg1) {
arg1.addColumn(COLUMN_FOO, String.class);
arg1.addColumn(COLUMN_BAR, Double.class);
return true;
}

}

Pour débugger rien de plus simple, mettre un point d'arrêt et lancer l'application en debug...
Pour s'assurer de la syntaxe du code... Eclipse est la !
Pour aider a la récupération des données issues de la grappe métier passée en paramètre à BIRT... encore une fois Eclipse est la !

PS: Par contre pour les projets utilisants BIRT coté client RCP... il peut y avoir des problèmes de partage de classpath... apparement les dataset scipted java ne sont pas trouvé... donc pour le moment méthode a utiliser uniquement coté serveur... a moins que...