我想在OSGi環境中使用專有的非OSGi jar包。對於開發，我們只需使用Maven bundle插件重新打包/導出它[1]。問題是，出於法律方面的原因，我們無法將這些軟件包重新分發給我們的客戶，這會殺死嵌入和重新打包，這是（AFAIK）唯一的選擇（參見[2]）。OSGi應用程序中需要專有的非OSGi包 - 無法重新分配
在使用OSGi之前，我們在手冊中有一節介紹瞭如何在自己獲取這些文件後將這些文件放在庫文件夾中。鑑於OSGi規則解決類，這顯然不會工作了。
我是否正確地認爲解決這個問題的唯一方法是合法的，即從軟件包的供應商那裏獲得再分配許可證（這可能是一種貴族式的噩夢並阻礙及時交付），還是我錯過了一項技術解？
[1] How can I share non-OSGi libraries between bundles in an OSGi container?
[2] Non-osgi library usage in an osgi application
我只是簡單地將這個JAR添加到主Java應用程序類路徑中，使用它已經建立的庫文件夾中的現有位置。然後，您可以使用org.osgi.framework.system.packages.extra屬性將所需的軟件包導出到OSGi中。
也許OSGi的遠程服務(distributed OSGi)可能是一個答案。您將承載公開專有庫的OSGi環境，並將剩餘的安裝在客戶機上。
我在一個商業項目中也看到了這個要求。我們最終添加了一個特殊的軟件包，它在啓動時從相關站點下載了所需的jar並將它們添加到我們的再出口軟件包中。
所以
J.jar我們想用META-INF/MANIFEST.MF是重新 - 出口所有相關包J.jarMETA-INF/DOWNLOADS - 指定我們可以從哪裏下載J.jarMETA-INF/DOWNLOADS。如果確實如此，則它下載指定的罐子（如果尚未存在的話）。當重新導出包稍後啓動時，看起來就像我們發佈了冒犯的jar ......每個人都很開心。
當我們需要新版本的jar時，我們剛剛發佈了我們的jar的新版本，正如我們通常所做的那樣。主要問題是如何處理下載過程中的任何問題。
這看起來是可行的，我喜歡下載內容的（潛在的）橫切關注的事實不是由需要下載的軟件包實現的。雖然這可能不是我解決當前問題的方法，但我會記住這個OSGI特定的關注分離模式，因爲它在許多情況下可能很有用。 – Christoph
這是非常哲學的。數字內容的確切構成分配？ （1）我們都同意，如果有問題的jar包含在您的安裝下載中，它是一個重新分發。（2）如果安裝程序是一個精簡的外殼，當它運行時，它會從互聯網下載更多的內容。如果它從你的服務器下載jar，我認爲大多數人會同意這與（1）基本相同，並且是重新分發。
（3）如果安裝shell從所有者服務器下載jar，該怎麼辦？假設它沒有最終用戶的知識就自動化了。
難道有人真的認爲（3）與（2）有很大不同，並且它是而不是的再分配？
我認爲它是，爲所有意圖和目的。我們正在有效地發佈我們的程序，這是如何做到底的，與再分配許可的精神無關。無論誰獲得該計劃都會得到這個罐子，這是一個事實。
至少我們應該聯繫作者來驗證他是否可以使用它。我們必須對免費軟件給予應有的尊重，不要以違背作者意願的方式使用它們。
非常好，謝謝！我錯過了這個屬性。 – Christoph