Лучшие практики для контроля доступа к пакету ".internal" - PullRequest
Новая
       22

Лучшие практики для контроля доступа к пакету ".internal"

10 голосов
/ 16 февраля 2009

Я пишу плагины Eclipse и экспортирую некоторые классы в виде API, желая ограничить доступ к другим классам.

Я следую распространенной практике Eclipse, разделяющей эти классы в подпакет ".internal".

Однако тогда я не могу использовать «пакет» или доступ уровня по умолчанию для этих классов, поскольку многие из них должны использоваться экспортируемыми классами.

Какова наилучшая практика для предотвращения или предотвращения использования пользователями моего API этих классов в своих целях? Есть ли автоматическая проверка?

Я признаю, что я баловался использованием некоторых внутренних классов Eclipse, когда у меня не было выбора:)

Уточнение: у меня аналогичная потребность с кодом без плагинов.

Ответы [ 3 ]

8 голосов
/ 16 февраля 2009

Разве это не просто случай обновления META-INF / MANIFEST.MF, чтобы он представлял собой подключаемый модуль osgi (если это еще не так?). Это должно выглядеть примерно так: 

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: My-plugin
Bundle-SymbolicName: com.mycompany.mypluginname
Bundle-Version: 1.0.0
Bundle-Vendor: MyCompany
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Service-Component: 
Import-Package: org.apache.log4j;version="1.2.14" (, separated etc)
Export-Package: com.mycompany.mypluginname.myapipackage;version="1.0.0"

А потом приятно опустить пакет .internal. Платформа должна сделать все остальное.

Кстати, вы затем используете Import-Package: в любых зависимых пакетах, плагинах и т. Д., А не в зависимости от jar / проекта (который является старым, отстойным способом, который не работает - как вы находите ).

Это дает вам массовое разъединение ваших зависимостей кода. Если вы решите, что код вашего плагина должен принадлежать другому jar / bundle, вы просто перемещаете отдельные пакеты и заставляете новый пакет / plug-in экспортировать его. Поскольку клиентские пакеты просто импортируют пакет из «облака» (облако является платформой OSGi), вы можете перемещать код гораздо более свободно.

Примечание : Как уже упоминалось в комментариях, вам не нужно запускать свои приложения в OSGi, чтобы получить эту "выгоду". Eclipse может скомпилировать свой код в соответствии с ограничениями пакета OSGi, и ваша сборка / сервер может работать в «незащищенном мире». например манифесты OSGi ничего не навязывают третьим сторонам (которые хотят использовать .internal), но предоставляют «уведомления» и ограничения тем, кто их хочет.

2 голосов
/ 16 февраля 2009

Для проектов плагинов : Используйте настройку Manifest, о которой упоминает Стивен. (Вы также можете отредактировать это на странице «Runtime» редактора Manifest. Обратите внимание, что если вы хотите выставлять пакет только определенным плагинам, вы можете сделать это также с помощью 

Export-Package: com.javadude.foo;x-friends:="com.javadude.fee"

Для проектов без плагинов : Используйте отдельные исходные папки, чтобы определить, что экспортируется из вашего проекта.

  1. Щелкните правой кнопкой мыши по проекту и выберите New Source Folder (возможно, назовите его «internal-source»)
  2. Щелкните правой кнопкой мыши проект и выберите Свойства
  3. Перейти к пути сборки Java
  4. Перейдите на вкладку «Заказ и экспорт»
  5. Снимите флажки с исходных папок, которые вы не хотите экспортировать

Только исходные папки, отмеченные в разделе «Заказ и экспорт», будут добавлены в путь к классам ссылок на проекты.

0 голосов
/ 16 февраля 2009

Если вам не приходится обрабатывать чужой ненадежный код с помощью доверенной библиотеки, не ограничивайте его.

Необходимость внутреннего доступа / доступа к пакету иногда указывает на сбой в дизайне API, и вы не можете знать об этом после долгих послесловий.

Сделайте это общедоступным, назовите его InternalWh чем угодно и живите с ним.

...