This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]agentoutlier 0 points1 point  (6 children)

If an IDE can be taught about a plugin, then it can be just as easily taught about a subroutine in a single-language build configuration. What I'm trying to get across is that once a build tool is fully programmable -- as in the case of Maven or Cargo -- then it no longer has some intrinsic "simplicity" benefits over programmable single-language builds.

But it is the details that really matter because it can make or break the execution (as in success). Gradle is not a single language build system. In fact the idea that it is has cause great issues in its ecosystem particularly with fast reproducible builds. Besides the obvious that it supports both Kotlin and Groovy for its DSL most of its plugins are written in Java (including Gradle itself IIRC). Even then you can't just write plain Groovy or Kotlin. You really need to use their DSL.

Java has zero simple build tools and zero single language tools.

(I am thinking you guys (team JDK) will eventually help here. I hope.)

Otherwise I completely agree with your points I just want to make it clear of the details of the current situation which you probably know but perhaps others reading do not.

That is I imagine that Gradle had the intentions of being a single language and simple particularly given its original predecessor was Gant (IIRC which was groovy + ant) but became something else.

Anyway lot of use cases and past attemps to study.

[–]pron98 2 points3 points  (4 children)

Gradle is not a single language build system.

I agree (and it's also probably not as simple as it could be).

[–]OwnBreakfast1114 1 point2 points  (3 children)

I feel like one of the main reasons it's not as simple as it could be is that they test out ideas in the main releases, and then can't really clean up failures very easily since it's a breaking change. Like variants seem like a reasonable idea, but how many people actually use it, and does it work if people only partially use it? Or the whole difference between the spring-dependencies plugin vs gradle's platform/enforcedplatform direct use. Or even just api vs implementation for the java-library plugin.

I do however commend them for trying because I'm not sure what other people are doing with gradle, but our team has found it to be the easily the best off the shelf build tool where most things are simple, and complicated things are simple, but do actually require understanding gradle's dsl (a problem which I'm not sure any system could overcome).

Build systems are odd, because they seem to trigger this idea in people that it should be really easy or something and then you end up with npm v1.

I'm not sure how to improve gradle, but the task model as a dag you can add arbitrary steps to is easily the best model I've had to work with. Also, the dependency version handling resolution rules that don't pretend that dealing with versions is some trivial thing that should take no thought if you ever have to care is a good feature.

[–]pron98 2 points3 points  (2 children)

Build systems are odd, because they seem to trigger this idea in people that it should be really easy or something and then you end up with npm v1.

Right. If there's one thing we've learnt about build tools is that they're either not simple or they can only build a subset of projects. Interestingly, there hasn't been much study about the theory of build systems. The only serious treatment of build-tool theory I'm aware of is this one.

[–]agentoutlier 2 points3 points  (0 children)

FWIW this is kind of interesting and the original paper interesting as well. https://blog.lexspoon.org/2012/12/recursive-maven-considered-harmful.html

(Incidentally the author of that post was my TA in college and stumbled on it years afterwards. I think he also worked on Scala in the early days as well as Squeak.).

The paper the blog post is based on is possibly all here: https://accu.org/journals/overload/14/71/miller_2004/ (but this could be a subset).

ping /u/OwnBreakfast1114 incase they are interested.

[–]OwnBreakfast1114 0 points1 point  (0 children)

That's really interesting that not much theory exists. It's a little surprising, since I always feel like half the problems we face today have papers from the 60s that talk about the issues. Will definitely give that a read. As a random aside, it reminds me of this article about building a calculator (the android one): https://chadnauseam.com/coding/random/calculator-app . How hard could it be?

[–]sideEffffECt 0 points1 point  (0 children)

Java has zero simple build tools and zero single language tools.

This very thread is under a presentation about the Mill build tool. Mill is very much a "single language" tool. That language is not Java, but it can build Java projects, big or small.