Générer un Version.java fichier Maven

J'ai un projet en Java que je construis à l'aide d'un script Ant. Je suis en train de convertir le projet de Maven.

L'une des tâches génère un fichier source de Java appelé Version.java qui contient une Chaîne statique de la représentation de la compilation d'horodatage, comme suit:

package com.foo.bar;
public final class Version {
 public static String VERSION="100301.1046";
}

La tâche Ant est très simple:

<target name="version" depends="init" description="Create Version.java">
    <echo file="src/${package.dir}/Version.java" message="package ${package.name};${line.separator}" />
    <echo file="src/${package.dir}/Version.java" append="true" message="public final class Version {${line.separator}" />
    <echo file="src/${package.dir}/Version.java"
          append="true"
          message=" public static String VERSION=&quot;${buildtime}&quot;;${line.separator}" />
    <echo file="src/${package.dir}/Version.java" append="true" message="}${line.separator}" />
    <echo message="BUILD ${buildtime}" />
</target>

Est-il possible de faire quelque chose de similaire dans Maven, à l'aide de generate-sources, ou une autre méthode simple?

InformationsquelleAutor Ralph | 2010-03-18
  1. 78

    Je ne pense pas que ce soit la bonne façon de résoudre ce type de problème.

    Une meilleure façon est de mettre les informations de version dans un properties fichier qui sera lu par votre programme Java:

    Les propriétés de votre fichier contient la ligne suivante:

    myapp.version=${project.version}

    Puis, dans votre pom.xml, indiquer que le fichier sera filtré par Maven :

    <resources>
    <resource>
        <directory>the/directory/that/contains/your/properties/file</directory>
        <filtering>true</filtering>
    </resource>
