I am an Eclipse committer !

Depuis très peu de temps, je participe à un projet qui me semble avoir un intérêt particulier: UFaceKit

Le but premier de ce projet est d'abstraire la couche graphique des applications et donc de permettre de passer d'une interface graphique de type client riche SWING à GWT ou d'Eclipse RCP à Q4 etc...
Le background de ce projet entre dans le cadre des projets actuels qui visent à radicalement revoir l'approche de la réalisation des projets.
Alors il est vrai que rien ne prouve que cette façon d'appréhender la refonte de la conception des projets IT est la bonne façon de faire qui va percer dans les prochaines années.
Mais plusieurs points m'ont poussés à prendre en charge certains besoins du projet:

• Le leader du projet n'est autre que le fabuleux Tom Schindl de bestsolution.at et j'ai la conviction qu'en travaillant aux côtés des meilleurs on apprend énormément
• Un des besoins de l'équipe projet est un coup de main sur la partie GWT, réalisation de l'équivalent des viewers JFace et des layout pour GWT natif et smartGWT
• Le projet est un projet Eclipse et il entre dans le cadre du projet Eclipse e4, le futur de la plateforme Eclipse qui est géré par les plus grands de l'écosystème, tout simplement.

Après avoir échangé avec les membres de l'équipe et plus particulièrement avec Tom Schindl par mail, chat et bugzilla, j'ai réalisé les premiers développements.

Ma première tache et non des moindre a été de créer un environnement de travail pour développer sur ce projet.
Pas si simple de comprendre le fonctionnement d'un projet qui existe déjà depuis plusieurs mois.
Puis il a fallu commencer à travailler et coder l'équivalent des viewers JFace pour GWT natif puis pour smartGWT (=librairie GWT de composant graphiques et de facilitant pour le développement)
Dans le même temps, les exemples permettant de tester ces développements ont été mis à disposition.

N'ayant pas les accès pour committer le travail sur SVN, j'envoyais le tout par pièces jointes sur bugzilla et par mail.
Je bataillais donc pour commencer au plus tôt le process d'élection afin de devenir committer et ainsi pouvoir plus simplement mettre à disposition le travail réalisé.

Mais pour devenir committer il ne suffit pas de demander, il faut évidemment faire ses preuves et être crédible quand aux compétences que l'on prétend mettre à disposition.
Le contrat était simple, une fois les exemples mis à disposition et validés, le process d'élection commencerait.
J'ai donc ajouté à mes projets des vidéos interactive réalisées avec wink afin d'aider les membres de l'équipe à tester ces exemples.

Le process d'élection a démarré au démarrage d'EclipseCon2009. Je ne sais pas si cela est lié au fait que j'en avais touché 2 mots à un ami, Olivier Moises, qui se rendait à l'événement et qui connaissait Tom, mais dans tous les cas, maintenant j'ai le statut d'Eclipse Committer sur le projet UFaceKit qui est au stade d'incubation.

Une fois élu, ce n'est pas du tout cuit ! En effet, c'est un engagement sur la réalisation de diverses taches liées au projet.

Pour valider le process il faut remplir un accord individuel ainsi qu'un accord avec son employeur si vous êtes dans le même cas que moi. Le but de cet accord est de protéger la communauté Eclipse en prévenant tout conflit juridique.

J'en suis à ce stade ci, j'ai en ma possession l'accord signé de mon employeur ainsi que l'accord individuel, reste à envoyer le tout à la fondation Eclipse.

La suite au prochain épisode...

Eclipse NowYouCan 2008, Trocadéro, Notes en vrac...

La 3ème édition d'Eclipse NowYouCan a eu lieu le 21 octobre a Paris, Trocadéro dans un cadre magnifique. En arrivant, le petit déjeuner nous attend, il faut prendre des forces avant d'attaquer cette journée qui promet d'être riche en informations. Certaines têtes paraissent familières, ça discute autour des stands, l'ambiance se veut conviviale et studieuse à la fois, enfin tout dépend des groupes...

