Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jib-maven-plugin fails if maven-war-plugin "warName" property is set #2206

Closed
padyx opened this issue Dec 28, 2019 · 6 comments · Fixed by #2208
Closed

jib-maven-plugin fails if maven-war-plugin "warName" property is set #2206

padyx opened this issue Dec 28, 2019 · 6 comments · Fixed by #2208

Comments

@padyx
Copy link
Contributor

padyx commented Dec 28, 2019

Environment:

  • Jib version: 1.8.0, 1.7.0
  • Build tool: Maven 3.6.3
  • OS: Fedora / Windows

Description of the issue:
Between 1.6.1 and 1.7.0, the behaviour of the jib-maven-plugin changed and no longer works if the WAR name is not according to the default (artifactID-version.war), but changed using the "warName" property of the maven-war-plugin.

Expected behavior:
Upgrading the jib-plugin from 1.6.1 to 1.7.0 does not change the result of the build.

Steps to reproduce:
I created a small repository that you can clone: https://github.com/padyx/jib-test-repository

Working configuration (initial repository state):

  1. Alter the pom.xml File in helloworld.ui.html.app.war and change the target image to a location you can push to.
  2. Execute the build as follows: mvn -Djib.to.auth.username=xxxxx -Djib.to.auth.password=xxxxx -DskipTests -P docker clean package (Success)

Error if upgrading:

  1. Change the jib-maven-plugin Version to 1.7.0 (or 1.8.0) in the helloworld/pom.xml File.
  2. Rerun the build with the command above.

jib-maven-plugin Configuration:

<!-- From parent module (build / pluginManagement) -->
<plugin>
  <groupId>com.google.cloud.tools</groupId>
    <artifactId>jib-maven-plugin</artifactId>
    <version>1.7.0</version>
    <executions>
      <execution>
      <phase>package</phase>
      <goals>
        <goal>build</goal>
      </goals>
    </execution>
  </executions>
</plugin>

<!-- From build in actual module-->
<plugin>
  <groupId>com.google.cloud.tools</groupId>
  <artifactId>jib-maven-plugin</artifactId>
  <configuration>
    <from>
      <image>tomcat:9-jdk11</image>
    </from>
    <to>
      <image>padyx/testimage</image>
    </to>
  </configuration>
</plugin>

Log output:
[ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:1.7.0:build (default) on project helloworld.ui.html.app.war: Obtaining project build output files failed; make sure you have compiled your project before trying to build the image. (Did you accidentally run "mvn clean jib:build" instead of "mvn clean compile jib:build"?): /home/chakotay/eclipse-workspace/helloworld/helloworld.ui.html.app.war/target/org.eclipse.scout.apps.helloworld.ui.html.war -> [Help 1]

Additional information
The configuration for the war name is: (helloworld.ui.html.app.war POM File)

<plugin>
  <artifactId>maven-war-plugin</artifactId>
  <configuration>
    <warName>uihtml</warName>
  </configuration>
</plugin>
@chanseokoh
Copy link
Member

Yeah, this is not yet supported. We should read some of the configuration parameters from maven-war-plugin.

@loosebazooka loosebazooka added this to the v2.1.0 milestone Jan 2, 2020
@padyx
Copy link
Contributor Author

padyx commented Jan 2, 2020

Do you think this is a regression (since it worked in 1.6.1) - or did it just work by accident in earlier versions?

@chanseokoh
Copy link
Member

Ah, yeah, I see in that sense you may think this is a regression. In #2069, we changed the behavior so that Jib unzips a final WAR instead of using an intermediate exploded WAR directory (whose contents may be incomplete compared to a final WAR file). I guess the intermediate exploded WAR directory name wasn't affected by the warName parameter. So, now the problem in your case is that Jib assumes the default WAR filename, whereas you are configuring warName.

@chanseokoh
Copy link
Member

Will be fixed by #2208. To be complete, I think we should also read <classifier> and <outputDirectory>, but at least #2208 will support <warName>.

@padyx
Copy link
Contributor Author

padyx commented Jan 3, 2020

Awesome, thank you! 😻
I tried this out locally by building 1.8.1-SNAPSHOT and I can confirm it works now.

@TadCordle
Copy link
Contributor

@padyx 2.0.0 has been released with this fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants