Finalement, le temps d’obtenir une machine sous Redhat 5 a laissé le temps à la team FusionForge de sortir une release finale de la version 5.0.

Nous voilà donc lancés dans cette installation que je me propose de décrire ici.

A noter que pour le moment la forge n’est pas totalement opérationnelle. Des évolutions dans la configuration devront être menées et j’espère pouvoir tenir à jour cet article pour les décrire.

Processus d’installation

Préinstallation

Création du sous-domaine

Il faut choisir un nom « agréable » pour la machine et le déclarer dans le DNS. Dans le reste du document, on considère qu’on installe la forme sous le nom maforge.mondomaine.

Espace disque

Il est recommandé également de prévoir un espace disque suffisant pour la forge en montant par exemple un disque sur une baie SAN. Dans le reste du document, on considère que le répertoire disponible est /maforge.

Configuration YUM pour internet

Les scripts d’installation nécessitent d’avoir un accès à internet pour télécharger à l’aide de yum les modules nécessaires pouvant manquer dans l’installation par défaut de la machine. Pour cela, si il est nécessaire de passer par un proxy, le déclarer dans yum.conf sous la forme d’une ligne :

proxy=http://adresseipproxy:port/

Téléchargement de la distribution fusionforge

Les packages à télécharger pour installer la forge sont disponibles à l’adresse :

http://fusionforge.org/frs/?group_id=6

A noter que le document présent est basé sur la version 5.0 de la forge. Il est conseillé de prendre la version notée « allinone ».

Dans la suite, on considère qu’on a téléchargé le fichier : fusionforge-5.0-allinone.tar.bz2

Processus d’installation

Une fois le fichier d’installation téléchargé, le déposer dans un répertoire temporaire de la machine, par exemple : /tmp

Puis en tant qu’utilisateur root :

cd /tmp
bunzip2 fusionforge-5.0-allinone.tar.bz2
tar xf fusionforge-5.0-allinone.tar

On doit se retrouver avec un répertoire /tmp/fusionforge-5.0

cd /tmp/fusionforge-5.0
install.sh maforge.modomaine

Ce script exécute l’installation de la forge :

• Téléchargement des dépendances (via le script fusionforge-install-1-deps.php)
• Installation des scripts de la forge, des répertoires, … (via le script fusionforge-install-2.php)
• Création de la base de données (fusionforge-install-3-db.php)

Lors de l’installation, le script demande d’entrer le nom de l’utilisateur administrateur de la forge et son mot de passe.

Note :

Lors de l’installation, le script semble ne pas avoir complètement fonctionné correctement. Des analyses sont en cours.

De ce fait, un démarrage manuel de la base postgres a dû être effectué à l’aide la commande suivante.

/etc/rc.d/init.d/postgresql start

Une fois ces opérations menées, il doit être possible d’ouvrir un navigateur web à l’adresse :

http://maforge.modomaine/

Page d'accueil de la forge

Processus post-installation

Déplacement des fichiers sur la baie SAN

La forge s’installe dans ses répertoires par défaut. En attendant que la communauté de développeur de la forge rende paramétrable les répertoires, un certain nombre d’action sont nécessaires pour déplacer les répertoires d’installation vers un disque adéquat (sur la baie SAN par exemple).

Pour faire ces déplacements, il est nécessaire de stopper la base de données :

/etc/rc.d/init.d/postgresql stop

Le tableau ci-dessous donne les répertoires par défaut d’installation de la forge et les répertoires cibles vers lesquels on souhaite se déplacer.

Pour déplacer les fichiers, faire :

