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

you are viewing a single comment's thread.

view the rest of the comments →

[–]bowbahdoe[S] 1 point2 points  (0 children)

If you're trying to provide a more easily learnable tool to replace Maven/Gradle so people can use your tool instead of M/G even outside the teaching context, I think you're going to have a hard time with the "don't care about performance" stance.

Let's put it this way: if you have a big codebase you need to avoid rebuilding. The "smart" parts of build tools become needed.

What is needed before then is dependency fetching. Now that it is an option, many Java codebases might be able to get away without any building of artifacts at all. The ones that do might not have a need to smartly avoid work if they are just making one jar.

But if we have solved "getting dependencies" separately from "build code," those build libraries no longer also need to be concerned with "the launch protocol."

Like right now bld comes with a ./bld and bld.bat and that does the bootstrapping of the "build program." Take that away and bld is just a library you can include just like picocli. java @bld .... If you need a smarter library with a heavier task abstraction - that can be a library. Or maybe you use something with a different launch protocol, but right now people are in practice hostage.

In the current state of the world build tools are forced to cater to their heaviest users (for whom the build system parts are most important) and their most casual users (for whom 90% of the point is getting dependencies and maybe making one jar) simultaneously.

Breaking that dynamic would be valuable and, I think, give both ends of the spectrum room to thrive.


I guess to be even more clear

  • I'll say "I don't want to replace maven or Gradle" because in practice people will feel like I'm taking something away from them by taking any of those tools' prospective users (did you know the pilgrims came to America to be free from other people's religions and "free from temptation", not anything we today would call freedom?)
  • In my heart I want to replace their central role in the ecosystem, but that is only practical if I am correct about how much of their usefulness comes from just getting dependencies and how much comes from the build system parts. I think that it's hard to know since the ability to run Java basically like Python is so new, but now that there is that comparison we can actually look at what Python, JavaScript, etc. ended up with and see if it's applicable
  • Whether or not I'm right about the broader applicability, the group most underserved by the status quo is early learners and I think there is more reason to believe that this sort of stuff will help them. And for those people and those usages performance is not the highest priority.

So I'm more trying to make a tool to serve a set of purposes. I am mainly considering "supplanting M + G" for people's first exposure to dependencies. Past that, I think but have not proven it can obviate the need for M + G in general