5

Próbuję użyć rozszerzenia gitflow-helper-maven-plugin dla moich buildów maven.Jak włączyć profil maven, gdy wbudowana wersja nie jest -SNAPSHOT?

Dlatego chciałbym skonfigurować mój projekt, aby wykonać kilka dodatkowych kroków podczas budowania wersji wydania i pomijanie ich podczas kompilowania pliku SNAPSHOT, ale nie mogę znaleźć sposobu na włączenie profilu, jeśli ${project.version} zawiera -SNAPSHOT.

Jakieś sugestie?

+0

są te dodatkowe kroki dotyczące wtyczek posiadających opcję 'pominąć'? –

+0

Teraz dodatkowe kroki to maven-source-plugin i maven-javadoc-plugin. – conteit86

Odpowiedz

8

poniżej możliwego podejścia, które jest jak zawsze można symulować oświadczenie if w budowie Maven:

  • Użyj buid-helper-maven-plugin i jego regex-property cel do analizowania domyślny ${project.version} property and create a new $ {tylko właściwość .when.is.snapshot.used} o wartości true lub ${project.version} w przypadku znalezionego sufiksu SNAPSHOT.
  • Konfiguracja maven-source-plugin wykonać swoją jar gola specjalną konfigurację przy użyciu jego opcję skipSource i przechodząc do niego nowy (dynamiczny) ${only.when.is.snapshot.used} property: in case of snapshot it will have value prawdziwą hence skip the execution, otherwise will have value ${project.version} which will be used as FALSE, a więc nie należy pominąć ten wykonanie
  • Konfiguracja taka sama jak powyżej dla maven-javadoc-plugin za pomocą swojego skip opcję

próbkę podejścia powyżej to:

<plugin> 
    <groupId>org.codehaus.mojo</groupId> 
    <artifactId>build-helper-maven-plugin</artifactId> 
    <version>1.10</version> 
    <executions> 
     <execution> 
      <!-- sets the only.when.is.snapshot.used property to true if SNAPSHOT was used, 
       to the project version otherwise --> 
      <id>build-helper-regex-is-snapshot-used</id> 
      <phase>validate</phase> 
      <goals> 
       <goal>regex-property</goal> 
      </goals> 
      <configuration> 
       <name>only.when.is.snapshot.used</name> 
       <value>${project.version}</value> 
       <regex>.*-SNAPSHOT</regex> 
       <replacement>true</replacement> 
       <failIfNoMatch>false</failIfNoMatch> 
      </configuration> 
     </execution> 
    </executions> 
</plugin> 

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-source-plugin</artifactId> 
    <version>3.0.1</version> 
    <executions> 
     <execution> 
      <id>create-sources</id> 
      <phase>package</phase> 
      <goals> 
       <goal>jar</goal> 
      </goals> 
      <configuration> 
       <!-- skip when version is SNAPSHOT --> 
       <skipSource>${only.when.is.snapshot.used}</skipSource> 
      </configuration> 
     </execution> 
    </executions> 
</plugin> 
<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-javadoc-plugin</artifactId> 
    <version>2.10.4</version> 
    <executions> 
     <execution> 
      <id>create-javadoc</id> 
      <phase>package</phase> 
      <goals> 
       <goal>jar</goal> 
      </goals> 
      <configuration> 
       <!-- skip when version is SNAPSHOT --> 
       <skip>${only.when.is.snapshot.used}</skip> 
      </configuration> 
     </execution> 
    </executions> 
</plugin> 

To znaczy, nie ma potrzeby tworzenia profili, ta konfiguracja zostanie włączona tylko wtedy, gdy będzie używana wersja inna niż SNAPSHOT, dynamicznie i bez żadnej dalszej konfiguracji (opcje wiersza poleceń lub w ogóle).


Przypominamy bocznym, można też spojrzeć na maven-release-plugin, która będzie skutecznie powoływać wtyczki źródłowego i javadoc tylko gdy performing uwolnienie bez dodanego (niewielkie) złożoności podejścia powyżej.

W przeciwnym razie, można proste użycie domyślny profil pochodzących z Maven Super POM które faktycznie wywołać takie same, wtyczki źródłowego i javadoc i może być aktywowana za pomocą zestawu nieruchomość performRelease cenić true. Oznacza to, że na każdym projekcie Maven można powołać następujące:

mvn clean package -DperformRelease=true 

lub

mvn clean package -Prelease-profile 

I będzie automatycznie korzystać z Super profil domyślny i mają źródła i słoiki javadoc generowane, mimo to podejście powinno być używane jako ostatnia opcja, ponieważ profil mógł zostać usunięty z super-pom w przyszłych wydaniach.

+0

Na podstawie tej fantastycznej odpowiedzi: https://plus.google.com/112346331375070267873/posts/AntD8wE1F3b?hl=es – albfan

0

Proponuję ci inne rozwiązanie.

Dlaczego nie ustawić wersji w profilu, zamiast podejmować decyzję o aktywacji profilu w wersji? Jak tutaj:

<version>${projectVersion}</version> 

<profiles> 
    <profile> 
     <id>snapshot</id> 
     <activation> 
      <activeByDefault>true</activeByDefault> 
     </activation> 
     <properties> 
      <projectVersion>1.0-SNAPSHOT</projectVersion> 
     </properties> 
    </profile> 
    <profile> 
     <id>release</id> 
     <properties> 
      <projectVersion>1.0-RELEASE</projectVersion> 
     </properties> 
    </profile> 
</profiles> 
+1

Idea gitflow-helper-maven-plugin polega na użyciu pojedynczego zadania na serwerze CI (które uruchamia proces mvn clean deploy) w celu zbudowania projektu. Według gałęzi, która kompiluje artefakty, zostaną wdrożone do migawek, repozytoriów stage lub release. Wersja jest zarządzana przy użyciu wersji: ustaw cel podczas tworzenia nowego oddziału. – conteit86

+0

W tym scenariuszu nie mogę aktywować określonych profili, więc nie mogę użyć Twojego rozwiązania. – conteit86