Repackaging twice without changing application classes results in issues.

[scottkurz]

To recreate:

1. Run a top-level:

   mvn clean install -Pit

2. cd to IT proj dir

   cd target/it/test15Implicit

3. Do another build:

   mvn install # or even mvn liberty:start-server

The messages.log shows: [8/3/18 13:02:31:608 EDT] 00000029 com.ibm.ws.app.manager.AppMessageHelper E CWWKZ0002E: An exception occurred while starting the application thin-gs-spring-boot-0.1.0. The exception message was: java.lang.RuntimeException: Failed to run jar due to error C:\Users\ScottKurz\wlpExtract\thin-gs-spring-boot-0.1.0_73998872913722\wlp\bin\tools\ws-server.jar (The system cannot find the path specified)

[scottkurz]

The issue involves the three plugins doing packaging here: jar, spring-boot, boost.

In the "normal" flow for the initial execution,

1. the jar plugin zips up the app classes
2. spring-boot makes it into a FAT jar and adds the SpringBoot loader stuff
3. boost thins the FAT jar and packages this into an executable Liberty server JAR

This is all fine if you make an app change, and run mvn package again. However, if you run without updating any app classes, the jar plugin will decide not to re-jar the classes, leaving in place the .jar which is the executable Liberty server. This is what the spring-boot plugin will try to turn into a FAT jar, and Liberty will try to thin.

---

Seems like a solution would either be to:

1. No-op (re)packaging when things are unchanged, adding "flags" to make this possible. The spring-boot plugin looks for a MF header named Spring-Boot-Version. We could perhaps write one into the server .jar output to short-circuit SpringBoot repackage. In some other way we could short-circuit the remaining Boost repackage.

2. Figure out how to re-thin and re-package a FAT SpringBoot JAR that has been built in this convoluted way. This seems ugly, but if for some reason there is some use case that 1. presents a problem with, I just mention it.

3. In the maven-jar-plugin doc, they mention this exact use case and the maven.jar.forceCreation property can be used to solve this. Unfortunately requiring a maven-jar-plugin config in this way is a burden we probably don't want to put on our users.

[chyt]

@scottkurz Can you verify that this issue still exists since 2.6-SNAPSHOT? I am unable to replicate.

[cherylking]

I think adding something like the following to the boost pom.xml would solve this. May want to look for a more optimized solution later though.

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>3.1.0</version>
                <configuration>
                    <forceCreation>true</forceCreation>
                </configuration>
            </plugin>
        </plugins>
    </build>

[scottkurz]

It still occurs for me and @cherylking adding that to the boost plugin.xml doesn't seem to have an effect.

I am running on Windows 10. Hmm...

[chyt]

Yes, I was wrong in suggesting that, since that plugin config will not be inherited unless through a parent pom.

Scott, can you add a test for this and see if it happens on Travis?

[scottkurz]

You can see the failure here:
https://github.com/OpenLiberty/boost-maven/pull/61/checks?check_run_id=12768246