2017-02-20 17 views
1

Я использую следующую команду,Maven свойство для тест-файлов .jar

mvn package -DskipTests -q -pl <<my list of projects>> -am exec:exec -Dexec.executable="echo" -Dexec.args='${project.artifact.file}' 

напечатать список файлов .jar производства моей сборки. Это полезно в Jenkins, где моя команда архива не имеет явных сведений о том, какая из них работает.

Но я заметил проблему. Если я определил тестовую банку, этот подход не обнаружит ее. например

<build> 
    <plugins> 
     <plugin> 
      <groupId>org.apache.maven.plugins</groupId> 
      <artifactId>maven-jar-plugin</artifactId> 
      <version>3.0.2</version> 
      <executions> 
       <execution> 
        <goals> 
         <goal>test-jar</goal> 
        </goals> 
       </execution> 
      </executions> 
     </plugin> 
    </plugins> 
</build> 

Есть ли какое-либо свойство, которое позволит мне получить имя тестовой банки? т. е. аналогично $ {project.artifact.file}

+0

Потому что это прикрепленный артефакт. '$ {project.attachedArtifacts}' будут перечислять их, но это будет не очень читаемо. Лучшим решением здесь будет использование настраиваемого плагина, подобного здесь http://stackoverflow.com/questions/10454181/how-to-determine-what-artifacts-are-built-from-a-maven-reactor-plan-ie- вк. – Tunaki

+0

Фактически это прекрасно. Результат анализируется так, как это следует делать. Вы хотите сказать это как ответ? –

+0

Зачем вам это нужно? Какова цель этого? – khmarbaise

ответ

1

Тестовый JAR не выводится, поскольку он не является главным артефактом проекта, а прикрепленным артефактом. Вместо этого вы можете получить доступ к прикрепленным артефактам с помощью ${project.attachedArtifacts}. Обратите внимание, что это не будет печатать файлы, а координаты артефактов в формате [groupId:artifactId:type:classifier:version].

Было бы возможно сделать это более общим с a Maven plugin или с event spy. Еще одно решение, которое не требует все это использовать GMavenPlus plugin, который позволяет выполнять сценарии Groovy в сборке:

<plugin> 
    <groupId>org.codehaus.gmavenplus</groupId> 
    <artifactId>gmavenplus-plugin</artifactId> 
    <version>1.5</version> 
    <executions> 
    <execution> 
     <goals> 
     <goal>execute</goal> 
     </goals> 
     <phase>install</phase> 
     <configuration> 
     <scripts> 
      <script><![CDATA[ 
      import org.apache.maven.artifact.Artifact 
      log.info(project.artifact.file.path) 
      for (Artifact artifact : project.attachedArtifacts) { 
       log.info(artifact.file.path) 
      } 
      ]]></script> 
     </scripts> 
     </configuration> 
    </execution> 
    </executions> 
    <dependencies> 
    <dependency> 
     <groupId>org.codehaus.groovy</groupId> 
     <artifactId>groovy-all</artifactId> 
     <version>2.4.8</version> 
     <scope>runtime</scope> 
    </dependency> 
    </dependencies> 
</plugin> 

Это имеет то преимущество, что вам не нужно (аб) использовать exec:exec для этого , он является полностью общим и фактически печатает путь к файлу (а не координаты). Он выводит в журналы путь основного артефакта и всех прикрепленных артефактов, например:

[INFO] Using Groovy 2.4.8 to perform execute. 
[INFO] ...\test\target\test-0.0.1-SNAPSHOT.jar 
[INFO] ...\test\target\test-0.0.1-SNAPSHOT-tests.jar 
+0

А ... не заметил, как прикрепленныеArtifacts были напечатаны, когда я первоначально тестировал. Добавление дополнительного плагина не является идеальным в моем сценарии. –

+0

@ShaneGannon Я думаю, что у вас может быть тот же код Groovy внутри вашего конвейера Jenkins, после сборки Maven. Он должен работать (хотя я не тестировал его). Может быть небольшая конфигурация, чтобы он мог получить доступ к «проекту» (экземпляр проекта Maven). – Tunaki

+0

Я рассмотрю этот вариант. Кажется, мне нужно добавить maven в classpath. –