I package my Maven-based Spring app with:
mvn install-DskipTests -Peverything.
And something strange arises. In META-INF of generated jar,
Not sure what you mean by duplicate
but the jar created by maven does come with pom.xml
and pom.properties
in META-INF
folder. See this section of the maven getting started guide.
I know this issue is a bit old, but I thought I'd share an obscure bit of information on this subject. I was running across the same issue, and I found that when I ran maven with Eclipse open, AND my workspace preferences were set to refresh the workspace using native hooks or polling, the extra pom.xml and pom.properties files were added by eclipse! Closing eclipse or removing the refresh workspace option solved the problem for me. This was a hard one to track down, so hopefully someone else will benefit from this.
Add
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<addMavenDescriptor>false</addMavenDescriptor>
</archive>
</configuration>
</plugin>
</plugins>
</build>
to your pom.xml
You need to do "mvn clean" and the do "mvn package" after that or just do "mvn clean package". if "mvn clean" fails due to any reason and if you do "mvn package" after that , you will see this issue again.
It seems like this is a somewhat common problem that arises from a conflict in Eclipse, especially with the m2e-wtp integration.
Some people are indicating that it can be fixed by including clean in the list of goals to run, e.g. mvn clean package
.
Also try to update your m2e installation and make sure you don't have multiple versions of m2e or m2eclipse (the pre-Indigo version) installed.
Some references to other people facing this problem:
Follow up to @Dan's work around:
I tried your solution and it appears to work -- at first blush. However, it's just delaying the eventual failure.
It appears than anytime the workspace is refreshed the pom.xml and pom.properties files are created in the /classes directory. After that any later "package" goal will include the duplicate files in the .jar and thus break any later signing.
If the polling is on - you "fail-fast". If it's off you can fail at arbitrary times in future builds.