затмение, один путь к классу для компиляции, другой для запуска
пример:
Для входа, моего использования кода log4j. но другие банки мой код зависят от, использование slf4j вместо этого. Таким образом, обе банки должны быть в пути сборки. К сожалению, его возможное для моего кода для прямого использования (зависят от), slf4j теперь, или контекстом - помогают, или некоторые другие изменения разработчиков. Я хотел бы, чтобы любое использование slf4j обнаружилось как ошибка, но для моего приложения (и тесты) будет все еще нужен он в пути к классу при выполнении.
объяснение:
Я хотел бы узнать, возможно ли это в затмении. Этот сценарий часто происходит для меня. У меня будет крупный проект, который пользуется большим количеством сторонних библиотек. И конечно те сторонние банки имеют свои собственные зависимости также. Таким образом, я должен включать все зависимости в путь к классу ("путь сборки" в затмении) для приложения и его тестов, чтобы скомпилировать и работать (из затмения).
Но я не хочу, чтобы мой код использовал все те банки, просто несколько прямых зависимостей, которые я решил меня. Таким образом, если мой код случайно использует зависимость зависимости, я хочу, чтобы он обнаружился как ошибка компиляции. Идеально, как класс, не найденный, но любая ошибка, сделал бы.
Я знаю, что могу вручную настроить путь к классу при выполнении за пределами затмения, и даже в затмении я могу изменить путь к классу для определенного класса, который я выполняю (в конфигурациях выполнения), но это не управляемо, если Вы выполняете много отдельных тестовых сценариев или имеете много основных () классы.
5 ответов
Почему бы не использовать правила доступа , чтобы ваш код оставался чистым?
По моему опыту, это помогает быть более строгим, я заставил команду заполнять (бумажные) формы, зачем нужна эта банка и какая лицензия ...
, и они скорее набирали несколько строк кода, чем тянули 20 банок, чтобы открыть файл, используя только одну строку кода или другую причудливую «функцию».
Использование maven может помочь какое-то время, но когда вы впервые обнаружите jar-файлы с именами вроде nightly-build или snapshot, вы поймете, что попали в ад.
вывод: хорошо выбирайте зависимости
Похоже, им лучше управлять с помощью maven, интегрированного в eclipse с помощью m2eclipse .
Таким образом, вы можете выполнить только часть жизненного цикла сборки maven и управлять отдельным набором зависимостей для каждого шага сборки.
Будет ли полезно использовать jar-файл slf4j-over-log4j? Это позволяет использовать slf4j с фактическим ведением журнала в log4j.
Похоже, у вашего проекта достаточно отношений зависимости, и вы могли бы подумать о его структурировании с помощью пакетов OSGi (плагинов). Каждый пакет получает свой собственный загрузчик классов и может указывать, от каких пакетов (и, возможно, диапазонов версий и т. Д.) Он зависит, какие пакеты он экспортирует, реэкспортирует ли он данные из своих зависимостей и т. Д.
Сам Eclipse структурирован. из подключаемых модулей и фрагментов Eclipse, которые представляют собой просто пакеты OSGi с необязательным крошечным кусочком дополнительной проводки Eclipse ( plugin.xml , который используется для объявления «точек расширения» и «расширений» Eclipse). . Таким образом, Eclipse имеет довольно хорошие инструменты для создания встроенных пакетов и управления ими (через среду разработки подключаемых модулей). Многое из того, что вы там обнаружите, может привести вас к объединению «пакета OSGi» с «подключаемым модулем, расширяющим Eclipse IDE», но эти две концепции вполне разделимы.
Инструментальные средства Eclipse действительно различают довольно четко (и иногда раздражающе, но с точки зрения «полезного лекарства») между пакетами в вашей среде сборки и пакетами, которые включает конкретная конфигурация запуска.
После нескольких лет жизни в стране OSGi стандартный Java «плоский путь к классам» кажется мне странным и даже немного неработающим, в основном потому, что (как вы уже испытали) он сбрасывает все JAR-файлы на одну гигантскую арену и надеется, что они может кое-что уладить. Среда OSGi дает мне гораздо больший контроль над отношениями зависимости, и в качестве «побочного эффекта», естественно, также требуется прояснение этих отношений.Между этими четкими декларациями и их применением инструментария структура проекта более очевидна для всех в команде.
если мой код случайно использует зависимость зависимости, я хочу, чтобы это отображалось как ошибка компиляции. В идеале, поскольку класс не найден, но подойдет любая ошибка.
Поместите свой код в один плагин, ваши прямые зависимости в другие плагины, их зависимости в другие плагины и т. Д. И объявите зависимости каждого плагина. Eclipse немедленно сделает именно то, что вы хотите. Вам не будет предлагаться содержимое зависимостей в автозаполнении; вы получите красные волнистые линии и ошибки построения; и т. д.