Maven 2.2.1: [Wanrning] POT sera vide - aucun contenu n'a été marqué pour l'inclusion
Maven 2.2.1
JDK - 1.6.0_45
[AVERTISSEMENT] POT sera vide - aucun contenu n'a été marqué pour l'intégration!
CONSTRUIRE DE BONNES
Mais construire crée pot avec pom.xml mais pas les fichiers de classe.
Sur le maven code source de cette exception est levée que lorsque le répertoire source est introuvable.
La génération fonctionne pour tous les autres développeurs, sauf sur ma station de travail et un plus poste de travail
J'ai essayé toutes les solutions proposées pour ce problème sur un débordement de pile.
Mon répertoire source est src/java.
J'ai également créé src/main/java comme source toujours pas de résultat.
Je fais appel mvn -o jar:jar && appel mvn -o antrun:run
-o est dommage parce que en ce moment je suis en train de tester avec quelques vieux pots.
<build>
<sourceDirectory>src/java</sourceDirectory>
<resources>
<resource>
<directory>${basedir}/src/java</directory>
<includes>
<include>**/*.xml</include>
<include>**/*.properties</include>
</includes>
</resource>
</resources>
<testResources>
<testResource>
<directory>${basedir}/src/test/resources</directory>
<includes>
<include>**/*.properties</include>
<include>**/*.xml</include>
</includes>
</testResource>
</testResources>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<debug>true</debug>
<optimize>false</optimize>
<showDeprecation>true</showDeprecation>
<source>1.5</source>
<target>1.5 </target>
</configuration>
</plugin>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<excludes>
<exclude>test*/temp/*.java</exclude>
<exclude>test*/support/*.java</exclude>
<exclude>test*/debug/*.java</exclude>
</excludes>
<includes>
<include>test*/**/AllTests.java</include>
</includes>
</configuration>
</plugin>
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>default-cli</id>
<phase>install</phase>
<configuration>
<target>
<copy file="${project.build.directory}/${artifactId}-${version}.jar"
todir="${user.home}/.m2/repository/${groupId}/${artifactId}/${version}" />
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<packaging>
? Ce qui se passe lorsque vous essayez d'exécuter mvn compile
?Vérifiez votre basedir comprendre, il comprend seulement .xml et .propriétés excluent par conséquent tout le reste
J : oui, c'est <packaging>pot</emballage>
Ces ressources comprennent. J'ai le <sourceDirectory balise> j'ai essayé d'ajouter .java et .ainsi, il n'a pas de travail.
Vous devez utiliser src/main/resources pour les ressources, et src/main/java pour Java... Voir maven.apache.org/guides/introduction/...
OriginalL'auteur Stack | 2015-06-23
Vous devez vous connecter pour publier un commentaire.
Suivre la première les conventions de Maven ce qui signifie que vos sources de production de code doit être dans
src/main/java
. Vous devriez également trouver vos ressources comme la propriété des fichiers ou d'autres types de fichiers (comme des fichiers xml) dans votre cas, à l'emplacement approprié qui est de la productionsrc/main/resources
et pour les tests unitairessrc/test/resources
.La première chose à changer est la structure de répertoire de votre projet dans le processus de migration. Qui permettra d'économiser beaucoup de tracas avec des configurations dans Maven de la cause que vous violer le
convention over configuration
paradigme.Votre unité de tests de code dans
src/test/java
et suivez les les conventions de nommage pour les tests unitaires ce qui signifie le nom de vos tests unitaires comme*Test.java
rien de plus. Vous n'avez pas besoin de définir une suite pour exécuter tous les tests. Si vous suivez la convention de nommage maven-surefire-plugin va faire tout le travail pour vous.Supprimer la antrun plugin à partir de votre pom configuration et de l'utilisation
au lieu d'installer votre produit jar dans le référentiel local. Basé sur le construire le cycle de vie vous de la compilation, les tests unitaires et d'emballage de votre code résultant des fichiers jar.
Généralement dans Maven il n'y a aucune raison de l'appeler
mvn jar:jar
séparément.En dehors de cela tout ce que vous devez cesser d'utiliser Maven 2.2.1 cause qu'il a défini en Fin De Vie. Mieux de commencer avec Maven 3.X à la place. Mais tout ce que j'ai écrit avant est valable de Maven 3.
OriginalL'auteur khmarbaise