Présentation d'Eclipse NowYouCan
http://eclipse-nowyoucan.com/?Symposia/Program
Tout commence avec une présentation d'Eclipse NowYouCan par la responsable de l'organisation de l'événement. Le programme est détaillé et l'équipe d'organisation remerciée pour les efforts accomplis cette année. Ça a l'air très alléchant comme prévu, on trépigne déjà sur certaines présentations. Nous sommes une centaine dans la salle. Il y a des retardataires, mais une fois que tout le monde est là, les choses sérieuses peuvent commencer !

Ralf Mueller - Director, Eclipse Ecosystems Europe

Ralf Mueller, directeur d'Eclipse Ecosystems Europe, a commencé par une remise en perspective de l'écosystème Eclipse (open source/marché). Les raisons de sa création, de son succès ainsi que les divers types d'intervenants autour d'Eclipse. Il a utilisé principalement l'exemple de BMW qui a bâti un écosystème utilisé par les industries automobile autour de l'open source/libre et d'Eclipse en remplacement d'un environnement hétérogène (différents produits commerciaux/libres).

Voici mes notes (succinctes) :

Contexte : Automobile / discussions autour des projets open source.

Exposition des différents EcoSystems logiciels:

* Free as in speech (GNU GPL) : Libre
* Free as in bear (EPL) : Free
* Company Driven : Use Free
* Producer/Distributor/Consumer/Community : Eclipse


History of Eclipse (since 2001...)

Fonctionnement Communautaire, Membres

Définition d'Eclipse

"Eclipse is an open source community focused on developing a universal platform of frameworks and exemplary tools that make it easy and cost-effective to build and deploy software in today’s connected and unconnected world.
Eclipse is a consortium of major software vendors, solution providers, corporations, educational and research institutions and individuals working together to create an eco-system that enhances, promotes and cultivates the Eclipse open platform with complementary products, services and capabilities."

Répartition :
IBM 46%
individual 25%

Nombre committers / members en augmentation : + 20 % / an

Graphique deny / use / contribute/ champion / collaborate / redefine :
Exposition des différents mode de participation existants.

EcoSystem Eclipse: Today & Tomorrow - Présentation globale des axes de développement Eclipse.

En résumé: un fort interet de l'open source pour les clients !!

E4 (Eclipse 4) - Jochen Krause - Innoopract
Cette présentation a pour but de nous informer sur le projet qui intéresse tous ceux qui utilisent Eclipse : E4 ! La communauté Eclipse à monter un projet pour faire passer Eclipse à la vitesse supérieure, le but étant de créer une nouvelle génération d'IDE, plus simple, plus rapide, plus orienté Web et surtout permettant de faire des IHM décrits par un format pivot XML (comprenez declarative UI)

Voici mes notes (succinctes) :

The environnement is changing !

What we need:
web 2.0
REST
fast dev. cycle
easy to deploy

slides IDE

what is E4 ?
nextgen platform with:
+ easy
+ sexy (UI & co)
+ services...
+ +++

slides community

Everything in the project e4 is public => transparency

Major Themes:
-better desktop
-bring eclipse to the web !
...

commitment to 3.X
En parallèle des versions 3.x (3.5 et 3.6)

protect the SDK & RAP

3.X => support more than 5 years

3.x plugins will works

coexistence as long as needed

make it easier to build plugins

architural improvment
-more uniform, more flexible, ++ (support backward compatibility)
-dependency injection (spring ?)

non java plugin :
-javascript (groovy)

flexible styling of Eclipse desktop app.

-separate UI definition from real UI
-tweeking eclipse UI
-CSS
-databinding from model to UI (with genericity)
-DOM-based model object

Eclipse Application model
-selection, D&D, progress...
-the 20 more important things
-easy to use / understand

modeling the workbench (xml)
EMF SWT JFace

RWT (RAP widget tools)

