Лучший способ построить систему плагинов с Java - PullRequest
Новая
       48

Лучший способ построить систему плагинов с Java

138 голосов
/ 21 января 2009

Как бы вы внедрили систему плагинов для своего Java-приложения?

Возможно ли иметь простую в использовании (для разработчика) систему, которая обеспечивает следующее:

  • Пользователи помещают свои плагины в подкаталог приложения
  • Плагин может предоставить экран конфигурации
  • Если вы используете платформу, совместима ли лицензия с коммерческим развитием?

Ответы [ 8 ]

100 голосов
/ 21 января 2009

Для начала вам нужен интерфейс, который должны быть реализованы всеми плагинами, например, 

public interface Plugin {
    public void load(PluginConfiguration pluginConfiguration);
    public void run();
    public void unload();
    public JComponent getConfigurationPage();
}

Авторы плагинов должны затем объединить свои плагины в файлы JAR. Ваши приложения открывают файл JAR и могут затем использовать атрибут из манифеста JAR или список всех файлов в файле JAR, чтобы найти класс, который реализует ваш интерфейс Plugin. Создайте этот класс, плагин готов к работе.

Конечно, вы также можете захотеть внедрить какую-то песочницу, чтобы плагин был ограничен в том, что он может и не может делать. Я создал небольшое тестовое приложение (и написал об этом в блоге ), которое состоит из двух плагинов, одному из которых запрещен доступ к локальным ресурсам.

40 голосов
/ 21 января 2009

Использование OSGi .

Это основа системы плагинов Eclipse. Equinox - это реализация Eclipse (лицензированная EPL), а Felix - это реализация проекта Apache (лицензированная публичная лицензия Apache).

Eclipse предоставляет конкретный пример того, как OSGi может охватывать упомянутые вами точки (или вы можете просто построить свое приложение поверх Eclipse RCP , если вам нужен полный стек Eclipse / SWT / JFace).

29 голосов
/ 21 января 2009

Начиная с версии 1.6, java.util.ServiceLoader может использоваться, если вы хотите написать свою простую систему

Но если вам нужно нечто большее, чем базовые функции, используйте одну из существующих платформ.

16 голосов
/ 21 января 2009

Существует также JPF (Java Plugin Framework) .

13 голосов
/ 24 ноября 2014

Используйте PF4J . Имеет поддержку Web, Spring и Wicket. Простота в использовании и сборке приложений

13 голосов
/ 10 декабря 2012

Я работал над OSGi в течение недели - интенсивной недели OSGi. В конце концов, это был плохой сон, но я многому научился.

Мне удалось заставить работать OSGi (не просто, все примеры устарели, всему в сети не менее трех лет, если не пять), но у меня возникли серьезные проблемы с его интеграцией в существующий проект из-за проблемы с банкой манифестов.

Короче говоря, есть только несколько неясных инструментов, используемых для создания манифестов, и они плохо документированы (BND Tools вряд ли неясен, но он разработан для определенного процесса в Eclipse). Кроме того, большая часть доступной информации OSGi не предназначена для разработчиков приложений, у которых уже есть настольное приложение.

Это делает большую часть контекста для информации туманной или неуместной. Сообщения Нила Бартлетта в блоге были самой большой помощью, но даже те, которые не смогли получить работающую систему (я взял некоторый код из учебника Феликса и собрал его вместе, чтобы развернуть встроенную среду). Я нашел черновик его книги, который он бесплатно опубликовал несколько лет назад, и это прекрасно, но примеры в Eclipse не работают из-за изменений в поддержке Eclipse OSGi.

Каждый шаг - серьезное препятствие. Я постараюсь опубликовать некоторые детали здесь позже.

9 голосов
/ 29 января 2009

Я думаю, что рекомендация OSGi для решения вышеуказанной проблемы - очень плохой совет. OSGi - это «правильный выбор», но для сценария, подобного описанному выше, я думаю, что достаточно JPF или какой-то доморощенный минималистичный каркас.

3 голосов
/ 23 октября 2009

Несколько лет назад я запустил такой проект, и надеюсь, что скоро он будет готов. Меня вдохновили такие проекты, как NetBeans и Eclipse, но между тем он изменился на что-то немного другое. OSGi выглядит сейчас как хороший выбор, но у меня не было возможности сравнить его с моим проектом. Он похож на JPF, упомянутый выше, но в то же время отличается во многих отношениях.

Основная идея, которая меня мотивировала, заключается в том, чтобы как можно проще создавать Java-приложения без разделения между веб-приложениями, настольными приложениями или апплетами / приложениями JWS (конечно, это не распространяется на пользовательский интерфейс - пока) как основная функциональность.

Я создал проект с несколькими целями:

  • Неважно, если вы создаете веб-приложение или приложение для настольного компьютера, вы должны запускать приложение таким же образом, простым основным методом, не требуя особого объявления web.xml (не то чтобы я против использования стандартного веб-интерфейса). дескриптор, но он не подходит для системы плагинов, где вы добавляете «сервлеты» - я называю их RequestHandler (s) - динамически по вашему желанию).
  • легко подключить «расширения» вокруг «точки расширения» - что-то из Eclipse, но другой подход.
  • самораспространяемый, поскольку все плагины зарегистрированы (файлы XML), приложение должно быть самораскрываемым независимо от системы сборки - конечно, есть задача Ant и Maven MOJO, которые являются связями с миром weside, но в конце он вызывает приложение и дает ему указание самостоятельно развернуться в определенном месте.
  • заимствованный у Maven, он может загружать код из репозиториев (включая репозитории Maven 1 и 2), так что ваше приложение может быть развернуто в виде одного маленького кувшина, если у вас есть доступ к репозиториям (полезно иногда, и в основном это обеспечивает поддержку). для автообновлений - разве вам не нравится идея получать уведомления от вашего веб-приложения о том, что есть более новая версия, она была загружена, и вам просто нужно ваше разрешение для ее установки? Я знаю, что мне это нравится).
  • базовый мониторинг приложений о состоянии системы, уведомления по электронной почте в случае сбоев
...