Diese Erkenntnis hat mich einige Kopfschmerzen gekostet. 
Damit
es anderen nicht auch so geht, sind hier die Details.
Zunächst als Erklärung zur Option -jar
beim Aufruf von java.exe. Wenn in einem Projekt mehrere Java-Klassen benötigt
werden, so können sie zusammen in einer komprimierten Datei gespeichert
werden. Eine solche Datei ist im Prinzip eine ZIP-Datei mit der Dateiendung
JAR. Damit der Java-Interpreter (java.exe) weiß, welche der Klassen er
beim Aufruf direkt ausführen soll, existiert in der JAR-Datei ein so genanntes
Manifest. Mit
java.exe -jar MyProject.jar
wird also Java so aufgerufen, dass in
der JAR-Datei nach dem Manifest gesucht wird und die dort angegebene Klasse
aufgerufen wird.
Wenn ich in Versionen vor Notes 8 eine
Kundenanforderung mit Standard-Notes-Mitteln nicht umsetzen kann, greife
ich gerne zu Java. Bisher habe ich dann einfach meinen Code in eine JAR-Datei
gepackt und im Verzeichnis [Notes-Programmpfad]\jvm\lib\ext abgelegt. (Wir
haben in unserem Framework einen Mechanismus, der solche Erweiterungen
automatisch beim Öffnen einer Datenbank auf dem Rechner des Anwenders verteilt.)
Wenn die JAR-Datei in diesem Verzeichnis liegt, spielt der Klassenpfad
(Classpath) keine Rolle, weil der Java-Interpreter automatisch in diesem
Verzeichnis sucht.
Nur hatte in einer Kundenumgebung die
Anwender kein Schreibrecht auf das Verzeichnis [Notes-Programmpfad]\jvm\lib\ext.
Insofern mussten wir die JAR-Datei in einem anderen Verzeichnis ablegen.
Weil das Java-Programm zwar aus dem Notes Client heraus aufgerufen werden
sollte, aber nicht als Java-Agent gestartet werden sollte, wurde der Java-Interpreter
direkt aufgerufen. Allerdings führte das zu der schönen Fehlermeldung
Exception in thread "main"
java.lang.NoClassDefFoundError: de/assono/demo/AnotherPackage
Der Java-Interpreter konnte also eine
benötige Klasse nicht finden, die sich in einer anderen JAR-Datei befand.
Die erste Überlegung war, dass wir vergessen
hatten, den Klassenpfad zu setzen. Eine Änderung des Aufrufs in
java.exe -jar -classpath ".;c:\temp\MyProject.jar;
c:\temp\AnotherPackage.jar;" MyProject.jar
brachte leider keine Verbesserung.
Nach einer etwas längeren Google-Recherche
bin ich dann in der Java-Dokumentation
fündig geworden.
-jar
...
When you use this option, the JAR file is the source of all user classes, and other user class path settings are ignored.
Die Lösung war dann relativ einfach.
Mit der einfachen Zeile Class-Path: AnotherPackage.jar
im Manifest kann der Klassenpfad angegeben
werden. Die Details stehen in einem Sun Tutorial.