Reuse SWT to create web app

2 ways:
UI + Application services on Server
UI on client + Application Services on server

Mashups
-OSGI
- ?

en parallèle de Eclipse 3.6 (=> dans 2 ans = 2010)


E-NOVE - RDTL

Le responsable du projet E-NOVE de la société RDTL est venu nous présenter l'architecture utilisée pour réaliser un système de communication d'un parc de véhicules de transports type BUS. Le besoin étant de mettre en place un système gérant de manière distante et embarquée les services d'affichages, de suivis, de paiement, de compostage, en bref, tous les services informatisés existants dans les BUS.

Les solutions propriétaires existantes n'étant pas satisfaisantes, RDTL s'est tourné vers OSGI et les solutions open-source. Je vous passe la tuyauterie et les schémas en tout genre, mais le projet sembait très riche techniquement et particulièrement novateur ! Une présentation de pionnier dans la matière qui était très interessante.

Mes notes :
Application mobile dans les transports (BUS)
need:
-communication d'informations
-cartographie en temps réel

Open system:
-upgrade the system over the air
-communication + data exchange

Graphique architecture client serveur avec OSGI etc.


Présentation juridique sur les licences
Peu avant l'heure du déjeuné, une intervention sur un thème juridique n'était pas chose aisée. Mais ils l'ont fait ! Les 2 intervenants nous ont présentés les différentes licences.

Mes notes :
1/ Free type licenses
GNU, EUPL, Cecilia A
VIRALE ! (+redistribution)
2/ Semi free licenses
héréditaire
3/ Domain public licenses

Arnaud Buisine/Guillaume Lours - Proxiad - Industrialisation du packaging et des controles qualité logicielle dans Eclipse avec Maven 2

-Cette présentation qui a pour thème l'industrialisation des développements, en somme la mise en place d'une usine de dev comprenant Maven, Continuum, de la génération de code (avec OBEO) et une suite de bonnes pratiques et de façons de faire.

-Pour l'automatisation de la création des projets, Proxiad utilise des Wizard Eclipse personnalisés.
Suite à une question de ma part, on apprend que historiquement ils ont testés l'utilisation des archetypes mais leur maintenabilité difficile à pousser l'utilisation de Wizard.

-L'importance de laisser la possibilité aux développeurs d'utiliser les même outils que dans l'intégration continue est primordiale pour permettre une bonne utilisation de la chaine de construction. Tous les outils de type checkstyle, PMD ou autre sont accessibles sur l'environnement de developpement. Le but est de pouvoir vérifier par soit même la qualité du code avant de la commiter.

-On ne doit pas être obligé de lancer de commandes Maven sur le poste de développement pour faire fonctionner les projets. Ca peut paraitre logique mais ce n'est pas forcément respecté...

-Je lance un pavé dans la marre et je pose une question concernant le contrôle de l'architecture par la chaine de construction. Réponse plus que correcte: Utilisation de checkstyle avec des pattern de vérification poussés le tout associé à Jdepend. L'architecture est vérifiée à partir de l'utilisation des package et des dépendances au sein des classes java.

-S'en suis une discussion sur le filtering et l'overlay Maven qui sont des sujets épineux car pluôt complexes à mettre en place dans de grandes structures que sont nos clients.

-L'utilisation massive de WTP d'Eclipse pour lancer les applications serveurs des projet est préconisée. Bien plus pratique que de lancer un serveur autonome en dehors de l'environnement de développement. Depuis plusieurs années, ce mode de fonctionnement apparait comme un standard, mais ce n'est forcément le cas partout. Les pauvres...

-Une question est posée concernant le build des projets type plugins Eclipse avec buckminster... encore une façon de se faire remarquer par l'assemblée mais cela ne fait en rien avancer le schmilblik...

Fin de la présentation, après une intervention d'un membre de l'organisation, les temsp alloué a été dépassé, la suite au prochain épisode.


Présentation de ZEND PHP, mes notes :

