È possibile impostare un archetipo multi-modulo per avere moduli opzionali?

Question

Ho intenzione di creare un archetipo multi-modulo. Genererà diversi moduli. Alcuni utenti dell'archetipo potrebbero aver bisogno di tutti loro, mentre alcuni ne hanno solo bisogno.

Il mio archetipo può prelevare argomenti dalla riga di comando e decidere quali moduli generare? Ho controllato https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html e non sembra supportarlo.

Answer 1

Ho biforcato il progetto e aggiunto una funzionalità per abilitare o disabilitare la generazione di sottomoduli in base alle proprietà passate alla sessione Maven.

Vedere https://github.com/manouti/maven-archetype.

Impostando -DgenerateEnableProperties=true quando si chiama l'obiettivo create-from-project, il plug-in crea proprietà di abilitazione per ciascun modulo figlio nel formato generate.module.X. Quando si chiama l'obiettivo generate, è possibile escludere un modulo passando -Dgenerate.module.X=false.

alternativa:

si può essere in grado di aggirare questo utilizzando archetipi parziali impostando partial="true" nel descrittore, che consente la generazione di un progetto in cima ad un progetto esistente. This post sembra affrontare lo stesso problema.

Quindi è possibile scrivere uno script che acquisisce le proprietà desiderate e genera le parti corrispondenti del progetto utilizzando gli archetipi parziali, ad es. usando Ant:

<target name="mvn.generate.project.module1" if="generate.module1"> 
    <exec dir="." executable="sh"> 
     <arg value="-c" /> 
     <arg value="mvn archetype:generate -DarchetypeGroupId="com.example.project" -DarchetypeArtifactId="archetype1" ..." /> 
    </exec> 
</target> 

<target name="mvn.generate.project.module2" if="generate.module2"> 
    <exec dir="." executable="sh"> 
     <arg value="-c" /> 
     <arg value="mvn archetype:generate -DarchetypeGroupId="com.example.project" -DarchetypeArtifactId="archetype2" ..." /> 
    </exec> 
</target> 

Update (6/11/16):

Un problema correlato è https://issues.apache.org/jira/browse/ARCHETYPE-494. Dalla descrizione del committer:

Qui è possibile specificare un file groovy, che verrà eseguito dopo la generazione dell'archetipo. Personalmente uso questo file groovy per fare qualcosa di simile: leggo le proprietà dalla riga di comando e quindi rimuovo dipendenze dichiarate, classi e file jsp di cui l'utente potrebbe non aver bisogno.

Answer 2

In questo caso specifico, l'archetipo potrebbe sempre creare tutti i moduli necessari e spostare le diverse sapori (insieme di moduli) in profili. Solo un profilo sarà attivo per impostazione predefinita come specificato durante il passaggio archetype:generate.

Come tale, se voglio avere la serie di moduli per flavorA, correrò l'archetipo come

mvn archetype:generate -DarchetypeGroupId=.. -DflavorA=true 

E l'archetipo passerà questa variabile all'elemento activeByDefault del profilo flavorA re -definizione dell'elemento modules per il set di moduli richiesto dagli utenti flavorA.

Lo stesso potrebbe essere fatto per flavorB e flavorB (per esempio), ciascuna delle quali definisce un diverso insieme di moduli.

Un esempio di tale POM aggregatore/genitore come parte del l'archetipo sarebbe:

<profiles> 
    <profile> 
     <id>flavourA</id> 
     <activation> 
      <activeByDefault>${flavourA}</activeByDefault> 
     </activation> 
     <modules> 
      <module>profiled-module2</module> 
      <module>profiled-module3</module> 
     </modules> 
    </profile> 
    <profile> 
     <id>flavourB</id> 
     <activation> 
      <activeByDefault>${flavourB}</activeByDefault> 
     </activation> 
     <modules> 
      <module>profiled-module3</module> 
     </modules> 
    </profile> 
    <profile> 
     <id>flavourC</id> 
     <activation> 
      <activeByDefault>${flavourC}</activeByDefault> 
     </activation> 
     <modules> 
      <module>profiles-module1</module> 
      <module>profiled-module2</module> 
      <module>profiled-module3</module> 
     </modules> 
    </profile> 