mkdir /maforge/conf
mv /etc/gforge/* /maforge/conf/
rmdir /etc/gforge
ln -s /maforge/conf/ /etc/gforge

mkdir /maforge/pgsql
mv /var/lib/pgsql/* /maforge/pgsql/
mv /var/lib/pgsql/.bash_profile /maforge/pgsql/
rmdir /var/lib/pgsql
ln -s /maforge/pgsql/ /var/lib/pgsql

mkdir /maforge/files
mv /var/lib/gforge/* /maforge/files/
rmdir /var/lib/gforge
ln -s /maforge/files/ /var/lib/gforge

mkdir /maforge/fforge50
mv /opt/gforge/* /maforge/fforge50/
rmdir /opt/gforge
ln -s /maforge/fforge50/ /opt/gforge

mkdir /maforge/groups
mv /opt/groups/* /maforge/groups/
rmdir /opt/groups
ln -s /maforge/groups/ /opt/groups

Puis redémarrer postgres :

/etc/rc.d/init.d/postgresql start

Patch sur les répertoires SVN et CVS

L’installation de la forge semble poser des problèmes sur Redhat 5 et CentOS 5 car des répertoires attendus par la forge ne sont pas créés. Il faut donc, créer des liens symboliques pour corriger ce problème :

ln -s /maforge/files/svnroot /maforge/files/svn
ln -s /maforge/files/cvsroot /maforge/files/cvs
ln -s /maforge/files /scmrepos
ln -s /maforge/files/svnroot /svnroot
ln -s /maforge/files/cvsroot /cvsroot

Installation BIND et configuration DNS (PROVISOIRE/EN COURS)

La forge doit gérer elle-même ses DNS afin de pouvoir déclarer chaque nouveau projet dans son espace propre (par exemple nomprojet.maforge.mondomaine).

Pour cela, une délégation de DNS doit être réalisée par le DNS principal du domaine mondomaine pour laisser le service BIND de la forge gérer le sous-domaine maforge.mondomaine.

Il faut donc également installer le service BIND sur la forge et le configurer.

Note : A compléter

Voir aussi : https://fusionforge.org/docman/view.php/6/1/gforge_manual.plain.html#id2623367

java.net.URISyntaxException: Illegal character in path at index 18: file:/C:/Documents and Settings/USER/.m2/repository/org/mortbay/jetty/jetty-maven-plugin/7.0.0.1beta2/jetty-maven-plugin-7.0.0.1beta2.jar

Ce problème n’est résolu que sous Maven 3. Pour ceux qui souhaitent rester sous Maven 2 (Maven 3 est encore en version alpha), il faut modifier l’emplacement de la repository pour éviter le souci du caractère ESPACE présent dans le chemin C:\Documents and settings\USER\.m2\repository (chemin par défaut).

Il est fortement recommandé de déplacer le répertoire repository dans c:\maven2\repository par exemple et modifier ensuite le fichier settings.xml qui se trouve normalement dans C:\Documents and settings\USER\.m2 ou (moins bien) dans votre répertoire d’installation de maven sous /conf.

<localRepository>/c:/maven2/repository</localRepository>

Ainsi, Maven ira chercher les libs dans un répertoire sans espaces…

En effet, dans une modélisation assez classique, imaginons le cas suivant :

Couche Modèle (ou DAO)

Classe POJO contenant un attribut x et une collection cols

@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
public class Dossier {
	@Id
	@GeneratedValue
	private Long id;
	private String x;

	@OneToMany(cascade=CascadeType.ALL)
	private Collections<String> cols;
	// Getter et setters
}

Classe DAO

Voir le blog pour l’utilisation des generics de Java5 afin d’éviter d’avoir à coder toujours les mêmes méthodes CRUD.

@Repository
@Transactional
public class DossierDAO {
	@Autowired
	protected SessionFactory factory;

	public Dossier getOne (Long id) {
		Session session = factory.getCurrentSession();
		return (Dossier)(session.get(Dossier.class,id));
	}
}

Couche Métier (ou Service)

Classe Service contenant l’injection du DAO

@Transactional
public class DossierServiceImpl implements DossierService {
	@Autowired
	@Qualifier("dossierDao")
	private DossierDAO dossierDao;

	public Dossier read(Long id) {
		return dossierDao.getOne(Dossier.class.getName(), id);
	}
}

On voit ici que la transaction peut démarrer au niveau du service et que par défaut, en mode Lazy, seul l’attribut x de Dossier sera chargé.

Pour que l’application Web appelante puisse faire une itération sur la collection, il faudrait que celle-ci soit chargée.
Il est possible de changer le mode LAZY pour dire à Hibernate de tout récupérer mais pour un arbre de données assez profond, cela peut devenir désastreux.
Il est également de modifier la méthode read du service DossierService ainsi :

public Dossier read(Long id) {
	Dossier d = dossierDao.getOne(Dossier.class.getName(), id);
	d.getCols();
	return d;
}

Dans ce cas, on a déclenché manuellement la recherche du contenu de la collection…

Autre possibilité, garder la connexion avec Hibernate pendant tout le temps du traitement de la requête Web de l’utilisateur.
Pour se faire, on doit ouvrir la transaction au début du traitement de la requête pour ne la restituer qu’à la fin de la génération de la vue.

On modifie le web.xml :

	<filter>
		<filter-name>OpenSessionInViewFilter</filter-name>
		<filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>
	</filter>
	<filter-mapping>
		<filter-name>OpenSessionInViewFilter</filter-name>
		<url-pattern>*.do</url-pattern>
	</filter-mapping>

Dans cette configuration, le filtre OpenSessionInViewFilter mis sur tous les appels *.do va déclencher une ouverture de session hibernate jusqu’à la restitution de la vue.
Ainsi, si dans la JSP, on trouve une itération de l’attribut cols du bean Dossier, un appel à la base de données via Hibernate sera déclenché à ce moment là (et seulement à ce moment là).
Autrement dit, si pour une autre JSP vous n’avez pas besoin d’afficher la collection, l’appel à la base ne sera pas réalisé.

Au début, j’ai regardé le format APT qui a l’avantage certain de générer du contenu directement consultable sous forme de page Web. Il existe de plus un plugin qui permet de fabriquer un PDF en regroupant les fichiers APT souhaités.

Mais, cela reste un nouveau langage à apprendre pour des équipes fonctionnelles et le format APT est trop limité pour permettre un travail efficace par les équipes de conception ou d’analyse.
Après avoir tourné et viré, testé quelques solutions, j’en suis arrivé à la conclusion que le plus pratique est de laisser les concepteurs utiliser leurs outils office (Microsoft ou oOo) et de transformer ces documents en PDF lors de la fabrication du site.

Pour cela, un petit plugin miracle (jodconverter-maven-plugin) couplé à oOo permet de faire le travail.

Tout d’abord, il faut lancer oOo en mode serveur. Sous Linux, ça se fait comme ça :

/opt/openoffice.org3/program/soffice -headless -accept="socket,host=localhost,port=8100;urp;" -nofirststartwizard

Sous Windows :

"C:\Program Files\OpenOffice.org 3\program\soffice.exe" -accept="socket,host=localhost,port=8100;urp;"

Puis ajouter dans le pom.xml :

<build>
<plugins>
<plugin>
<groupId>com.artofsolving</groupId>
<artifactId>jodconverter-maven-plugin</artifactId>
<version>2.2.3</version>
<inherited>false</inherited>
<configuration>
<sourceDirectory>${basedir}/src/site/docs</sourceDirectory>
<outputDirectory>${project.reporting.outputDirectory}/docs</outputDirectory>
<include>**/*.odt,**/*.odp</include>
<outputFormat>pdf</outputFormat>
<port>8100</port>
</configuration>
<executions>
<execution>
<id>convert</id>
<phase>pre-site</phase>
<goals>
<goal>convert</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>

Ainsi, lors de la génération du site, tous les documents odt ou odp présents dans le répertoire /src/site/docs et sous-répertoires seront transformés en documents PDF dans le répertoire de sortie du site sous /docs. Les sous-répertoires sont également recréés.

Il ne reste plus qu’à faire des liens vers ces documents générés que ce soit dans site.xml ou dans un fichier APT.

Dans l’exemple suivant, le fichier source MonDoc.odt se trouve dans /src/site/docs/1.

<!-- Extrait du site.xml -->
<body>
<menu name="Fonctionnel">
<item name="Mon document" href="./docs/1/MonDoc.pdf" />
</menu>
</body>

Dans le cadre des projets que je gère, j’ai mis en place Hudson qui me reconstruit toutes les nuits une vision documentaire de mes projets. Ainsi, lorsqu’un concepteur valide dans CVS ou SVN pendant la journée un document, il est automatiquement publié la nuit sur le site Maven correspondant.

Autre intérêt : à chaque livraison (release), une photographie complète de l’état de la documentation au moment de la fabrication des livrables est générée. Il est ainsi possible de retrouver facilement le contexte fonctionnel d’une version particulière…

Histoire d’être cohérent avec d’autres choix faits par l’administration, projet Adullact, j’ai retenu la forge GFORGE.

Je vais décrire ici le processus d’installation que je vais suivre afin de partager cette information avec d’autres personnes qui pourraient être intéressés par cette démarche.

Installation de la Forge sur Ubuntu 9.10

Tout d’abord, il faut télécharger les sources de la forge. Je me suis basé sur la dernière version connue à ce moment : 5.7b2 Community Edition.

Correction du problème avec Postgresql

La version de postgres téléchargée par Ubuntu ne correspond pas à la version attendue dans le script d’installation install-gforge-2-db.php.

Pour corriger ce problème, j’ai remplacé partout (sauf à la fin) la version 8.3 par 8.4.

Par exemple la ligne

'/etc/init.d/postgresql-8.3',

est devenue

'/etc/init.d/postgresql-8.4',

Correction du problème avec la distribution Apache pour Ubuntu (Rewrite)

La gestion de la configuration Apache n’est pas « standard » sur Ubuntu. J’ai donc suivi les recommandations du blog de Josh Street pour corriger le problème.

cd /etc/apache2/mods-enabled
sudo ln -s ../mods-available/rewrite.load rewrite.load
sudo service apache2 start

Finalement, Adullact a annoncé vouloir passer sous FusionForge qui est un fork de GForge afin de conserver la forge dans le monde open-source. La team FusionForge travaille en ce moment sur la version 5.0 mais elle n’est pas encore stabilisée. Nous allons donc installer la version 4.8.3.

La mise en place de FusionForge est abordée dans cet article.

David

De quoi s’agit-il ?

Ni plus, ni moins que ce que tout développeur Java cherche : un hébergement gratuit d’applications Java. Bon, il ne s’agit pas d’un serveur J2EE du type JBoss, Glassfish ou autre mais il permet de faire tourner des applications Web (des Webapps Java)  et de pouvoir y intégrer les outils Google.

Je viens juste de créer mon compte, de diriger mon domaine vers ce site et de faire tourner une application de base générée avec le plugin Eclipse pour google.

Je vais compléter cet article au fur et à mesure de découvertes…

Stay tuned !