Verwenden Sie den externen Paketlokalisierungspfad in der MANIFEST-Datei

Question

Die Datei MANIFEST.MF enthält einen Eintrag zum Definieren, welche * .properties-Dateien zur Laufzeit geladen werden. Diese Einträge definieren, den Namen und die entsprechenden Eigenschaften-Datei, die verwendet wird, um die Plug-Strings zu übersetzen, die mit dem Präfix „%“ beginnen, wie „% plugin.name“

Bundle-Localization: plugin 

plugin.properties als eine Zeile wie

%plugin.name=Runtime Plugin 

die Eigenschaftendatei können auch die Namen application.properties haben, als ich

Bundle-Localization: application 

Wenn die Eigenschaften von Dateien in einem Plugin definieren sind sub dire ctory "Eigenschaften" kann ich definieren

Bundle-Localization: properties/application 

---

Meine Frage: Kann ich ein Bundle-Lokalisierungspfad zu definieren, die außerhalb des Plugin ist, wie

Bundle-Localization: ../properties/application 

Es scheint, dass die ManifestLocalization-Objekt, das nach dem Pfad der Eigenschaftendatei sucht, fragt ZipFile nach dem Pfad. Und ZipPath unterstützt diese Funktionalität nicht.

Wie kann ich dieses Problem lösen?

Answer 1

Nein, Sie können keinen Pfad definieren, der sich außerhalb des Plugins befindet. Obwohl Fragmente zusätzlich zu dem Bündel betrachtet werden.

Im Allgemeinen sind Bundles nicht an einen Speicherort auf der Festplatte gebunden, so dass Sie nicht wirklich definieren können, wo ein Pfad wie ../properties aufgelöst werden soll. Stellen Sie sich beispielsweise ein Bundle vor, das mit BundleContext#installBundle(String location, InputStream input) installiert wurde. Der location-Parameter ist die Identität des Bundles und es sind keine Semantiken damit verbunden. Der Inhalt des Pakets wird aus dem Eingabestream ausgelesen. Was würde dann ein Pfad außerhalb des Bündels bedeuten?