Choose build system

[ghost]

Quoting this blog (which I find myself largely agreeing with):

JVM ecosystem is dominated with three build tools:

• Apache Ant with Ivy
• Maven
• Gradle

Currently, ContentMine uses Maven, but the existence of bug #1 shows that ContentMine's expertise with Maven is lacking.

Is investing team time in learning Maven the best option, or would that time be better spent migrating to either Ant+Ivy or to Gradle? I don't have a strong opinion about this myself, but the question seemed worth asking.

Compared to Maven:

• No-one I have ever spoken with about JVM build systems, including @petermr, prefers Ant+Ivy. So, migrating from Maven to Ant+Ivy would probably be a bad idea.
• Praise of Gradle, by contrast, is easy to come by. It might be worth migrating ContentMine from Maven to Gradle.

Comments welcome!

Update: other potentially appealing build systems include:

• Bazel.

[tarrow]

Cool! I wouldn't object to a move to Gradle.
I think this question would probably be well answered by talking to people we know who have more java expertise. I think @jkbcm might know about this. We can also ask @jimdowning who is on our advisory board.

[jimdowning]

Haven't used gradle. The core of clojure uses maven, but most people use leiningen. An apparently balanced review for another data point: https://dzone.com/articles/maven-vs-gradle-one-year-later

Some thoughts rather than solid guidance.

First bear in mind that migrating a working build is yak shaving.

Is the problem that you don't have expertise in maven, or more fundamentally that you don't have expertise in build? If the latter, I'd stick to maven for now. If you know what you're doing, then it sounds like the tooling support is the crucial factor (or maybe how much multi-lang build you need to do), but sounds like gradle would be a better choice.

[jkbcm]

I have no previous buy-in to either Maven or Gradle (have used Ant and Eclipse). Peter and I agree that Ant is historical at this point.

Based on various experiences migrating teams to new build technology I think there are a few things worth considering (briefly!) first. These include but are not limited to: what is the migration path from Maven to Gradle (have Gradle factored this into their design and documentation), what is the learning curve for Gradle, are the timescales for current development milestones/deliverables going to be affected by migrating.

Not saying we shouldn't move, and could fit in with a phase of refactoring, but the issues are definitely not purely on the technology side.

[tarrow]

Is the problem that you don't have expertise in maven, or more fundamentally that you don't have expertise in build? If the latter, I'd stick to maven for now.

For me this describes the problem (but I'm not the one working with it right now). I don't know either gradle or maven well. I know a little maven though. This is a good point to consider the move but perhaps not at length.

IMHO unless there is a clear advantage to gradle (i.e. someone knows it really well or it has some features that would simplify building loads) moving is not worth it.

First bear in mind that migrating a working build is yak shaving.

Do you mean from wiktionary:

1. Any apparently useless activity which, by allowing you to overcome intermediate difficulties, allows you to solve a larger problem.
2. A less useful activity done consciously or subconsciously to procrastinate about a larger but more useful task.

[jimdowning]

I meant in the first sense, but you tell me :-)

[jkbcm]

I wasn't aware of the first sense, so good to clarify :)

I'm inclined to agree with this:

IMHO unless there is a clear advantage to gradle (i.e. someone knows it really well or it has some features that would simplify building loads) moving is not worth it.

for now at least, unless we can identify particular Gradle features we are affected by being without.

[petermr]

From our discussions yesterday I think the main issues are: * we are not completely up to speed with what we can do with Maven, but that it generally works * the problem is more between SNAPSHOTs and individual version numbers * We don't have an automatic versioner. * we are still finding the right balance between internal releases and client-facing releases. Assuming we take GROBID (which is Java) on board, it also uses Maven and Maven's project aggregation strategy so we pay a significant cost in moving away from that.

[ghost]

@jkbcm wrote:

[moving is not worth it] for now at least, unless we can identify particular Gradle features we are affected by being without.

The features that would make switching worthwhile IMO would be if Gradle has, compared to Maven,

• more comprehensible handling of dependencies of multi-module projects;
• better documentation;
• equal or better reliability & functionality in all other significant respects.

I do not know whether any of these features obtain. It would be useful to know if they do.

@petermr wrote:

From our discussions yesterday I think the main issues are:

• we are not completely up to speed with what we can do with Maven, but
  that it generally works
• the problem is more between SNAPSHOTs and individual version numbers
• We don't have an automatic versioner.
• we are still finding the right balance between internal releases and
  client-facing releases.

Yes, i.e. bug #1 .

Assuming we take GROBID (which is Java) on board, it also uses Maven and
Maven's project aggregation strategy so we pay a significant cost in moving
away from that.

Good point. To my mind that is a very strong reason to stick with Maven unless:

• GROBID stops using Maven; and
• the features above obtain.

I'm going to close this thread as resolved. This will stop it showing up as an open issue, but needn't prevent people continuing the discussion if they want to.

If for any reason the decision to use Maven needs to be revisited in the future, this thread should be reopened.