Gradle oddness: placing .class files under /src


#1

I’m thinking this must be some strange thing going on in my own playground here due to past monkeying :monkey: around and shenanigans, because this kind of thing couldn’t go unnoticed. But I’m a little stumped at the moment.

Extra .class files are being placed alongside .java files under my /src tree. This happens with both versions of Gradle I tried. They do also end up under /build with timestamps about 4-5 seconds earlier.

At first I suspected a NetBeans 11 Gradle support bug - nope. I’ve watched this happen with a regular command line “gradle build” from the jmonkeyengine root folder, with NB not running.

I didn’t see any issues for it on GitHub. Do I have a gremlin problem or has anyone else also noticed this?

Linux, Gradle 5.4.1 and 4.10.2, OpenJDK 12 (& 8)

Side note… I’ve decided it’s time I get a little more active on the open source front in general. And while I haven’t always been the most active here over the years (mostly stalked around quite a few years), JME has definitely been the most fun to hang out with. So what better place is there?

I’ll be looking for things to help out with, review, test, bugfix or whatever. We’ll see where things go. While I can’t guarantee I’ll find all suggestions interesting, I am considering applications (lol).

Of course I’m also making an effort to learn Gradle better… so figuring out what the heck is going on here will be a start won’t it? :rofl: First thing tomorrow will be to see if I can even reproduce it on another machine… taking bets, I’m going to go with “nope”.


#2

Something is wrong with your build.gradle file. We can’t see it, though.

This is definitely not normal behavior… you can try “insert any of my open source projects here” to confirm.




#3

What jme version are you using? I vaguely remember reading something like this in the rejected java 11 support PR.


#4

Yep, I also doubt if that is the case, if so then I think (not sure) you may need to remove it from your disk and clone the project from the master again. This is what I end up doing. I am not much experienced with git commands, someone else might know a better way.


#5

Well I should have virtually the same build files in JME’s master branch, if Git’s being honest? I’m not building my any project of my own here, I’m building JME. (The projects I do have which use JME were acting normally.)

I was indeed checking out the Java 11 support branch on tlf30’s repo before it was merged. I also forgot that I switched to another PR for transform feedback to check that out.

BUT… Git’s still not reporting any difference in the root JME gradle build files.

There is a suspicious diff in jme3-bullet’s build.gradle (but not the root JME gradle.build) - maybe that’s it? Strange to me that it could impact other sub-projects.

So yeah, I’ll solve the mystery tonight.


#6

Yep, the problem is in the transform feedback PR branch I was taking a look at (and before that).

I guess the issue was in some subproject build files. I wouldn’t have guessed that could impact other subprojects. Gradle learning moment…

I can reproduce on The_Leo’s branch but not jme master.

Sorry @The_Leo, you might want to rebase that and clean up a bit. (It was something the branch “inherited” from it’s parent commit.)

So Git’s not a liar, but Gradle is a sneaky bugger.


#7

@louhy thanks for trying out TR, regarding the issue I don’t follow.

I haven’t changed a single gradle file afaik.
Currently TF is 25 commits behind jme:master, thus was the issue in the master when i cloned and it is fixed now in master only?
If that is the case then there should be no problem if its merged.


#8

Wasn’t a change you made, it was something pulled in from the commit you branched off of. Fixed in master (but not fixed for anyone testing the PR).