Cela fait plusieurs fois que l'idée me traverse l'esprit mais c'est la première fois que je passe le pas et que je me décide à coucher l'idée sur la toile !
Il existe de nombreux JUG (Java User Group) en France et ils sont très actifs ! voir de plus en plus actif si j'en crois mes flux RSS !
A en croire les billets de certains blogger assidus du monde de Java J2EE comme le touilleur ou Eric Lefevre, les JUG sont de plus en plus répandus en France SAUF DANS LE NORD !!!
Si c'est pas une honte ça ! Avec tout le beau monde qu'on a, on est même pas capable de maintenir un JUG digne de ce nom... Et nos amis les belges, juste à côté de nous, ont un JUG extrement bien développé puisqu'ils organise la "petite" conférence Devoxx... (> 3000 participants !!! voir parleys.com)
Alors je ne sais pas ce que vous en pensez VOUS qui êtes du Nord de la France, mais organiser un JUG peut se révêler une expérience professionnelle très riche et valorisante pour les organisateur et les participants !
Si vous, votre entreprise ou même votre voisin êtes motivés pour monter ce type de projet, alors n'hésitez pas à me contacter ! Je suis sur la métropole Lilloise et je pense qu'on se doit d'avoir un JUG sur Lille, 4eme agglomération française... et même pas un JUG...
Pour ce qui est du nom du JUG, étant dans le nord, je pense que seul le Ch'ti JUG ou le Ch'tio JUG peut etre retenu... Ca fait partie des choses qui s'imposent dans le Nord.
Pour le logo, une idée ?
Affichage des articles dont le libellé est j2ee. Afficher tous les articles
Affichage des articles dont le libellé est j2ee. Afficher tous les articles
dimanche 8 février 2009
samedi 7 février 2009
GWT 1.6 M1 Release
Hi every GWT fans !
Just a post to relay the GWT 1.6 M1 release yesterday !
Here is the original announce on the GWT group:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/3e7e6cc3b35ad98a
You can download it on the GWT download page:
http://code.google.com/p/google-web-toolkit/downloads/list?can=1&q=1.6.0
Or here directly if you can wait to get it :
http://google-web-toolkit.googlecode.com/files/gwt-windows-1.6.0.zip
To remember you, here is the GWT 1.6 roadmap from the google web site here:
http://code.google.com/intl/fr/webtoolkit/makinggwtbetter.html#roadmap
Just a post to relay the GWT 1.6 M1 release yesterday !
Here is the original announce on the GWT group:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/3e7e6cc3b35ad98a
You can download it on the GWT download page:
http://code.google.com/p/google-web-toolkit/downloads/list?can=1&q=1.6.0
Or here directly if you can wait to get it :
http://google-web-toolkit.googlecode.com/files/gwt-windows-1.6.0.zip
To remember you, here is the GWT 1.6 roadmap from the google web site here:
http://code.google.com/intl/fr/webtoolkit/makinggwtbetter.html#roadmap
Release 1.6
Anticipated Time Frame - Q1 2009
- New compiled file deployment structure
- Easily compile into a WAR file, making it easy to deploy your compiled GWT application into standard servlet containers
- Migration from Tomcat to Jetty hosted mode server
- A more pluggable architecture for the hosted mode server will enable developers to use servlet containers other than Tomcat with the Hosted Mode browser
- Uniform event handlers
- Event handlers will be implemented in a uniform fashion across all widgets, with listeners deprecated
- DatePicker, LazyPanel migrated in from incubator
- New widgets from the incubator
- String performance improvements
- StringBuilder uses deferred binding to optimize string appends per-browser
- Compiler performance improvements
- 1.6 will introduce parallel permutation compilations and other performance tweaks for faster compiles
dimanche 16 novembre 2008
GWT && ( ACEGI || Spring Security )
Il y a quelques temps, j'ai eu pour mission d'ACEGIfier une application Web en GWT.Le but premier était de sécuriser l'accès aux ressources concernant l'affichage ! Alors pour ce qui est de sécuriser les services exposés etc. ce n'est pas l'objet de ce billet !
Etape 1/
Après quelques recherches sur mon ami google, j'ai pu rapidement me rendre compte qu'il était plutôt préconisé d'utiliser une page html/jsp autonome pour s'authentifier. Soit, n'étant pas un fervent défenseur du tuning applicatif, je n'ai pas perdu de temps avec ça, j'avais bien assez à faire avec ACEGI lui même.
cf:http://www.dotnetguru2.org/bmarchesson/index.php?c=1&more=1&pb=1&tb=1&title=technical_tip_using_acegi_with_gwt
Voici le résultat, pas folichon, n'est ce pas ?! Mais c'est rapide et fonctionnel !
cf:http://www.dotnetguru2.org/bmarchesson/index.php?c=1&more=1&pb=1&tb=1&title=technical_tip_using_acegi_with_gwt
Voici le résultat, pas folichon, n'est ce pas ?! Mais c'est rapide et fonctionnel !
Code:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html">
<title>My Login Page</title>
</head>
<body>
<h2>Please log in</h2><br>
<form method="POST" action="j_acegi_security_check">
Username: <input type="text" name="j_username"><br>
Password: <input type="password" name="j_password"><br>
<input type="submit" value="Log in >>">
</form>
</body>
</html>
Image:
Après coup, je me suis aperçu que ma page HTML de login était quelque peu en décalage avec l'application, feuille de style, internationalisation des libellés... J'ai donc réalisé un écran GWT d'authentification d'après le HOWTO d'Instantiations.com ! J'ai ensuite affiché cet écran dans firefox et avec firebug j'ai pu récupérer le code HTML correspondant... Mais ce n'est pas terminé, après quoi, il a fallut ACEGIfier le code HTML.
Je vous passe le code... c'est du GWT et c'est plutôt verbeux !
Image (lors d'une authentification erronée) :
Je vous passe le code... c'est du GWT et c'est plutôt verbeux !
Image (lors d'une authentification erronée) :
Etape 3/
L'application et l'écran de login étaient donc en phase ! Enfin, jusqu'à ce que je me rende compte que l'écran de login s'affichait différent en fonction des navigateurs... En effet, dans ie6, la fenêtre était déformée ! Normal, GWT ne sert donc pas a rien, il adapte le code HTML en fonction du navigateur... et ayant copier coller le code HTML depuis firefox... bref, il me fallait trouver une autre solution: un module GWT d'authentification !
En ajoutant un module d'authentification dans mon projet GWT, je suis certain de ne plus avoir de problèmes d'affichage ! Et je peux lui appliquer le même style que l'application principale ! Et je peux internationaliser l'authentification de la même façon ! Par contre, je dois modifier ma configuration ACEGI pour authoriser l'accès au fichiers GWT du module de login mais pas au reste de l'application !
J'utilise un FormPanel classique de GWT (pas GWT-EXT) et je le configure pour ACEGI (j_username, j_password, j_acegi_security_check, POST) rien de plus !
Voici le résultat, pas tellement différent qu'à l'étape 2 me direz vous, mais le gain se situe au niveau de la maintenabilité et l'homogénéitéde l'application !
Code :
Etape 4/
Il faut maintenant modifier le tout pour créer un module d'authentification autonome et non embarquer dans mon application... Histoire de le réutiliser de la même façon dans d'autres applications avec du SSO par exemple. La suite au prochain épisode !
L'application et l'écran de login étaient donc en phase ! Enfin, jusqu'à ce que je me rende compte que l'écran de login s'affichait différent en fonction des navigateurs... En effet, dans ie6, la fenêtre était déformée ! Normal, GWT ne sert donc pas a rien, il adapte le code HTML en fonction du navigateur... et ayant copier coller le code HTML depuis firefox... bref, il me fallait trouver une autre solution: un module GWT d'authentification !
En ajoutant un module d'authentification dans mon projet GWT, je suis certain de ne plus avoir de problèmes d'affichage ! Et je peux lui appliquer le même style que l'application principale ! Et je peux internationaliser l'authentification de la même façon ! Par contre, je dois modifier ma configuration ACEGI pour authoriser l'accès au fichiers GWT du module de login mais pas au reste de l'application !
J'utilise un FormPanel classique de GWT (pas GWT-EXT) et je le configure pour ACEGI (j_username, j_password, j_acegi_security_check, POST) rien de plus !
Voici le résultat, pas tellement différent qu'à l'étape 2 me direz vous, mais le gain se situe au niveau de la maintenabilité et l'homogénéitéde l'application !
Code :
A venir
Image :Rapidement:
Il faut utiliser un FormPanel de GWT natif.
FormPanel form = new FormPanel();
form.setAction("j_acegi_security_check");
on le configure pour la méthode POST
on ajoute les 2 composants de saisi du login / pass en leur donnant des noms particuliers : j_username et j_password
un bouton de validation avec un listener qui submit : form.submit();
et voila...
Il faut utiliser un FormPanel de GWT natif.
FormPanel form = new FormPanel();
form.setAction("j_acegi_security_check");
on le configure pour la méthode POST
on ajoute les 2 composants de saisi du login / pass en leur donnant des noms particuliers : j_username et j_password
un bouton de validation avec un listener qui submit : form.submit();
et voila...
Etape 4/
Il faut maintenant modifier le tout pour créer un module d'authentification autonome et non embarquer dans mon application... Histoire de le réutiliser de la même façon dans d'autres applications avec du SSO par exemple. La suite au prochain épisode !
4
commentaires
Libellés :
acegi,
authentication,
authentification,
gwt,
j2ee,
login,
spring security,
web
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:
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 !
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
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:
Puis dans le MANIFEST.MF du plugin 2 il faut spécifier la politique de gestion du classloading en ajoutant la ligne:
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
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.plugin2Avec 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: registeredCe 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
http://help.eclipse.org/help32
http://www.ibm.com/developerwor
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 :
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...
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 :
Bien entendu vous remplacez "1.0" par R7, 1.5 ou 2.0 en fonction de votre version WTP.mvn -Dwtpversion=1.0 eclipse:eclipse
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...
0
commentaires
Libellés :
client riche,
eclipse,
hibernate,
intégration,
j2ee,
java,
maven,
open-source,
rcp
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: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
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.
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.
mardi 21 août 2007
Problème de suppression d'objets dans les collections avec Hibernate !
Hibernate est un framework de gestion de la persistance renommé et très connu qui permet bien des choses et avec lequel on peut s'arracher bien des cheveux !
Hibernate à la "facheuse" tendance à utiliser des types collection qui lui sont specifique pour gérer tout ce qui concerne les list, set... Les attributs de type list et set sont remplacés par des objets de type PersistentList et PersistentSet. Cela permet par exemple à hibernate de charger dynamiquement la collection lors de l'appelle à une méthode comme size() add() ou remove() dans le cas par exemple d'une collection mappée avec le lazy loading. Pour résumer, tant qu'on n'a pas besoin du contenu de la liste, elle est remplacé par un proxy qui est pret à al charger à la première demande.
Quand on utilise Hibernate dans le cadre d'une application ayant une architecture client-serveur, les classes d'hibernate ne sont accéssibles que coté serveur, coté base de données. Or dans une architecture client-serveur on fait transiter des objets métiers java de part et d'autre via le réseau (en HTTP par exemple avec Spring remoting) mais sous une condition : Que tous les objets envoyés soit accessibles dans les dépendances des 2 projets.
Or comme je l'ai expliqué juste avant, Hibernate remplace les listes par des objets qui lui sont propres et qui ne sont accéssibles qu'au projet serveur via la librairie hibernate (hibernate3.jar par exemple dans répertoire lib du serveur). Donc si on envoie au client une grappe métier contenant des listes après extraction de la base via hibernate, cela va poser problème et on va voir fleurir dans la console des erreurs du type "Exception : Ahhhhhh je ne connais pas la classe PersistentSet"
Il se peut qu'on ne soit pas impacté par ce problème car il est coutume d'utiliser des DTOs et des transformateurs pour faire transiter les objets sur le réseau et par conséquent les types spécifiques d'hibernate sont transformés automatiquement (par les transformateurs). Dans le cas ou nous n'avons pas de couche de DTOs, on peut utiliser des mappeurs qui remplacent les PersistentList et PersistentSet en ArrayList et HashpSet par exemple.
Bref, une fois les objets récupérés transformés (sans PersistentXXX) sur le client, on joue avec, ou les modifie et on peut être amené à supprimer des éléments d'une liste. Et c'est la que l'affaire se corse car il se peut, sans qu'on sache réellement pourquoi, que Hibernate ne puisse pas détecter la suppression d'un élément donné lors de la sauvegarde.
Effectivement, puisqu'on a remplacer les gestionnaire de liste à la sauce hibernate quand on renvoie la grappe coté serveur... il ne se rend pas compte qu'il y a eu suppression même avec les options type delete-orphan all-delete-orphan dans le mapping... La seule solution, l'ultime chance restante consiste à mapper la liste d'une manière bien différente.
Ce problème commun est connu sur le site hibernate.org :
------------------------------
I removed an object from a collection mapped with cascade="all" but the object was not deleted!
cascade="all" cascades the delete() operation from parent to child. If this is a one-to-many association, try using cascade="all,delete-orphan".
Another solution is to model your child objects as composite elements (a kind of value type) rather than entities. Value types are always persisted or removed along with their parent entity. So you would use a mapping for the element class instead of a mapping..
------------------------------
Voici le mapping de la liste contenu dans mon objet Truc :
<set name="maListe" table="element" lazy="true" >
<key column="elt_trc_id" not-null="true" />
<composite-element class="org.truc.Element">
<parent name="truc"/>
<property name="identifiant" type="java.lang.Integer">
<column name="elt_id" />
</property>
<property name="commentaire" type="java.lang.String">
<column name="elt_commentaire" length="254" />
</property>
<property name="date" type="timestamp">
<column name="elt_date" />
</property>
</composite-element>
</set>
au lieu de par exemple:
<list name="maListe" lazy="true" cascade="persist, save-update, evict, merge, all-delete-orphan">
<key column="elt_trc_id" not-null="true" />
<index column="elt_numero" />
<one-to-many class="Element" />
</list>
Hibernate à la "facheuse" tendance à utiliser des types collection qui lui sont specifique pour gérer tout ce qui concerne les list, set... Les attributs de type list et set sont remplacés par des objets de type PersistentList et PersistentSet. Cela permet par exemple à hibernate de charger dynamiquement la collection lors de l'appelle à une méthode comme size() add() ou remove() dans le cas par exemple d'une collection mappée avec le lazy loading. Pour résumer, tant qu'on n'a pas besoin du contenu de la liste, elle est remplacé par un proxy qui est pret à al charger à la première demande.
Quand on utilise Hibernate dans le cadre d'une application ayant une architecture client-serveur, les classes d'hibernate ne sont accéssibles que coté serveur, coté base de données. Or dans une architecture client-serveur on fait transiter des objets métiers java de part et d'autre via le réseau (en HTTP par exemple avec Spring remoting) mais sous une condition : Que tous les objets envoyés soit accessibles dans les dépendances des 2 projets.
Or comme je l'ai expliqué juste avant, Hibernate remplace les listes par des objets qui lui sont propres et qui ne sont accéssibles qu'au projet serveur via la librairie hibernate (hibernate3.jar par exemple dans répertoire lib du serveur). Donc si on envoie au client une grappe métier contenant des listes après extraction de la base via hibernate, cela va poser problème et on va voir fleurir dans la console des erreurs du type "Exception : Ahhhhhh je ne connais pas la classe PersistentSet"
Il se peut qu'on ne soit pas impacté par ce problème car il est coutume d'utiliser des DTOs et des transformateurs pour faire transiter les objets sur le réseau et par conséquent les types spécifiques d'hibernate sont transformés automatiquement (par les transformateurs). Dans le cas ou nous n'avons pas de couche de DTOs, on peut utiliser des mappeurs qui remplacent les PersistentList et PersistentSet en ArrayList et HashpSet par exemple.
Bref, une fois les objets récupérés transformés (sans PersistentXXX) sur le client, on joue avec, ou les modifie et on peut être amené à supprimer des éléments d'une liste. Et c'est la que l'affaire se corse car il se peut, sans qu'on sache réellement pourquoi, que Hibernate ne puisse pas détecter la suppression d'un élément donné lors de la sauvegarde.
Effectivement, puisqu'on a remplacer les gestionnaire de liste à la sauce hibernate quand on renvoie la grappe coté serveur... il ne se rend pas compte qu'il y a eu suppression même avec les options type delete-orphan all-delete-orphan dans le mapping... La seule solution, l'ultime chance restante consiste à mapper la liste d'une manière bien différente.
Ce problème commun est connu sur le site hibernate.org :
------------------------------
I removed an object from a collection mapped with cascade="all" but the object was not deleted!
cascade="all" cascades the delete() operation from parent to child. If this is a one-to-many association, try using cascade="all,delete-orphan".
Another solution is to model your child objects as composite elements (a kind of value type) rather than entities. Value types are always persisted or removed along with their parent entity. So you would use a
------------------------------
Voici le mapping de la liste contenu dans mon objet Truc :
<set name="maListe" table="element" lazy="true" >
<key column="elt_trc_id" not-null="true" />
<composite-element class="org.truc.Element">
<parent name="truc"/>
<property name="identifiant" type="java.lang.Integer">
<column name="elt_id" />
</property>
<property name="commentaire" type="java.lang.String">
<column name="elt_commentaire" length="254" />
</property>
<property name="date" type="timestamp">
<column name="elt_date" />
</property>
</composite-element>
</set>
<list name="maListe" lazy="true" cascade="persist, save-update, evict, merge, all-delete-orphan">
<key column="elt_trc_id" not-null="true" />
<index column="elt_numero" />
<one-to-many class="Element" />
</list>
Mais bon ca fonctionne et les objets sont biens mis à jours et surtout supprimés quand on sauvegarde l'objet conteneur...
dimanche 25 mars 2007
Wazaabi & Eclipse RCP
Eclipse RCP, un environnement de développement "utopique" :
Un des besoins récurrents chez les clients de type grand compte est de refondre leurs applicatifs métier réalisés avec des technos archaïques. Les raisons qui poussent les clients à refaire ce type d'application sont l'arrivée de nouveaux besoins, la nécessité d'interfacer les applicatifs, permettre une meilleure maintenabilité, augmenter l'ergonomie et j'en passe. Pour ce faire, une des solutions permettant de répondre tous les besoins est d'utiliser le framework d'Eclipse RCP ! Ce n'est pas la seule solution mais elle mérite d'être mise en avant son potentiel est intéressant.
Eclipse RCP permet très facilement de générer des applications clientes qui sont capables de communiquer avec un serveur distant. Avec des interfaces graphiques basées sur des composants propres au système d'exploitation exécutant, Eclipse RCP possède un véritable tookit de widgets standardisé, comme son nom l'indique (SWT = Standart Widget Toolkit). Accompagné de JFace, une surcouche à SWT, Eclipse RCP se dote d'un cadre de développement simple pour les composants dits "complexes" (les listes par exemple) mais c'est aussi une foultitude de fonctionnalités complémentaires: boites de dialogues, assistants, raccourcis clavier, undo/redo, filtres/tris... SWT s'occupe donc de fournir une bibliothèque de composants performants alors que JFace permet de simplifier la création des interfaces et offre un cadre de développement ainsi que des facilitant puissants !
Eclipse RCP c'est aussi et surtout le workbench d'Eclipse: ses vues, ses éditeurs, sa gestion des perspectives et ses fenêtres de préférence... Un atout considérable pour créer une application complexe ! Un environnement de travail ou les aspects principaux de l'application sont régis par des règles répondant à des besoins basiques. Ce framework, c'est aussi la gestion des plugins dont hérite une application de type Eclipse RCP, ce qui permet d'étendre des plugins existants ou de laisser la possibilité à d'autres d'utiliser son application, son plugin pardon...
Bien sur en choisissant Eclipse RCP, on prend ce qu'il y a de meilleur, c'est a dire l'environnement de développement d'Eclipse, l'IDE Java le plus aboutit à mon sens dont les performances et la maniabilité n'est plus a démontrer ! C'est notamment un facilitant de création pour les plugins Eclipse (RCP ou non) ou encore un assistant pour dessiner ses interfaces graphiques avec Visual Editor ! Utiliser Eclipse RCP c'est aussi "s'assurer" une compatibilité avec la batteries de projets Eclipse tel que BIRT, GEF etc...
Parlons de Wazaabi, un facilitant pour Eclipse RCP :
Je n'ai pas parlé des inconvénients d'Eclipse RCP... oui, comme tout ce qui existe, il y existe des inconvénients propres à Eclipse RCP ! Et la conception des interfaces graphiques en fait partie... En effet, un des avantages des applications web sur les clients riches type Eclipse RCP, est de pouvoir concevoir les écrans via un langages balisé comme l'HTML. Wazaabi est la pour combler ce manque ! Il permet de créer des interfaces graphiques en utilisant le langages XUL très proche du XML. Les fichiers XUL comme les fichiers HTML sont interprétés par un moteur de rendus pour générer visuellement les écrans ! Ceci permet de séparer la conception des écrans et les services métiers de l'application comme pour les clients légers en somme.
Pour résumer Wazaabi est une surcouche à Eclipse RCP qui est une alternative à l'utilisation de Visual Editor pour concevoir ses écrans. Ce framework permet notamment de mettre facilement en place l'internalisation des écrans depuis peu, et bientôt les feuilles de style. De plus, d'ici quelques temps un éditeur graphique permettra bientôt de concevoir les interfaces graphiques XUL... ce qui est tout de même un manque pour un facilitant dans ce même domaine mais passons... Un projet plein d'avenir qui a déjà été utilisé chez Leroy Merlin ainsi que chez Kiabi sur divers projets sur lesquels j'ai eu la chance de pouvoir m'impliquer.
Inscription à :
Articles (Atom)