For the Gradle case, consider defining app name/location similar to how we do for Maven.

[scottkurz]

There's an opportunity for the starter to add more consistency across the Gradle/Maven cases, which would be to define a common server.xml config.

In the Maven case we explicitly generate this via the server.xml template:

    <!-- Configures the application on a specified context root -->
    <webApplication contextRoot="/app-name" location="app-name.war" />

whereas in the Gradle case we do not have an application element, but rather rely on the ability of Liberty Gradle Plugin to generate an application config in config dropins.

One detail that the Maven case handles, to make this happen, is removing the version name from the location (generated WAR file name) via this element in pom.xml:

  <finalName>app-name</finalName>

It seems we could do the equivalent in Gradle with something like this:

war {
    archiveName = "${baseName}.${extension}"
}

As long as this is not bad or weird from some broader, more general Gradle user's perspective, this would be an option.

Why do this?

I'm not sure consistency purely for the sake of consistency is that compelling. Most users will only be interested in using one of Maven vs. Gradle at a time.

However, I think there is a case to be made for having the explicit config in server.xml as opposed to the generated config dropins entry.

The latter isn't as transparent...it's kind of "magic". We have had bugs in this area within the Maven/Gradle plugins (though I would guess we've fixed most or all??? of them).

I think we kind of went down a similar path in the discussion here:
#5

[gkwan-ibm]

why server.xml having <webApplication/> element for Maven project only?

related PR change: ef91b70

[cherylking]

I think the differences in server.xml came about because the app names were different for Maven (because of setting of finalName) vs Gradle (defaulted to include the version in the app name). I suggest that for both Maven and Gradle we use the stripVersion configuration from LMP/LGP to strip the version from the app name and remove setting of finalName in pom.xml.

Then undo the change that omitted webApplication in server.xml for Gradle.

Both the Maven and Gradle project should then be tested to ensure the app gets deployed and starts correctly.

[scottkurz]

I suggest that for both Maven and Gradle we use the stripVersion configuration from LMP/LGP to strip the version from the app name and remove setting of finalName in pom.xml.

@cherylking we could do this. I take it you're thinking the logic is that it's better to use Liberty plugin config to align with Liberty server config than use more generic WAR/artifact mechanisms?

I don't have a huge opinion one way or the other. Would be curious if anyone had a compelling reason.