WAR file to use final name

[sverhagen]

Correct me if I'm wrong, but when using <descriptorRef>artifact</descriptorRef> for a <packaging>war</packaging> project, I'm getting the following WAR file inside my container:

myArtifactName-war-0.1.0-SNAPSHOT.war

I am setting final name as follows, during my build:

<finalName>myArtifactName</finalName>

I had expected the following WAR file inside my container:

myArtifactName.war

Since the WAR file name translates into the context path, this leads to unfortunate URLs such as:

http://host/myArtifactName-war-0.1.0-SNAPSHOT/et/cetera

Thanks for a great plugin.

[jgangemi]

this might be a side effect of how the assembly plugin itself works, but i'm not sure. what happens if you create your own assembly descriptor, do you still see the same behavior?

now that filtering has been fixed, a possible solution could be to create another packaged descriptor that supports a maven property to set the war name.

  <dependencySets>
    <dependencySet>
      <useProjectArtifact>true</useProjectArtifact>
      <includes>
        <include>${project.groupId}:${project.artifactId}</include>
      </includes>
      <outputDirectory>.</outputDirectory>
      <outputFileNameMapping>${war.final.name}</outputFileNameMapping>
    </dependencySet>
  </dependencySets>

[sverhagen]

Thanks for the quick feedback. I don't think there even needs to be a separate property, just use the final name:

<outputFileNameMapping>${project.finalName}</outputFileNameMapping>

That would be a sensible implementation of the "artifact" default descriptor.

If it'd work... surprisingly this leads to the same name as before: myArtifactName-war-0.1.0-SNAPSHOT. Is the assembler implementation not seeing my finalName configuration?

Here's an excerpt of my POM:

<finalName>contour</finalName>
<plugins>
    <plugin>
        <groupId>org.jolokia</groupId>
        <artifactId>docker-maven-plugin</artifactId>

[sverhagen]

I have to correct myself. This:

<outputFileNameMapping>${project.finalName}</outputFileNameMapping>

Leads to a WAR file in the image called ${project.finalName} (literally). I'm using version 0.11.1 of the plugin, which I believe to be the latest.

[jgangemi]

yeah - i'm not entirely sure that's going to work in the current setup. it looks like you can set finalName as part of the assembly plugin configuration when using it directly, but that won't work here.

have you tried adding this to the war plugin configuration?

<configuration>
  <warName>${project.artifactId}</warName>
</configuration>

i use that along w/ an assembly descriptor that looks like this:

<assembly
  xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2 http://maven.apache.org/xsd/assembly-1.1.2.xsd">

  <id>bin</id>
  <formats>
    <format>zip</format>
  </formats>
  <includeBaseDirectory>false</includeBaseDirectory>
  <fileSets>
    <fileSet>
      <directory>${project.build.directory}</directory>
      <outputDirectory>/usr/local/tomcat/webapps</outputDirectory>
      <includes>
        <include>*.war</include>
      </includes>
    </fileSet>
  </fileSets>
  <files>
    <file>
      <source>src/main/docker/app/startup.sh</source>
      <outputDirectory>/usr/local/bin</outputDirectory>
      <fileMode>0755</fileMode>
    </file>
  </files>
</assembly>

and everything works as expected.

[jgangemi]

hrm - it's also possible ${project.finalName} isn't being resolved properly due to #82 which has been fixed and is waiting to be merged in.

if you're feeling daring, you could pulling #106 into a local build.

[sverhagen]

I was feeling daring enough. There's unit test failures in DockerAssemblyConfigurationSourceTest.java on my machine (probably paths not Windows compatible). But I dared (also) to ignore those. This does not resolve the problem. It tried:

1. <descriptor>assembly.xml</descriptor> and <outputFileNameMapping>${project.finalName}</outputFileNameMapping>. Output is: ${project.finalName} (literally)
2. <descriptorRef>artifact</descriptorRef>. Output is: myArtifactName-war-0.1.0-SNAPSHOT.war (as expected)

In both cases I have now <warName>myArtifactName</warName> in the maven-war-plugin configuration.

[rhuss]

The windows unit test failure are fixed (though not yet released). I'm trying to push out a snapshot release 0.11.2-SNAPSHOT with most of the outstanding PRs applied. Since I'm just back from vacations, daily work ate me up today and there is still quite some stuff in my backlog.

