eclipse, один путь к классам для компиляции, другой для запуска

Question

пример:
Для регистрации мой код использует log4j. но другие банки, от которых зависит мой код, вместо этого используют slf4j. Таким образом, обе банки должны быть в пути сборки. К сожалению, теперь мой код может напрямую использовать (зависеть от) slf4j, либо с помощью context-assist, либо некоторыми другими разработчиками. Я хотел бы, чтобы любое использование slf4j отображалось как ошибка, но моему приложению (и тестам) все равно понадобится его в classpath при запуске.

Объяснение:
Я хотел бы узнать, возможно ли это в затмении. Этот сценарий часто случается для меня. У меня будет большой проект, который использует множество сторонних библиотек. И, конечно же, эти сторонние банки также имеют свои зависимости. Поэтому я должен включить все зависимости в classpath («путь сборки» в eclipse) для приложения и его тестов для компиляции и запуска (изнутри eclipse).

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

Я знаю, что могу вручную настроить classpath при запуске вне eclipse, и даже внутри eclipse я могу изменить classpath для конкретного класса, который я запускаю (в конфигурациях run), но это не поддается управлению, если вы запускаете много отдельные тестовые случаи или несколько классов main ().

Answer 1

Похоже, у вашего проекта достаточно зависимостей, чтобы вы могли подумать о его структурировании с помощью пакетов OSGi (плагинов). Каждый пакет получает свой собственный загрузчик классов и определяет, какие пакеты (и, возможно, какие диапазоны версий и т. Д.) Он зависит, от каких пакетов он экспортирует, реэкспортирует ли он данные из своих зависимостей и т. Д.

Сам Eclipse структурирован из плагинов и фрагментов Eclipse, которые являются просто пакетами OSGi с необязательным крошечным кусочком дополнительной проводки Eclipse (plugin.xml, который используется для объявления «точек расширения» и «расширений» Eclipse) прилагается. Eclipse, таким образом, имеет довольно хорошие инструменты для создания и управления встроенными пакетами (через среду разработки плагинов). Многое из того, что вы там обнаружите, может привести к тому, что вы объедините «OSGi bundle» с «плагином, расширяющим IDE Eclipse», но эти две концепции вполне разделимы.

Инструменты Eclipse довольно четко (а иногда и раздражающе, но в смысле «полезной медицины») различают пакеты в вашей среде сборки и пакеты, включенные в конкретную конфигурацию запуска.

После нескольких лет жизни на земле OSGi стандартная Java-платформа "flat classpath" кажется мне странной и даже немного сломанной, в основном потому, что (как вы уже видели) она выбрасывает все JAR-файлы в одну гигантскую арену и надеется, что они может сортировать вещи. Среда OSGi дает мне намного больший контроль над отношениями зависимости, и как «побочный эффект» также естественно требует прояснения этих отношений. Между этими четкими декларациями и их применением инструментарием структура проекта более очевидна для всех в команде.

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

Поместите свой код в один плагин, свои прямые зависимости в другие плагины, их зависимости в другие плагины и т. Д. И объявите зависимости каждого плагина. Затмение сразу сделает то, что вы хотите. Вам не будет предложено содержимое зависимостей в автозаполнениях; вы получите красные загогулины и ошибки в построении; и т.д.

Answer 2

Почему бы не использовать правила доступа , чтобы сохранить ваш код в чистоте?

Answer 3

Было бы полезно использовать jar slf4j-over-log4j? Это позволяет использовать slf4j с фактической регистрацией, идущей в log4j.

Answer 4

По моему опыту, это помогает быть более сдержанным, я заставил команду заполнять (бумажные) формы, зачем нужен этот кувшин и какая лицензия ...

и они действительно набрали несколько строк кода вместо перетаскивания по 20 банкам, чтобы открыть файл, используя только одну строку кода, или другую необычную «функцию».

Использование maven может помочь на некоторое время, но когда вы впервые заметите банки с такими именами, как nightly-build или snapshot, вы будете знать, что находитесь в jar-hell.

Вывод: хорошо выбирайте зависимости

Answer 5

Похоже, что лучше управлять с помощью maven, интегрированного в Eclipse с m2eclipse .

Таким образом, вы можете выполнить только часть сборки mavenжизненного цикла, и вы можете управлять отдельным набором зависимостей на этапы сборки.