Spring-boot: Dependency on jar project with redefined finalName in multi module maven project causes duplicate jar in repackaged war

[jakobfaerch]

Using the spring-boot-maven-plugin version 1.4.2.RELEASE, I build a multimodule maven project with the following module structure:

parent 
  -> jar
  -> war

"jar" has a redefined finalName of "jar".
"war" has a dependency on "jar"

(see the example project available as PR https://github.com/spring-projects/spring-boot-issues/pull/61)

I run the following in the root dir of the multi module project:

$ mvn clean install
$ jar tvf war/target/war-0.0.1-SNAPSHOT.war|grep lib/jar

Observed behaviour
I get this output:

  1688 Mon Nov 14 21:14:04 CET 2016 WEB-INF/lib/jar-0.0.1-SNAPSHOT.jar
  1688 Mon Nov 14 21:14:04 CET 2016 WEB-INF/lib/jar.jar

Indicating that the jar project is included twice.

Expected behaviour
I expected output like

  1688 Mon Nov 14 21:14:04 CET 2016 WEB-INF/lib/jar-0.0.1-SNAPSHOT.jar

I would expect the versioned jar file to be included, even though the final name is overridden, as this would be symmetrical with a dependency fetched from the Maven repository, but including jar.jar would be acceptable as well.

[jakobfaerch]

Add sample project (identical to https://github.com/spring-projects/spring-boot-issues/pull/61) as zip
gh-7389.zip

[philwebb]

Interesting. It seems that Maven's war plugin adds jar-0.0.1-SNAPSHOT.jar and our repackager adds jar.jar.

As a work around you can use excludeArtifactIds:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <version>1.4.2.RELEASE</version>
    <executions>
        <execution>
            <goals>
                <goal>repackage</goal>
            </goals>
            <configuration>
                <excludeArtifactIds>jar</excludeArtifactIds>
            </configuration>
        </execution>
    </executions>
</plugin>

[jakobfaerch]

Thanks, @philwebb, we might do either what you suggest - using excludeArtifactIds or find a way to live without the redefined finalName, so this issue is not blocking for us

[wilkinsona]

Our plugin simply uses the name of the file to determine the name of the artifact inside the repackaged war. The war plugin's logic is a bit more sophisticated:

protected String getArtifactFinalName( WarPackagingContext context, Artifact artifact )
    throws InterpolationException
{
    if ( context.getOutputFileNameMapping() != null )
    {
        return MappingUtils.evaluateFileNameMapping( context.getOutputFileNameMapping(), artifact );
    }
    String classifier = artifact.getClassifier();
    if ( ( classifier != null ) && !( "".equals( classifier.trim() ) ) )
    {
        return MappingUtils.evaluateFileNameMapping( MappingUtils.DEFAULT_FILE_NAME_MAPPING_CLASSIFIER, artifact );
    }
    else
    {
        return MappingUtils.evaluateFileNameMapping( MappingUtils.DEFAULT_FILE_NAME_MAPPING, artifact );
    }
}

Given the author of much of this logic, I think @snicoll is probably best placed to handle this one

[philwebb]

Maybe there's another snicoll that works on Apache Maven :)