I have a project that I have been working on for a few days and I finally got it to compile cleanly. However, a git clone of the same remote branch (on the same machine, compiled in the same terminal instance) caused a compilation error. A fresh clone on a different machine had the same error. I figured it was an issue with my working directory having some additional untracked files, but I deleted all untracked files to the point where diff says the directories are identical except for things contained in the .git folder. I even checked permissions with tree and compared the resulting files with meld – they were basically identical, although a few source files had slightly different execution permissions.
The error was one that came from a file which I had excluded in the maven-compiler-plugin. This should essentially mean that the filename is never passed to javac, although I don’t know exactly how it works under the hood. I realize that clearly the compiler is getting the file from somewhere if it is erroring on code inside it. In the one directory on my computer which worked, there are no errors and it compiles perfectly. On the other clones of the repo (which are, again, identical according to diff) it gives an error on this (excluded) file.
Additional experimentation showed that on a fresh git clone of the remote branch, a cp -R of the local directory, or a git clone of the local directory, compile failed. However, if I did a cp with the --archive option, the compile in the resulting directory succeeded. I narrowed it down to the --preserve=timestamps flag (which is enabled due to the fact that --archive is the same as -dR --preserve=all). If you didn’t quite catch that, I’ll say it again.
When I copy the directory normally, it refuses to compile properly. Only when the timestamps are preserved does it behave identically to the original directory.
I don’t understand this – why does the java compiler (or maven) care about the timestamps?
The problem ended up being a Maven compiler plugin issue combined with the fact that I was trying to do something which was somewhat misguided.
Briefly, the compiler plugin passes in a list of every file you want to compile as well as a link to the source directory.
The list of files is perfectly fine, as this is how javac knows which things to compile. However, the fact that the source directory is also being passed is not ideal. When you put a file (or pattern) into the maven compiler plugin’s
<excludes>tag, it will no longer show up in the list of files passed to javac. However, it will most likely reside in your source directory (which maven passes to javac). This means that javac can still compile these files if it wants to, even though you excluded them. This may occur if one of the files is a dependency of another. The expected behavior here would be to throw an error – instead, it compiles the excluded file and continues on its merry way.In my situation (as I explained in the comments) I was having issues because a file which was explicitly excluded (reason: an unrelated bug in the way maven handles classpaths means that file cannot be compiled properly by maven) was still trying to be compiled, even though I was trying to provide a pre-compiled version of the class.
In this case, if I copied the files without timestamps being preserved it thought the source files had been modified recently, and that the precompiled version of the class was out of date. Therefore javac tried to compile the excluded file. Only when I preserved the timestamps (which showed that the file had not been modified in months) did javac realize it should use the provided .class file instead.