Maven: file.separator und properties-Dateien

[BlackCraze]

Hallo an alle

Ich baue meine Projekte mit Maven (momentan 2.0.9) und benutze auch den test-resources- und den main-resources-Ordner um entsprechende properties-Dateien für die Erstellung meines Enterprisearchives für Test und Realease zu trennen. In einer der Properties-Dateien befindet sich ein Dateipfad, der je nach Betriebssystem natürlich anders aussieht:

var1=C:\Dokumente und Einstellungen\ich\workspace\Projekt\src\test\resources\die.datei

\\ ODER EBEN

var1=/home/ich/und/so/weiter/die.datei

Für das Release ist es immer der gleiche Pfad und kann somit hart drin stehen - aber da mehrere Personen am Projekt arbeiten, muss das file im testresources irgendwie dynamisch gebaut werden (jeder hat den workspace woanders -.-')
Alles kein Thema - kann man ja automatisch zusammenbauen - ich habe einen Filter eingebaut, der mir den Pfad zur Testphase automatisch zusammenschustert - So funktioniert die POM auch auf den Rechnern meiner Kollegen - zumindest theoretisch ;-)

var1=${${basedir}${file.separator}src${file.separator}test${file.separator}resources${file.separator}die.datei}

Unter Windows steht dann in der gefilterten Datei:

var1=C:\Dokumente und Einstellungen\ich\workspace\Projekt\src\test\resources\die.datei

Wenn ich jetzt die Properties-Datei via Java einlese, sind aber die Backslashes weg, was dazu führt, dass der Pfad nicht stimmt. Habe schon ein Flüchtungszeichen vor die file.separator gestellt - aber der Teil aus der basedir-Variable geht natürlich nicht auf diesem Weg. ???:L

Hat jemand ne Ahnung, wie ich entweder den Pfad mit Flüchtungszeichen bekomme, oder die Properties-Datei mit nem normalen Pfad eingelesen bekomme?

Danke schonmal

 

[maki]

Dafür nimmt man profile

Ansonsten kann man property dateien auch aus dem Classpath laden, natürlich nur wenn sie auch dort liegen.

 

[BlackCraze]

Ziel des ganzen sollte eigentlich sein, dass das Projekt nach dem auschecken direkt baubar ist (ohne irgendwelche Systemeinstellungen zu setzen etc.) Sonst könnte ichs die Leute ja auch einfach in der properties-datei pflegen lassen. Das muss doch irgendwie zu lösen sein - ich kann mir nicht vorstellen, dass ich der erste mit dem Problem bin - aber ich finde tatsächlich nichts dazu im Netz. Wie würde deine profile-Variante dazu aussehen? Filtern musst du es doch trotzdem, wenn du was in ne Datei reinschreiben willst - oder irre ich da?

 

[maki]

/

geht immer als seperator.

Immer baubar ist richtig, imho sollte jeder entwickler eine eigene settings.xml datei haben, in der nochmals die werte aus der pom.xml überschrieben werden.
Profile sollten aber auch schon in der pom drinnen sein, eines für die dev, test, prod, etc. pp.
Selbstverständlich sollten die Werte aber auch schon als properties (ohne profil) angeben sein, standarwerte eben, wo möglich.

Filter ist schon ok.

Du findest nichts im Netz weil du wahrscheinlich nicht nach dem richtigen suchst
Standard vorgehen nach Buch eben.

Würde dir abraten so vorzugehen: http://sujitpal.blogspot.com/2006/10/maven2-multi-environment-filter-setup.html
Hat ime mehr Nachteile als Vorteile.

 

[BlackCraze]

Ich glaube wir reden aneinander vorbei ^^

Das Problem ist, dass die referenzierte Datein ein Zertifikat und ein Truststore sind. Die werden für ne SSL-Verbindung gebraucht und müssen als Systemvariablen gesetzt sein. Im Testsystem sind das natürlich andere Zertifikate als im Produktivsystem. Um diese Verbindung aufzubauen (egal ob prod oder test) lese ich in meinem Connector die besagte Propertiesdatei mit Pfaden ein und setze die Systemvariablen (keystore/truststore). Ich würde ja auch relationale Pfade für den Test nehmen ... aber es klappt nicht wenn ich da "/die.datei" reinschreibe. So würde man es machen, wenn die Datei direkt in der Testklasse über:

