mercredi 8 octobre 2008

The Blogger Tag Code Copy Paste Tool

Notre sauveur, François Schnell, a publié sur son site perso il y a déjà quelques temps un utilitaire permettant de convertir votre code contenant des tags afin qu'il soit interprété par blogger et affiché comme on le souhaite.

En effet, si vous vous amusez a insérer du code contenant des tags dans un billet blogger (par exempe: <html>) vous aurez la mauvaise surprise de devoir chercher longtemps ce code dans votre billet une fois publié... blogger l'aura tout simplement... "caché" ! A la place, une zone vide apparaitra... super interessant pour vos lecteurs n'est ce pas ^^

Je cite l'auteur de cet outils:
To show tags in a Blogger post you need to manually "escape" each "<" and ">" characters.
This small tool does it automatically for you: paste your code on the left and click "convert"
En gros, pour que les "<" et les ">" s'affichent, il doivent être respectivement remplacés par "&lt;" et "&gt;" ! ET bien cet outil le fait pour vous ! Facile !

Vous allez me dire que c'est facilement faisable avec un recherché/remplacé sous notepad... et vous n'avez pas tord ! Par contre, si on fait un concours du convertisseur le plus rapide suivant ces 2 méthodes... avec cet outil vous ne ferez pas le poids !

Bref, l'essayer c'est l'adopter ! Foncez !

http://francois.schnell.free.fr/tools/BloggerPaste/BloggerPaste.html

N'hésitez pas a remercier l'auteur de cet outil !

Si vous en connaissez d'autres, je suis preneur bien entendu ^^

Eclipse development tips and tricks :: Trucs et astuces du developpement d'Eclipse

...Rapide billet sur des trucs et astuces Eclipse bien pratiques...

1 / Comment supprimer les raccourcis eclipse inutiles dans des applications RCP :
http://code9.com/2008/07/18/tip-suppressing-keybindings/

Par défaut, les applications RCP héritent des raccourcis claviers d'Eclipse. Vous pouvez tester avec la fameuse application d'exemple Mail RCP; si vous utilisez des raccourcis clavier d'Eclipse... ca ouvre des popups qui n'ont rien a voir avec votre application. Pas génial tout ca !

Mais une solution simple consiste a ajouter un scheme a votre plugin.xml :
<extension point="org.eclipse.ui.bindings">
<scheme id="mail.scheme" name="My Mail Scheme">
</scheme>
</extension>
Après il suffit de spécifier le scheme a utiliser dans vos bindings et d'ajouter un fichier plugin_customization.ini avec le code suivant:
org.eclipse.ui/KEY_CONFIGURATION_ID=mail.scheme
2 / La vue display d'Eclipse a été trop longtemps mise sous silence:
http://larsho.blogspot.com/2008/07/my-favorite-eclipse-view.html

Cette vue permet de coder dans une fenêtre détacher du code java en cours de debug. Rien de transcendant jusque là. Le code réalisé au sein de cette vue est exécuté dans le contexte du debugger Eclipse.

Si vous mettez un point d'arrêt sur une ligne de code et que vous faites en sorte que le debugger s'y arrête, vous pouvez alors exécuter du code en utilisant les variables accessibles comme si vous codiez sur la ligne du point d'arrêt.

Pour faire apparaitre cette vue: Window > Show View > Display.

Bien entendu tous les bienfaits d'Eclipse fonctionnent aussi dans cette vue: autocomplétion, coloration syntaxique etc.

3 / Paramétrer votre lanceur Eclipse et utiliser les filtres de types :
http://dailyupdateu.blogspot.com/2008/07/top-10-tips-for-new-eclipse-users.html

-Il est possible de modifier votre lanceur Eclipse pour que le chemin du workspace utilisé s'affiche dans la barre de titre... pratique quand on utilise plusieurs instance d'Eclipse !
Ajouter "-showlocation" en paramètre à votre lanceur et le tour est joué.

Cette fonctionnalité prend tout son sens si vous avez plusieurs workspaces. Pour que votre lanceur utilise un workspace particulier ajoutez "-data c:\monworkspace" à votre lanceur.

Pour utiliser ces 2 fonctionnalités ajoutez "-data c:\monworkspace -showlocation".

A noter aussi que pour faciliter la configuration de vos différents workspaces vous pouvez utiliser l'import/export des préférences Eclipse. Configurez un seul workspace et reportez sa configuration en exportant ses préférences puis en les importants dans les autres workspaces.

-Une autre fonctionnalité des plus utiles d'Eclipse est l'ajout de filtres pour les types utilisés par Eclipse pour l'autocomplétion et la recherche de classes. Par exemple, il existe 2 classes List dans la librairie standard de Java java.util.List et java.awt.List... Mais comme vous êtes un adepte de GWT... le fait d'insérer une List AWT dans votre code peut vous laisser perplexe... Vous souhaitez qu'Eclipse arrête de vous proposer des classes issues de AWT (par exemple) ?

Il suffit de vous rendre dans Window -> Preferences -> Java -> Appearance -> Type Filters et d'ajouter java.awt.* à la liste des filtres.

4 / Les filtres de log dans Jboss :

Vous en avez assez des logs trop verbeux dans votre bon vieux serveur d'application JBoss sous Eclipse ?
La vie d'Hibernate et de Spring vous importe peu ?

Alors ajoutez des filtres afin de spécifier pour ces 2 frameworks un niveau de log raisonnable pour ne plus vous polluer la vie.

Pour un Jboss 3.2.6, dans le fichier .xml ajoutez le code suivant:

<category name="org.hibernate">
<priority value="ERROR"/>
</category>

<category name="org.springframework">
<priority value="ERROR"/>
</category>

Et voila...

...En espérant que cela soit utile au plus grand nombre...

jeudi 11 septembre 2008

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 !

mercredi 30 avril 2008

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

dimanche 9 mars 2008

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...

samedi 9 février 2008

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...

samedi 5 janvier 2008

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

mardi 4 décembre 2007

(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...

dimanche 2 décembre 2007

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...

mercredi 28 novembre 2007

(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".


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.