Gradle not compliant with resource policy of Java getResource()

Help/Discuss
1

After learning Gradle through Android environments, there is but no option to migrate from Ant to Gradle, also for revision of historic pure-Java projects, using e.g. the Gradle plugin for Netbeans. Thus, for your consideration:

To make it swift and easy to migrate, Gradle should (must) put resources in a folder where the Java system and the programmer expects to find it, which is typically (or at least traditionally) in a /resources subfolder to where the code is.

The current solution of the Java plugin is cumbersome and easily a timethief. Why? There are two options:

  1. Reprogram and give the getResource() method a relative path to resources found high above in the hiearchy, like …/…/… /resources, or

  2. Instruct Gradle to put resources like this:

sourceSets {
main {
output.resourcesDir = “build/classes/java/main/bla/bla/bla/bla”

Not that hard, but cumbersome and you need to use time to detect this solution. In addition I could not find anything on this major migration issue in the user manual?

Do you want to make it easy for ant people to migrate? OK, then put resources next to code in a /resources subfolder. You could add a separate keyword to enable that easily for those who need it in such a migration processes, however it should really be default because Java expects what it expects.

Hope for a comment!

2

Instead of reprogramming or changing the output dir, the conventional way to use resources (both in Gradle and in Maven) is to create a folder structure that matches the java package structure. I.e. if you have a class that needs an accompanying resource, you’d do the following:

src/main
   java
     com/foo/Foo.java
   resources
     com/foo/Foo.properties

Then you can simply use Foo.class.getResource("Foo.properties")

3

Thank you, but problem not fully solved.

As this is implemented, Gradle + Netbeans now expect package name to include main.java.com.myproject, not the normal com.myproject (1)

Now, to find resources, the only way found was to put resources under

main.resources.main.java.com.myproject.

How can I instruct Gradle to accept that the redundant main.java part of the package name is omitted, i.e. like (1), EVEN if the source folder structure is indeed positioned in the src/main/java/ folder?

(Trying to minimize work converting a rather large ant project to Gradle)

4

Sorry for bothering you, this issue may be closed. The reason was that the Netbeans Clean function is partly broken and has been for years. I will explain in case it could help others:

First, there was an error in that NB found inconsistency between package name and actual folder structure, i.e. that standard Gradle assumes the src/main/java top folders, but this was not accepted by NB, reporting inconsistency against acutal folder structure. This could be a cache issue, I don’t know.

Therefore, I removed main.java from the package name in the “package explorer”. Therefore, NB automatically and without saying anything is rearranging the folders accordingly, to src/com

Therefore, and perhaps I did some other things too, there are old empty source folders remaining.

A clean&build does not remove these empty folders, nor is NB providing any notifications.

I finally found the menu “rightclick project” /source roots/delete empty source roots/ function. This removed these empty folders, and then it worked again, according to your outline.

This is my best guess as to what happened.

One question could be to ask what Gradle does with empty source folders. It is either Gradle, the NetBeans Gradle plugin, or Netbeans that causes these empty folders to be included in the build folders, again causing major havoc.

5

The Netbeans Gradle plugin gets the source folders from Gradle. Those are src/main/java for instance. I assume that previously you had your sources under the src folder directly, so there probably was stale configuration in Netbeans. Since src/main/java is a child of src, Netbeans probably got confused. What it should have done is remove the outdated src folder definition. This is what Eclipse Buildship does for instance. This might be an issue in the Netbeans Gradle plugin, so I’d open a question on their issue tracker.

6

Netbeans is great, but I have time and time again found these kind of “kindergarten” inconsistencies. What I would expect from a modern IDE, is that a Clean, possibly an envisioned “superclean”, or “brutaly and irrevocable clear all history”, would always clear cache and offer the user to start from scratch. This is such a major timethief.

For example, when would it ever be constructive to NOT at all report inconsistency between package explorer paths and actual package paths? Never, and yet, Netbeans is silently overlooking this major fault.

These kind of problems are not present in Android Studio.

That was my frustration in short. The remedy was to clear the local cache files in the project.

Yes, I have an issue running at the Gradle Plugin issue tracker. Thanks for your help.