[DEV] SSL/TLS Paket fertig - wie in die Verzeichnisstruktur?

Hi!

Ich habe die Bouncycastle SSL/TLS-Bibliothek (GPL) für ewe portiert und alles rausgeschmissen, was man für https nicht braucht. Außerdem habe ich unsere httpConnection.java so angepasst, dass man ihr bloß "https://..." zu übergeben braucht und der Rest tut sich von selbst

Nun ist die Frage, wie ich die SSL/TLS-Bibliothek in die Verzeichnisstruktur bei BerliOS integrieren sollte. Die Bibliothek besteht aus gut 300 .java-Dateien bzw. genau so vielen .class-Dateien.

A. Sie könnte so eingebunden werden, dass sie jedes Mal mit kompiliert wird. Das ist schön, weil man dafür in der Konfiguration in Eclipse nicht viel ändern müsste (denke ich). Es ist außerdem schön, weil man leicht drin debuggen kann und auch leicht Fehler drin beheben kann. Hätte aber den Nachteil, dass es jedes Mal neu kompiliert werden muss. Ich habe das noch nicht probiert, ich denke, dazu müsste es dann unter src neben Cachewolf noch einen Zweig org.boncycastle geben.

B. Man siedelt unterhalb von lib ein eigenes Projekt tls_ewe an. Dann liegen dort die .java- und die .class-Dateien, die beide ins SVN eingecheckt werden müssten Man müsste dann ein Verzeichnis org/bouncycastle unterhalb von lib anlegen. Man kann ebenfalls darein debuggen, aber wenn man etwas ändern will, müsste man ein eigene Project "tls_ewe" in Eclipse anlegen, dort die ewe-libraries einbinden usw.

C. ???

Was meint Ihr?

Gruß,
Pfeffer.

PS: ich habe noch keinen Programmteil geschrieben, der Zertifikate überprüft. Es wird im Moment jedes Zertifikat akzeptiert (also abgelaufene genauso wie welche, bei denen der Name mit der Web-Adresse nicht übereinstimmt und bei denen die Ausstellersignatur falsch ist... Damit wird die Verbindung zwar verschlüsselt und kann rein passiv nicht entschlüsselt werden, aber aber durch aktive Man-in-the-middle-Attacken umgeleitet und entschlüsselt werden)

Ich entwickle zwar nicht an Cachewolf, aber die class-Dateien werden ja eh nicht mit eingecheckt. Da das Teil unter GPL steht, kann man es auch nicht einfach so ein eine .jar kompilieren (was sonst wohl das einfachste wäre). Somit bleibt nur die Möglichkeit, den Source mit hochzuladen und der kommt logischerweise in ./src, in diesem Fall ./src/org/boncycastle/

Naja, heute haben wir unter lib sowohl .class als auch .java Dateien. Mag sein, dass ich es damals aus Dummheit so angelegt habe. In eclipse ist lib unter libraries eingebunden, es werden also die .class Dateien genommen. Wenn man an diesen Dateien etwas ändert, muss man halt die .class Dateien neu erzeugen, am Besten über ein eigenes Projekt. Da es an diesen Dateien aber normalerweise kaum Änderungen gibt, wäre es OK.

Würde also für Variante B. sprechen.

N'Abend

an für sich spricht alles für Variante B). Die Möglichkeit JAR-Dateien einzubinden (oder EWE-Dateien) gibt es wohl nicht und damit scheidet C) aus

Gruß
ColleIsarco

Ich denke auch, dass B die bessere Lösung ist.

Wobei ich auch davon ausgehe, dass Eclipse auch bei A nicht bei jedem Kompilieren die ungeänderten Dateien wieder kompilieren würde.

So, habe mich doch für Alternative A entschieden, weil das keinerlei Anpassungen der Konfig in Eclipse erfordert und weitere Anleitungen erspart, wie man gegebenenfalls an der SSL/TLS-Library etwas ändert.

Leider habe ich dabei versehentlich auch die *.class mit eingecheckt - MiK, Du kennst Dich doch mit SVN aus: kannst Du sie wieder löschen?

Gruß,
Pfeffer.

PS: Über Rückmeldung, dass es funktioniert, freue ich mich natürlich

pfeffer schrieb:

Leider habe ich dabei versehentlich auch die *.class mit eingecheckt - MiK, Du kennst Dich doch mit SVN aus: kannst Du sie wieder löschen?

Zum Vergrößern anklicken....

Erledigt.

koennte wer die anderen build dateien (fwrtsnapshot.sh,compile.sh,compile.bat) auch eben anpassen und einchecken?

danke