I will ping you when it's out so that you could try again.

[jgangemi]

yeah - i'm on a mac so it's very possible it's a path issue - have to remember to account for that going forward.

so i'm not sure using outputFileNameMapping is going to do anything. try creating an assembly descriptor w/ just this section:

  <fileSets>
    <fileSet>
      <directory>${project.build.directory}</directory>
      <outputDirectory>/usr/local/tomcat/webapps</outputDirectory>
      <includes>
        <include>*.war</include>
      </includes>
    </fileSet>
  </fileSets>

where outputDirectory is wherever you want the war to end up and see where that gets you.

also - make sure you've done a rebuilt your code before trying to build the container so you're sure the artifacts are correct.

[sverhagen]

@rhuss I'm not too worried about the tests passing on Windows, but thanks for following up so well!

[rhuss]

sorry, didn't made it today. I've planned to spend Friday some hours on integrating the pull requests.

[sverhagen]

I don't think we'd want it to read <include>*.war</include>, since it depends on there being just the one WAR file. So I'd rather it be specific, such as <include>myArtifactName.war</include>. That might be good enough for my purposes, although ultimately I'd rather point to an existing descriptorRef, since I don't feel I'm trying to do anything out of the ordinary here. So to generalize this, something like <include>${project.finalName}.war</include> would be nice, but that still does not work (I'm still on the same 0.11.2-SNAPSHOT from @jgangemi's branch from yesterday).

I find the <outputDirectory>/usr/local/tomcat/webapps</outputDirectory> interesting. Would you expect users to configure this in the assembly (and do that similarly for the provided descriptorRefs) or have them use <basedir>/usr/local/tomcat/webapps</basedir>?

[jgangemi]

ok - i just spent some time trying different configurations and from what i can tell, it's not possible to achieve what you want using any of the current pre-packaged assembly descriptors.

there is no way to change the final name of the archive the assembly plugin creates/copies when using a dependencySet tag w/o also including the outputFileNameMapping tag.

one thing we could do is change the artifact descriptor to the following (a similar change would also be made to the artifact-with-dependencies descriptor):

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd">
  <id>artifact</id>
  <dependencySets>
    <dependencySet>
      <useProjectArtifact>true</useProjectArtifact>
      <includes>
        <include>${project.groupId}:${project.artifactId}</include>
      </includes>
      <outputFileNameMapping>${project.build.finalName}.${artifact.extension}</outputFileNameMapping>
    </dependencySet>
  </dependencySets>
</assembly>

if you wanted to override final name of the artifact being created, you'd do this in your pom

<build>
  <finalName>some-app-name</finalName>
  ...
</build>

and then you'd end up w/ the artifact you want in the docker container.

if you don't want to alter the name of the artifact at that level and want to do it in the configuration of the plugin e.g:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-war-plugin</artifactId>
  <version>2.6</version>
  <configuration>
    <warName>${project.artifactId}</warName>
  </configuration>
</plugin>

then the only way to get that artifact into your docker container is to use a custom assembly descriptor like the one from my comment above. filtering should be working with the changes you pulled and so you could just change the includes section to be this (technically your build should only be producing one war artifact anyway so the *.war is ok but that's a different discussion).:

<includes>
  <include>${project.artifactId}.war</include>
</includes>

and achieve your desired results.

as for your question about the outputDirectory, usage of that field depends on whether or not you have additional files that need to be deployed, in which case the pre-built descriptors won't work anyway.

in the above example if i was just deploying the war, the assembly section of my pom would look like this:

<assembly>
  <basedir>/usr/local/tomcat/webapps</basedir>
  <descriptorRef>artifact</descriptorRef>
</assembly>

but b/c i need to deploy a startup script along side the war, i need to control where the files get placed using the assembly descriptor and so my basedir in the pom is / and i set the appropriate outputDirectory

[jgangemi]

i just created a PR that allows the artifact name to be overridden as described above. could you give it a try?

[rhuss]

0.11.2 including the fix has been released and pushed to Maven central. You can directly reference it and check, whether it works for you. Please reopen the ticket, if there is still an issue.

[sverhagen]

I think it works, thanks!