Лучшая практика для управления доступом к “.internal” пакету
Вы не можете проверить данные, когда данные находятся в файле (CSV, TXT ...). Вы должны прочитать данные в память компьютера, а затем с помощью различных методов, чтобы прочитать данные в файле другого типа.
Например, вы можете читать txt файл через File.ReadAllText, но вы не можете читать Excel таким же образом.
По моему мнению, вы можете попытаться ... поймать ... обернуть прочитанный код файла, если выдается какое-либо исключение, то файл не совсем то, что вы хотите.
3 ответа
Разве это не просто случай обновления 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 пакет. Платформа должна сделать остальных.
Между прочим, Вы затем используете Пакет Импорта: в любых зависимых пакетах, плагины и т.д., а не в зависимости от банки/проекта (который является старым, sucky путь, который не работает - поскольку Вы находите).
Это дает Вам крупное отделение Ваших зависимостей от кода. Если Вы решаете, что Ваш сменный код должен принадлежать другой банки/пакета, Вы просто перемещаете отдельные пакеты и заставляете новый пакет/плагин экспортировать его. Так как клиент связывается, просто импортируют пакет из "облака" (облако, являющееся платформой OSGi), можно переместить код намного более свободно.
Примечание: Как упомянуто в комментариях, Вы не должны запускать свои приложения в OSGi для извлечения этой "пользы". Eclipse может скомпилировать, это - код в условиях ограничений пакета OSGi, и Ваша сборка/сервер может работать в "незащищенном мире". например, декларации OSGi ничего не осуществляют третьим сторонам (кто хочет использовать .internal), но предоставьте "уведомления" и ограничения тем, которые хотят их.
Для сменных проектов: Используйте Явную установку, которую упоминает Stephen. (Можно также отредактировать это через страницу "Runtime" Явного редактора. Обратите внимание, что, если требуется только выставить пакет определенным плагинам, можно сделать это также использование
Export-Package: com.javadude.foo;x-friends:="com.javadude.fee"
Для несменных проектов: Используйте отдельные исходные папки для определения то, что экспортируется из проекта.
- Щелкните правой кнопкой по проекту и выберите, New Source Folder (возможно, называют это "внутренним источником"),
- Щелкните правой кнопкой по проекту и выберите Properties
- Перейдите к пути сборки Java
- Нажмите вкладку Order и Export
- Снимите флажок с исходными папками, которые Вы не хотите экспортировать
Только исходные папки, которые проверяются согласно "Порядку и Экспорту", будут добавлены к пути к классу ссылки на проекты.
Если Вы не должны обрабатывать чей-либо недоверяемый код, пользующийся Вашей доверяемой библиотекой, не ограничивайте его.
Быть необходимостью внутренний доступ / доступ пакета иногда указывает на отказ Вашего дизайна API, и Вы не можете знать до длинных послесловий.
Обнародуйте его, назовите его InternalWhatever, и живой с ним.