Yesterday I finally had it building on my machine (I had pulled latest code yesterday morning I suppose).
This morning I synched up latest from master and now it is back to a disaster of hundreds of errors.
Any hints most appreciated. I was hoping if I got my “build path” configured right once then it would “stay mostly okay” but apparently not.
Mostly I’m obviously looking for if any configuration parameters/requirements are new.
I only see a makefile change (which shouldn’t affect me on Windows, right?), a change that looks like it only affected comment lines, and a rollback to a single file.
So I’m baffled. But admittedly Java buildpath configuration baffles me – I thought once I got it building yesterday I ought to be done for a while (which was the case last time I got going and then successfully built a bunch of custom classes).
Actually I have built quite a few times today from more or less the master. I see a lot of warnings but I believe those are “expected” until it all gets cleaned up. (I fear that process now!)
Still you have not actually given us an example of the errors.
It’s errors not warnings.
Here is one example from among the many, this one in AbstractBuildable.java:
[attachment=0]Screen11.png[/attachment]
Hunh. Well yesterday it was okay to have Java 14.0.1 and have it set to Java 11 as the target. TODAY it only behaves if I switch it to the Java 11 JRE.
I suppose I should seriously think of taking FlintB’s advice and just switch IDE’s.
Sorry I am not getting those (even as a warning).
If you go back to what worked before, does it still work?
When I set it to use the Java 11 SDK (instead of “Java 14 but target Java 11”) the latest now works. Go figure. Good enough for now.
There’s no reason why this shouldn’t work if you want to keep using Eclipse. Brent has it working. Maybe just hang on until he chimes in?
There’s nothing which has changed on master since yesterday which should affect your build setup at all.
There is no build path problem of Eclipse that cannot be solved by crossing fingers, doing a handstand, followed by a rain dance and a prayer to the gods of eclipse, and most importantly N iterations of “project → clean”, with N roughly between 2 and 10, depending on the current weather.
If we add maven, it’s going to be project → clean; maven → update project; maven → update dependencies; project → clean; maven → update project and so on.
On my first job after uni I had build path problems with Eclipse, almost every day. After a while they started thinking that I’m just incapable and don’t know what I’m doing so they had a senior dev sit next to me and help me fix the Eclipse problems. He fixed them, next day they were back, he fixed them again, this went on until at some point he had to report to management that he had spent about 10 hours fixing the same problems over and over. Problems that did not exist on any other computer in the company. Then they gave me another computer and these problems were gone 
Well having done the rain dance several times, I have now created “baby’s first PR” for Bug 12980
github.com/vassalengine/vassal/pull/30
Because I am nothing if not persistent 
Okay, NOW I think I have somewhat of an idea of what’s going on.
I think there must be some Eclipse project configurations IN THE DEPOT.
Because I just did the “switch back to master and make sure it’s in synch” workflow to get a new branch started, and guess what!
(1) “test” tree items were back in my buildpath even though I’d removed them
(2) JDK had switched back to full 14.0.1, rather than 11, and thus stopped working again.
(3) I had to go back and manually add the Expose Package stuff for sun.java2d.cmm once again.
Sooooo… I’m going to suggest that it might be best practice to not have those Eclipse files in the Repo? (I don’t even know what they’re called, though I notice something called .classpath is apparently trying to be part of my PR even though I didn’t knowingly change it and certainly didn’t add it to my commit with the command line – perhaps Eclipse decided to auto-add it?)
And to the extent that they are in the Repo I’m definitely interested in learning how to tell git to “do everything else, but never ever pull THAT file down”.
I feel a little less like an idiot now. Only a little, but still.
Brian
This is actually considered best practice as each developer might have slightly different settings in his local IDE installation. It is possible to force all Eclipse/IntelliJ/whatever other IDE users to use all the same settings, but unnecessary, and it only really works in scenarios where all developers use the same OS, same JDK, same IDE and same directory layouts.
The Eclipse files are .classpath, .project, and the directory .settings/
Okay yeah - that’s what I thought. All the videogame projects I worked on, checking in the IDE configs was a “no go”. Having it exist was somewhat useful in getting off the ground (because it saved me having to do the extra steps of adding in the library and non-redist files), but then apparently even though this works for somebody else (Brent?) it needed some different settings to be willing to build on my machine. Which doesn’t mean I’m necessarily configuring my own set perfectly, but does mean that whatever is up there in the repo won’t build it on my machine.
.classpath for sure is part of it. As far as I can tell that’s the only one directly causing me problems, but yeah there may be others.
If my PR with maven gets accepted these Eclipse settings will be gone, maven will then be in charge of telling eclipse how to configure the build path.
FYI if you have any local files that you don’t want to be tracked by git, you can add them to the file “.gitignore” in the root directory of the project. This is the mechanism which prevents IDE settings and other local files from ever showing up in any git commits. There is even a whole gitignore generator available as an online tool, which takes keywords and spits out a premade gitignore file that ignores commonly ignored sets of files: toptal.com/developers/gitignore
You just have to be aware that if you clone someone else’s repository, those files won’t be there and you will need to copy them and .gitignore them. I ran into all sorts of problems when I first started with most of my branches broken, but I think it was because I branched my master before creating and .gitignoring the settings files in the master.