Map application plugin main class to JAR manifest

[ljacomet]

While this change was done as part of the work for JPMS support in Gradle 6.4, it was considered a breaking change and thus postponed to Gradle 7.0.

See #13057 for context.

[ludoch]

Do you have more doc for this? Would it be possible to create a jar with a manifest main entry which is not really executable with java -jar?
Examples of usage would help... We could modify our buildpacks stack to adapt, but need more info there, otherwise our buildpacks will break again when using Gradle 7.0.
Our logic is to calculate, after a build what would be the default executable entrypoint the user would want to use for the app execution. So far, we open all the jars and if 1 and only 1 has the main entry, we use it. If 0 or more than 1, we cannot determine the user intent, and they have to specify a entrypoint...

[ludoch]

(BTW, bonjour!)

[ljacomet]

@ludoch 👋
If I understand correctly, what you are saying is that if we start adding the Main-Class entry in the manifest, while it marks the JAR as executable, it is not enough since we would be missing the classpath anyway.

That is an interesting data point.

And since the JPMS support takes care of adding the main class to the module-info, the modular part is covered through a different path.

Interested to have the opinion of other Gradle users if they have similar requirements / remarks / concerns.

[Mahoney]

I wrote my own application plugin that adds the Class-Path attribute to the manifest as well, so that java -jar myjar.jar just works. So much more pleasant when you list processes - I hate the way that a java process takes up two screens worth of a terminal output on a ps -ef, and good luck working out which of the 500 jars listed is actually the entry point.

https://github.com/Mahoney-playground/goos/blob/d13fe1ce2bc6d2ae6ce2e036186d914b17b3e777/buildSrc/src/uk/org/lidalia/gradle/plugins/application/ApplicationPlugin.kt

[swpalmer]

I've always expected the application plugin to set the Main-Class and Class-Path entries so java -jar "just works" . I stopped using it because it didn't do this and it created overly complex launch scripts instead.

[ludoch]

Never saw this behavior with Maven (yet)... You experience was with Gradle or Maven?

[swpalmer]

? Nobody mentioned Maven. I haven’t used it for years. I was referring to the Gradle application plugin.

[ashih]

Is there any update on this ticket? Is this feature still planned to be released in Gradle 7? Has there been any investigation into if we can avoid creating multiple jars with Main-Class manifest entries? (#13057)

[ljacomet]

No further update, still interested in having more user feedback on this topic.

Has there been any investigation into if we can avoid creating multiple jars with Main-Class manifest entries?

I do not see that being a responsibility of Gradle. If a build author wants to create multiple executable JARs, why should Gradle prevent it?

Regarding using that information to determine the main output of a project, I think it is at best a brittle solution.
The canonical approach that Gradle would recommend is to have a plugin which carries that information, can be configured and have clearly documented defaults.

[ljacomet]

Now that Gradle is looking at the 7.0 content, going back on this issue, it seems like its benefit are too small given the potential drawbacks.
This default mapping will not be implemented and a build author can express it in his own build with:

jar {
    manifest {
        attributes("Main-Class": application.mainClass)
    }
}

[pantherdd]

@ljacomet I've written a Gradle plugin to build Java applications that work this way. Take a look, I'd actually like to contribute it to Gradle if there is interest 🙂

• https://github.com/morganstanley/gradle-plugin-application
• https://plugins.gradle.org/plugin/com.ms.gradle.application