Overlay dependency leakage. Causes needed jars to be missing from war.

[michael-newsrx]

Overlay dependency leakage. Causes needed jars to be missing from war.

Issue: Overlay dependencies are applied to target project dependencies resulting in bad dependency resolution chains.

I have two sub-projects - Servlet API and GWT-Client.

• The Servlet API project declares GWT-Client as an overlay.
• The Servlet API project has a dependency on commons-lang3.
• The GWT-Client is a GWT 2.10.0 project and has a need for the following: providedCompile "net.sourceforge.htmlunit:htmlunit:2.55.0" which has a dependency on commons-lang3.

The dependency declarations for the GWT-Client project are affecting the Servlet API project's dependencies.

This results in the commons-lang3 dependency is missing from the Servlet API war.

If I change the dependency to be implementation then htmlunit and all it's dependencies end up in the final war, which is definitely not wanted.

Is there a work around to stop an overlay altering the target project's dependency configuration?

edit: Version 3.0.8, Our production systems are still on Tomcat9 so we can't use version 4.0.1

[f4lco]

So essentially you are saying that the overlay feature does not work as advertised? From the documentation:

When performing appRun[Debug] and appStart[Debug], runtime classpath of overlay sources is added to the runtime classpath of the current project. Classpath of the current project has priority.

From your description, it looks as if the dependency configurations of the "current project" ("Servlet API", I suppose) do not take precedence in your case.

Have you tried to move the htmlunit dependency to the testImplementation or testCompile dependency scopes? Does the requirement really exist to have test code in the production source set?

TBH, if you want someone else to debug / fix this issue, it would be extremely helpful if you could provide a reproducer project exhibiting the behavior. To much depends on the particular build script, and on the individual dependency configuration setup.
Alternatively, If you feel confident to send a patch in yourself, I'd gladly help and review it, as well as prepare a new release.
Unluckily, I do not know of a workaround solution, nor did I encounter this behavior by myself.

[michael-newsrx]

The htmlunit dependency is required for GWT Superdev mode to work. I'll play around with test* to see if GWT Superdev mode still works. The current project's dependency on commons-lang3 is changed from parent project's declared of "implementation" to the child project's declaration of "providedCompile". The child project's declaration for the htmlunit dependency is compileOnly and this compileOnly in the child project is overriding the parent project's implementation dependency. I hope that makes sense.

…

On 8/16/22 15:20, f4lco wrote: So essentially you are saying that the overlay feature does not work as advertised? From the documentation <https://gretty-gradle-plugin.github.io/gretty-doc/Web-app-overlays.html#_effects>: When performing appRun[Debug] and appStart[Debug], runtime classpath of overlay sources is added to the runtime classpath of the current project. Classpath of the current project has priority. From your description, it looks as if the dependency configurations of the "current project" ("Servlet API", I suppose) do not take precedence in your case. Have you tried to move the htmlunit dependency to the testImplementation or testCompile dependency scopes? Does the requirement really exist to have test code in the production source set? TBH, if you want someone else to debug / fix this issue, it would be extremely helpful if you could provide a reproducer project exhibiting the behavior. To much depends on the particular build script, and on the individual dependency configuration setup. Alternatively, If you feel confident to send a patch in yourself, I'd gladly help and review it, as well as prepare a new release. Unluckily, I do not know of a workaround solution, nor did I encounter this behavior by myself. — Reply to this email directly, view it on GitHub <#262 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHY72LT4IZBGJSBLULNP5DVZPSXHANCNFSM56SDSNTA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[f4lco]

The htmlunit dependency is required for GWT Superdev mode to work. I'll
play around with test* to see if GWT Superdev mode still works.

I see, my memory of GWT is waning. How do you start SDM, is that another Gradle plugin? I'd be surprised if it did not have a separate dependency configuration for things to put on the classpath when running SDM. Then you could get away with putting the htmlunit dependency on the superdevmode configuration. In theory, you do not want to end up with htmlunit in your production WAR anyway.

The child project's declaration for the htmlunit dependency is
compileOnly and this compileOnly in the child project is overriding the
parent project's implementation dependency.

It does make sense to me. If you want to take route with the reproducer project, take a look at an example integration test for the overlay functionality, or bootstrap from a Gretty example project. In any case, it does not need to be fully fledged, just enough to replicate your dependency configuration setup, and to debug.