Need help with pom.xml to divide Forge into modules

[Max mtg]

Forge has been developed as a single module application since the very beginning. That has some benefits of easy access to everything withing a single project, but as it grows in size some disadvantages do emerge:

[*] Dependencies needed for a certain part of code become avaliable projectwide, so it opens a potential for their misuse, like GUI calls in code that implements game effects or abilities.
[*] GUI classes may access just any class of game core, learn their state directly and call their methods. This kind of coupling is bad when it comes to multiplayer implementation (when client should really have only a projection of game state filled with the information the player is allowed to know according to game rules).
[*] Forge is built as a GUI application, so it's impossible to invoke it a command line tool to run a series of ai vs ai simulations. I would like to develop a console application for that purpose, but just cannot.

So, it seems evident to me that Forge should be cut into a few modules, like game engine and gui (2 for now. That is to be achieved by introducing a <modules> tag into root pom.xml, creating subfolders for each module with their own pom.xml that should point at their parent. Practically, there are some sections in current pom.xml that I don't know how to handle - from simple questions like "where to move the developer list" to most complicated ones, like "where to put the build script and how to make it include forge.core artifact".

That said, I am asking for help in arranging the maven project setup. The desired result is - forge split in two modules the gui-client one (containing all the current code) and another one (that is to be filled with code used by many applications, such as the 1st module, console app for tests & simulations or dedicated server)

[silly freak]

Hi! I'm not a Maven pro and probably won't be able to help too much, but I could give you some pointers here from my experience:

firstly, modules are mostly for building multiple projects at once. I haven't done much with modules, but having modules basically specifies that not only the projects itself, but also its modules are built. This does not imply that the modules are to be bundled in the application or anything, it just adds building them to the lifecycle.

things like developer list, SVN connection etc. could be moved into a parent POM. you can specify a dedicated POM for things shared by all projects. The packaging of the parent POM would likely be pom (the default is jar), i.e. building the artifact only makes its pom available to child projects. Parent POMs are also a common place to put dependency and plugin versions. using the <dependencyManagement> element, you can specify dependency versions and scopes without requiring them. A child project can use the dependency without specifying a version, and will use the version from the parent POM.

I don't have insight into what you mean by the build script, but my feeling is, into the artifact that's going to be the final executable. Right now, forge is *only* the executable, so I guess it should stay there. Forge has dependencies (I guess?) that are already incorporated into the jar, so bundling the forge.core artifact into the forge.gui artifact should work out of the box, as it's just another dependency, right?

One caveat I have for multiple projects: It's a little harder to develop. Usually, you take libraries as given and don't encounter too many bugs. So, you're mostly fine with always having the same dependency version, and only update every so often. However, as soon as you have two artifacts, and probably a parent POM, it becomes a little harder:

Let's say you're working on the GUI and encounter a bug in the core. After fixing it, you have to update the version of the core. To use the newer version in the GUI, you need to change the dependency version in the parent pom, then update the version number of the parent pom, then update the parent pom version referenced in the gui artifact, and update the version number of the gui artifact itself.

as I said, I'm not an expert. I'm pretty sure I'm not using the right best practices here. What I'm trying to say is: getting your structure for modules, parent poms, version management right is not trivial, so think about the expected development workflow and how the structure would aid it best.

[moomarc]

Max, you could also send jendave a PM. He did the initial maven implementation and, if I recall correctly, is a Maven specialist at work.

[silly freak]

oh, and the most important point: find a consensus in the team before radically restructuring the project

[jendave]

Hey Max,

I'd be willing to help. Forge is so large, it would benefit from being broken up into modules. Silly Freak is right in that getting the consensus is the most important thing. On my end, I'll start experimenting with an aggregate/module Maven setup to make sure the assembly stuff will work.

[Max mtg]

Thank you, Dave

The build and packaging process is the most complicated thing that prevented me from completing this task. And your help is much aprecciated.

This thread is certainly a good place to discuss the upcoming modules separation.

Speaking of objections there haven't been any by now.
Silly freak is wrong that changes in libraries require version change. At least, when I experimented in Eclipse with all modules loaded as projects into a single workspace I faced no issues like the problem he describes.

[drdev]

I've spent most of this release working on big changes to the way screens are set up and how we switch between them (using navigation tabs). I think it might be nice for each GUI screen to have its own module (Home, Deck Editor, Match, Bazaar), in addition to a more generic GUI framework module. The FScreen enum would live in the GUI framework module and be responsible for linking to the correct module based on the screen being shown, much as it does now. The nice thing is these modules would roughly correspond to the subfolders of forge.gui.

How doable do you think that would be? I'm still pretty new to Java programming, and I've never worked on a multi-module application before in Java.

[Max mtg]

I've spent most of this release working on big changes to the way screens are set up and how we switch between them (using navigation tabs). I think it might be nice for each GUI screen to have its own module (Home, Deck Editor, Match, Bazaar), in addition to a more generic GUI framework module. The FScreen enum would live in the GUI framework module and be responsible for linking to the correct module based on the screen being shown, much as it does now. The nice thing is these modules would roughly correspond to the subfolders of forge.gui.

What are the benfits of such separation?
All the gui screens use merely the same references and resources, have a common ancestor.

[drdev]

I've spent most of this release working on big changes to the way screens are set up and how we switch between them (using navigation tabs). I think it might be nice for each GUI screen to have its own module (Home, Deck Editor, Match, Bazaar), in addition to a more generic GUI framework module. The FScreen enum would live in the GUI framework module and be responsible for linking to the correct module based on the screen being shown, much as it does now. The nice thing is these modules would roughly correspond to the subfolders of forge.gui.

What are the benfits of such separation?
All the gui screens use merely the same references and resources, have a common ancestor.

I guess none then. Like I said, I'm not familiar with how modules work in Java. In that case, I assume the plan is to just have one module for the GUI?

[Max mtg]

I assume the plan is to just have one module for the GUI?

The first part of the plan is to separate game rules from swing application.
(And later on change the communication between these modules into something that could travel through the network and finally have the application run remotelly)

Another part of plan is to make a console application that will use the game rules to run ai-vs-ai simulations and host a dedicated server (after that 1st part is completed)

[ptx]

Like others have said, the main thing that's needed is a consensus about the "ideal" modules and dependencies for Forge.

From my current naïve point of view, a first attempt at defining such a basic structure would look like i{dot}imgur{dot}com/N2tBBfb.png (can't post the real link yet) :
Core : Basic entities representing cards, abilities, colors, players, zones, ...
Rules and cards : Actual rule and card implementation
Game : The basic engine for running a game, including an interface for player interaction
GUI : base GUI stuff
GameGUI : The game GUI, including the "human" implementation of the player interaction interface
AI : the AI implementation for that interface
Forge : The main GUI (for options, deckbuilding, setting up games, ...) and glue

Note: for the sake of keeping this simple, GUI, GameGUI, and Forge could be kept as a single GUI module, which would then have a dependency on both AI and Game

[silly freak]

What do you think will be the benefits of separating core, rules and game?

[ptx]

What do you think will be the benefits of separating core, rules and game?

Not much probably, but sometimes it is easy to get carried away when drawing diagrams

Separating the game module from the rest makes some sense :
The latter is basically just a straight implementation of the comprehensive rules and card details, merely our translation of what Richard Garfield and co invent. It changes a little bit with every new set they release (and of course also whenever we implement old stuff we didn't have yet). This is what allows you to look at a table, see the cards, and reason about what might happen next.
The game module, on the other hand, defines the interface for player interaction, and actually runs the game (construct initial game state, use rules module to figure out what happens next, continuously update the game state, inform the players, ask them for input, ...). This is essentially just a technical implementation detail, not directly based on anything WotC makes, it should (normally) not have to change every time a new set is released. This is what allows you to communicate with your opponent about what happens next, and to actually make it happen.
Though as you pointed out, even though it might make sense, it offers little benefit.

The case for core vs rules is even more flimsy.
The former will probably change less often than the latter.
If we ever end up separating out the deckbuilder from the rest of the gui, or introducing a custom card editor, those modules would not really need rules, only core (because that is where all the basic elements are defined).

I agree though, the benefits are small, and it's probably best to just keep them as 1 module. That'll be a lot easier to accomplish, while still allowing us to focus on the main task : separating game logic from gui logic.

[silly freak]

ok, I see. As I understand it, there is a distinction between "printed" cards" and cards in the forge; in my project I called those static model and game model. It might make sense to separate them, for potential deck editor, card database and collection management applications.

As for game vs rest, I can't see a clear distinction, as things like turn order, priority, winning and losing are also defined in the comprehensive rules. I don't really see the place where a game module would mediate to the player, as the rules are so specific on when and what players can do. setting up a game alone doesn't warrant its own module IMO. Maybe forge's architecture lends itself to such a separation, but I doubt it's worth the effort.

Anyway, that's just my two cents. I'm not active in forge, just giving my uninformed opinion. Maybe what I say doesn't even make sense for forge.

[Max mtg]

ok, I see. As I understand it, there is a distinction between "printed" cards" and cards in the forge; in my project I called those static model and game model. It might make sense to separate them, for potential deck editor, card database and collection management applications.

That's probably a fair suggestion, but for now I just don't think of that until we've untied gui from core.