search

gretty-gradle-plugin / gretty

Advanced gradle plugin for running web-apps on jetty and tomcat.
MIT License
128 stars 36 forks source link

Gretty 2.2 cannot find resources in java-library project dependencies #55

Open carey opened 6 years ago

carey commented 6 years ago

Please see the example at https://github.com/carey/gretty-resources.

If I start this by running

./gradlew clean :web:appRun

then the servlet in the lib module cannot load the hello.properties resource in the same module from the class path. I can fix this by using the java plugin for lib instead of java-library, or by running

./gradlew clean :lib:jar :web:appRun

I assume this is related to #37.

javabrett commented 6 years ago

I think this is to do with how the in-place appRun assembles the classpath and resource-path. For example, ./gradlew clean :web:appRunWar works fine.

Also, if you run a build then cp lib/src/main/resources/hello.properties lib/build/classes/java/main/, then :web:appRun will also work.

I've seen this before in my projects and lamented that appRun can't really assemble the war-like behaviour completely.

I'm curious about java-library fixing it though - can you push another branch to your example project to demonstrate?

carey commented 6 years ago

Here's the change on new branch: https://github.com/carey/gretty-resources/compare/java.

As I understand it, the java-library plugin was made so that Java compilation would be much faster. It doesn't need to build against a jar for this, just build/classes. But apparently it doesn't need the resources, either.

javabrett commented 6 years ago

Thanks. For clarity, after execution of :web:appRun using the java plugin instead of java-library, the following additional files are present:

diff java-library.txt java.txt 
16a17,21
> lib/build/resources
> lib/build/resources/main
> lib/build/resources/main/hello.properties
> lib/build/libs
> lib/build/libs/lib.jar
17a23,24
> lib/build/tmp/jar
> lib/build/tmp/jar/MANIFEST.MF

So java is both building the jar and copying the resources file into the build tree. As already observed, running :lib:jar results in the same files as above, and everything works fine.

I think this was partially anticipated by the Gradle team according to https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_known_issues_compat . So I think what we could do here is try and link in with java-library and effectively force the dependency on :lib:jar so that you don't have to run it explicitly. How does that sound?

I'm not sure there are other good options based on what the standard lifecycle of java-library is doing (or not doing) with resources, but someone else might have a suggestion.

Of course pull-requests for this are welcome :).