Jar, War and EAR do not support the "forced=false" option of the Maven Archiver

[Yann <ya...@club-internet.fr>]

The Maven Archiver proposes a very nice option to not regenerate an 
archive (http://maven.apache.org/shared/maven-archiver/index.html): the 
"forced" option. So using this option we can save time when running the 
maven package phase.
By default the option is set to true.
So for instance with a jar module we can use:
<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-jar-plugin</artifactId>
	<configuration>
		<archive>
			<forced>false</forced>
		</archive>
	</configuration>
</plugin>
and it would be a similar configuration for the war and ear plugin.

But unfortunately it doesn't work for the following reason:
if project contains resources and if filtered is activated. Even if it 
exists a resource that doesn't contain a variable to filter (i.e. 
${something}) then the resource plugin copies the resource. And the 
consequence is that the Maven Archiver compares the timestamp and then 
displays this kind of message:
[DEBUG] isUp2date: false (Input file 
...\myProject\myModuleJar\target\classes\myRessource.xml is newer.)

If I disable filtering then the jar is not rebuild.
So the issue is more inside the resource plugin.

Do you think it will be valuable that the resource plugin copy filering 
resources only when necessary:
if resources files and pom.xml file (only because of variables) are 
newer than the destination file.

For war and ear plugins it seems to be more tricky:
The filtering is also done by the plugin (soon in the EAR plugin: 
http://jira.codehaus.org/browse/MEAR-43) so the logic also need to be 
done at the level.
But Even if I disable filtering I still get
[DEBUG] isUp2date: false (Input file 
...\myProject\myModuleWeb\pom.properties is newer.)
so I changed the archiver configuration of the war plugin using 
addMavenDescriptor=false
Then this time it worked:
[DEBUG] isUp2date: true
[DEBUG] Archive 
...\myProject\myModuleWeb\target\myModuleWeb-1.0.0-SNAPSHOT.war is uptodate.

What do you think ?
Yann.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org