Il modo migliore per memorizzare le informazioni sulla versione di Subversion in EAR?

Question

Quando si riceve un bug report o un messaggio it-doesnt-work una delle mie domande iniziali è sempre quale versione? Con diverse build che si trovano in molti stadi di test, la pianificazione e la distribuzione di questo è spesso una domanda non banale.

I il caso di rilascio di file Java JAR (ear, jar, rar, war) Mi piacerebbe essere in grado di cercare in/sul JAR e passare allo stesso ramo, versione o tag che era la fonte del rilasciato JAR.

Come è possibile regolare al meglio il processo di generazione di form in modo che le informazioni sulla versione nella checkout di svn rimangano nella build creata?

Stavo pensando lungo le linee di:

• aggiunta di un file versione, ma con un contenuto che cosa?
• memorizzare informazioni nel file META-INF, ma con quale proprietà con quale contenuto?
• fonti copia nell'archivio risultato
• aggiunti svn: oggetti da tutte le fonti con le parole chiave in luoghi compilatore li lascia essere

---

ho finito per usare l'approccio svnversion (l'anwser accettato), perché analizza l'intera sottostruttura anziché le informazioni svn che guardano solo il file/directory corrente. Per questo ho definito l'attività SVN nel file ant per renderla più portabile.

<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> 

Non tutte le build risultano nei servizi Web. Il file ear prima della distribuzione deve rimanere lo stesso nome a causa dell'aggiornamento nel server delle applicazioni. Rendere il file eseguibile è ancora un'opzione, ma fino ad allora includo solo un file di informazioni sulla versione.

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

Refs:
svnrevision: http://svnbook.red-bean.com/en/1.1/re57.html
svn informazioni http://svnbook.red-bean.com/en/1.1/re13.html
subclipse compito svn: http://subclipse.tigris.org/svnant/svn.html
svn client: http://svnkit.com/

Answer 1

Utilizzare il comando svnversion nello script Ant per ottenere il numero di revisione:

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

Poi utilizzare i $ {} svnversion proprietà da qualche parte nel vostro orecchio. Abbiamo messo nel nome del file EAR, ma si potrebbe anche metterlo in un file readme o la versione dentro l'orecchio, o specificare la versione in dell'AER META-INF/MANIFEST.MF:

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

Answer 2

Dall'alto della mia mente. Un tag per ogni build di jar?

Answer 3

Abbiamo la prima parte della nostra build creare un file version.txt nella radice del pacchetto e scaricare il tag utilizzato per controllare il codice da (nel nostro caso) CVS ... Inoltre, la parte finale di il nostro processo di compilazione controlla l'EAR completamente compilato in CVS per riferimento futuro.

In questo modo, se abbiamo un problema con una webapp - è solo un caso di chiedere al reporter di premere /app/version.txt - da lì possiamo analizzare la particolare cronologia di compilazione in CVS per individuare i componenti rilevanti (gestisce diverse versioni di librerie nelle app) per individuare l'errore.

Non sono sicuro di quale aiuto questo sia per il nostro personale di supporto - ma è sicuramente qualcosa che si lamentano di non essere lì!

Answer 4

Si desidera fornire il numero Subversion e il numero di repository.Come discusso in How to access the current Subversion build number?, il comando svn info ti fornirà queste informazioni, che potrai quindi utilizzare per creare un file VERSION o posizionarlo in uno qualsiasi degli altri file che stai creando nei tuoi file * AR. Se non hai niente altro in mente, si potrebbe considerare l'utilizzo del XmlProperty Ant task per estrarre le informazioni rilevanti dalla uscita del svn   informazioni   comando --xml

Answer 5

fare automatica costruisce, e inserire un tag (con una data timbro) sul codebase quando la compilazione è riuscita (con un corso non richiesto).

Nel processo di consegna, consegnare solo build taggati al cliente. In questo modo hai il controllo e puoi posizionare il nome del tag in un readme.txt da qualche parte, oppure il nome del file ear rispecchi il tagname.

Sono tornato personalmente al CVS, e questo è uno dei motivi. In CVS, posso avere un report di classe sul tag. Tutti i miei file jar contengono un "main" che li rende eseguibili. Con domande di supporto, chiedo al cliente di fare un "java -jar somejar.jar" e inviare l'output a me a fianco della domanda.

In questo modo sono sicuro della build che stanno usando e posso anche avere informazioni come la versione di Java, il tipo di SO e la versione. Senza che il cliente debba rispondere a strane domande.

È semplice ma molto efficace.

Answer 6

Perché non inserire il numero di build in un file di proprietà ... questo può quindi essere facilmente letto da java e prodotto in una guida | Informazioni sulla finestra di dialogo (applet/applicazione), il piè di pagina web o qualsiasi altra GUI che si possa avere.

(Vedere la coda per ogni pagina SOF .... ha il numero di versione SVN lì.)

Sembra un carico più facile che guardare nella guerra/EAR/JAR etc facile tempo?

Answer 7

I memorizzare la revisione del repository assoluto come parte del mio numero di versione completo. Questo dà alle persone una rapida occhiata per vedere se una determinata modifica è in una determinata versione o meno.

Memorizziamo anche il numero di versione/data di creazione/ecc nel file manifest dell'orecchio come proprietà personalizzate, queste sono per lo più solo informative. Lo memorizziamo anche in un file di proprietà che è incorporato nel nostro jar, quindi l'applicazione può leggerlo.

Answer 8

Verificare il progetto jreleaseinfo. Contiene un'attività ANT che può generare una classe java che può essere richiamata in fase di runtime per visualizzare le informazioni sulla versione del progetto.

Mi piace la sua semplicità.

Answer 9

Vedi anche questa domanda: Build and Version Numbering for Java Projects (ant, cvs, hudson)

Esso comprende diversi frammenti di codice utile.