modificare un commento ad un commit su svn

Se avete sbagliato ad inserire un commento su un commit di svn, questo si può modificare.
Ecco come da riga di comando:
svn propset svn:log --revprop -r <revision> "<comment>" <url>
- revision=numero della revisione di cui si vuole modificare il commento
- comment=nuovo commento
- url=url del repository, per esempio http://j4shop-dev:9090/svn/BASE/

Sul mio repository questo non è consentito di base. Bisogna prima creare un hook script nel repository stesso. Nel caso specifico ho creato pre-revprop-change.bat hook script. Questo script è vuoto.
Dato che i commenti non sono versionati, svn da la possibilità di gestire le eventuali modifiche per memorizzarseli, se necessario. Per fare questo usa gli hook script. Dato che non mi interessa gestire il valore vecchio, il mio script non fa niente.
Lo script deve essere copiato nella cartella hooks del repository.

Maggiori informazioni qui:
http://svnbook.red-bean.com/nightly/it/svn.reposadmin.create.html#svn.reposadmin.create.hooks

Ubuntu 9.10 e pulsanti di Eclipse

Da quando ho aggiornato il mio kubuntu dalla versione 9.04 alla 9.10, ho riscontrato dei fastidiosi problemi in eclipse. Infatti i pulsanti delle varie finestre non sempre sono visualizzati e a volte, anche se cliccati, non fanno niente.
Per "aggirare" il problema basta settare una variabile d'ambiente: GDK_NATIVE_WINDOWS=1.
Io ho creato uno script shell che setta la variabile e lancia eclipse.

#!/bin/sh
export GDK_NATIVE_WINDOWS=1
/opt/eclipse-3.4.2/eclipse

Per maggiori informazioni:
http://www.norio.be/blog/2009/10/problems-eclipse-buttons-ubuntu-910

Ricavare classpath da un JUnitTest eseguito da maven

Se da una classe java voglio sapere il classpath usato per l'esecuzione della stessa, basta fare:

String classpath = System.getProperty("java.class.path");

Questa cosa, se fatta da un JUnitTest, non funziona se il test è eseguito da maven. Infatti il codice qui sopra tornerebbe il classpath usato per il lancio di maven. Per sapere invece il classpath usato per l'esecuzione del test, bisogna cambiare property:

String classpath = System.getProperty("surefire.test.class.path");

Debug di test eseguiti da maven

Ogni tanto succede che un JUnitTest eseguito da eclipse funzioni, mentre eseguito da maven vada in errore. Se la causa dell'errore non è chiaro, la cosa migliore è fare un debug del test eseguito da maven.
A complicare la cosa, maven esegue i test in un processo separato.
Innanzitutto bisogna dire a maven di lanciare i test nel processo separato in modalità di debug. Questo si fa lanciando maven nel seguente modo:

mvn -Dmaven.surefire.debug test

La porta su cui connettersi per il debug è la 5005. Per cambiarla bisogna usare questa sintassi:

mvn -Dmaven.surefire.debug="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000 -Xnoagent -Djava.compiler=NONE" test

Si può anche fare in modo che maven non lanci i test in un processo separato:

mvn -DforkMode=none test

Tutto questo lo trovate anche qui

Server ssh su ubuntu

L'installazione base di kubuntu non mi ha installato il server ssh.
Per capirci, non esiste alcun file /etc/init.d/ssh.
Per installarlo basta installare il pacchetto openssh-server.

Accedere a un server svn attraverso un tunnel ssh da Fedora 10

Esistono più metodi di accesso ad un server svn, uno di questi è utilizzando un protocollo personalizzato a un server svnserve attraverso un tunnel ssh, ossia utilizzando una stringa del tipo:
svn checkout svn+ssh://utente@server/directory

Cosa indispensabile è avere la chiave pubblica per poter accedere al server, che consiste, nel mio caso, di un file id_rsa.
A questo punto, da una macchina con Fedora Core 10 bisogna:
1) copiare il certificato (il file id_rsa) nella ~/.ssh/
2) lanciare il comamndo svn checkout.... riportato sopra

Fatto il passo 1, anche dai plugin di eclipse si riesce senza problemi ad accedere al server, basta specificare, dal tab "ssl setting" o "ssh setting", la posizione del certificato.

Spero sia utile a qualcuno, io ho girato un sacco su internet per trovare la soluzione, alla fine l'ho trovata dal man di ssh-add.

Applicazione java in modalità debug

Per fare in modo che una qualunque applicazione java possa essere debug-gata da remoto, bisogna aggiungere questa riga nel comando di lancio del programma:
-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

Nel caso di Tomcat, si potrebbe seguire la stessa strada, ma è già previsto dal comando di lancio di Tomcat. Infatti basta usare i parametri jpda start. Quindi, dalla directory di tomcat, bisogna eseguire:
bin/catalina.sh jpda start

A questo punto Tomcat sarà debug-abile da remoto sulla porta 8000 di default. Per cambiare tale porta si imposta la variabile d'ambiente JPDA_ADDRESS= e la porta specificata sarà usata per il debug da remoto.