Простой код Java для извлечения пути к классам из заданного файла pom.xml?

Как мне написать простой java main(), который:

  1. Принимает имя области действия maven и путь к файлу pom.xml в качестве аргументов.
  2. Создает список строк, содержащих путь к классам соответствующего проекта maven и области видимости.
  3. Зависит только от библиотек, которые в настоящее время поддерживаются?

Мотивация:

Я пытаюсь обновить зависимости плагина Fitnesse-maven-classpath, найденного по адресу https://github.com/amolenaar/fitnesse-maven-classpath , который имеет проблемы с удобством использования из-за его зависимости от maven-embedder-3.0.4, см., например, Fitnesse maven-classpath-plugin конфликтует с банкой Guava и Maven/Plexus ComponentLookupException - кошмар пути к классам? .

Простое обновление зависимости в pom-файле плагина до maven-embedder-3.1.1 и замена import com.sonatype.aether на import com.eclipse.aether в исходном коде java делает проект компилируемым, но тесты завершаются неудачей с длинным списком ошибок, который начинается следующим образом:

    Unable to parse POM file: org.codehaus.plexus.component.repository.exception.ComponentLookupException: com.google.inject.ProvisionException: Guice provision errors:

    1) No implementation for java.util.Set<org.eclipse.aether.RepositoryListener> was bound.
      while locating java.util.Set<org.eclipse.aether.RepositoryListener>
        for parameter 0 at org.eclipse.aether.internal.impl.DefaultRepositoryEventDispatcher.<init>(Unknown Source)
      while locating org.eclipse.aether.internal.impl.DefaultRepositoryEventDispatcher
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      while locating org.eclipse.aether.impl.RepositoryEventDispatcher
        for parameter 0 at org.eclipse.aether.internal.impl.DefaultMetadataResolver.<init>(Unknown Source)
      while locating org.eclipse.aether.internal.impl.DefaultMetadataResolver
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      while locating org.eclipse.aether.impl.MetadataResolver
        for parameter 0 at org.apache.maven.repository.internal.DefaultVersionResolver.<init>(Unknown Source)
      while locating org.apache.maven.repository.internal.DefaultVersionResolver
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      while locating org.eclipse.aether.impl.VersionResolver
        for parameter 0 at org.eclipse.aether.internal.impl.DefaultRepositorySystem.<init>(Unknown Source)
      while locating org.eclipse.aether.internal.impl.DefaultRepositorySystem
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      while locating org.eclipse.aether.RepositorySystem
      while locating org.apache.maven.artifact.resolver.DefaultArtifactResolver
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      while locating org.apache.maven.artifact.resolver.ArtifactResolver
      while locating org.apache.maven.repository.legacy.LegacyRepositorySystem
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      while locating org.apache.maven.repository.RepositorySystem
      while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      while locating org.apache.maven.execution.MavenExecutionRequestPopulator

    2) No implementation for java.util.Set<org.eclipse.aether.RepositoryListener> was bound.
      while locating java.util.Set<org.eclipse.aether.RepositoryListener>
        for parameter 0 at org.eclipse.aether.internal.impl.DefaultRepositoryEventDispatcher.<init>(Unknown Source)
      while locating org.eclipse.aether.internal.impl.DefaultRepositoryEventDispatcher

    ...
    etc
    ...

      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
      while locating org.apache.maven.execution.MavenExecutionRequestPopulator

    37 errors
        at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:974)
        at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
        at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
        at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
        ... 37 more

В частности, плагин по сути состоит из двух частей: во-первых, получение пути к классам из файла pom, а во-вторых, передача этого пути к классам в Fitnesse. Первая часть, создание пути к классам, завершается с ошибкой с указанным выше сообщением об ошибке при обновлении до maven-embedder-3.1.1 и с менее подробным сообщением при обновлении до 3.5.4.

Существует ли простая альтернатива существующей реализации пути к классам, которая зависит только от современных библиотек, скажем, на https://github.com/apache/maven-dependency-plugin/tree/maven-dependency-plugin-3.1.1 ?

