Revamped build system -- Maven?

[apocalyptech]

My understanding is that ant is a somewhat deprecated system, or at least not really recommended by the wider Java community. Maven seems to be the way to go? Maven would also allow us to specify third-party libraries a little more sensibly, and avoid having the third-party libraries stored right in our git repo. It'd also be nice to be able to build+run from commandline a bit more easily, though technically I think I could fire off ant builds from the CLI already...

[apocalyptech]

Did a bit of searching on this, including this seemingly-helpful article which even talks Netbeans: https://blog.idrsolutions.com/convert-ant-based-netbeans-project-to-a-maven-project/

One downside of moving from ant -> maven is that it requires a different directory structure, so we'd end up with another big directory-move commit which would break historical diffing in annoying ways. I did that once when building up to v1.3.0, which I didn't mind much, but it'd be a shame to break it now that there's actual "live" history. So, we'll see. I may just shelve this idea for the time being.

[apocalyptech]

So yeah, not gonna be handling this for now. Will be keeping it open 'cause I would like to eventually do it, but laziness plus not wanting to make VCS history more messy is winning out.

[apocalyptech]

Well, ended up giving this a bit of a go, as we approach v1.4.0, but I'm going to once again kick it down the road. Getting the project as a whole migrated from ant -> Maven isn't too bad, really, but there's some edge cases I don't feel like fighting through.

A few things to note:

1. Netbeans will download the Maven central cache and unpack it for use. By default the download+unpack happens inside java.io.tmpdir, which defaults to /tmp. The problem there is that the whole process takes like 8GB, and my /tmp is only 4GB. Launching netbeans with -J-Djava.io.tmpdir=/usr/local/dv/.netbeans-tmp allows that process to finish up. Not entirely sure where it ends up after that, to be honest.
2. Maven's location for "resources" changes as well -- the app needs to get rid of references to /resources when pulling stuff out. Note that in some cases we do need a leading slash still, though.
3. Our "work dir" detection stuff might need some tweaking too, come to think of it, for when running in Netbeans. It looks like it might be all right, though -- prefs and stuff were being written out in the project root, as expected.
4. Updating dependencies seems annoying in Netbeans. You have to remove the old dependency entirely and add in the new version from "scratch." No idea why there isn't just a "change version" number in there.
5. Note that TestNG needs to be added in as an explicit dependency -- set it to a scope of test so it's not needed for ordinary usage.

The main thing causing me to kick this down the line is test handling. Running tests through Maven doesn't actually list out our dataProvider arguments for failures. See an old bug about it and a potential workaround @ stackexchange. I just don't feel like mucking with that stuff. As an example of what I mean, a Maven failure ends up looking like: testGetCompleteOverwriters Failed: lists don't have the same size whereas an ant failure looks like: blcmm.gui.tree.OverwriteCheckerNGTest.textGetCompleteOverwriters("Full after TPS specific add-to-array syntax", ...) Failed: lists don't have the same size

There's also the potential issue of generating the "fat" Jarfile which I want to keep using. It does look like there's support for that kind of thing in Maven, though that may involve making some concessions to how I want stuff; it looks like it might not be as flexible as my current ant stuff.

So, eh, kicking this down the line a bit more. It would be nice to get that auto-dependency stuff down, but it's feeling like too much of a hassle at the moment.