Including finalName in plugin configuration results in StackOverflowError

[stevenlyde]

This bug is present in version 2.1.3.RELEASE.

Trying to run a jar created with the maven plugin where finalName has been specified results in a StackOverflowError during class loading. To reproduce the error, see the attached sample and run the following commands.

sample.tar.gz

mvn clean install
java -jar target/exec.jar

The finalName property is no longer customizable but still exists in plugin.xml. Also, a jar is still built with the specified name from the finalName property, but with the described bad behavior. It seems like it might be better to either not allow that property to be specified or to ignore it and display a warning.

[snicoll]

Thanks for the report and the sample. Making it read only is exactly what I thought would happen (see #12608) but for some reason Maven still allows for the field to be changed so I must have misunderstood the purpose of readOnly.

[gatesjd]

Since finalName is missing from the spring-boot:repackage goal's parameters, and usage examples, I understood it was no longer supported in the plugin configuration. The Spring Boot 2.1 Release Notes are a little vague about the intent of this change and what programmers should do instead.

I'm guessing you meant to completely remove finalName from the plugin configuration to avoid potential conflicts with the standard maven build element

<build>
  <finalName>xyz</finalName>
  ...

which would then be the only supported way to specify finalName.

Even though finalName is a standard maven build element, it might be helpful to mention it in the repackage goal's documentation and include it in one of the usage examples.

[snicoll]

I'm guessing you meant to completely remove finalName from the plugin configuration to avoid potential conflicts with the standard maven build element

You are correct.

Even though finalName is a standard maven build element, it might be helpful to mention it in the repackage goal's documentation and include it in one of the usage examples.

I agree it would be helpful to show such an example, I have created #16334

[snicoll]

@stevenlyde for the record, this issue was due to the fact that repackage was running twice. Once without the final name option (so it'd create a fat jar) and once with (so it's attempt to create a fat jar from a fat jar).

The latter is the reason of the stack overflow: since we have no main class, we read the one from the manifest. In the case of an existing fat jar, the main class is the JarLauncher which means we basically attempt to start the Spring Boot app with the JarLauncher as the main method (hence the cycle).

I misunderstood the root cause of the issue and the following configuration works properly (as we don't run repackage twice):

<build>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
      <executions>
        <execution>
          <id>repackage</id>
          <configuration>
            <finalName>exec</finalName>
          </configuration>
        </execution>
      </executions>
    </plugin>
  </plugins>
</build>

See the release notes for more details.

I've also created #16828 to handle this case.

[mpalourdio]

@snicoll I have followed all the issues but I am not really sure of the conclusion for this.

What's the deal with finalName as part of Spring Boot 2.2 ? Must it still be set in <project><build> to avoid further maven deprecation, or can we safely put in back in the spring-boot-maven-plugin 's dedicated configuration as it was before Spring Boot 2.1 ?

I have tested with Spring Boot 2.2 latest milestone, and it looks like the previous behaviour works back. But is it safe or not recommended ?

Thanks again for feedback.

[snicoll]

@mpalourdio the release notes link in my comment above yours states that it is no longer customisable. You’ve noticed you still can but that’s a bug in maven for which we have no control upon.

In short m, you must not use it, it isn’t documented anywhere and the maven plugin doc refers to the standard property only.

[mpalourdio]

@snicoll Thanks for your quick feedback!