Rilascio Maven: versione di sviluppo successiva in modalità batch

Question

Ho configurato un lavoro Jenkins per rilasciare automaticamente il mio progetto Maven. Questa operazione viene eseguita utilizzando: mvn --batch-mode clean release:prepare release:perform In modalità batch, la versione di rilascio e la versione di sviluppo verranno determinate automaticamente. Questo è esattamente quello che voglio.

Il problema è che voglio aumentare il 2 ° numero della versione anziché il 3 °. Quindi quando rilascio la versione 1.2.0, la prossima versione di sviluppo deve essere 1.3.0-SNAPSHOT. Non 1.2.1-SNAPSHOT. L'aggiunta di un parametro della riga di comando non è un'opzione, poiché ciò mi obbliga a modificare costantemente il lavoro di compilazione.

Qualche suggerimento su come modificare l'algoritmo utilizzato per determinare la prossima versione di sviluppo?

Answer 1

Come suggerito Khmarbaise, penso anche che non ci sia una soluzione al tuo problema.

C'è qualche regola, che può automaticamente dire se è necessario modificare il secondo o il terzo numero? In effetti, io non la penso così. Detto questo, non puoi chiedere a Maven/Jenkins di sceglierlo per te, una volta la cifra della versione principale, l'altra cifra della versione secondaria.

È necessario modificarlo tramite un parametro o consentire all'utente di configurarlo tramite il plug-in Jenkins M2 Release, come suggerito da willome. Può essere solo un'azione manuale.

Answer 2

È possibile utilizzare un parametro della riga di comando senza modificare il lavoro se si utilizza una generazione parametrizzata in Jenkins. Controlla l'opzione "questa build è parametrizzata" nella pagina di configurazione del lavoro.

Questo non consentirà a Jenkins di eseguire le pubblicazioni interamente da solo (il che è positivo, non vogliamo che i robot svolgano il nostro lavoro!) - quando avvii manualmente una build da Jenkins, essere in grado di impostare qualsiasi parametro che hai configurato.

Answer 3

È possibile utilizzare uno script Groovy personalizzato per fornire automaticamente maven-release-plugin con releaseVersion e developmentVersion. Poi il comando Maven apparirebbe somwthing simile:

mvn rilascio pulito: rilascio pulito: preparare rilascio: eseguire -DreleaseVersion = $ {} releaseVersion -DdevelopmentVersion = $ {} developmentVersion

Seguire i passaggi in this answer e cambiare il parte dello script Groovy ideale per la tua casi d'uso (per esempio questa parte):

def newFixVersion = 0; 
if (hasSnapshotPart) { 
    newMinorRelVersion = minorVersion; 
    newMinorDevVersion = minorVersion + 1; 
} else { 
    //TODO: either throw an exception here or change the newMinorRelVersion newMinorDevVersion appropriately to suite your use-cases: 
     //throw new IllegalArgumentException("The pom at location " + POM_LOCATION + " contains the version " + projectVersion + " which is not a snapshot version (missing " + SNAPSHOT_PART + "). This is a released version and nothing should happen to it!"); 
} 

Answer 4

ho avuto lo stesso problema e ho voluto risolverlo senza correre più di un comando o inserendo la versione manualmente.

Qui è la mia soluzione per y (o minore) minimo:

