I am thinking more and more about splitting up the code into two modules, and I think it would be a good idea. Would be glad to hear some feedback from you.
The idea is, if/once we implement the maven multi-module approach, to split up the code into two modules, “vassal-api” and “vassal-app”:
vassal-app would depend on vassal-api
vassal-api would be the module for module developers, they would put this as a dependency in their pom.xml and extend its classes
vassal-app would contain all the rest, all the code that module developers have nothing to do with and have no business extending, things like ModuleManager, Player and Editor classes come to mind, things like the Jabber implementation, the Wizard code under org.netbeans, probably the whole tree of classes that make up the module editor, various internals like the image tiling algorithm, audio playback, the bug reporting facility, the code that handles save files and logfiles (VASSAL.build package?), the veteran developers probably know many more core parts of Vassal that are integral to running Vassal but are of no interest for module development
This would be a mid-term project and would take some time to decide what goes in which module, the advantages that I see with this approach are:
a more modularized codebase would give us a cleaner code structure
module designers would not be confused with a huge API parts of which is not relevant to them
we could keep maintaining backward compatibility for the vassal-api module, but changing things in vassal-app would be much easier since no one but us would depend on it
If you are going to take the Java code base that seriously as an ongoing concern, then I think you should also start a library of classes that can be used and reused in modules. This would require a new category entity to be uploaded and somewhere to store the code. This would probably have to be an area of the git repository. This would finally put an end to people asking about how to upgrade or modify a module where the java code has been broken.
May be also do the same for Java stuff that is used in modules but not especially intended to be used in more than one module.
Even if it’s the worst spaghetti code, with the worst possible design decisions, but at the end of the day it’s a piece of software that gets its job done and makes many users happy. Wargaming companies link to Vassal modules on their websites. On Boardgamegeek Vassal seems to be widely known. Boardgame designers are well aware of Vassal modules assist in module development. The wiki page on Squad Leader and Advanced S.L. have references to Vassal. Why give it up? Also Java is not going anywhere in the near future, the exact same Vassal releases and modules we have now will run out of the box on computers that aren’t even invented today, like on this new Mac CPU architecture.
Compare this to the stone tools, us humans and our ancestors have worked over 3 million years to design them and improve them, and some kinds of stone tools like obsidian knives are used to this day, not to mention the modern hobbyist movements where people make stone tools for fun.
Or compare to ID’s Doom that came out in 1993, still has a strong community today, and one of its lead designers even made a whole new episode a couple years ago.
A hundred years from now people will still use stone tools, play the original Doom, let’s make sure they play Vassal as well!
I’m sorry! I think I triggered you. You seem to have missed my suggestion that try to we look after the Java code and binaries that are used in modules. But at the moment they do get lost.
Nono it’s all good, I have seen that one. I have already introduced several improvements concerning custom code in modules, we now have a dependency checker that helps finding out what exactly the modules depend on, on a field and method level. And the new maven setup will help with creating a module template to give module designers an easy start.
Library of classes for modules, sadly I don’t know that much about custom module code and have no idea whether there are common use cases for module code. Vassal itself is a library that can be used in modules. How would we even organize a library of module code, we would need to peek into every single module, see if there is code inside, decompile the code since I’m afraid in most cases the source is not included, then read and understand the code, figure out what it’s supposed to do, compare it to the code of other modules, find common cases and extract them into this class library. I’m afraid that’s a job for the module designers association, they would need to team up, work out what they commonly use in their modules, write up a set of core classes that all module designers are happy with, then maintain this library over the years.
The Vassal side could offer some very simple examples that could be used in modules but anything beyond that would end in a maintenance hell for the Vassal development team. The team’s time is better spent on improving Vassal itself and documenting its features, maintenance of a custom code library is a job for the module designers.
That’s probably true. But one could provide a space for module designers to share their custom solutions (documentation, .jar and source). The uploads would have to be moderated but beyond that it could be assumed that the custom module designers are policing this themselves.
Well it’s a good idea, this is probably a question for the module designers and for those who run this website/forum/wiki, what is the best way to organize this? Forum section? Wiki? With GitHub I’m not even sure, I am not a member of the central repository, I can only propose PRs.
My theory is that if vassal is open source, it follows that module designers should include in the module the source file as well as the binary file of stuff they make.
I do actually put the source in my module files. But note that even if you find a module where it’s missing you can easily decompile it using one of the free online tools, e.g. procyon or whatever. (javadecompilers.com/).
I can certainly imagine some upsides if there were a place in the vassal repo for custom module code. But then I’m not sure how to handle e.g. push requests for that – the only think workable would be if somehow each module author had a private little repo or piece-of-repo where they had push privileges, and then there were somehow a directory of these. Dunno.
say why don’t you borrow my jar file from such and such a module.
ask where can we find the source for such and such jar file.
There is an obvious need here but the website is not even setting aside a space to store such assets. Once it does that might create other problems, and I accept that some junk or broken stuff is likely to creep in. But there is an obvious need there that requires minimal steps to fulfil at a very basic level.
Also how hard would it be to modify the module upload process so that modules with custom java code were rejected unless they had the source as well (at least without some sort of special permission).
Maybe the module template on the wiki could be modified to have a space for the source code.
As a module custom-code maker I can’t think of anything wrong with that. Basically everything that “has an entry in the buildFile” should be in the api side, and I suppose some of their closely related classes might go there too for convenience.
The biggest “day to day annoyance” I tend to have when I’m researching/making custom code (or for that matter when I’m trying to track down a bug in Vassal) is actually finding things in the vast shattered directory-tree that is Vassal. But I’ve been gradually programming Slickedit w/ more convenient “flat tree” file-opens and automatic recursive-directory-searches which is improving my productivity. So the concern that I would have had, that bifurcating everything into another level of tree hierarchy would make things even harder to find, is probably not important when the entire thrust of my Editor/IDE environment has been to make the tree invisible to me.
That’s a really good idea. The wiki upload interface is already pretty robust, filtered, and moderated. And it’s already where I often put “demo” modules both for bugs and for new custom code I want to offer people. Rather than bollix up the Modules template I’d just suggest some related “Custom Code” template, and then it can mostly self-police like a normal wiki page.
I don’t see that anything really needs to be done.
The module template already has a files section. If a module developer is interested, they can easily upload a zipped source archive there, if they don’t want to include it in to their module.
No matter what you do, it is not going to force module developers to upload their source if they can’t be bothered.
The wiki is also a public document and any interested party is more than welcome to set up a ‘let’s share our useful widgets’ section that could include links to developers custom git repositories, I don’t think module custom source should be in the Vassal repository because it would require the mythical ‘someone’ to maintain it.
My theory is that if vassal is open source, it follows that module
designers should include in the module the source file as well as the
binary file of stuff they make.
So is mine but I guess that to actually enforce it, someone would have
to send a lawyer to have a talk with them.
I have also seen a website of a company that sells vassal modules, not
sure if that’s legit.
Our license is LGPL. It doesn’t require that custom module code be
open-source (though I would certainly encourage module designers writing
custom code to open-source it).
