Un environnement de developpement Java: Création de l’arborescence du projet

Le gestionnaire de source installé et paramétré, il est maintenant possible d’y importer la première mouture de l’arborescence du projet. Il s’agit de l’étape sine-qua-none d’un développement distribué et multi-utilisateur. Comme nous utilisons un gestionnaire de source gérant le renommage et le déplacement de fichier, il n’est pas nécessaire d’avoir la structure de répertoire définitive. Il suffit d’ajouter au repository une structure fonctionnel c’est-à-dire qui compile au moins et nous pourrons toujours la modifier par la suite.

Nous adoptons l’arborescence de projet définie par Maven 2 et l”DE utilisé Netbeans, va nous simplifier la tâche en nous apportant une intégration poussée avec Maven. Pour cela aller dans le menu Tools > plugin puis l’onglet Available Plugins. Sélectionner Maven puis cliquer sur Installer.

Netbeans > Menu Tools > PLugin Ajout duplugin Maven

Le plugin maven permet d’ajouter dans Netbeans des menus pour lancer des goals maven et une intégration poussée des concepts de Maven dans les fenêtres d’éditions.

La création d’un projet Maven dans Netbeans est alors très simplifiée. Aller dans le menu File > New Project puis choisir la catégorie Maven et le type Maven Project. Cela donne accès à une liste d’archetype c’est-à-dire de modèle de projet Maven. Il en existe de trés nombreux et le chargement de cette liste est un peu long  la première fois qu’on l’utilise (En effet sont contenu est rapatrié depuis internet). Pour les besoins de l’article nous allons simplement choisir Maven Quickstart Archetype. Il permet de créer un projet qui génère un jar. Il en existe de beaucoup plus complexe et Maven nous  permet d’en créer nous même afin de répondre à tous les besoins. Le dernier écran permet de renseigner les informations primordiales du nouveau projet: nom, paquet, version.

Fênetre de création de projet de Netbeans Fenêtre de selection de l'archetype utilisé dans la création de projet Maven Fenetre de personnalisation du projet qui va être créé par un archetype Maven

La création du projet va prendre quelque seconde la première fois que vous utilisez cette fonction. En effet le principe de maven est de ne pas inclure les dépendances d’un projet. L’éxecution de l’archétype pour le création d’un projet est un cas particulier de build maven. Les dépendances sont donc téléchargées depuis le repository central de Maven. Ce téléchargement n’interviendra qu’une seule fois et les dépendances seront conservées dans le repository maven 2 du plugin Netbeans i.e. quelque part dans les fichiers internes de Netbeans.

Voici un exemple de log d’éxecution quand il n’est pas nécessaire de résoudre par internet les dépendances manquantes:

Scanning for projects…
project-execute
Setting property: classpath.resource.loader.class => ‘org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader’.
Setting property: velocimacro.messages.on => ‘false’.
Setting property: resource.loader => ‘classpath’.
Setting property: resource.manager.logwhenfound => ‘false’.
**************************************************************
Starting Jakarta Velocity v1.4
RuntimeInstance initializing.
Default Properties File: org/apache/velocity/runtime/defaults/velocity.properties
Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl)
Resource Loader Instantiated: org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
ClasspathResourceLoader : initialization starting.
ClasspathResourceLoader : initialization complete.
ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl)
Default ResourceManager initialization complete.
Loaded System Directive: org.apache.velocity.runtime.directive.Literal
Loaded System Directive: org.apache.velocity.runtime.directive.Macro
Loaded System Directive: org.apache.velocity.runtime.directive.Parse
Loaded System Directive: org.apache.velocity.runtime.directive.Include
Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
Created: 20 parsers.
Velocimacro : initialization starting.
Velocimacro : adding VMs from VM library template : VM_global_library.vm
[ERROR]ResourceManager : unable to find resource ‘VM_global_library.vm’ in any resource loader.
Velocimacro : error using  VM library template VM_global_library.vm : org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource ‘VM_global_library.vm’
Velocimacro :  VM library template macro registration complete.
Velocimacro : allowInline = true : VMs can be defined inline in templates
Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions
Velocimacro : allowInlineLocal = false : VMs defined inline will be  global in scope if allowed.
Velocimacro : initialization complete.
Velocity successfully started.
[archetype:create]
—————————————————————————-
Using following parameters for creating Archetype: maven-archetype-quickstart:1.0
—————————————————————————-
Parameter: groupId, Value: net.bressure
Parameter: packageName, Value: net.bressure.vroom
Parameter: package, Value: net.bressure.vroom
Parameter: artifactId, Value: vroom
Parameter: basedir, Value: /home/thierry/NetBeansProjects
Parameter: version, Value: 1.0-SNAPSHOT
********************* End of debug info from resources from generated POM ***********************
Archetype created in dir: /home/thierry/NetBeansProjects/vroom
————————————————————————
BUILD SUCCESSFUL
————————————————————————
Total time: < 1 second
Finished at: Mon Oct 06 12:50:15 CEST 2008
Final Memory: 66M/69M
————————————————————————

