Discussion :

[vinzzzz]

Hello,

Je souhaiterai mettre en place un framework permettant de gérer quelques projets JAVA de la manière la plus simple et clean possible. Rapidement, il y a pour l'instant 3 développeurs (1 très actif, 2 occasionels), et 4 projets JAVA, dont 1 central dont dépendent les 3 autres. Chaque projet a certaines dépendances externes spécifiques, et ils ont également tous des dépendances partagées. La plupart d'entre eux génèrent des .jar que l'on souhaite ensuite déployer en environnement de test dans une application tierce.

Après quelques recherches, j'ai trouvé bon nombre d'outils permettant de gérer les divers aspects liés au développement et au déploiement de projets. J'ai notamment retenu les suivants:
- NetBeans (ou Eclipse) pour le développement
- Subversion pour le versionning
- Track pour les tickets, bugs, timelines etc..
- Maven pour mettre en place une organisation propre et (apparemment) simplifier le cycle de développement
- Hudson pour des builds automatiques, mais pas certain qu'on en ait vraiment besoin.

Je voulais connaitre vos avis et expériences sur ces différents outils (ou leurs équivalents) et leur combinaison. A première vue, il me semble que ca fait beaucoup d'outils, dont certains ne semblent pas forcément facile à prendre en main, e.g. Maven, et je voulais savoir si ca vaut vraiment le coup d'investir du temps pour les mettre en place.

Merci d'avance

[Robin56]

Je voulais connaitre vos avis et expériences sur ces différents outils (ou leurs équivalents) et leur combinaison. A première vue, il me semble que ca fait beaucoup d'outils, dont certains ne semblent pas forcément facile à prendre en main, e.g. Maven, et je voulais savoir si ca vaut vraiment le coup d'investir du temps pour les mettre en place.

Eh bien je dirais que tu viens de citer le minimum des outils utilisés au sein de tout les projets Java pro.

- NetBeans (ou Eclipse) pour le développement

Un IDE c'est le minimum syndical en Java. Avantage à Eclipse pour moi mais je n'ai jamais vraiment manipulé NetBeans.

- Subversion pour le versionning