</resources>

    Lorsque Maven sera de construire votre application, il remplace tous ${...} par leur valeur. Par défaut, ${project.version} définit la version de la pom.xml (c'est à dire la valeur de la <version> tag).

    Puis, dans votre code Java, vous aurez juste besoin de charger le properties fichier et de récupérer la myApp.version la valeur de la propriété.

    Notez que vous pouvez utiliser le Numéro de version du plugin pour définir quelque chose de plus "complexe" que votre version actuelle (par exemple si vous voulez mettre l'accumulation de temps dans votre propriété).

    • Oui, vous avez tout à fait raison. J'ai supprimé cette partie...
    • +1 de toute façon, pour les propriétés qui approche 🙂
    • Je pense que cette approche est bien, mais il ne s'applique pas lorsque vous avez une annotation comme @PersistentUnit(valeur="myPU"). Que pensez-vous de cette affaire?
    • Si vous utilisez maven 3.x, remplacer ${pom.version} (aujourd'hui obsolète) avec ${project.version}. docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide
    • Vous avez raison. J'ai édité mon post. Merci.
    • Pourquoi n'est-il pas la bonne façon de le résoudre? J'ai plusieurs modules avec des ensembles disjoints de fichiers de propriétés. Je crois que stocker de multiples fichiers de propriétés est de la mauvaise façon.
    • Pour de nombreuses raisons, la maintenabilité est l'un d'entre eux. La création d'un fichier Java avec concaténation de Chaîne de caractères à partir d'une tâche Ant est un peu bizarre, et vous ne pouvez pas être sûr que vous ne serez pas écrire de code invalide. Maven filtre a exactement ce but, alors pourquoi ne pas l'utiliser?
    • Des fichiers de propriétés peuvent être modifiées ou perdues. Il semble préférable si celui-ci est intégré dans le binaire.
    • Je suis en désaccord. Certains des fichiers de propriétés contient de l'information qui est dépendante de l'environnement (par exemple la base de données d'informations d'identification). Ainsi, vous ne pouvez pas les intégrer dans le binaire (dans le cas contraire, vous devrez créer un binaire par l'environnement, qui est également une mauvaise pratique).
    • bien sûr, les fichiers de propriétés sont extrêmement utiles. Je suis en train de dire qu'ils ne sont pas utiles pour le stockage d'un client de l'application des informations de version spécifique.
    • en effet, certaines propriétés des fichiers, comme celui qui va stocker la version de l'application, peut être intégré dans le système binaire, comme ils ne sont pas dépendants de l'environnement. Mais c'est exactement le point de ma réponse: vous avez un fichier de propriétés dans src/main/properties avec des espaces réservés, et lors de l'emballage, Maven va remplacer l'espace réservé par la valeur, et incorporer un fichier de propriétés dans le .jar.
    • C'est très bien, sauf quand la constante doit être utilisé dans une annotation de l'attribut, où seules les constantes de compilation sont autorisés.

    InformationsquelleAutor Romain Linsolas
  2. 27

    Vous pouvez également utiliser maven-remplacement-plugin si vous vous sentez ant est un peu moche:
    La pom entrée peut être:

    <project>
  ...
  <properties>
    <version.template.file>src/main/java/com/stackoverflowVersion.java.template</version.template.file>
<version.file>src/main/java/com/stackoverflow/Version.java</version.file>
  </properties>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>com.google.code.maven-replacer-plugin</groupId>
            <artifactId>maven-replacer-plugin</artifactId>
            <version>1.4.0</version>
            <executions>                
                <execution>
                    <phase>process-sources</phase>
                    <goals>
                        <goal>replace</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <file>${version.template.file}</file>
                <outputFile>${version.file}</outputFile>
                <replacements>
                    <replacement>
                        <token>@buildnumber@</token>
                        <value>${svn.revision}</value>
                    </replacement>
                    <replacement>
                        <token>@buildtime@</token>
                        <value>${maven.build.timestamp}</value>
                    </replacement>
                    <replacement>
                        <token>@pomversion@</token>
                        <value>${project.version}</value>
                    </replacement>
                </replacements>                        
            </configuration>
      </plugin>
    </plugins>
  </build>
  ...
</project>

    La Version.java.modèle peut être:

    package com.stackoverflow;

public final class Version {

    public static final String build_number="@buildnumber@";

    public static final String build_time="@buildtime@";

    public static final String pomversion="@pomversion@";

}
    • Mieux utiliser "generate-sources" phase au lieu
    InformationsquelleAutor spupek
  3. 15

    C'est une vieille question, mais il existe une autre solution qui n' un excellent travail parfaitement (dans le Maven sens): Création De Modèles Plugin Maven.

    À l'aide de ce plugin résultats dans le traité fichier Java de la mettre dans le target/generated-sources dossier, comme vous le souhaitez. Et il ajoute le dossier sous generated-sources pour le build path. Vous n'aurez plus l'enregistrement dans le fichier traité par erreur.

    Comment utiliser

    D'abord le mettre à la suite sous la src/main/java-templates/com/foo/bar/Version.java:

    package com.foo.bar;
public final class Version {
    public static final String VERSION = "${project.version}";
}

    Puis ajoutez les lignes suivantes à votre POM:

    <build>
    <plugins>
    ...
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>templating-maven-plugin</artifactId>
            <version>1.0.0</version>
            <executions>
                <execution>
                    <id>filtering-java-templates</id>
                    <goals>
                        <goal>filter-sources</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    ...
    </plugins>
</build>

    Le dossier target/generated-sources/java-templates est ajouté au chemin de génération par Maven.

    • Cela fonctionne pour mon mais j'ai encore de démarrer manuellement templating:filtre-sources. Je suis nouveau sur Maven. Comment exécuter ce plug-in avant le changement de profil ou de départ de chaque build?
    • Oui, vous avez besoin d'appeler Maven pour générer la source si vous modifiez un modèle. Mais vous pouvez simplement appeler mvn install et ne pas avoir à la peine de rappeler l'objectif spécifique que vous avez utilisé.
    • ce plugin va lier automatiquement pour l'une des premières phases du cycle de vie de Maven: generate-sources. Donc, vous avez réellement n'avez pas à appeler manuellement comme dit aussi vegemite4me
    InformationsquelleAutor vegemite4me
  4. 12

    Voici une autre solution qui produira le même que Ralph sa propre réponse,
    à l'aide de pom propriétés de filtrage et d'un fichier de modèle:

    Le fichier de modèle (VersionJava.modèle placé dans src/main/resources/version):

    package ${ver.package.name};
public final class ${ver.class.name} {
    public static String VERSION="${ver.buildtime}";
}

    Le pom:

    <properties>
    ...
    <ver.package.dir>com/foo/bar${project.artifactId}</ver.package.dir>
    <ver.package.name>com.foo.bar${project.artifactId}</ver.package.name>
    <ver.class.name>Version</ver.class.name>
    <ver.buildtime>${maven.build.timestamp}</ver.buildtime>
    <ver.template.dir>src/main/resources/version</ver.template.dir>
    <ver.template.file>VersionJava.template</ver.template.file>
</properties>
<build>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <excludes>
                <exclude>version/*</exclude>
            </excludes>
        </resource>
        <resource>
            <directory>${ver.template.dir}</directory>
            <includes>
                <include>*.java</include>
            </includes>
            <filtering>true</filtering>
            <targetPath>${basedir}/src/main/java/${ver.package.dir}</targetPath>
        </resource>
    </resources>        
    <plugins>
        <plugin>
            <artifactId>maven-antrun-plugin</artifactId>
            <executions>
                <execution>
                    <phase>generate-sources</phase>
                    <configuration>
                        <tasks>
                            <copy file="${ver.template.dir}/${ver.template.file}" tofile="${ver.template.dir}/${ver.class.name}.java" />
                        </tasks>
                    </configuration>
                    <goals>
                        <goal>run</goal>
                    </goals>
                </execution>
                <execution>
                    <phase>compile</phase>
                    <configuration>
                        <tasks>
                            <delete file="${ver.template.dir}/${ver.class.name}.java" />
                        </tasks>
                    </configuration>
                    <goals>
                        <goal>run</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

    Maintenant, cela peut sembler excessif, mais il est extrêmement polyvalent, et ce que j'aime le plus à ce sujet
    c'est que j'ai le fichier de modèle dans un format lisible (plutôt que de l'écho des déclarations dans le pom).
    Cela me permet également de modifier la version de classe sans avoir à modifier le pom

    • C'est aweseome! Je mettrais le fichier cible /cible/source/${ver.package.dir} et alors (en supposant que Eclipse) ajouter /cible/source/${ver.package.dir} comme un dossier source. De cette façon, vous exclure de contrôle de code source
    • Je suis d'accord. Le fichier généré doit avoir été dans le dossier cible plutôt que de la src. De plus, je pense que si il a été mis en 'target/generated-sources/pom/${ver.package.dir}", puis (en supposant que NetBeans), il serait compris comme une source automatiquement. Je n'ai pas essayé encore mais je, et si ça marche comme prévu, je devrais modifier ma réponse 🙂
    • Cette solution entraîne une boucle sans fin dans Eclipse 4.2 avec le m2e plugin. J'ai utilisé, cependant, la solution sans la tâche ant. Actuellement, je ne vois pas la raison pour celle-ci: La solution de filtrage génère l'Version.java avec les champs appropriés.
    InformationsquelleAutor Superole
  5. 8

    Après plusieurs recherches sur Google, j'ai trouvé ceci (dans le pom.xml):

    <plugins>
  ...
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.3</version>
    <executions>
      <execution>
        <goals>
          <goal>run</goal>
        </goals>
        <phase>generate-sources</phase>
        <configuration>
          <tasks>
            <property name="src.dir" value="${project.build.sourceDirectory}" />
            <property name="package.dir" value="com/foo/bar" />
            <property name="package.name" value="com.foo.bar" />
            <property name="buildtime" value="${maven.build.timestamp}" />

            <echo file="${src.dir}/${package.dir}/Version.java" message="package ${package.name};${line.separator}" />
            <echo file="${src.dir}/${package.dir}/Version.java" append="true" message="public final class Version {${line.separator}" />
            <echo file="${src.dir}/${package.dir}/Version.java" append="true"
              message=" public static String VERSION=&quot;${buildtime}&quot;;${line.separator}" />
            <echo file="${src.dir}/${package.dir}/Version.java" append="true" message="}${line.separator}" />
            <echo message="BUILD ${buildtime}" />
          </tasks>
        </configuration>
      </execution>
    </executions>
  </plugin>
  ...
</plugins>

    Il semble bien fonctionner et produit ce fichier Java:

    package com.foo.bar;
public final class Version {
 public static String VERSION="100318.1211";
}
    • C'est une très mauvaise solution. Mieux utiliser la solution donnée par la romaintaz. La génération de code source pour ce genre de choses conduit à inutiles compile le fichier java est recréée à chaque fois, ce qui déclenche une cascade de compilations. S'il vous plaît ne vous-même et vos collègues de travail une faveur et ne pas le faire!
    • Je cherchais une solution pour créer un fichier texte version.txt à l'intérieur de webapp racine, et je suppose que c'est le meilleur.
    InformationsquelleAutor Ralph
  6. 8

    Basé sur la réponse par @superole. C'est une version simplifiée, sans la nécessité de définir des propriétés supplémentaires. Le projet de version est copié dans Version.java.

    Mettre Version.java en src/main/templates:

    package thepackage;

public final class Version {

 public static String VERSION="${project.version}";

}

    Instruire maven pour remplacer les jetons dans Version.java

    <resources>
    <resource>
        <directory>src/main/templates</directory>
        <includes>
            <include>*.java</include>
        </includes>
        <filtering>true</filtering>
        <targetPath>${project.build.directory}/generated-sources/java/thepackage</targetPath>
    </resource>
</resources>

    Instruire maven savoir generated-sources/java comme build path:

    <plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>build-helper-maven-plugin</artifactId>
    <version>1.8</version>
    <executions>
        <execution>
             <id>add-source</id>
            <phase>generate-sources</phase>
            <goals>
                <goal>add-source</goal>
            </goals>
            <configuration>
                <sources>
                    <source>${project.build.directory}/generated-sources/java/</source>
                </sources>
            </configuration>
        </execution>
    </executions>
</plugin>

    Enfin, permettez-Eclipse m2e

    • être au courant de la nouvelle build path
    • et ne pas tomber dans une boucle infinie construire.

    Le deuxième point est atteint par la désactivation à l'aide de la maven-ressources-plugin lors de l'augmentation de la construction d'eclipse.

    <pluginManagement>
    <plugins>
        <plugin>
            <groupId>org.eclipse.m2e</groupId>
            <artifactId>lifecycle-mapping</artifactId>
            <version>1.0.0</version>
            <configuration>
                <lifecycleMappingMetadata>
                    <pluginExecutions>
                        <pluginExecution>
                          <pluginExecutionFilter>
                            <groupId>org.codehaus.mojo</groupId>
                            <artifactId>build-helper-maven-plugin</artifactId>
                            <versionRange>[1.0,)</versionRange>
                            <goals>
                              <goal>parse-version</goal>
                              <goal>add-source</goal>
                              <goal>maven-version</goal>
                              <goal>add-resource</goal>
                              <goal>add-test-resource</goal>
                              <goal>add-test-source</goal>
                            </goals>
                          </pluginExecutionFilter>
                          <action>
                            <execute>
                              <runOnConfiguration>true</runOnConfiguration>
                              <runOnIncremental>true</runOnIncremental>
                            </execute>
                          </action>
                        </pluginExecution>
                        <pluginExecution>
                            <pluginExecutionFilter>
                                <groupId>org.apache.maven.plugins</groupId>
                                <artifactId>maven-resources-plugin</artifactId>
                                <versionRange>[1.0.0,)</versionRange>
                                <goals>
                                    <goal>resources</goal>
                                </goals>
                            </pluginExecutionFilter>
                            <action>
                                <execute>
                                    <runOnConfiguration>true</runOnConfiguration>
                                    <runOnIncremental>false</runOnIncremental>
                                </execute>
                            </action>
                        </pluginExecution>
                    </pluginExecutions>
                </lifecycleMappingMetadata>
            </configuration>
        </plugin>
    </plugins>
</pluginManagement>

    thepackage doit être remplacé par votre package: Également ajuster le targetPath en conséquence. Je l'ai trouvé plus facile de définir le chemin d'accès dans targetpath au lieu d'avoir plusieurs sous-dossiers dans src/main/templates.

    • C'est génial.
    • Ce doit être la accepté de répondre! Je vous remercie.
    InformationsquelleAutor koppor
  7. 3

    Comme suggéré par @Romain, vous pouvez lire la version à partir d'un fichier de propriétés (soit /META-INF/maven/groupId/artifactId/pom.properties si vous pouvez attendre jusqu'à ce que l'emballage ou le rouleau de votre propre fichier filtré si vous ne pouvez pas ou si elle n'a pas à fournir tout ce dont vous avez besoin).

    Et vous voulez coller avec votre Version classe, alors jetez un oeil à ce fil sur le maven de la liste des utilisateurs qui est précisément de proposer une solution pour cela (basé sur le antrun plugin que vous aurez lié sur la generated-sources phase).

    InformationsquelleAutor Pascal Thivent
  9. 2

    Je suis en train de faire à l'aide de la Maven GUERRE Plugin ajout d'informations à la Le MANIFESTE.MF fichier et, plus tard, la lecture de ce MANIFESTE.MF fichier en Java:

         <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <version>2.6</version>
        <configuration>
           <archive>
              <manifest>
                 <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
                 <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
              </manifest>
              <manifestEntries>
                 <Build-Time>${maven.build.timestamp}</Build-Time>
              </manifestEntries>
           </archive>
        </configuration>
     </plugin>

    Cette configuration génère le MANIFESTE suivantes.MF fichier:

    Manifest-Version: 1.0
Implementation-Title: MyApp
Implementation-Version: 2.11.0-SNAPSHOT
Built-By: niestroj
Specification-Title: MyApp
Implementation-Vendor-Id: com.mycompany
Build-Time: 2017-01-09 15:30
Created-By: Apache Maven 3.0.5
Build-Jdk: 1.8.0_40
Specification-Version: 2.11

    Et, plus tard, je suis en train de lire ce en Java comme ceci:

      try {
     Manifest manifest = new Manifest(getServletContext().getResourceAsStream("/META-INF/MANIFEST.MF"));
     Attributes attributes = manifest.getMainAttributes();
     attributes.getValue("Implementation-Version");
     attributes.getValue("Build-Time");
  } catch (IOException ex) {
     LOGGER.debug("Error reading manifest file information", ex);
  }
    InformationsquelleAutor Robert Niestroj
  10. 1

    La norme de façon à faire avec très peu de lignes de code XML est maintenant d'utiliser le template-maven-plugin.

    Voir ma réponse dans Le filtrage du code source dans Maven

    En général, le Maven moyen est de décrire ce que vous voulez faire. Puis figure comment. Quand comment nécessite des dizaines ou des centaines de lignes de XML, soit trouver le bon plugin qui fait ça, ou l'écrire. Tel est le raisonnement qui a créé le template-maven-plugin :-).

    InformationsquelleAutor Baptiste Mathus