getClass().getResourceAsStream("/meine.datei")

gelesen werden würde (nehme stark an, dass das am Classloader liegt).


Um auf das urspürüngliche Problem zurückzukommen ...
Das eigentliche Problem ist nicht der file.separator aus der Maven-Property ${file.separator} - Das Problem ist der Wert, den ${basedir} herauswirft. Denn da kommt der Pfad mit backslashes - das kann ich auch nicht verhindern, indem ich die ${file.seperator} mit backslashes ersetze.

//in der zu filternden Properties:
var1=${basedir}${file.separator}src${file.separator}test${file.separator}resources${file.separator}die.datei
// --->
// var1=C:\Dokumente und Einstellungen\ich\workspace\Projekt\src\test\resources\die.datei

//in der zu filternden Properties:
var1=${${basedir}/src/test/resources/die.datei
// --->
// var1=C:\Dokumente und Einstellungen\ich\workspace\Projekt/src/test/resources/die.datei

Immer baubar ist richtig, imho sollte jeder entwickler eine eigene settings.xml datei haben, in der nochmals die werte aus der pom.xml überschrieben werden.

Das ist auch bei uns so ... da stehen zB die Werte für den lokalen Testserver drin

Profile sollten aber auch schon in der pom drinnen sein, eines für die dev, test, prod, etc. pp.
Selbstverständlich sollten die Werte aber auch schon als properties (ohne profil) angeben sein, standarwerte eben, wo möglich.

Das ist es ja, was ich erreichen will - jeder soll das gleiche Zertifikat nutzen ohne es nochmal einstellen zu müssen - dazu liegt das Zertifikat im testresources-Ordner. Zusätzlich gibt es eine Propertiesdatei "connection.properties" in der der Pfad steht, wo das Zertifikat zu finden ist. Wegen des o.g. Problems muss der Pfad imo absolut sein. Da aber der workspace bei jedem Entwickler wo anders ist, muss dieser Pfad in der "connection.properties" in der process-resources lifecyclephase generiert werden. Sonst kommt wärend der Testphase keine SSL-Verbindung zustande

 

[BlackCraze]

Kleiner Nachtrag:

Die Propertiesdatei wird über java.util.Properties geladen ... in der ApiDoc steht auch, dass die Backslashes wegfliegen, wenn sie nicht escaped sind:
Java ApiDoc

 

[BlackCraze]

Okay ... haben es gerade gelöst Es gibt zwei Wege, wie man das Problem umgehen kann:

1.Möglichkeit
Man speichert die Propertiesdatei als XML ab und lädt sie mit der Methode aProperties.loadFromXML(); Beim Lesen von XML beachtet die Properties-API keine Unicodeescapes (encoding wird ja in XML-Dateien angegeben)

2. Möglichkeit (imo die Bessere und richtigere ^^)
Man gibt in der pom EXPLIZIT die Version des maven-resources-plugin an ... (warum auch immer) wurde bei uns ohne Angabe der Versionsnummer die 2.2 benutzt ... diese version hatte den bekannten Bug, dass die Backslashes nicht escaped wurden. QUELLE
Nachdem die pom also folgendes intus hatte ...

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-resources-plugin</artifactId>
	<version>2.3</version>
</plugin>

... stand in der gefilterten Propertiesdatei folgendes:

var1=C\:\\Dokumente und Einstellungen\\ich\\workspace\\usw\\src\\test\\resources\\die.datei

Problem gelöst ... danke für die Mühe :toll:

 

[maki]

Danke für die Info, gut zu wissen

 

[BlackCraze]

übrigens gibt ${file.separator} immernoch ein einzelnes Backslash aus genau wie ${path.separator} - nur vollständige Pfade werden escaped