ho eseguito uno script Groovy in inizializzare fase. Questo script crea release.properties. Aggiungi questo al vostro progetto /costruire/plugins sezione del pom.xml:

 <plugin> 
      <groupId>org.codehaus.gmavenplus</groupId> 
      <artifactId>gmavenplus-plugin</artifactId> 
      <version>1.5</version> 
      <dependencies> 
       <dependency> 
        <groupId>org.codehaus.groovy</groupId> 
        <artifactId>groovy-all</artifactId> 
        <version>2.4.6</version> 
       </dependency> 
      </dependencies> 
      <executions> 
       <!-- Force maven-release-plugin to increase MINOR, not PATCH, and create tag as vX.Y.Z --> 
       <execution> 
        <id>release-parameters</id> 
        <phase>initialize</phase> 
        <goals> 
         <goal>execute</goal> 
        </goals> 
        <configuration> 
         <scripts> 
          <script> 
           <![CDATA[ 
            final String SNAPSHOT = '-SNAPSHOT' 

            Properties releaseProps = new Properties() 
            File releasePropsFile = new File('release.properties') 
            String releaseVersion = '${project.version}'.replace('-SNAPSHOT', '') 
            String[] vNumbers = releaseVersion.split('\\.') 
            String snapshotVersion = vNumbers[0] + '.' + (Integer.parseInt(vNumbers[1]) + 1) + '.' + '0' + SNAPSHOT 

            releaseProps.setProperty('scm.tag', 'v' + releaseVersion) 
            releaseProps.setProperty('project.rel.${project.groupId}:${project.artifactId}', releaseVersion) 
            releaseProps.setProperty('project.dev.${project.groupId}:${project.artifactId}', snapshotVersion) 
            releaseProps.store(releasePropsFile.newWriter(), null) 
           ]]> 
          </script> 
         </scripts> 
        </configuration> 
       </execution> 
      </executions> 
     </plugin> 

Questo script cambia anche il tag nome per vX.Y.Z in SCM.La fase di inizializzazione non viene eseguita nella versione : preparare la fase. Per risolvere questo problema, è possibile eseguire un "mvn install" prima di un rilascio, o cambiare la tua comando di rilascio a:

mvn --batch-mode initialize clean release:prepare release:perform 

Chi release.properties: https://maven.apache.org/maven-release/maven-release-plugin/examples/non-interactive-release.html

Answer 5

So che questo è un post un pò vecchio, ma Non ho trovato una risposta che mi piacesse davvero ovunque online e sono riuscito a trovare qualcosa che potesse funzionare bene per gli altri ...

Ho voluto incrementare la versione secondaria come indica l'OP, e sono stato in grado di fallo utilizzando una combinazione del plugin build helper (per analizzare la versione) e il plugin di rilascio, nel mio progetto POM. Notare la fase di "inizializzazione" a cui si fa riferimento in POM e la proprietà run di Maven ...

Ecco l'estratto dal POM, usiamo il plugin di build helper per analizzare la versione a cui possiamo fare riferimento nel plugin di rilascio ...

<plugin> 
       <groupId>org.codehaus.mojo</groupId> 
       <artifactId>build-helper-maven-plugin</artifactId> 
       <version>${maven.build.helper.plugin.version}</version> 
       <executions> 
        <execution> 
         <id>parse-versions-for-release</id> 
         <phase>initialize</phase> 
         <goals> 
          <goal>parse-version</goal> 
         </goals> 
         <configuration> 
          <propertyPrefix>parsedVersion</propertyPrefix> 
         </configuration> 
        </execution> 
       </executions> 
      </plugin> 
      <plugin> 
       <groupId>org.apache.maven.plugins</groupId> 
       <artifactId>maven-release-plugin</artifactId> 
       <version>${maven.release.plugin.version}</version> 
       <configuration> 
        <autoVersionSubmodules>true</autoVersionSubmodules> 
        <tagNameFormat>@{project.artifactId}-@{project.version}</tagNameFormat> 
        <useReleaseProfile>false</useReleaseProfile> 
        <developmentVersion>${parsedVersion.majorVersion}.${parsedVersion.nextMinorVersion}.0-SNAPSHOT</developmentVersion> 
       </configuration> 
      </plugin> 

Ora possiamo semplicemente eseguire un rilascio abbastanza normale, ma aggiungendo nella fase di "inizializzazione" per attivare la versione di analisi (e assicurarsi che si verifica prima di cercare le versioni analizzati) ...

mvn initialize release:clean release:prepare release:perform