2 Ordner namens org einbinden müssen

[Guest]

@ all

Ich habe ein "kleines" aber vielleicht doch simples Problem:

Ich muss in mein Jar-File für den Kunden den Ordner org für die Datenbank einbinden (für den Treiber, ansprechen des Servers usw. usw.). Nun möchte ich noch JXDatePicker einbinden. In meiner Entwicklungsdokumentation kein Prob. Da gebe ich einfach den Pfad an, wo sich das Jar-File liegt. ABER: Für den Kunden muss ich dieses Jar-File entpacken und den Ordner org mit in das Jar-File legen. Das kann ich aber nicht, da zwei Ordner namens org --> da wird einer mindestens überschrieben.

Hat da einer vielleicht eine ganz easy Lösung?

 

[maki]

Wieso musst du das jar File entpacken?

 

[Guest]

Siehe FAQ dieser Seite:

www.java-forum.org/de/viewtopic.php?t=13075

 

[maki]

Mal davon abgesehen ob das überhaupt legal ist, kann du die Verzeichnisse auch mergen, musst nur hoffen das keine Klasse/Datei doppelt vorkommt sonst fliegt eine raus.

Der sauberere Weg wäre einfach die benötigten jars in den CP zu hängen.

 

[Guest]

Und wie mache ich das, bei Erzeugung des eigenen jar-Files die benötigten Jars in den CP hängen?

 

[maki]

Nicht beim erzeugen, sondern beim ausführen der Anwendung.

 

[Guest]

@ maki

Der Anwender macht nix anderes wie Doppelklick auf das JAR-File. Die rufen das nicht über die Konsole auf!! Davon haben die keine Ahnung. Die brauchen den Doppelklick.

 

[maki]

"Die brauchen den Doppelklick" lässt sich auf viele Arten lösen, start skripte gehen immer, Webstart wäre auch eine Möglichkeit.

 

[Guest]

@ maki

Die möchten nur das Jar-File. PUNKT. Nix anderes. Kein Starten über Start-Skripte, Webstart oder oder oder.

 

[Guest]

@ maki

Ich habe eine andere Möglichkeit gefunden, wie man das einbindet. Einfach in die MAINFEST-Datei den Klasspfad aufnehmen und das Problem hat sich erledigt.

 

[maki]

Die möchten nur das Jar-File. PUNKT. Nix anderes.

Na dann gilt mein 2. Post.

Ich habe eine andere Möglichkeit gefunden

Wie jetzt, doch "was anderes"... *g*

 

[Guest]

@ Moderatoren

wenn die in der FAQ beschriebene Vorgehensweise "nicht ganz" legal ist, dann sollte man diese Vorgehensweise überarbeiten! Und zwar dringend.

 

[Wildcard]

wenn die in der FAQ beschriebene Vorgehensweise "nicht ganz" legal ist, dann sollte man diese Vorgehensweise überarbeiten! Und zwar dringend.

Nein, es handelt sich um eine reine Lizenzfrage, die entscheidet was erlaubt ist und was nicht. Mit der WTFPL ist das zum Beispiel überhaupt kein Problem.

 

[Guest]

Wie sieht das denn bei der H2-Datenbank aus? Ich habe zwar die Lizenz gelesen, aber nichts dazu gelesen. Oder habe ich was überlesen?

 

[Wildcard]

Ich bin kein Anwalt und meines Wissens besteht in diesem Punkt auch überhaupt keine Rechtssicherheit, da entsprechende Urteile fehlen.
Repackaging kann durchaus als Modifikation verstanden werden, was nach der MPL (eine der H2 Lizenzen) folgende Konsequenz hat:

3.2. Availability of Source Code

Any Modification which You create or to which You contribute must be made available in Source Code form under the terms of this License either on the same media as an Executable version or via an accepted Electronic Distribution Mechanism to anyone to whom you made an Executable version available; and if made available via Electronic Distribution Mechanism, must remain available for at least twelve (12) months after the date it initially became available, or at least six (6) months after a subsequent version of that particular Modification has been made available to such recipients. You are responsible for ensuring that the Source Code version remains available even if the Electronic Distribution Mechanism is maintained by a third party.

http://www.h2database.com/html/license.html

Übrigens auch interessant zum Thema OpenSource Lizenzen:
Es gab kürzlich ein Urteil (leider keine Quelle zur Hand) nach dem das ableiten von Klassen als Derivative Works gilt. Bei Interfaces angeblich noch ok, aber bei konkreten Klassen wird die Funktionalität selbst verändert. Das hat in der Regel zur Folge, das man sein Produkt plötzlich ebenfalls als OpenSource veröffentlichen muss. Im konkreten Fall war es AFAIK LGPL.
Also, immer schön vorsichtig sein und besser auf späße wie FatJAR verzichten.

 

[Guest]

Dann schreibt in der FAQ auch nicht, dass ein jar-File nicht in ein jar-File gelegt werden kann.

 

[Wildcard]

Dann schreibt in der FAQ auch nicht, dass ein jar-File nicht in ein jar-File gelegt werden kann.

Wieso? Was hast du daran auszusetzen?

 

[Guest]

Die Erläuterungen zu Manifest.MF -> also was da drinnen stehen mußt, solltet ihr schon wissen, ich gehe hier nur drauf ein, wie ich ein Jar File via dem jar Befehl in ein anderes Jar File packen kann.

Also grundsätzlich geht das eigentlich gar nicht, man muss das Jar File (ich nehme hier den neueste ODBC-Treiber von Oracle - http://download.oracle.com/otn/utilities_drivers/jdbc/9205/ojdbc14.jar ) entpacken und wieder reinstecken!

Also das man ein Jar File einfach reinkopiert und dann sagt man lässt den Classpath drauf zeigen funktioniert nicht (vielleicht gehts irgendwie, aber das will ich nicht näher behandeln).

Hier wird beschrieben, dass es grundsätzlich nicht geht, ein jar-File in ein jar-File zu stecken. Geht schon. Z. B. Unterordner lib erstellen, gewünschtes jar-File reinstecken und in die Mainfest-Datei den Class-Path für dieses Jar-File aufnehmen. Anschließend jar-File erstellen und es ist kein Problem. Dort wird beschrieben, dass man das Jar-File entpacken muss. Nein, muss man nicht, wenn man es entsprechend einbindet.

 

[Wildcard]

Nein, die FAQ ist an dieser Stelle korrekt. Es ist mit regulären Classloadern nicht möglich Klassen aus einem inneren jar zu laden.