Resources folders recognized as packages using the gradle plugin

[u1234]

I am testing Gradle IDE 3.2.0 in eclipse Juno. I have created a minimal multi-project. But when I add subfolders in the src/main/resources folder it looks like this:

wrong.jpg

why are the subfolders recognized as packages? I have tried to run update on the gradle projects and re-import but its keeps looking like the above picture.


In maven it looks like this:

correct.jpg

Is this a bug in the Gradle IDE integrator for eclipse?

[u1234]

manually adding "excluding='**'" in the .classpath file solves the problem:


<classpathentry excluding="**" kind="src" path="src/main/resources"/>

could be nice it this was done when running the eclipse project/classpath tasks.

EDIT:

But as a result the resources are no longer visible when using eg. the classloader.

[Kris De Volder]

It may be worth investigating this a little deeper (i.e. trying to determine why this happens and how to fix it).

From what I understand now, they show as packages because the 'resources' are in fact on the classpath.
You are fixing that by removing them from the classpath with:

<classpathentry excluding="**" kind="src" path="src/main/resources"/>

That fixes how they look in the IDE, but I wonder if that doesn't create other problems. For example if the resources are not on the classpath than I beleive they will not be accessible via Java classloader APIs like this one:

http://docs.oracle.com/javase/1.5.0/...lang.String%29

This is something that an application may depend on to access the resources at runtime.

I.e. if you build your project with Gradle then the resources will be copied into the jar artifact for your project. If you remove the entries from the eclipse classpath than building your app inside Eclipse, I think, will *not* copy the resources onto the runtime classpath. So you might then have problems accessing them when running your code inside Eclipse.

Another thing to note is that the Gradle tooling really just reflects information returned from the Gradle tooling API into Eclipse classpath entries. The resources folder was added to the classpath because the tooling API told us that it is a 'source folder'.

You in fact can remove it from the classpath by customizing your project layout via your gradle build script.
See here for some info in section: 23.4.1 if this chapter of the Gradle user guide:

http://www.gradle.org/docs/current/u...va_plugin.html

(But again... if the resources folder is not on the classpath it means resources may not be copied/accessible at runtime).

It is interesting that maven renders the resources folder differently. I don't actually know how that is handled it may be interesting to look into it. Have you checked the .classpath file in a maven project? How does the 'resources' entry appear in there? Maybe Gradle + tooling could do the same thing. This would probably require both changes to the tooling API in gradle itself, the Gradle eclipse plugin in Gradle and STS Gradle tooling, but maybe it is possible.

Kris

[u1234]

Yes the resource cannot be loaded using eg.:

this.getClass().getClassLoader().getResource("test .txt");

when manually adding excluding="**" to the .classpath (see my edit in the original topic). For some reason it works with maven even though they add excluding="**". Below is a sample .classpath generated by m2e:

<code>

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" output="target/classes" path="src/main/java">
<attributes>
<attribute name="optional" value="true"/>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry excluding="**" kind="src" output="target/classes" path="src/main/resources">
<attributes>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="src" output="target/test-classes" path="src/test/java">
<attributes>
<attribute name="optional" value="true"/>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry excluding="**" kind="src" output="target/test-classes" path="src/test/resources">
<attributes>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.Standar dVMType/J2SE-1.5">
<attributes>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER">
<attributes>
<attribute name="maven.pomderived" value="true"/>
</attributes>
</classpathentry>
<classpathentry kind="output" path="target/classes"/>
</classpath>

</code>

[Kris De Volder]

My suspicion is that this works in maven projects because m2e provides its own Eclipse builder that copies the resources using some maven mojos that get run as part of the Eclipse build cycle by m2e.

M2e tools integrate deeper with maven than gradle tools do with Gradle. Presently there's really no mechanism for gradle builds to participate in IDE builds and 'play their part' so to speak in the Eclipse builds lifecycle. So instead we have to emulate Gradle behavior by mapping it onto equivalent Eclipse concepts.

When resources folders are treated as 'source folders'. The Eclipse Java builder handles them correctly, copying non Java resources to the output folder, but, as you noted, it renders a bit oddly in the package explorer view. This has never really bothered me personally.

It may be possible to fix this somehow, but as a first step Gradle itself would need to refine the tooling API model it exposes to the tools to distinguish 'resources' folders from 'source' folders. Right now short of implementing something hacky based on the names of source folders, the tools have no way of knowing the difference between a 'real' source folder and a 'resources' folder.
So the tools really forced to treat them the same.

To be honest with you, it looks like fixing this is not so easy. And it doesn't seem important enough to warrant a large effort.
The problem seems mostly cosmetic. In a sense, actually seeing them as packages may even conveye some useful information, i.e. that those things are indeed on your classpath and accessible via the classloader.

Kris