bash, zip, unzip, xargs, grep, find, tree im PATHjava, javac, pack200, unpack200, jar, jarsigner, keytool, usw. sind im PATHcd <nuclos>; cp build.properties_template build.propertiesbuild.properties editieren und an die lokalen Verhältnisse anpassen. 3rdparty.dir ist ein (zunächst) leeres Verzeichnis, in denen die Tomcats und PostgreSQL Installationspakete hinein geladen werden.cd nuclos-installerant main
cd <nuclos>mvn -Pquick clean installpack200 Pakete) werden vom Build lokal im Verzeichnis ~/jar.cache abgelegt, um den Build zu beschleunigen. Dies ist notwendig, da der Jenkins zum Erzeugen aller signierten JARs für einen Nuclos 4.4 Build etwa 6 Stunden benötigt.Der Java 6 jarsigner hat regelmäßig Schwierigkeiten, JARs richtig zu unterschreiben und merkt es dann noch nicht einmal. Die Probleme erkennt man daher erst beim Client Start über Web Start. In der Vergangenheit waren u.A. folgende JARs betroffen:
Das ist auch der Grund, warum es unter Java 6 nicht möglich ist, ein all-in-one JAR zu erzeugen.
Maven betreibt einen lokalen JAR Cache (normalerweise unter ~/.m2/repository), der für selbst gebaute JARs und heruntergeladene Abhängigkeiten verwendet wird. Wir bauen jedoch Java 6 und Java 7 JARs. Damit in einem Java 6 Build nicht auf einmal Java 7 JARs auftauchen (die dann nicht funktionieren), ist es notwendig, für die beiden Builds unterschiedliche JAR Caches zu verwenden.
Der JAR Cache kann in der settings.xml (normalerweise ~/.m2/settings.xml) konfiguriert werden. Maven lässt sich jedoch davon überzeugen, eine andere settings.xml Datei zu verwenden. Auf dem Jenkins wird daher die Standard settings.xml Datei (die als JAR Cache ~/.m2/repository verwendet) für die Java 6 Builds benutzt, während für Java 7 Builds eine ~/.m2/settings-j7.xml Datei verwendet wird (die als JAR Cache ~/.m2/repository-j7 benutzt). Entsprechende setting Dateien sind (Nuclos intern) in Slack zu finden.
Oracle ermutigt sehr stark, signierten JARs einen Timestamp zu verpassen (d.h. signierte JARs ohne Timestamp führen zu einer Warnung bei der Überprüfung der Signatur). Daher bekommen die von uns signierten JARs seit einiger Zeit einen (cryptographischen) Timestamp. In den den modjar*.sh Scripten ist dafür die Zeile
SIGN_OPTIONS="-tsa http://tsa.starfieldtech.com/ -tsacert $ALIAS" |
verantwortlich. Ein großer Nachteil dieser Timestamps ist jedoch, dass dadurch das Signieren der JARs deutlich länger braucht. Insbesondere ist die Antwortzeit des Dienstes stark erhöht, wenn man bereits einige JARs signiert hat. Auch deswegen ist der ~/jar.cache zwingend erforderlich.
Hier wird ein kostenloser (nicht-dokumentierter) Timestamp Service (tsa.starfieldtech.com) aus dem Internet verwendet. Die Zeit, um signierte JAR mit Timestamp zu erzeugen, könnte sich durch die Verwendung eines kommerziellen Timestamp Service wahrscheinlich deutlich reduzieren. |