lundi 15 février 2010

Silverpeas sur JBoss 5

Dans mon billet précédent, j'avais installé Silverpeas v5 dans JBoss 4, sur une machine Debian 5. Je vais maintenant m'attaquer à l'installation de Silverpeas v5 dans JBoss 5, sur la même machine. Ce n'est toujours pas mon but ultime, mais comme je connais bien ce serveur d'applications, je continue ainsi à me faire la main. Tout d'abord, je dois noter que je n'ai aucune garantie de réussite et que je devrai probablement faire des modifications à la configuration de Silverpeas pour l'adapter aux contraintes de cette version de JBoss.

Comme il n'y a pas de procédure prévue pour installer Silverpeas sur JBoss 5, je vais partir de mon installation sur JBoss 4, je vais récupérer les éléments (datasource, JMS, ear) et les modifier pour les adapter à JBoss 5.

jeudi 11 février 2010

Installation de Silverpeas

Pour aujourd'hui, je me lance dans une installation de Silverpeas v5, la première version libre. Je pars sur une installation standard, c'est à dire avec JBoss 4.0, le serveur d'application préconisé. Celui-ci est un peu vieillot, mais si ça fonctionne, ce sera un bon début. J'essaierai plus tard sur un JBoss plus récent et/ou un Jonas.

J'ai déroulé la procédure d'installation du début à la fin, sur une machine virtuelle vierge, sous Linux. J'ai utilisé une version de Silverpeas qui n'est pas finalisée, ce qui peut se ressentir à certaines étapes.

Script de création de machine virutelle VirtualBox

J'utilise régulièrement des machines virtuelles pour évaluer des produits ou pour élaborer des procédures d'installation. Ce procédé a plein d'avantages, comme pouvoir transférer le résultat sur d'autres machines, repartir facilement d'un environnement vierge ou ne pas polluer mon environnement de travail.

J'utilise un nombre restreint de configurations types. Par exemple, pour toutes les installations de type serveur (JBoss, Glassfish, Hudson CI,...), j'ai configuré une Debian avec Java, MySQL et quelques autres logiciels. Chaque fois que j'en ai besoin, je fais une copie de l'environnement étalon et je travaille sur cette copie.

Le principal défaut de cette procédure est que la duplication de disque virtuel est facile à réaliser, mais pas la duplication de la configuration. J'ai donc décidé de faire un script shell pour automatiser la création de nouvelles machines virtuelles à partir du disque étalon.

mardi 9 février 2010

Persistance dans Google App Engine : JDO, JPA ou ... ?

Le moteur de persistance de Google App Engine va m'obliger à sortir des sentiers battus. En effet, comme beaucoup de jeunes développeur de ma génération, j'ai toujours stocké mes données dans des bases relationnelles. Or Google nous fournit un stockage de nature NoSQL appelé BigTable. Cette technique est propriétaire et a été développée par Google pour le moteur de recherche et Google Earth. Au sein du projet Apache Hadoop!, une équipe a repris les spécifications publiées par Google pour créer un moteur similaire appelé Hbase!. Par conséquent, dans mon projet, il n'y aura pas de SQL, pas de JDBC, pas de Foreign Key,...
Google nous fournit une API de bas niveau pour accéder à ce stockage, et, pour nous simplifier la tâche, il nous propose aussi les APIs classiques JDO et JPA. Naturellement, je serais tenté d'utiliser JPA car je l'utilise régulièrement pour des projets en architecture plus traditionnelle. Il semble par contre que JDO est mieux supporté. Il apparait clairement que le choix n'est pas évident.

lundi 8 février 2010

Environnement de développement pour GAE

Avant de commencer le projet, il faut que je constitue un environnement de développement. Même si, pour l'instant, je n'ai pas besoin d'un environnement complet, avec outils de suivi de qualité ou intégration continue, il faut au moins que j'évalue les capacités des outils de développement, en me concentrant sur Netbeans et Eclipse, avec ou sans Maven ou Ant.

Il est possible de développer avec des outils rudimentaires : un JDK 5 ou 6, le SDK et un éditeur de texte. J'ai fait quelques essais dont j'ai rendu compte sur JTips. Ces essais m'ont juste servi à comprendre le fonctionnement du SDK avant d'étudier l'intégration avec les environnements de développement.