Obligatoire pour du travail à plusieurs (plugin Subclipse d'Eclipse ou TortoiseSVN)

- Track pour les tickets, bugs, timelines etc..

Eh bien tu n'as pas précisé dans quel cadre tu as besoin de ça ? Si c'est en entreprise, tu en auras besoin pour gérer et tracer correctement les soucis, remontés de bugs, évolutions, ...

- Maven pour mettre en place une organisation propre et (apparemment) simplifier le cycle de développement

Facilite la gestion des dépendances externes, il peut paraître complexe au premier abord mais permet de gérer plus facilement l'ajout de jar.

- Hudson pour des builds automatiques, mais pas certain qu'on en ait vraiment besoin.

Si l'on veut assurer un processus de compilation automatisé et donc assurer son cycle de développement/test, c'est un outil bien intéressant.

Après comme je l'ai dis tout à l'heure, on ne sait pas dans quel cadre tu veux ces outils (perso ? pro ?). On ne sait pas le niveau de compétence des pratiquants sur ces outils ? Si tu pars de 0, il est évident qu'il ne faut pas intégrer tout ces outils d'un coup sous peine de se noyer et de ne jamais avoir quelque chose de stable : Eclipse/SVN étant le minimum.

[LittleBean]

Eh bien je dirais que tu viens de citer le minimum des outils utilisés au sein de tout les projets Java pro.

Tout à fait

Facilite la gestion des dépendances externes, il peut paraître complexe au premier abord mais permet de gérer plus facilement l'ajout de jar.

Maven est assez compliqué, si tu as un tout petit projet ant peut suffire.

Hudson pour des builds automatiques, mais pas certain qu'on en ait vraiment besoin.

Tu peux regarder aussi jenkins issu d'un fork (du "papa") de hudson. (A ma connaissance hudson est en incubation à la fondation eclipse... avenir incertain)

=> hudson prend tout son sens si tu le couple avec des tests automatiques
(ça permet d'avoir un indicateur crédible de l'avancement du projet)
Pour des projets simples junit peut suffire

Subversion pour le versionning

Si j'avais le choix j'opterais pour git, il est vrai que dans la plus part des organistations sont encore au svn . (J'ai pas encore pu tester git sur un vrai projet)

On ne sait pas le niveau de compétence des pratiquants sur ces outils ?

+1
Consulte les sur les outils qu'ils souhaitent, ils doivent bien avoir une idée de ce dont ils ont besoin. Ce sera d'autant plus facile de leur imposer ces outils ensuite.

Si tu pars de 0, il est évident qu'il ne faut pas intégrer tout ces outils d'un coup sous peine de se noyer et de ne jamais avoir quelque chose de stable : Eclipse/SVN étant le minimum

+1000

[vinzzzz]

Si j'avais le choix j'opterais pour git, il est vrai que dans la plus part des organistations sont encore au svn . (J'ai pas encore pu tester git sur un vrai projet)

J'ai regardé un peu GIT et Subversion, et pour le moment je n'ai pas parfaitement compris le réel avantage de l'architecture distribuée de GIT par rapport à celle centralisée de Subversion. Ce que j'en ai retenu c'est que pour un petit nombre de développeurs, Subversion convient très bien.

Consulte les sur les outils qu'ils souhaitent, ils doivent bien avoir une idée de ce dont ils ont besoin. Ce sera d'autant plus facile de leur imposer ces outils ensuite.

"Ils" c'est moi je suis en environnement pro.

Après comme je l'ai dis tout à l'heure, on ne sait pas dans quel cadre tu veux ces outils (perso ? pro ?). On ne sait pas le niveau de compétence des pratiquants sur ces outils ? Si tu pars de 0, il est évident qu'il ne faut pas intégrer tout ces outils d'un coup sous peine de se noyer et de ne jamais avoir quelque chose de stable : Eclipse/SVN étant le minimum.

Actuellement le framework se limite à Eclipse / Subversion / Trac et des builds.xml pour 4 projets de taille modéré.

J'explore toutes les options pour déterminer si une réorganisation est nécessaire, le but étant de repartir sur des bases saines, et obtenir un bon compromis entre évolutivité et temps nécessaire pour mettre en place la nouvelle architecture. Le but ultime bien sur c'est d'essayer de simplifier le cycle de développement (construction des jar, mise en place de ceux ci dans l'environnement de tests pour chaque développeur, ajouts de dépendances, création de JAR pour la production avec obfuscation etc..).

La grande question surtout, c'est Maven VS ant sachant qu'il y a 4 projets, que potentiellement d'autres viendront, que certains projets dépendent d'autres et qu'il y a pas mal de dépendances externes.

Exemple: Maven permet d'ajouter plus facilement des JAR.. J'immagine qu'il y a d'autres avantages par rapport à la situation décrite ?

[Robin56]

@LittleBean : Que reproches tu à SVN ?

Actuellement le framework se limite à Eclipse / Subversion / Trac et des builds.xml pour 4 projets de taille modéré.

Pourquoi parles tu de "framework" ? Ce n'est pas un terme à utiliser à toutes les sauces. Ce dont tu parles là c'est un environnement de développement, pas un framework.

J'explore toutes les options pour déterminer si une réorganisation est nécessaire, le but étant de repartir sur des bases saines, et obtenir un bon compromis entre évolutivité et temps nécessaire pour mettre en place la nouvelle architecture.

Quels sont concrètement les soucis actuels ? Avant d'incorporer un nouvel outil dans un projet, il est important de bien cerner les soucis et les buts recherchés.

La grande question surtout, c'est Maven VS ant sachant qu'il y a 4 projets, que potentiellement d'autres viendront, que certains projets dépendent d'autres et qu'il y a pas mal de dépendances externes.

Maven VS Ant ? Oulah c'est un gros débat, trop pointu pour moi. J'ai plus souvent utilisé Maven, je ne pourrais donc t'éclairer davantage. Moi ce que je peux en dire du peu que je connaisse c'est que la gestion des dépendances est centralisée au sein d'un "repository". Ceci à l'avantage de pouvoir centraliser les références pour utiliser avec plusieurs projets. Pour le reste, je laisse les connaisseurs s'exprimer.

[vinzzzz]

Pourquoi parles tu de "framework" ? Ce n'est pas un terme à utiliser à toutes les sauces. Ce dont tu parles là c'est un environnement de développement, pas un framework.

environnement de développement ~ cadre de développement, cadre ~ framework. Un racourcis / anglicisme facile certes, mais il me semble avoir été compris ce qui est le principal après tout

Quels sont concrètement les soucis actuels ? Avant d'incorporer un n
ouvel outil dans un projet, il est important de bien cerner les soucis et les buts recherchés.

Les soucis, il n'y en a pas particulièrement dans le sens où tout fonctionne de manière acceptable. Mais certaines choses peuvent bien sur être améliorées, et notamment la gestion des dépendances qui pour le moment se fait plus ou moins à la main.

Le but est donc de déterminer si utiliser Maven (ou autre) permettrait d'améliorer certains aspect du processus, de le rendre plus robuste et évolutif etc... La difficulté pour moi, c'est que j'ai peu utilisé ant et pas du tout Maven, donc c'est assez difficile de me faire une idée des avantages des uns et des autres, et notamment si c'est vraiment utile de passer sous Maven.

Je peux alors poser ma question autrement: si on suppose que je ne connais ni Maven, ni ant, et que je souhaite mettre en place un environnement de développement évolutif et le plus simple possible pour quelques projets en environnement pro, que choisir ? Après avoir parcouru un peu le site de Maven, celui-ci semble séduisant sur le papier, mais bon... D'où mon post

Merci en tout cas de vos réponses.