inconvéniants PHP: les idées reçues ?
-mélange des layers (svc, daos etc...)
-bidouille en totu genre
-d'autres apriori divers

gain de temps en dev ! => argent !

je cite : "le PHP ce n'est pas que des trucs de mickey" => équivalent archi java possible !


Présentation de P2 - Benjamin Cabé (benjamin.cabe anyware-tech com + http://blog.benjamin-cabe.com )

Notions a connaitre:

Installation Unit

Artefact repository: zip, jars, ...

Metadata repository (directory ???) : installation unit

profile

engine : execute provisionning request

touchpoint : runtimes ?


Possibilités:
-bundle pooling
-dev. env
-quick install
-target platform
-deliver installer on CD / USB Key
-different flavour of the product depending on the customer
-install mirrors


Présentation de BIRT - Actuate

ACTUATE = main commiter + project leader (80 devs)

new functionalities:

intéractif
=> ajax
=> web 2.0 function
=> adobe flex...

increase number of users

talend

bdd: mysql, infres, postgresql

spagobi

Crosstab

Cube: drill / = hierarchie

Cube stocké en mémoire

Assistant de saisie des requetes ! ++++

Question sur les Sous rapports ? => Réponse : Non...

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

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

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

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

Birt Eclipse, ça promet !

J'étudie la mise en place de Birt sur un projet Client Riche basé sur Eclipse RCP et j'avoue être quelque peu bluffé par certaines fonctionnalités bien sympathiques de ce framework de reporting.

En effet, en plus de fournir le minimum vital qui sont pour moi un designer WYSIWYG et une solution d'intégration du moteur de génération de documents (+ graphiques etc...), BIRT apporte des fonctionnalités étonnantes !

Par exemple, la possibilité d'être intégré très simplement dans une application RCP avec le BIRT Viewer ! Cette solution élégante permet notamment d'ajouter un côté "événementiel" fort convivial et pratique aux rapports de l'application. Il est possible d'afficher un rapport (un "état" pour les puristes) et sa table des matières dans colonne à gauche de l'écran avec un système de liens (ancres) sur chacun des titres un peu à la manière d'adobe viewer pour les fichiers PDF.

De plus, l'utilisation du BIRT Viewer permet d'ajouter au sein de vos rapports des liens vers d'autres rapports. C'est aussi la possibilité de paginer vos rapports et ce même au format HTML. Et pour finir, il est possible d'ajouter de l'interactivité (AJAX-like) aux rapports soit via du code javascript soit du code Java directement... Tout ceci peut en laisser rêveur quand on sait que le tout est bien entendu gratuit !

Les bons points qui me font écrire se billet sont:
-La communauté Eclipse qui héberge le projet (Birt Designer = plugin Eclipse ^^)
-Actuate dans l'ombre de BIRT ($$$)
-Une aide complète avec moult tutoriaux et exemples !
-Les possibilités d'extension de toute part du projet (ODA, Output Emitters, Birt Item...) pour ceux qui sont pressés et qui ont absolument besoin de certaines fonctionnalités manquantes à ce jour !
-Le libre choix du processus de génération et d'affichage des rapports (génération coté serveur ou client, render coté serveur ou client, fichier rptdocument transportable entre le client et le serveur si besoin pour externaliser l'affichage...)
-Des sous-rapports facilement gérables , testables et intégrables

Bon il y a certes quelques inconvénients quand même:
-La stabilité du designer qui peu parfois laisser perplexe le concepteur de rapport que j'ai pu être. (plantages réguliers sur différentes versions)
-Le codage style javascript pour prendre en entrée des objets javas (beans POJOs)
-Le manque d'input/output par rapport à d'autres framework de reporting à l'heure actuelle...
-La jeunesse du projet par rapport à d'autres...
-La lenteur de génération ?!

Les listes des atouts/défauts ne sont pas exhaustives... juste le reflet de mon retour d'expérience.

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.