Conseils sur un bon outil de construction Java, bien intégré à eclipse
Je travaille en petite équipe (3 personnes) sur plusieurs modules (environ 10 actuellement). La compilation, l'intégration et la gestion des versions de build deviennent de plus en plus fastidieuses. Je cherche un bon outil de construction / intégration pour remplacer / compléter Ant.
Voici la description de notre environnement de développement : - Plusieurs modules en fonction de chacun sur et sur des POTS tiers - Certains peuvent exporter des POTS, d'autres exporter des GUERRES, d'autres exporter des POTS autonomes, exécutables (avec Fat-Jar) - Javadoc pour tous - On travaille avec eclipse - Script Ant personnalisé pour chaque module. De nombreuses informations redondantes entre la configuration eclipse et les scripts Ant. Par exemple, pour le Fat-JAR autonome, nous avons répertorié toutes les dépendances récursives, alors qu'idéalement, il pourrait clairement être importé à partir de la configuration eclipse. - Le code source est versionné en utilisant SVN
Voici ce que je voudrais qu'un outil d'intégration parfait fasse pour moi:
Automatiser les versions et le versioning des modules. Idéalement, l'outil d'intégration doit détecter si une nouvelle version est nécessaire. Par exemple, si je veux publier un projet A qui dépend d'un projet B, et si j'ai apporté de petites modifications au projet B localement, l'outil d'intégration doit d'abord publier une nouvelle version de B et en faire un basé sur celui-ci.
Intégrez fortement eclipse, afin qu'il puisse obtenir les dépendances entre les modules et les bibliothèques tierces à partir de sa configuration. BTW, je voudrais continuer à configurer le chemin de construction avec eclipse sans mettre à jour un autre ".xml" choses". J'ai vu que Gradle peut générer des fichiers de projet eclipse à partir de sa configuration, mais la contrepartie serait géniale.
Permettre un développement" live " et transparent sur les projets locaux. Je veux dire que je fais souvent de petits changements sur les projets core / common tout en développant les projets main / "leaf". Je voudrais que mes modifications sur les projets de base soient immédiatement disponibles pour leaf projets sans avoir besoin de publier (même localement) les POTs de mes projets de base.
Stocker toutes les versions des versions de mon module sur un serveur externe. Le plus simple (dossier partages / Webdav) serait le meilleur. Une belle page Web avec la liste des modules et des artefacts livrés serait génial aussi.
J'ai regardé autour de moi pour beaucoup de choses. De Ant4eclipse (pour intégrer la configuration Eclipse dans mon script Ant), au Maven / Ivy / Gradle outils.
Je suis un peu confus. Voici ce que j'ai compris jusqu'à présent: - Maven est un grand / grand outil, mais est un peu rigide et vous oblige à vous plier à sa structure et à ses concepts. Il est basé sur la description plutôt que sur les scripts. Si vous sortez du chemin, vous devez développer vos propres plugins. La puce est moins puissant que maven, il gère moins de choses, mais est plus flexible. - Gradle est entre les deux. Il est d'usage général. Il permet les scripts ainsi que la configuration "basée sur des conventions". Il intègre Ant et l'étend.
Donc, à ce stade, je recherche des témoignages réels d'utilisateurs réels. Quels outils utilisez-vous ? Comment ? Avez-vous les mêmes besoins que moi ? Est-il facilité votre vie ou dans la manière ?
Existe-t-il des exemples de cas d'utilisation ou des squelettes d'espace de travail que je pourrais utiliser comme point de départ pour voir de quoi ces outils sont capables ?
Désolé pour la longueur de ce message. Et merci à l'avance pour vous conseiller.
Type cordialement,
Raphaël
6 answers
Automatiser les versions et le versioning des modules (...)
Les concepts de versioning et de référentiel sont intégrés avec Maven et ils pourraient s'adapter ici.
Maven prend en charge Les dépendances d'INSTANTANÉS . Lors de l'utilisation d'un instantané, Maven essaiera périodiquement de télécharger le dernier instantané disponible à partir d'un référentiel lorsque vous exécutez une génération. Les SNAPSHOTS sont généralement utilisés lorsqu'un projet est en développement actif.
Maven 2 prend également en charge version les plages (je ne les recommande pas vraiment mais c'est une autre histoire) qui permettent par exemple de configurer A pour dépendre de la version [4.0,) de B (toute version supérieure ou égale à 4.0). Si vous construisez et publiez une nouvelle version de B, A l'utiliserait.
Intégrer fortement avec eclipse
Le plugin m2eclipse fournit une synchronisation bidirectionnelle avec Eclipse.
Permettre un développement" en direct " et transparent sur les projet.
Le plugin m2eclipse prend en charge la "résolution de l'espace de travail" : si le projet A dépend du projet B et si le projet B est dans l'espace de travail, vous pouvez configurer A pour dépendre des sources B et non de B.jar (c'est le mode par défaut si je ne me trompe pas). Ainsi, un changement sur les sources B serait directement visible, sans avoir besoin de construire B.jar.
Stocke toutes les versions des releases de mon module sur un serveur externe.
Comme mentionné précédemment, il s'agit en fait d'un le concept de Maven (vous n'avez même pas le choix) et le déploiement via file:// ou dav:// sont tous deux pris en charge.
Pour résumer, Maven n'est (probablement) pas le seul candidat mais je suis sûr que cela conviendrait:
- Votre projet n'est pas si exotique ou complexe, il n'y a rien d'effrayant dans votre description (un refactoring de la structure sera probablement nécessaire mais cela ne devrait pas être un gros problème).
- Maven apporte également un flux de travail basé sur best pratique.
- m2eclipse fournit une forte intégration avec l'E.
Mais Maven a une courbe d'apprentissage.
Outils CI? Pour moi, il n'y en a qu'un: le Hudson CI.
J'ai configuré un environnement de développement logiciel pour Java une fois, avec les composants:
- eclipse ID
- mercurial
- bugzilla
- maven
- Lien
- Hudson CI
Et quelques apache, mysql, php, perl, python, .. pour l'intégration.
L'hudson n'était pas intégré à eclipse et c'était exprès, parce que je voulais construire sur un serveur séparé. pour tous les autres outils que j'ai eu une intégration croisée parfaite (comme: mylyn sur eclipse pour parler avec bugzilla, m2eclipse pour utiliser maven eclipse, beaucoup de plugins pour hudson,...)
Nous avons commencé à intégrer Gradle dans notre processus de construction, et je peux ajouter aux réponses déjà publiées que Gradle fonctionnerait également. Vos hypothèses sont pour la plupart correctes, gradle est plus désinvolte, mais est puissant et permet des scripts et autres dans la construction elle-même. Il semble que la plupart des choses que maven peut faire, gradle le fait aussi.
Maintenant pour vos points individuels:
Versioning : gradle prend en charge les cartes de dépendance, le versioning et si vous ajoutez un CI serveur, vous pouvez déclencher automatisé/dépendant construit. Par exemple, presque tous nos "livrables" le sont .guerres, mais nous avons plusieurs bibliothèques de code (.pots) et un exécutable .jar dans le développement. Une configuration consiste à rendre les guerres et le "fat-jar" dépendants des bibliothèques de code partagé. Ensuite, lorsque les bibliothèques partagées sont mises à jour, bump les versions sur les bibliothèques partagées, testez les projets consommateurs, puis utilisez la capacité de Hudson à déclencher des projets dépendants pour les redéployer. Il existe d'autres moyens, mais que semble fonctionner le mieux pour nous, pour l'instant.
Intégrez fortement eclipse : Vous avez raison, gradle peut générer les fichiers eclipse. Nous avons tendance à utiliser uniquement l'eclipseCp (pour mettre à jour .classpath) tâche une fois que nous allons, car seul classpath doit être modifié. C'est un peu bizarre (attrape votre JRE par défaut, alors assurez-vous que c'est correct, n'ajoute pas exported="true" si vous en avez besoin), mais vous obtient 99% du chemin.
Permettre un développement" live " et transparent sur les projets locaux : Ceci je ne suis pas sûr à ce sujet. Je n'ai piraté que gradle dans ce cas; en supprimant l'artefact dans le projet consommateur et en marquant le projet partagé comme tel dans eclipse, puis en revenant par la suite.
Stocker toutes les versions des versions de mon module sur un serveur externe: des approches simples et nombreuses sont prises en charge, similaires à Maven.
En ce qui concerne les exemples, les documents pour gradle sont bons, ainsi que les exemples de projets fournis avec le zip complet. Ils te lèveront et courir assez rapidement.
Jetez un oeil à Ant Ivy. http://ant.apache.org/ivy/
Il n'y a pas de balles d'argent, mais dans mon expérience Maven est un excellent outil de gestion de projet. Personnellement, j'aime utiliser une comibnation de subversion (pour le contrôle de version), maven (pour la gestion de projet/build) et hudson (pour la construction/intégration continue).
Je trouve que la convention apportée par maven est vraiment utile pour le changement de contexte et idéale pour la gestion des dépendances. Cela peut être frustrant si les fichiers jar ne sont pas dans les dépôts, mais vous pouvez les installer localement et lorsque vous êtes prêt vous pouvez héberger votre propre référentiel privé qui reflète d'autres endroits. J'ai eu une bonne expérience en utilisant sonar.nexus par http://www.sonatype.com/ . Ils fournissent également un livre gratuit excellenmt pour vous aider à démarrer.
Cela peut sembler exagéré maintenant, mais la mise en place d'un bon environnement de build / test / integrate / release maintenant rapportera des dividendes plus tard. Il est toujours plus difficile de rétro-adapter, et c'est quelque chose que vous pouvez reproduire facilement.
Enfin, je préfère Netbeans intégration pour maven, mais c'est juste moi:)
Certaines de vos rubriques font partie de la gestion des déploiements et des versions.
, Vous pouvez vérifier un produit comme: Xebia DeployIt
(avec une personal edition qui est gratuite)