Switch to a modern build system

[mountain]

If we want to change the the tool to a git-style command line tool

• mmj2 gui to invoke the GUI
• mmj2 verify to invoke the verification
• ...

How can we achieve this quickly?

I think the most convenient way is adopting argsparser libraries outside and connect the old https://github.com/digama0/mmj2/blob/master/src/mmj/util/BatchMMJ2.java or other source files.

But the obstacle here is the old build system. We need to switch to a modern build system, they can add dependencies easily, e.g.

• gradle: the most widely adopted
• maven: quite old but easier than ant
• bazal: from google
• lein: mostly used in clojure community

Mingli

[mountain]

issues #62 is related with this issue.

[digama0]

I'm not convinced that argument parsing requires a change to the build system. Plus the CLI you suggest doesn't cover all the use cases of RunParms files. Well, there is more to say but it's a separate issue from the build system.

I'm not opposed to changing the build system except that I will surely lose track of how to build the project unless there is some good quick start documentation and ideally a CI setup as well. I have no real opinions about which one to use, since I haven't done any Java development since Java 8 and this project is on life support.

[tirix]

Hi Mingli,

You seem to already have a build system using lein in mmj2e, that would probably be the easiest to use?

[mountain]

@tirix Let me consider how to setup a CI, that is the best way.

The problem of lein is that it involve the clojure code base which will make the jar fat.

@digama0 I understand what you said a life-long project, and prudent actions are proper.

[digama0]

I'm not a fan of adding clojure to the build dependencies. If I was writing this today I would probably use a shell script, but when I wrote the ant file I was still on windows, and a shell script might cause problems for people not on linux-ish systems.

I'm not sure what you mean by a life-long project. There isn't too much to the build process, but it's hard to find something that works in all environments.

[tirix]

FYI @digama0 , @mountain has started a project mmtk which wraps MMJ2 and has a clojure installer. This looks like a good solution!

[digama0]

@tirix Well I already stated my view on adding clojure to the build dependencies. For someone who is installing Java and mmj2 together this could easily double the amount of stuff to download, as well as the number of moving parts / things that can fail. To the extent possible I would like the build system to stay as simple as it can be; a whole separate project just for building this one sounds like way overkill.

[tirix]

I meant it's a good solution in the sense that it shall have no impact on this repository, which can remain minimal in terms of build requirements.

[mountain]

I investigate these build system today:

• gradle/bazal add some skeleton code
• maven required a directory structure by default, but only add one pom.xml
• lein only add one project.clj

If we only build by lein and dose not require the jar to be executable by java -jar, it looks like no clojure code will be mixed in. But if we required to build an uberjar with main option in project.clj, means the uberjar can be executable, clojure code is needed.

Another option is ant with ivy which are very old.

I still think dependency management is important for development, that is one factor I created this issue.
With momentum from the whole ecology, we can build tools faster.

Mingli

[digama0]

Note that mmj2 already has one dependency, a JSON parser library. Is there a reason you can't just use a similar method for other libraries you want to include? I don't think that "being old" is a strong argument against a build tool, especially if it's still in use and receiving updates today.

[mountain]

Yes, if we intend to keep thing complete and minimal, and don't want to involve too many functions, that is the correct choice. I agree...

[jvierling]

As of de57384 mmj2 can be built with maven. In particular, dependencies can now be managed via pom.xml.