Я специально прошу код метода main(), чтобы убедиться, что я могу преобразовать его в код плагина, а не предполагать, что мой код вызывается, скажем, из запущенного процесса mvn, который уже вычислил путь к классам.


maven pom.xml classpath maven-dependency-plugin fitnesse
person Olivier    schedule 11.07.2018    source источник
comment
Зачем вам нужно получить путь к классам из сборки? С какой целью? Если у этого фитнес-плагина есть проблема, она должна быть исправлена...   -  person khmarbaise    schedule 11.07.2018
comment
@khmarbaise, цель состоит в том, чтобы посмотреть, смогу ли я решить проблему с плагином.   -  person Olivier    schedule 11.07.2018
comment
Тогда вам следует заглянуть в код плагина и не пытаться применить путь к классам извне...   -  person khmarbaise    schedule 11.07.2018
comment
Это именно то, что я делаю. Я сузил проблему до части извлечения classpath, т.е. проблема не зависит от пригодности. Я не понимаю существующий код извлечения пути к классам maven и подозреваю, что кто-то может придумать более простую реализацию, чем существующая, учитывая, что желаемая функциональность почти обеспечивается плагином maven-dependency-plugin, за исключением того факта, что это инструмент командной строки. Как только кто-нибудь предоставит мне main(), я удалю объявление main и вставлю тело предложенного метода main() в исходный код плагина.   -  person Olivier    schedule 11.07.2018
comment
@Olivier говорит не об исправлении плагина Maven, а о плагине FitNesse.   -  person Fried Hoeben    schedule 21.07.2018

Ответы (1)


arrow_upward
0
arrow_downward

Я столкнулся с той же проблемой, используя плагин FitNesse maven, и я отказался от попыток исправить ошибку. проблема. Вместо этого я работал над этим, используя несколько разных подходов, может быть, они сработают и для вас?

При запуске тестов из вики (например, когда у меня есть локальный (веб)сервер FitNesse и я хочу нажать «Тест» или «Люкс» в своем браузере):

  • Я использую плагин как есть (поместив его в папку плагинов вики) без проблем; поскольку тесты выполняются в отдельной JVM, у них есть собственный путь к классам, отдельный от вики (у которой есть плагин), поэтому версии библиотек не конфликтуют.
  • Чтобы создать локальную вики-установку без необходимости в Maven, я использую плагин зависимостей Maven, чтобы скопировать все библиотеки, необходимые моим приборам, в одну папку, и использую стандартный символ FitNesse !path, чтобы добавить все jar-файлы в этом каталоге в путь к классам (например, !path fixtures/*.jar)

Чтобы запустить тесты на сервере сборки с помощью средства запуска тестов jUnit, я использую отказоустойчивый плагин Maven для запуска тестов FitNesse, как если бы они были обычными тестами jUnit. В моей установке FitNesse доступен плагин classpath (чтобы разрешить запуск вики локально), поэтому я не сталкиваюсь с проблемой, которую вы описываете, поскольку одна и та же JVM используется для анализа файлов вики и запуска тестов:

  • В этом сценарии я отключаю подключаемый модуль пути к классам в установке FitNesse (поскольку он не нужен, поскольку подключаемый модуль Maven Failsafe гарантирует, что все зависимости находятся в пути к классам этой JVM, поэтому нет необходимости снова анализировать pom.xml и добавлять зависимости от пути к классам снова). Я делаю это, устанавливая для системного свойства «fitnesse.wikitext.widgets.MavenClasspathSymbolType.Disable» значение «true». Я решил сделать это в своем собственном подкласс бегунка jUnit от FitNesse (в коде Java с использованием System.setProperty("fitnesse.wikitext.widgets.MavenClasspathSymbolType.Disable", "true");), но это также можно настроить в pom.xml как часть конфигурации Failsafe.
person Fried Hoeben    schedule 21.07.2018