2010-10-04 21 views
1

Je suis actuellement en train de chercher à migrer de maven2 vers buildr et je suis préoccupé par la façon de garder les scripts de construction DRY.Fichier de construction parent dans buildr

Actuellement, notre projet Maven est défini avec le fichier pom parent contenant tout le code de construction commune et est repris comme toute autre dépendance:

<parent> 
    <groupId>com.companyname</groupid> 
    <artifactId>parent</artifactId> 
    <version>1.0.0</artifactId> 
</parent> 

Maintenant, je suis à la recherche buildr et je remarque qu'il a un Simular concept, mais il nécessite de placer un fichier de construction d'un niveau haut, par exemple:

/svnrepo/buildfile 
/svnrepo/ProjectA 
/svnrepo/ProjectB 

Ce problème est cependant parce que ces projets ne sont pas liés et seront extraits et construire totalement séparément. Donc ma question est: comment puis-je résoudre au mieux ce problème? Comment puis-je référencer un fichier de construction commun tout en ne pouvant extraire qu'un seul projet à la fois?

+0

Juste pour l'intérêt: Pourquoi avez-vous décidé de déménager à buildr loin de Maven? (Pouvez-vous donner quelques raisons?) Serait gentil merci. – khmarbaise

+0

De plus petits scripts de construction, l'utilisation complète de ruby ​​et la possibilité de créer des fonctions et plus important que cela est la vitesse: http://bit.ly/9lylOi (quelque chose que j'ai testé moi-même et montré pour être précis) –

Répondre

1

J'ai découvert la réponse à ce problème et je me rends compte à quel point c'est facile: créer une gemme. Remplacez parent-pom.xml par parent.rb et distribuez le fichier ruby ​​en tant que gem pour être requis par tous les autres projets.

+0

Une autre alternative que beaucoup de gens utilisent est de partager des fichiers via le système de contrôle de version en utilisant des fonctionnalités telles que les externalités SVN, les sous-modules Git, les tresses Git, etc. Cette approche allège le besoin d'empaqueter et de déployer une gemme. –

0

Je pense que vous êtes confus:

d'une part, vos projets sont construits en ce moment avec Maven, avec 4 référentiels différents que vous consultez dans les bons endroits ou utilisez svn: externals. Cela semble être une mauvaise idée. D'un autre côté, vous voulez faire la même chose avec Buildr, mais est-ce que ça ne va pas avoir l'air bon?

S'il vous plaît construire ces projets séparément en effet! Si vous avez du code qui peut être réutilisé d'un projet à un autre, comme une tâche personnalisée, utilisez un svn: externals dans chaque projet pointant vers un fichier ruby ​​que le fichier de construction nécessite.

+0

Ils sont tous séparés , des projets indépendants que nous construisons séparément. Mais il y aura toujours des tâches communes que nous voulons partager entre les projets (outils d'analyse statique, tâches de déploiement, etc.). Je pourrais utiliser svn: externals mais j'espérais éviter cela parce que c'est généralement une mauvaise pratique: http://bit.ly/9wN9yk –

+0

Je me trouve en désaccord avec la plupart des points soulevés dans le blog ci-dessus. Des solutions équivalentes existent dans d'autres outils SCM pour obtenir le même résultat que les externalités SVN. Et certains points ne sont pas pertinents, car il s'agit précisément de partager le code de script entre les projets. Dans tous les cas, on dirait que vous avez trouvé une solution qui vous plaît, c'est donc important. –