I would very much like to get these things done, and we are very close to achieving them, there’s just a little bit of work left, and they are all interconnected:
a) deploy the Vassal jar and also the source-jar and javadoc-jar as their own maven artifacts, there are several options where we could deploy it, we could even deploy them right there in the github repo and this would be enough for others (module designers) to use them as a dependency their pom.xml.
b) start using the maven clir plugin to test for API compatibility changes, for this we would need something to compare to, and the jar from a) would be the baseline. once this is established we would never again have to manually search for API compatibility changes in every PR, this would free up time for more important matters including all these Vassal NG plans
c) create a template maven project for module designers, this would also need a)
Right now all of this depends on a single step–making the jar it’s own build artifact, and there is a PR that does just that: github.com/vassalengine/vassal/pull/57
It is a somewhat bigger change, not as big as the switch to maven but it could still mean that development environments need to be setup again. I keep this PR merge-able as almost every commit to master introduces conflicts, but it’s somewhat tedious and since I don’t know when/if this will be accepted at all I am not sure whether it’s worth the trouble updating it every day.