</profiles> 

Il file archetype-metadata.xml potrebbe quindi specificare:

<requiredProperties> 
    <requiredProperty key="flavourA"> 
     <defaultValue>false</defaultValue> 
    </requiredProperty> 
    <requiredProperty key="flavourB"> 
     <defaultValue>false</defaultValue> 
    </requiredProperty> 
    <requiredProperty key="flavourC"> 
     <defaultValue>false</defaultValue> 
    </requiredProperty> 
</requiredProperties> 

E l'archetipo invocato con l'-DflavorB=true l'opzione sarebbe quindi generare un pom come segue:

<profiles> 
    <profile> 
     <id>flavourA</id> 
     <activation> 
      <activeByDefault>false</activeByDefault> 
     </activation> 
     <modules> 
      <module>profiled-module2</module> 
      <module>profiled-module3</module> 
     </modules> 
    </profile> 
    <profile> 
     <id>flavourB</id> 
     <activation> 
      <activeByDefault>true</activeByDefault> 
     </activation> 
     <modules> 
      <module>profiled-module3</module> 
     </modules> 
    </profile> 
    <profile> 
     <id>flavourC</id> 
     <activation> 
      <activeByDefault>false</activeByDefault> 
     </activation> 
     <modules> 
      <module>profiles-module1</module> 
      <module>profiled-module2</module> 
      <module>profiled-module3</module> 
     </modules> 
    </profile> 
</profiles> 

Tale approccio ha i seguenti vantaggi e svantaggi:

Vantaggi

• ti tengono i moduli comuni e la manutenzione archetipo in un unico luogo centralizzato, lasciando la scelta di sapori per l'utente del archetipo
• utenti del archetipo potrebbe, se desiderato e con costo zero, passare da un sapore all'altro solo attivazione/disattivazione profili
• l'approccio utilizza lo standard Maven offre

Svantaggi

• Ogni archetipo genererà l'intero insieme di moduli, anche se non tutti sarà richiesto
• Se veramente un "rumore", l'utente potrebbe eliminare manualmente la moduli indesiderati, ma sarebbe un'azione manuale

---

Inoltre, sulla parte superiore del t si avvicina sopra, potremmo anche configurare il Maven Clean Plugin in ciascun profilo per eliminare i moduli non interessati dal suo sapore, in modo che alla sua prima build (a maven clean), qualsiasi modulo non richiesto venga eliminato. Tale approccio lascerebbe comunque il POM con profili incoerenti, ma potrebbe anche essere considerato (non consigliato).

Qualcosa di simile:

<profile> 
    <id>flavourA</id> 
    <activation> 
     <activeByDefault>${flavorA}</activeByDefault> 
    </activation> 
    <modules> 
     <module>profiled-module2</module> 
     <module>profiled-module3</module> 
    </modules> 

    <build> 
     <plugins> 
      <plugin> 
       <groupId>org.apache.maven.plugins</groupId> 
       <artifactId>maven-clean-plugin</artifactId> 
       <version>3.0.0</version> 
       <configuration> 
        <filesets> 
         <fileset> 
          <directory>${basedir}/profiled-module1</directory> 
         </fileset> 
        </filesets> 
       </configuration> 
      </plugin> 
     </plugins> 
    </build> 
</profile> 

Answer 3

Penso che quello che chiedete è nel contesto di questo problema:

https://issues.apache.org/jira/browse/ARCHETYPE-494

l'ho già implementato e sarà incluso nella prossima versione del plugin di archetipo di Maven. Qui puoi specificare un file groovy, che verrà eseguito dopo la generazione dell'archetipo. Personalmente uso questo file groovy per fare qualcosa di simile: leggo le proprietà dalla riga di comando e quindi rimuovo dipendenze dichiarate, classi e file jsp di cui l'utente potrebbe non aver bisogno.

Per favore fatemi sapere se questo aiuta.