Le projet qui vien d’être créé est compilable et comporte déjà les prémices de l’atelier de développement Java agile. Le build du projet passe par une phase d’éxécution des tests unitaires. Voici un exemple de sortie en faisant un clic-droit sur le projet et sélectionnant build :

Scanning for projects…
project-execute
[#process-resources]
[resources:resources]
Using default encoding to copy filtered resources.
[#compile]
[compiler:compile]
Nothing to compile – all classes are up to date
[#process-test-resources]
[resources:testResources]
Using default encoding to copy filtered resources.
[#test-compile]
[compiler:testCompile]
Nothing to compile – all classes are up to date
[#test]
[surefire:test]
Surefire report directory: /home/thierry/NetBeansProjects/vroom/target/surefire-reports
——————————————————-
T E S T S
——————————————————-
Running net.bressure.vroom.AppTest
Results :
[#package]
[jar:jar]
[#install]
[install:install]
Installing /home/thierry/NetBeansProjects/vroom/target/vroom-1.0-SNAPSHOT.jar to /home/thierry/.m2/repository/net/bressure/vroom/1.0-SNAPSHOT/vroom-1.0-SNAPSHOT.jar
————————————————————————
BUILD SUCCESSFUL
————————————————————————
Total time: 1 second
Finished at: Mon Oct 06 16:23:49 CEST 2008
Final Memory: 18M/56M
————————————————————————

Un projet qui build est un projet qui doit être partagé. Nous allons importer dans le repository l’arborescence du projet. Pour ce faire Netbeans s’interface avec Subversion à merveille. Sur le projet utiliser un clic droit > Versionning > Import to Subversion Repository pour accéder à la fenêtre de dialogue pour choisir l’emplacement sur le serveur subversion.

Nebeans Menu d'import de nouveau sources dans Subversion Netbeans Dialogue d'import de sources dans subversion

L’url à renseignée est de la forme svn://<serveur>/<projet>/trunk et dans le cas de l’article cela donne svn://localhost/vroom/trunk

Dans la boite de dialogue suivante supprimer le dernier répertoire pour ne garder que <projet>/trunk

Le trunk final est important car cela respecte l’arborescence classique des projets sous Subversion. Le trunk est l’équivalent de la HEAD sous CVS.

Nous avons créé un projet maven 2 en utilisant un archétype. Le projet est disponible dans le référentiel de source Subversion. La prochaine étape va être la mise en place de l’intégration continue.

Un environnement de developpement Java: Création de l’arborescence du projet

Le gestionnaire de source installé et paramétré, il est maintenant possible d’y importer la première mouture de l’arborescence du projet. Il s’agit de l’étape sine-qua-none d’un développement distribué et multi-utilisateur. Comme nous utilisons un gestionnaire de source gérant le renommage et le déplacement de fichier, il n’est pas nécessaire d’avoir la structure de répertoire définitive. Il suffit d’ajouter au repository une structure fonctionnel c’est-à-dire qui compile au moins et nous pourrons toujours la modifier par la suite.

Nous adoptons l’arborescence de projet définie par Maven 2 et l”DE utilisé Netbeans, va nous simplifier la tâche en nous apportant une intégration poussée avec Maven. Pour cela aller dans le menu Tools > plugin puis l’onglet Available Plugins. Sélectionner Maven puis cliquer sur Installer.

Netbeans > Menu Tools > PLugin Ajout duplugin Maven

Le plugin maven permet d’ajouter dans Netbeans des menus pour lancer des goals maven et une intégration poussée des concepts de Maven dans les fenêtres d’éditions.

La création d’un projet Maven dans Netbeans est alors très simplifiée. Aller dans le menu File > New Project puis choisir la catégorie Maven et le type Maven Project. Cela donne accès à une liste d’archetype c’est-à-dire de modèle de projet Maven. Il en existe de trés nombreux et le chargement de cette liste est un peu long  la première fois qu’on l’utilise (En effet sont contenu est rapatrié depuis internet). Pour les besoins de l’article nous allons simplement choisir Maven Quickstart Archetype. Il permet de créer un projet qui génère un jar. Il en existe de beaucoup plus complexe et Maven nous  permet d’en créer nous même afin de répondre à tous les besoins. Le dernier écran permet de renseigner les informations primordiales du nouveau projet: nom, paquet, version.

Fênetre de création de projet de Netbeans Fenêtre de selection de l'archetype utilisé dans la création de projet Maven Fenetre de personnalisation du projet qui va être créé par un archetype Maven

La création du projet va prendre quelque seconde la première fois que vous utilisez cette fonction. En effet le principe de maven est de ne pas inclure les dépendances d’un projet. L’éxecution de l’archétype pour le création d’un projet est un cas particulier de build maven. Les dépendances sont donc téléchargées depuis le repository central de Maven. Ce téléchargement n’interviendra qu’une seule fois et les dépendances seront conservées dans le repository maven 2 du plugin Netbeans i.e. quelque part dans les fichiers internes de Netbeans.

Voici un exemple de log d’éxecution quand il n’est pas nécessaire de résoudre par internet les dépendances manquantes:

Scanning for projects…
project-execute
Setting property: classpath.resource.loader.class => ‘org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader’.
Setting property: velocimacro.messages.on => ‘false’.
Setting property: resource.loader => ‘classpath’.
Setting property: resource.manager.logwhenfound => ‘false’.
**************************************************************
Starting Jakarta Velocity v1.4
RuntimeInstance initializing.
Default Properties File: org/apache/velocity/runtime/defaults/velocity.properties
Default ResourceManager initializing. (class org.apache.velocity.runtime.resource.ResourceManagerImpl)
Resource Loader Instantiated: org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
ClasspathResourceLoader : initialization starting.
ClasspathResourceLoader : initialization complete.
ResourceCache : initialized. (class org.apache.velocity.runtime.resource.ResourceCacheImpl)
Default ResourceManager initialization complete.
Loaded System Directive: org.apache.velocity.runtime.directive.Literal
Loaded System Directive: org.apache.velocity.runtime.directive.Macro
Loaded System Directive: org.apache.velocity.runtime.directive.Parse
Loaded System Directive: org.apache.velocity.runtime.directive.Include
Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
Created: 20 parsers.
Velocimacro : initialization starting.
Velocimacro : adding VMs from VM library template : VM_global_library.vm
[ERROR]ResourceManager : unable to find resource ‘VM_global_library.vm’ in any resource loader.
Velocimacro : error using  VM library template VM_global_library.vm : org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource ‘VM_global_library.vm’
Velocimacro :  VM library template macro registration complete.
Velocimacro : allowInline = true : VMs can be defined inline in templates
Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT replace previous VM definitions
Velocimacro : allowInlineLocal = false : VMs defined inline will be  global in scope if allowed.
Velocimacro : initialization complete.
Velocity successfully started.
[archetype:create]
—————————————————————————-
Using following parameters for creating Archetype: maven-archetype-quickstart:1.0
—————————————————————————-
Parameter: groupId, Value: net.bressure
Parameter: packageName, Value: net.bressure.vroom
Parameter: package, Value: net.bressure.vroom
Parameter: artifactId, Value: vroom
Parameter: basedir, Value: /home/thierry/NetBeansProjects
Parameter: version, Value: 1.0-SNAPSHOT
********************* End of debug info from resources from generated POM ***********************
Archetype created in dir: /home/thierry/NetBeansProjects/vroom
————————————————————————
BUILD SUCCESSFUL
————————————————————————
Total time: < 1 second
Finished at: Mon Oct 06 12:50:15 CEST 2008
Final Memory: 66M/69M
————————————————————————

Le projet qui vien d’être créé est compilable et comporte déjà les prémices de l’atelier de développement Java agile. Le build du projet passe par une phase d’éxécution des tests unitaires. Voici un exemple de sortie en faisant un clic-droit sur le projet et sélectionnant build :

Scanning for projects…
project-execute
[#process-resources]
[resources:resources]
Using default encoding to copy filtered resources.
[#compile]
[compiler:compile]
Nothing to compile – all classes are up to date
[#process-test-resources]
[resources:testResources]
Using default encoding to copy filtered resources.
[#test-compile]
[compiler:testCompile]
Nothing to compile – all classes are up to date
[#test]
[surefire:test]
Surefire report directory: /home/thierry/NetBeansProjects/vroom/target/surefire-reports
——————————————————-
T E S T S
——————————————————-
Running net.bressure.vroom.AppTest
Results :
[#package]
[jar:jar]
[#install]
[install:install]
Installing /home/thierry/NetBeansProjects/vroom/target/vroom-1.0-SNAPSHOT.jar to /home/thierry/.m2/repository/net/bressure/vroom/1.0-SNAPSHOT/vroom-1.0-SNAPSHOT.jar
————————————————————————
BUILD SUCCESSFUL
————————————————————————
Total time: 1 second
Finished at: Mon Oct 06 16:23:49 CEST 2008
Final Memory: 18M/56M
————————————————————————

Un projet qui build est un projet qui doit être partagé. Nous allons importer dans le repository l’arborescence du projet. Pour ce faire Netbeans s’interface avec Subversion à merveille. Sur le projet utiliser un clic droit > Versionning > Import to Subversion Repository pour accéder à la fenêtre de dialogue pour choisir l’emplacement sur le serveur subversion.

Nebeans Menu d'import de nouveau sources dans Subversion Netbeans Dialogue d'import de sources dans subversion

L’url à renseignée est de la forme svn://<serveur>/<projet>/trunk et dans le cas de l’article cela donne svn://localhost/vroom/trunk

Dans la boite de dialogue suivante supprimer le dernier répertoire pour ne garder que <projet>/trunk

Le trunk final est important car cela respecte l’arborescence classique des projets sous Subversion. Le trunk est l’équivalent de la HEAD sous CVS.

Nous avons créé un projet maven 2 en utilisant un archétype. Le projet est disponible dans le référentiel de source Subversion. La prochaine étape va être la mise en place de l’intégration continue.

Un environnement de developpement Java: création d’un projet

Les outils qui vont être utilisés sont déjà selectionnés et installés. Nous allons maintenant vérifier que tout fonctionne bien en créant un premier projet. La régle principale que je me fixe quand je dois créer un projet est que l’ensemble de la chaine de production doit être fonctionnelle avant tout développement à proprement parler. Cela siginifie que le dépot de source, le système de build et de reporting doivent être en parfait état de marche.

Dans le cas de notre environnement il s’agit de vérifier que Subversion, le mécanisme de build maven 2  couplé au système d’intégration continue Continuum sont pleinement fonctionnels.

L’installation de Subversion via le gestionnaire de paquet constituent seulement le dépaquetage du logiciel. Il faut encore créer  un “repository” ou dépôt de source puis paramétrer le serveur pour permettre l’accès à ce dépôt en distant. N’oublions pas que nous créons notre environnement de développement dans l’optique d’être un environnement ressemblant le plus possible à celui utilisé dans une équipe de plusieurs personnes. Pour cela nous commençons par créer le dépôt de sources en ouvrant une console et tapant la commande suivante

mkdir /home/thierry/repository/svn/default

Bien entendu vous aller utiliser le chemin qui correspond le mieux à votre besoin. Dans mon cas je veux seulement un repository dans mon répertoire personnel.Puis il faut initialiaser ce dépôt par la command :

svnadmin create /home/thierry/repository/svn/default

Puis il faut paramétrer le démon svnserve pour rendre ce repository accessible en distant. Cela passe par la création d’un fichier de /etc/init.d/svnserve

sudo vim /etc/init.d/svnserve

Voici le contenu du fichier

#!/bin/sh

set -e
if [ -x /usr/bin/svnserve ] ; then
HAVE_SVNSERVE=1
else
echo “Svnserve not installed.”
exit 0
fi

. /lib/lsb/init-functions

case “$1” in
start)
log_action_begin_msg “Starting SVN server”
svnserve -d -r /home/thierry/repository/svn/default
log_action_end_msg $?
;;
stop)
log_action_begin_msg “Stoping SVN server”
start-stop-daemon –stop –exec /usr/bin/svnserve
log_action_end_msg $?
;;
force-reload|restart)
$0 stop
$0 start
;;
*)
echo “Usage: /etc/init.d/svnserve {start|stop|restart|force-reload}”
exit 1
;;
esac

exit 0

Ajouter les droits d’éxécution au script par :

sudo chmod +x /etc/init.d/svnserve

Ce script devra être lancé automatiquement au démarrage de la machine. Nous l’ajoutons aux services de démarrage comme suit:

sudo update-rc.d svnserve defaults

Voilà le serveur de source est presque prêt. Il ne reste que l’étape des droit d’accès. En effet une Software Factory  ne doit pas permettre un accès non contrôlé au dépôt de source. Aller dans le répertoire du repository i.e. /home/thierry/repository/svn/default

repository subversion

Allez ensuite dans le répertoir conf qui contient les fichiers svnserve.conf et passwd. Modifier le fichier svnserve.conf en décommentant les lignes suivantes:

anon-access = read
auth-access = write
password-db = passwd

Cela a pour effet de n’autoriser que les utilisateurs authentifiés à modifier les sources, les autres ayant un accès en lecture seule. L’authentification se fait par le fichier passwd en y mettant des couples login = password comme par exemple :

thierry = thierry

Enfin le serveur de source est prêt. Lancer le par la commande suivante :

sudo /etc/init.d/svnserve start

Le titre de l’article est volontairement non révélateur de son contenu afin de souligner que la création d’un projet nécessite des étapes de préparation préalables. La première étape de la créationde l’environnement de développement est la mise en place du dépôt de source. Mais que l’on se rassure, la création d’un repository ne se fait pas à chaque fois que l’on crée un projet. Le prochain article de la série traitera de la création de l’arborescence du projet et de l’import dans le repository.

Un environnement de developpement Java: création d’un projet

Les outils qui vont être utilisés sont déjà selectionnés et installés. Nous allons maintenant vérifier que tout fonctionne bien en créant un premier projet. La régle principale que je me fixe quand je dois créer un projet est que l’ensemble de la chaine de production doit être fonctionnelle avant tout développement à proprement parler. Cela siginifie que le dépot de source, le système de build et de reporting doivent être en parfait état de marche.

Dans le cas de notre environnement il s’agit de vérifier que Subversion, le mécanisme de build maven 2  couplé au système d’intégration continue Continuum sont pleinement fonctionnels.

L’installation de Subversion via le gestionnaire de paquet constituent seulement le dépaquetage du logiciel. Il faut encore créer  un “repository” ou dépôt de source puis paramétrer le serveur pour permettre l’accès à ce dépôt en distant. N’oublions pas que nous créons notre environnement de développement dans l’optique d’être un environnement ressemblant le plus possible à celui utilisé dans une équipe de plusieurs personnes. Pour cela nous commençons par créer le dépôt de sources en ouvrant une console et tapant la commande suivante

mkdir /home/thierry/repository/svn/default

Bien entendu vous aller utiliser le chemin qui correspond le mieux à votre besoin. Dans mon cas je veux seulement un repository dans mon répertoire personnel.Puis il faut initialiaser ce dépôt par la command :

svnadmin create /home/thierry/repository/svn/default

Puis il faut paramétrer le démon svnserve pour rendre ce repository accessible en distant. Cela passe par la création d’un fichier de /etc/init.d/svnserve

sudo vim /etc/init.d/svnserve

Voici le contenu du fichier

#!/bin/sh

set -e
if [ -x /usr/bin/svnserve ] ; then
HAVE_SVNSERVE=1
else
echo “Svnserve not installed.”
exit 0
fi

. /lib/lsb/init-functions

case “$1” in
start)
log_action_begin_msg “Starting SVN server”
svnserve -d -r /home/thierry/repository/svn/default
log_action_end_msg $?
;;
stop)
log_action_begin_msg “Stoping SVN server”
start-stop-daemon –stop –exec /usr/bin/svnserve
log_action_end_msg $?
;;
force-reload|restart)
$0 stop
$0 start
;;
*)
echo “Usage: /etc/init.d/svnserve {start|stop|restart|force-reload}”
exit 1
;;
esac

exit 0

Ajouter les droits d’éxécution au script par :

sudo chmod +x /etc/init.d/svnserve

Ce script devra être lancé automatiquement au démarrage de la machine. Nous l’ajoutons aux services de démarrage comme suit:

sudo update-rc.d svnserve defaults

Voilà le serveur de source est presque prêt. Il ne reste que l’étape des droit d’accès. En effet une Software Factory  ne doit pas permettre un accès non contrôlé au dépôt de source. Aller dans le répertoire du repository i.e. /home/thierry/repository/svn/default

repository subversion

Allez ensuite dans le répertoir conf qui contient les fichiers svnserve.conf et passwd. Modifier le fichier svnserve.conf en décommentant les lignes suivantes:

anon-access = read
auth-access = write
password-db = passwd

Cela a pour effet de n’autoriser que les utilisateurs authentifiés à modifier les sources, les autres ayant un accès en lecture seule. L’authentification se fait par le fichier passwd en y mettant des couples login = password comme par exemple :

thierry = thierry

Enfin le serveur de source est prêt. Lancer le par la commande suivante :

sudo /etc/init.d/svnserve start

Le titre de l’article est volontairement non révélateur de son contenu afin de souligner que la création d’un projet nécessite des étapes de préparation préalables. La première étape de la créationde l’environnement de développement est la mise en place du dépôt de source. Mais que l’on se rassure, la création d’un repository ne se fait pas à chaque fois que l’on crée un projet. Le prochain article de la série traitera de la création de l’arborescence du projet et de l’import dans le repository.

Un environnement de developpement Java

J’ai eu envie de faire un petit développement personnel en Java et comme j’avais réinstallé mon ordinateur, je devais refaire mon environnement depuis le début. Ce n’est d’ailleurs pas un si grand mal et l’exercice serait même intéressant car il arrive que nous devions le faire quand par exemple une défaillance de notre IDE survient comme un crash d’Eclipse réduisant à néant la configuration du workspace.

En partant d’une distribution classique Ubuntu 64 bit avec les dépôts officiels, peut-on monter un environnement de développement Java ? Est-il nécessaire d’installer des logiciels manuellement et donc maintenir par soi-même les mise-à-jour ? Est-ce que l’installation est accessible ou nécessite-t-elle une équipe système ? Pour réponde à ces questions il faut commencer par définir ce dont nous avons besoin.

Le système d’exploitation est un Linux abordable: Ubuntu. Nous supposons qu’il est déjà installé et fonctionnel. C’est une supposition très raisonnable. A partir de là il nous faut obtenir un environnement de développement Java complet comprenant :

  • un outils de modélisation
  • un éditeur de source
  • un compilateur
  • un outils de versionnage
  • un outils d’intégration continue

L’outil de modélisation sera bien pratique pour les phases préliminaires avant tout codage et devra permettre au moins la génération de code. L’opération inverse sera aussi utile car une fois emporté dans le code on risque bien d’oublier l’architecture générale et voire même la galvauder dans notre élan. Nous pouvons soit opter pour outils dédié  comme BOUML ou bien se contenter des fonctions UML de l’IDE. LEs 2 IDE open-source majeurs propose de l’UML.

L’IDE doit permettre d’écrire du code, d’apporter la coloration syntaxique, l’assistance à la frappe, le debogguage et le support de plusieurs JVM. L’IDE ne doit pas nous enfermé dans un système propriétaire de build et devra donc s’interfacer simplement avec notre outil de build préféré : Maven. Nous porterons notre choix sur Netbeans dont l’offre “packagée” estplus complète que Eclipse et mieux adapté que ce dernier pour une utilisation avec Maven.  La version 6.0 est installable directement depuis Ubuntu en utilisant Synaptic. Il faudra ajouter les plugins Subversion, Maven et UML pour completer l’installation de base. Cela ce fait directement depuis l’ID.

La partie compilateur dans le cas de java se compose du JDK  qui est l’ensemble des outils pour compiler et debugger des programmes écrit en Java. Le JDK contient aussi un JRE qui permet d’éxécuter les programmes Java. C’est le point de départ de notre environnement. Les dépots officiels d’Ubuntu propose OpenJDK 1.6 donc son installation se fera le plus simplement du monde via le gestionnaire de paquet Synaptic.

L’outils de versionnage devra permettre un refactoring constant du code et devra gérer le renommage les déplacements de fichiers sans perte d’historique sans avoir recours à l’administration du serveur. On choisira naturellement subversion dont l’installation est possible depuis les dépôt Ubuntu.

L’intégration continue est une pratique obligatoire dans les projets nécessitant plusieurs développeurs ou plusieurs module devant être assemblés. Cependant même dans le cas d’un seul développeur il aura besoin de découper le projet en modules qui devront être assemblés. Un outils permettant d’assurer le que l’ensemble “fonctionnent” correctement est nécessaire. Afin de simplifier l’intégration nous allons choisir Continuum qui se marie à merveille avec Maven. Son installation se fera manuellement en décompressant l’archive trouvé sur le site officiel de continuum

Enfin pour terminer la liste des outils nous mentionnerons l’outils de build maven qui est avec l’intégration continue les éléments le splus importants de l’environnement de developpement d’un point de vue structurel. Nous allons installer maven par le biais de Synaptic. Pour simplifier et offrir une évolutivité maximal dans l’utilisation de maven nous allons utiliser le gestionnaire de repository Apache Archiva

Maintenant que tout est installé, il faut s’assurer que tout fonctionne bien ensemble. Pour cela l’article suivant traitera de la création initiale du projet.

Solution propriétaire dans l’atelier de production logicielle Java

Il est courant de faire l’éloge des outils open source dans l’atelier de production logicielle au travers de Maven ou Eclipse, mais est-ce par idéologie ou par raison économique ou bien par réel intérêt ? N’existe-t-il pas des cas où les solutions propriétaires constituent un alternative judicieuse ?

Nous entendons par atelier de production logiciel ou usine de production logiciel, l’ensemble des composants techniques et processus permettant de réaliser le logiciel. Cela va des outils de spécification, de modélisation aux outils de contrôle de la qualité en passant par les outils de développement. Il est indéniable que là où se battaient pléthore éditeurs comme Symantec ou Borland, ne subsiste aujourd’hui qu’un ou deux acteurs commerciaux tel que IBM tellement les solutions open source sont devenues  légions. Mais derrière cette percée de l’open source il se cache peut-être une disparité de l’offre.

Nous pouvons distinguer plusieurs domaines suivant l’usage de l’outil en commençant par la phase de conception et de spécification. Les AGL (Atelier de Génie Logiciel) sont un domaine où l’open source est très peu présent et ne peut rivaliser avec les offres payantes. Les fonctions de round-trip (aller-retour entre le code et le modèle) ainsi que la prise en charge de technologie d’implémentation (EJB, Webservice) sont l’apanache des solutions propriétaires payantes. Au contraire le domaine des outils de build et les IDE sont le terrain de jeux de l’open-source. Le système de build Ant est devenu le standard à l’intérieur de nombreux IDE, même propriétaires. Mais aujourd’hui ce système de build est vieillissant et sera supplanté par Maven dont les principaux IDE commencent à s’accommoder et il n’est pas nécessaire de s’appesentir sur la “part de marché” d’Eclipse dans les IDE. Enfin l’autre bout du spectre, celui du contrôle de la qualité au travers des outils d’intégration continue et de tests automatiques est mitigé. L’intégration continue est un concept avancé du génie logiciel que les éditeurs n’ont pas encore exploité laissant le champ libre à l’open source avec CruiseControl par exemple. A l’inverse le concept de test d’intégration est très industrialisé les éditeurs sont présents avec par exemple TestDirector.

Finalement c’est la partie centrale constituée du developpement et un peu de la phase suivante que l’open source occupe réellement dans l’atelier de production logiciel. La présence de brique propriétaire est donc encore nécessaire.

Cette situation va-t-elle évolué ? Pour les idéalistes de l’open source il serait de bon ton que les récents efforts pour intégrer des fonctionnalité UML directement aux IDE se poursuivent a l’instar de Netbeans . Ainsi la première phase de l’atelier sera conquise. Reste à savoir si le phase d’intégration évoluera vers une prise en charge complète par l’open source. Je tiens le pari que oui. L’histoire a montré que la valeur ajoutée de l’informatique s’est déplacée du matériel au logiciel et aujourd’hui elle se déplace du logiciel au service. Les éditeurs de logiciels non personnalisés que ce soit des logiciels outils ou pas sont bien concurrencés par l’open source comme le montre OpenOffice. Les éditeurs de logiciel devront faire du sur-mesure ou offrir du service d’expertise. Les raisons pour lesquels cette évolution me semble inéluctable est que la pression sur les coûts pousse à une rationalisation des dépenses. L’entreprise préfère utiliser chaque euro du budget du projet dans la création de fonctionnalité à valeur ajoutée donc la pression sur les coûts des outils fait tourner l’entreprise vers des solutions open-source gratuites. Cela réduit les revenus des éditeurs d’outils propriétaires qui pour assurer leur rentabilité ont tendance à réutiliser des solutions open-source maquillées dans leur produit.

Solution propriétaire dans l’atelier de production logicielle Java

Il est courant de faire l’éloge des outils open source dans l’atelier de production logicielle au travers de Maven ou Eclipse, mais est-ce par idéologie ou par raison économique ou bien par réel intérêt ? N’existe-t-il pas des cas où les solutions propriétaires constituent un alternative judicieuse ?

Nous entendons par atelier de production logiciel ou usine de production logiciel, l’ensemble des composants techniques et processus permettant de réaliser le logiciel. Cela va des outils de spécification, de modélisation aux outils de contrôle de la qualité en passant par les outils de développement. Il est indéniable que là où se battaient pléthore éditeurs comme Symantec ou Borland, ne subsiste aujourd’hui qu’un ou deux acteurs commerciaux tel que IBM tellement les solutions open source sont devenues  légions. Mais derrière cette percée de l’open source il se cache peut-être une disparité de l’offre.

Nous pouvons distinguer plusieurs domaines suivant l’usage de l’outil en commençant par la phase de conception et de spécification. Les AGL (Atelier de Génie Logiciel) sont un domaine où l’open source est très peu présent et ne peut rivaliser avec les offres payantes. Les fonctions de round-trip (aller-retour entre le code et le modèle) ainsi que la prise en charge de technologie d’implémentation (EJB, Webservice) sont l’apanache des solutions propriétaires payantes. Au contraire le domaine des outils de build et les IDE sont le terrain de jeux de l’open-source. Le système de build Ant est devenu le standard à l’intérieur de nombreux IDE, même propriétaires. Mais aujourd’hui ce système de build est vieillissant et sera supplanté par Maven dont les principaux IDE commencent à s’accommoder et il n’est pas nécessaire de s’appesentir sur la “part de marché” d’Eclipse dans les IDE. Enfin l’autre bout du spectre, celui du contrôle de la qualité au travers des outils d’intégration continue et de tests automatiques est mitigé. L’intégration continue est un concept avancé du génie logiciel que les éditeurs n’ont pas encore exploité laissant le champ libre à l’open source avec CruiseControl par exemple. A l’inverse le concept de test d’intégration est très industrialisé les éditeurs sont présents avec par exemple TestDirector.

Finalement c’est la partie centrale constituée du developpement et un peu de la phase suivante que l’open source occupe réellement dans l’atelier de production logiciel. La présence de brique propriétaire est donc encore nécessaire.

Cette situation va-t-elle évolué ? Pour les idéalistes de l’open source il serait de bon ton que les récents efforts pour intégrer des fonctionnalité UML directement aux IDE se poursuivent a l’instar de Netbeans . Ainsi la première phase de l’atelier sera conquise. Reste à savoir si le phase d’intégration évoluera vers une prise en charge complète par l’open source. Je tiens le pari que oui. L’histoire a montré que la valeur ajoutée de l’informatique s’est déplacée du matériel au logiciel et aujourd’hui elle se déplace du logiciel au service. Les éditeurs de logiciels non personnalisés que ce soit des logiciels outils ou pas sont bien concurrencés par l’open source comme le montre OpenOffice. Les éditeurs de logiciel devront faire du sur-mesure ou offrir du service d’expertise. Les raisons pour lesquels cette évolution me semble inéluctable est que la pression sur les coûts pousse à une rationalisation des dépenses. L’entreprise préfère utiliser chaque euro du budget du projet dans la création de fonctionnalité à valeur ajoutée donc la pression sur les coûts des outils fait tourner l’entreprise vers des solutions open-source gratuites. Cela réduit les revenus des éditeurs d’outils propriétaires qui pour assurer leur rentabilité ont tendance à réutiliser des solutions open-source maquillées dans leur produit.