Raisons d'utiliser les fichiers de propriétés Ant sur "Propriétés Tâches"

Question

Je travaille actuellement avec des développeurs qui souhaitent configurer des tâches Ant qui définissent des variables spécifiques à l'environnement plutôt que d'utiliser des fichiers de propriétés. Il semble qu'ils préfèrent faire cela parce qu'il est plus facile de taper:

ant <environment task> dist 

que de taper:

ant -propertyfile <environment property file> dist 

Ainsi, par exemple:

<project name="whatever" default="dist"> 

<target name="local"> 
    <property name="webXml" value="WebContent/WEB-INF/web-local.xml"/> 
</target> 

<target name="remote"> 
    <property name="webXml" value="WebContent/WEB-INF/web-remote.xml"/> 
</target> 

<target name="build"> 
    <!-- build tasks here ---> 
</target> 

<target name="dist" depends="build"> 
    <war destfile="/dist/foo.war" webxml="${webXml}"> 
     <!-- rest of war tasks here --> 
    </war> 
</target> 

Je trouve qu'il est difficile de Convainquez-les que les fichiers de propriétés sont la bonne solution. Je crois que les propriétés des fichiers sont mieux parce que:

• Ils fournissent plus de flexibilité - si vous avez besoin d'un nouvel environnement il suffit d'ajouter un nouveau fichier de propriétés
• Il est clair ce qui se passe - Vous devez savoir sur ce petit « truc » pour réaliser ce qu'ils accomplissent
• Ne fournit pas de valeurs par défaut et la possibilité d'utiliser des substitutions - s'ils utilisaient des fichiers de propriétés, ils pouvaient fournir des valeurs par défaut en haut du projet mais pouvaient les remplacer par un fichier
• Le script ne se brise pas si une tâche d'environnement n'est pas fournie sur la ligne de commande

Bien sûr, tout ce qu'ils entendent, c'est qu'ils doivent changer leur script Ant et doivent taper plus sur la ligne de commande.

Pouvez-vous fournir des arguments supplémentaires en faveur des fichiers de propriétés sur les "tâches de propriétés"?

Answer 1

Les tâches de propriétés couplent étroitement le fichier de construction aux environnements. Si vos collègues développeurs prétendent qu'ils doivent "changer leur script ant" avec vos suggestions, pourquoi ne se disputent-ils pas pour le changer chaque fois qu'ils doivent se déployer dans un nouvel environnement? :)

Vous pouvez peut-être les convaincre d'autoriser la configuration des fichiers de propriétés et de la ligne de commande. Je configure mes constructions Ant de sorte que si un build.properties existe dans le même répertoire que le build.xml, il le lit. Sinon, il utilise un ensemble de propriétés par défaut codées en dur dans la construction. C'est très flexible.

<project name="example"> 

    <property file="build.properties"/> 

    <property name="foo.property" value="foo"/> 
    <property name="bar.property" value="bar"/> 

    ... 
</project> 

Je ne fournit pas de build.properties avec le projet (à savoir build.properties n'est pas versionné SCM). De cette façon, les développeurs ne sont pas obligés d'utiliser le fichier de propriétés. Je fournis un fichier build.properties.example que les développeurs peuvent référencer.

Depuis propriétés Ant, une fois établies, sont immuables, le fichier de construction utilisera les propriétés définies dans cet ordre:

• propriétés fournies avec -D ou -propertyfile via la ligne de commande
• Propriétés chargées de la construction .properties
• Propriétés par défaut dans la construction.xml

avantages de cette approche:

• Le fichier de construction est plus petit et donc plus maintenable, moins sujettes aux bugs
• Les développeurs qui ne peuvent tout simplement se débarasser de propriétés de réglage à la ligne de commande peut toujours les utiliser.
• fichiers de propriétés peuvent être utilisés, mais ne sont pas nécessaires

Answer 2

Les arguments que vous avez sont déjà assez convaincant. Si ces arguments n'ont pas fonctionné, argumenter ne va pas résoudre le problème. En fait, rien va résoudre le problème. Ne supposez pas que les gens sont rationnels et feront la chose la plus pratique. Leurs egos sont impliqués.

Arrête de discuter. Même si vous gagnez, le ressentiment et l'irritation que vous créez ne vaudra pas la peine. Gagner un argument peut être pire que de perdre.

Faites votre cas, puis laissez tomber. Il est possible qu'après un certain temps, ils décident de passer à votre chemin (parce que c'est mieux). Si cela arrive, ils agiront comme si c'était leur propre idée. Il n'y aura aucune mention de votre proposition. D'autre part, ils ne peuvent jamais changer. La seule solution est de travailler vers une position d'autorité, où vous pouvez dire comment les choses doivent être faites.

Answer 3

Le problème avec la première solution (en utilisant la propriété ant) ​​est essentiellement le codage en dur. Cela peut être pratique lorsque vous démarrez un projet pour vous-même mais rapidement vous devez supprimer cette mauvaise habitude.

J'utilise un fichier de propriétés proche de ce que dit robhruska sauf que j'ai validé le fichier build.properties directement. De cette façon, vous en avez un par défaut.

D'autre part, je comprends que je pourrais ajouter ces valeurs par défaut dans le fichier build.xml. (Je vais probablement essayer dans les prochaines heures/jours ;-)).

De toute façon, je n'aime vraiment pas la première approche et je voudrais forcer ces gars à suivre le second ...