Comment mieux stocker les informations de version Subversion dans les fichiers EAR?

Question

Lors de la réception d'un rapport de bug ou d'un message it-doesnt-work, une de mes questions initiales est toujours quelle version? Avec une construction différente étant à plusieurs étapes de test, la planification et le déploiement de cette question est souvent une question non triviale. Dans le cas de la publication de fichiers Java JAR (ear, jar, rar, war), je voudrais pouvoir regarder dans/dans le JAR et passer à la même branche, version ou tag qui était la source de JAR publié.

Comment puis-je ajuster au mieux le processus de construction des fourmis de sorte que les informations de version dans la vérification svn restent dans la construction créée?

Je pensais le long des lignes de:

• l'ajout d'un fichier VERSION, mais avec quel contenu?
• stocker des informations dans le fichier META-INF, mais sous quelle propriété avec quel contenu?
• sources de copie dans l'archive des résultats
• ajouté svn: propriétés à toutes les sources avec des mots clés dans des endroits le compilateur les feuilles être

---

Je fini par utiliser l'approche svnversion (la anwser acceptée), car il analyse l'ensemble du sous-arbre par opposition à svn info qui ne regarde que le fichier/répertoire en cours. Pour cela j'ai défini la tâche SVN dans le fichier ant pour le rendre plus portable.

<taskdef name="svn" classname="org.tigris.subversion.svnant.SvnTask"> 
    <classpath> 
    <pathelement location="${dir.lib}/ant/svnant.jar"/> 
    <pathelement location="${dir.lib}/ant/svnClientAdapter.jar"/> 
    <pathelement location="${dir.lib}/ant/svnkit.jar"/> 
    <pathelement location="${dir.lib}/ant/svnjavahl.jar"/> 
    </classpath>   
</taskdef> 

Toutes les générations ne donnent pas lieu à des services Web. Le fichier ear avant le déploiement doit conserver le même nom en raison de la mise à jour dans le serveur d'applications. Rendre le fichier exécutable est toujours une option, mais jusque-là, je viens d'inclure un fichier d'informations de version.

<target name="version"> 
    <svn><wcVersion path="${dir.source}"/></svn> 
    <echo file="${dir.build}/VERSION">${revision.range}</echo> 
</target> 

: Réfs
svnrevision: http://svnbook.red-bean.com/en/1.1/re57.html
svn info http://svnbook.red-bean.com/en/1.1/re13.html
subclipse tâche svn: http://subclipse.tigris.org/svnant/svn.html
svn client: http://svnkit.com/

Answer 1

Utilisez la commande svnversion dans votre script Ant pour obtenir le numéro de révision:

<exec executable="svnversion" outputproperty="svnversion" failonerror="true"> 
    <env key="path" value="/usr/bin"/> 
    <arg value="--no-newline" /> 
</exec> 

Ensuite, utilisez les $ {} svnversion propriété quelque part dans votre oreille. Nous l'avons mis dans le nom du fichier EAR, mais vous pouvez aussi le mettre dans un fichier readme ou une version dans l'oreille ou d'indiquer la version META-INF/manifest.mf de l'AER:

<!-- myapp-r1234.ear --> 
<property name="ear" value="myapp-r${svnrevision}.ear" /> 

Answer 2

Du haut de mon esprit. Un tag pour chaque construction de pot?

Answer 3

Nous avons la première partie de notre build créer un fichier version.txt à la racine du paquet et vider la balise utilisée pour vérifier le code de (dans notre cas) CVS ... En outre, la partie finale de Notre processus de construction vérifie que l'EAR entièrement construit est de nouveau dans CVS pour référence future. De cette façon, si nous avons un problème avec une webapp - c'est juste un cas de demander au journaliste de cliquer sur /app/version.txt - à partir de là, nous pouvons explorer l'historique de construction particulier dans CVS pour localiser les composants pertinents (gère différentes versions de bibliothèques dans les applications) pour localiser l'erreur.

Vous ne savez pas combien d'aide cela est à nos gens de soutien - mais c'est certainement quelque chose dont ils se plaignent pas être là!

Answer 4

Vous souhaitez fournir le numéro de branche et de référentiel Subversion.Comme discuté dans How to access the current Subversion build number?, la commande svn info vous donnera cette information, que vous pourrez ensuite utiliser pour construire un fichier VERSION ou le placer dans l'un des autres fichiers que vous construisez dans vos fichiers * AR. Si vous avez rien d'autre à l'esprit, vous pouvez envisager d'utiliser le XmlProperty Ant task pour extraire les informations pertinentes de la sortie de votre svn   informations   commande --xml

Answer 5

Est-ce automatique construit et placer une étiquette (avec une date stamp) sur la base de code lorsque la construction est réussie (avec unittest ofcourse).

Dans votre processus de livraison, Livrer seulement étiqueté builds au client. De cette façon, vous avez le contrôle et pouvez placer le nom du tag dans un readme.txt quelque part, ou avoir le nom du fichier ear qui reflète la variable.

je suis passé personnellement revenir à CVS, ce qui est l'une des raisons. Dans CVS, je peux avoir un rapport de classe c'est tag. Tous mes fichiers jar contiennent une "main" qui les rend exécutables. Avec des questions de support, je demande au client de faire un "java -jar somejar.jar" et de m'envoyer la sortie à côté de la question.

De cette façon, je suis sûr de la construction, ils re-utiliser et je peux même avoir des informations comme la version java, le type de système d'exploitation et la version. Sans que le client doive répondre à des questions étranges.

C'est simple mais très efficace.

Answer 6

Pourquoi ne pas mettre le numéro de build dans un fichier de propriétés ... cela peut être lu facilement par la java et de sortie à une aide | À propos de la boîte de dialogue (applet/application), du pied de page Web ou de toute autre interface graphique que vous pourriez avoir.

(Voir le pied de page sur chaque page SOF .... a le numéro de version SVN là.)

Semble une charge plus facile que de regarder dans le WAR/EAR/JAR etc temps facile?

Answer 7

I stocker la révision du référentiel absolu dans le cadre de mon numéro de version complet. Cela donne aux gens un coup d'oeil rapide pour voir si un changement donné est dans une version donnée ou non.

Nous stockons également la date numéro de version/build/etc dans le fichier manifeste de l'oreille comme des propriétés personnalisées, ce sont la plupart du temps à titre informatif uniquement. Nous le stockons également dans un fichier de propriétés intégré dans notre fichier jar, afin que l'application puisse le lire.

Answer 8

Vérifiez le projet jreleaseinfo. Contient une tâche ANT qui peut générer une classe Java pouvant être appelée au moment de l'exécution pour afficher les informations de version de votre projet.

J'aime sa simplicité.

Answer 9

Voir aussi cette question: Build and Version Numbering for Java Projects (ant, cvs, hudson)

Il comprend plusieurs extraits de code utiles.