search

ContentMine / meta

A repository in which to file and fix meta issues (issues affecting more than one ContentMine repo or project)
0 stars 0 forks source link

Choose build system #7

Closed ghost closed 7 years ago

ghost commented 7 years ago

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

JVM ecosystem is dominated with three build tools:

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:

Comments welcome!

Update: other potentially appealing build systems include:

tarrow commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

jkbcm commented 7 years ago

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 commented 7 years ago

From our discussions yesterday I think the main issues are:

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 commented 7 years ago

@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,

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:

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.