Лучшая практика для контроля доступа к пакету «.Internal»

Question

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

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

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

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

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

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

Answer 1

Разве это не случай обновления 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" 

И затем красиво опустить внутренний пакет. Платформа должна делать все остальное.

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

1. Щелкните правой кнопкой мыши проект и выберите New Source Folder (возможно, назовите его "внутренний-источник")
2. правой кнопкой мыши проект и выберите Свойства
3. Перейти к Java Build Path
4. Нажмите Заказ и вкладка Экспорт
5. Uncheck исходные папки, которые вы не хотите экспортировать

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