Self-executable jars though, that's an interesting idea. No reason why it can't work, zip archives are read from the end, you can put anything in the beginning, including "#!/usr/bin/java -jar"
Oh so actually, you can use a shebang, just without the .java extension and with the "--source" flag, it's specifically written out in that spec. I was doing my experiment wrong!
As much as I hate adding more build tools to the Java ecosystem this one is pretty interesting since it is entirely Java based and version controllable without any additional dependencies to install. Obviously this won't solve all build problems but its simplicity is attractive.
Maven and Gradle are entirely version controllable too.
I also don't understand how your comment isn't in direct contradiction to the link you posted (which is from 2013!). At any rate, that there is no innovation in Gradle respective to maven is demonstrably false - you don't have to like these innovations, but they're there.
While this looks cool, isn't using a full programming language to power your build the reason why builds become fragile? e.g. Maven just works because you're limited in what you can do.
I guess that makes sense, there are pros and cons to everything.
I'm trying to designing the API in such a way that power users as well as noobs can have fun with it, which is a challenging task.
There are some good points, but I disagree pretty strongly with some of the premises in your blog post. I ask this quite seriously: why should I care about the health of the jvm ecosystem? Unless I am oracle, how does that fit in with my personal or business goals?
I know definitively that for me, personally, the quality of my build tool significantly impacts my productivity. Maven does not meet my personal bar and if I needed to use java for whatever reason, I'm not making a sacrifice to the altar of the jvm ecosystem purity and subjecting myself to maven.
Even if you care about "the health of the ecosystem", a little bit of competition can help. If I'm not mistaken, the maven wrapper was a direct response to gradle introducing this feature first, for example, so the existence of gradle also made maven better.
Maven is the de facto standard for open source Java projects, and it still has a reserved seat at that table, but it falls short of what other build systems provide. For example, multi-module projects and incremental builds are more like bolted-on hacks in Maven 3 (I say this with great respect for the work put in by the maintainers). With rules_jvm_external, and other general usability improvements in recent years, Bazel is now quite easy to use. In a corporate context, I think Bazel is a better choice where Java is concerned. I do hope that Maven 4 will close the gap.
Ten years? Try one year. I've had massive problems upgrading Gradle between consecutive major versions despite always trying to stick to the rules (as I understand them) and never using deprecated or experimental features. Maven simply doesn't have these problems.
Search for Gradle discussions on HN if you're interested, the rough consensus of this site (if there is such a thing) seems to confirm my experience.
Funny, I'd've expected the opposite in the Java ecosystem. As someone entirely outside of it: why would one then use Gradle? Haven't seen a single positive post here yet.
Gradle makes it incredibly fast and easy to bootstrap a simple project. Then, it's extraordinarily flexible after that in how you can use Groovy to add custom logic into how your build works. There are a lot of things I like about it.
What I really hate though is that it's designed around a principle of everything happening 'magically' such that when something goes wrong it is nearly impossible to mechanistically understand what happened and how to fix it. It really leans into the most negative aspects of Groovy and amplifies them.
I usually try to gen out a graphviz dotfile of a “typical” Gradle project’s task dependency in an org to demonstrate to people how much magic happens under the hood. I often have to choose the smallest, simplest project or the graphviz engine will choke on the hundreds to thousands of nodes and dependencies used.
Just the default task dependency tree for a build.gradle/settings.grade. And sure, a default project might be pretty simple but add one or two plugins and it gets very unsimple very quickly. And no JVM project is using Gradle without leveraging at least a few plugins. At my last job I did this for a simple generic cron style service project (perhaps maybe 10-15 Java files, including tests) and still ended up with a task dependency tree of hundreds of nodes, due to the plugins.
Adding onto the things that other people said: Gradle is an extremely powerful build tool. It has three tiered caching (project wide, machine wide, remote, with fallbacks), complex DAG resolution, and in general is just really good at building jvm stuff. It can handle nearly every weird way that you could possibly dream of to structure your project. It’s generally not super buggy. It’s generally pretty fast if you know what you are doing. There are years and years of optimizations built into it. It is the tool to build enterprise jvm code. If you go to a jvm shop at an adult company that isn’t stuck in 2006, they are using Gradle.
The downside is that it is insanely complex, and nearly impenetrable for newbies. It’s also for the same reason pretty Perl-like (a “write-only” language)
I would also add that there isn’t too many players in its category of general build tools. Like, sure, you can have a go-specific build tool that is more ergonomic, but it chokes the instant you add a c dependency.
I guess there is only bazel and gradle that are on this level of capability, being able to compile polyglot code bases. Probably also cmake, but compared to that, gradle looks as if it was designed by God itself, even though it severely lacks in ergonomics.
Yeah, I’ll also add is that while Gradle is technically a generic build tool, in practice the ecosystem realistically only makes sense to use for JVM code. All of the JS, Docker, Python, other plugins have significant issues due to only being supported/maintained by a few people. As well as Gradle giving a lot of JVM based caching for tasks set up as part of vanilla Gradle, that aren’t set up in these other ecosystems.
I would argue Buildkit is also trying to be this kind of tool but is significantly less mature.
I strongly disagree. Gradle is extremely buggy where it matters the most. For instance, if I cancel a build part-way through and then run it again, gradle assumes that the in-progress JavaCompile task is completed, and proceeds to generate a Jar file containing resources but no classes. To fix this, I am forced to make useless changes, or clear my entire user-level gradle cache.
No, running `gradle clean` only cleans the project-level cache as far as I can tell. It leaves the user-level cache untouched (as far as the issue is concerned). Not sure about that flag you mention though. I'll have to look into that.
One of the main reasons for me is that incremental compilation is essentially broken on maven, which may matter on large enough projects and if you keep waiting for CI builds.
That, and the fact that anything slightly out of the ordinary that you'd want to do with maven requires a plugin - or, since most people won't bother, just extra scripts on top of maven, or no automation at all.
Gradle has faster builds due to the build daemon it uses and it has a better CLI interface. Starting a new project is just: gradle init. Some people use it just because XML == bad too.
If you think it’s like Ant, then you have absolutely zero understanding of gradle.
Only the config step is “turing-complete”, which outputs a build graph that is cached and used to do every further step, finding the tasks that need recompilation, etc.
"only the config step" - isn't that the only step users of gradle should be interested in?
If config is a code, then it makes it more complicated in the long run (people are people and will add complexity to it) - there is a reason why they work on declarative syntax.
The Gradle team seem to come from the school of developers that aggressively break backward compatibility as if it's a best practice. Cynically I always feel like it must give them a bump in consulting revenue each time, because it often feels gratuitous. They literally just seem to rename or shuffle things around for the fun of it. Plugins are especially brittle between versions, so I will spend hours trying to find a magic combo of gradle version, plugin version and java version that will work across a multi-project build.
After having worked with Gradle for many years, I think there is a lot packed into this statement:
> 1JPM is a comparatively new project, thus does not contain all the functionalities of the other major build tools like Maven and Gradle, however should provide the basic and most used functions.
Gradle can do an insane amount of things. I would be surprised if this tool is capable of even 5% what Gradle can do.
That being said, I actually see this as a feature. I think Gradle would actually be better if it could only do 10% of what it currently does. As is it’s so complex and powerful it’s tempting to pack all of your build logic into some impossible to understand and maintain Gradle configuration. Having a pure standalone Java file that people who are familiar with Java can work with seamlessly and is easily integrated with existing test suites is probably better in the long run. I’d rather see the “cruft” of build tooling lifted into a higher level of abstraction than the quasi DSL that is Gradle - IMO it’s too similar yet different to Java/Groovy/Scala that it’s too tempting to create an unmaintainable mess otherwise.
Or do some work to rid yourself of the logic in the build.
Fit the build process into the build tool, rather than try to contort the build tool to suit the project. After all, it's unlikely that the project is such a special snowflake that it needs custom build steps, rather than just rely on the standard build steps provided in maven.
It's not at all unlikely. Most large projects i've worked on have need some element of custom building. Generation of files, compiling native code, multiple separate test suites, etc. The Gradle developers didn't just add that flexibility because they felt like it, there's a genuine need that Maven does not meet.
i really fail to believe that tbh. Making a maven plugin, in the worst case, works.
The flexibility of gradle (or any other procedural build tools) is to make the project _easy_ to customize, which means the tool encourages it.
Maven deliberately forces _all_ builds to conform to their set of phases, and assign meaning to each phase. If you're coming in fresh to a project, it's easy to see what phases are being attached to, and guess what's being done without having to have intimate understanding of the actual work.
Yeah. I think it is tempting to overload Gradle however. It runs bash and can build oci images and call other languages, which is fine in theory, but in practice it turns out to be quite limiting and full of complex pitfalls. The best setups I’ve worked with let other tools build non JVM stuff and leave Gradle to compile and test the JVM stuff only, because that is what it is good at.
I feel that transitive dependency is convenient, but that's what makes your application fat.
Moreover, many of those transitive dependencies aren't actually needed (they might be needed for some obscure feature that you don't use). Good libraries might declare those dependencies as optional, but not always.
And almost all dependency conflicts arise from multi-level transitive dependency problems.
May be it's better to just instruct user which transitive dependencies he has to install and let him do the job.
I, myself, miss dumb simple java build tool which would to the very minimum of job. I'm happy to assist it when necessary. Maven is nightmare and Gradle is hell of a nightmare. I don't need that complexity for my projects but I have to pay the price. I often think to downgrade to Makefile or shell script.
> I, myself, miss dumb simple java build tool which would to the very minimum of job.
I did that in ~2007 with apache ant.
I barely understood the tool (have mercy, I was 15 at the time) and had cobbled up a very basic build.xml file. It did build and it did assemble a runnable jar file, given a classpath containing the dependency jars (i wasn't using many, like 1 or 2).
I still had to download the jars and manually place them in a sub-directory.
if you want a build tool that can be very dumb I'd say that ant is what you need.
It can be as dumb or as smart as you want it to be.
Yeah I wish I could say build tools are simple.
1JPM was until I had to deal with transitive dependencies.
The recursion going on there broke my mind quite a bit.
Have been working the last 2 days (and nights) on this.
It was a headache and it still doesn't feel like I implemented transitive dependencies correctly, but give 1JPM 1.0.3 a try.
This would have interested me before wrappers for Maven and Gradle became common. Now that you can check in wrappers and easily upgrade the build tool version I don't see this being worth while for general use. I could see it being useful in situations where you needed full code auditability of everything involved in the build process but I've never run into that requirement in my work.
Which would have been great if I found it earlier, since it allows you to use maven but write Java.
The only edge 1JPM has compared to that project is that auto-complete and even more advanced features of your IDE work with it, since you can also move your JPM.java file into ./src/main/java.
So given that its intended mode of use is to be copied into another project and modified ... when would this maven build file in it be used? Also, I don't see that the dependencies (e.g. their `jlib`) actually get used.
Isn't this the exact opposite of what you want security wise? To even read the most basic project metadata (project name, version, deps, ... ), you have to run arbitrary in project code. So you have to do a code review of the project file before you can even open the project in your IDE. Programmatic project scanning is right off the list.
At some level of complexity/edge-case-ey-ness you just need arbitrary execution to get things done. At some point you need to accept that that if you're pulling in a dependency, you trust the authors of that code enough to execute their code. That being said, getting project version, deps, etc. should be statically available for packages, but being computed from source isn't the worst thing IMO, though it's not what I would go with.
Haha glad to hear that!
But really don't at the moment, the project is really fresh and I published a early access release to see if there was even demand, and I guess there is!
Contributions are welcome and I am happy to work on this project.
Maven allows you to parse the project definition and understand its build definition without running arbitrary code, and you can configure it to only run signed code with a whitelist of keys.
does this still hold true if the project uses build plugins?
isn't this just an arbitrary distinction regarding complexity, because i can look at the gradle build script code and - theoretically - vet it in the same way i can vet the xml build file of a maven project. the main difference is just that the one's a relatively simple XML document and the other is a comparable more complex groovy or kotlin program.
> does this still hold true if the project uses build plugins?
Build plugins are the code I was thinking of, you can check the signatures of all the build plugins and whitelist only plugins signed with particular keys, or only specific versions of them. Of course some plugins allow executing arbitrary code, so you'd have to not whitelist those plugins, and if you whitelist keys then you have to trust the holders of those keys not to publish plugins that allow running arbitrary code. But that's reasonably practical, because most maven builds don't use that kind of plugin and maven culture is generally that plugins should only do one specific thing.
> isn't this just an arbitrary distinction regarding complexity, because i can look at the gradle build script code and - theoretically - vet it in the same way i can vet the xml build file of a maven project. the main difference is just that the one's a relatively simple XML document and the other is a comparable more complex groovy or kotlin program.
Theoretically you can't, because it's code in a Turing-complete programming language, and it's theoretically impossible to check any nontrivial property of general programs reliably, because you run into the halting problem.
More practically, it's very easy to safely e.g. pull out the list of dependencies of a Maven build, you just parse the XML (you can even use an XPath expression or something if you want). How would you even begin to do that for a Gradle build? You can't do anything with it until you've executed it as code (you can do a really awful hack like regex search for common patterns, but that's not going to be reliable), and once you've executed it as code it's game over.
(Of course if the maven build is using a plugin that adds extra undeclared dependencies then you'll miss those. But that's not a common thing in maven culture, and we've already said you'd need to check and whitelist plugins)
Maven has plugins for practically every conceivable use case - if I have to implement all that, this single Java file will become another giant file that will bring its own can of worms minus the advantages of the Maven ecosystem.
I love seeing small Java projects like this and I always enjoy reading through the code.
On build tools: I don't actually mind Maven: I use a proper editor that can read and understand an XSD schema. But if it weren't for that I'd totally understand why people dislike it!
To those who say that it's not a good idea to use a full programming language for your build scripts.
Gradle uses "a full programming language" and I hate it but I have to use it for Android projects. Debugging Gradle problems is as fun as you'd imagine. There's a lot of dark matter in your build scripts that you don't see but that influences what happens. And because Android tooling is a clusterfuck ever since the demise of Eclipse+ADT, any change you make to your build process runs the risk of the entire thing exploding in your face.
This one is at least fully predictable, self-contained and doesn't randomly download 150 MB of crap when you're on a slow coffee shop wifi. I'm gonna try it sometime.
> Gradle uses "a full programming language" and I hate it
Yep, that's exactly why you're much better off with Maven. Last I knew it was still possible to build Android apps with Maven, even if it's not the primary/recommended way.
Gradle uses a programming language to create a static build graph that can be analyzed and efficiently executed.
I agree that gradle is not the most user-friendly software out there, but I can only think of bazel that would be up for the task of building such a complex project as android, so it’s also a testament to its strength.
Happy to hear that!
1JPM is still pretty new and I expect there to be bugs, so if you have some free time and are interested in making this something usable feel free to contribute some day :)
As someone who doesn't dabble with Java too often, this looks nice. I do cross-platform mobile work from time to time and whenever I pick up Android I end up bashing my head against the wall with all the Maven/Gradle stuff. I'm sure it's intuitive when you're using it a ton but it always feels overcomplicated to me.
> Maven/Gradle stuff. I'm sure it's intuitive when you're using it a ton
Maven was okay, Gradle less so. It comes down to being opinionated or infinitely flexible, and being infinitely flexible means that Gradle can be infinitely complex if you have "one of those people" on your team.
Thats what 1JPM is also trying to prevent a bit, by leveraging the rigid structure of Java, or more accurately by proving an API that tries to satisfy noobs and power users.
> bld was created because we're not really interested in build tools. We use them because we have to, but we'd rather just get on with coding the real stuff.
no interest in build tools, so let's create our own. Baffling.
Never heard of bld before, but my read is that they were overwhelmed by the complexity of existing tools, and wanted one with minimal frills that doesn't get in the way and which looks like app code (as opposed to using a declarative language), so they wrote one. I suppose they wanted to "get it over with"... whether this is a pipe dream or not remains to be seen ;)
Build tools are complex because builds are complex. Of course, if you create a bespoke tool for your specific use case and then a bunch of other people use it but it doesn't really gain widespread adoption, you can keep stuff simple.
I'm not saying that there's not accidental complexity in current build tools and that a new build tool couldn't strike the balance better, but a rarely used build tool being simple doesn't really say much (and this much is true for almost any kind of software).
I'm not disputing anything you say, but my comment was aimed at explaining why someone who doesn't like dealing with build tools would want to write one.
I don't want to have to defend their choice or explain why build tools are often complex and cumbersome.
Sadly there's tons of code-based Java build tools, but possibly zero concise (toml/yaml- like) declarative build tools. If you're currently using Groovy or Kotlin scripts for building Java projects however, then Java build scripts are appealing.
I mostly like the Kotlin flavor of Gradle, but it still has some relatively simple workflows for which you need to deeply understand the execution model of Gradle. The ideal build tool would just work intuitively - i.e. would be geared towards developers rather than build tool nerds.
For example, I wanted a standalone database migration task that wouldn't be run by default. The magic for that is "doLast", which I don't think describes what it's actually doing particularly well.
The thing about gradle is that you need to understand its model first (especially that you're describing build steps, not executing them directly). After you do that, it's not that hard anymore, but I agree that it would be better if it was slightly more intuitive.
But then again, this is well explained in the docs, it's just that, sadly, today nobody has any time to read docs for the 5000 tools that we use anymore (which I can't fault individual engineers for).
His complaint is that it should have been something like "executeTask" or "doAction" or "lazyTask". Anything that implies something about the execution model of the task. Nobody really cares about the order of the actions within a single task most of the time.
In the example the DatabaseSetup is an existing task type that is registered under a new name. Since that has an action body, the doFirst and doLast append logic to run around that. Thus, after setting up the database it then runs a migration and code generator phase. The more straightforward way is to define a new task and use a dependsOn relationship.
val databaseSetup = tasks.register<DatabaseSetup>("databaseSetup")
tasks.register<GenerateJooq>("generateJooq") {
dependsOn(databaseSetup)
}
class GenerateJooq : DefaultTask() {
@TaskAction fun run() {
println("Now migrating")
migrate()
jooqGenerate()
}
}
It is more code to define the custom task, but then allows for adding command-line input options. The doFirst / doLast are script shortcuts for quick proof-of-concept projects, whereas custom tasks are preferred for maintainability of long-lived ones.
Its not really different. Except that bld seems to only support Java 17+,
whereass 1JPM support Java 8+ and there is still a lot of Java 8 projects out there I guess.
Another difference is also that 1JPM is a single file, which has its advantages and disantwages, checkout the README for more details.
I haven't been in the java ecosystem in a while, but when I was using Maven you could just download the portable version and run it, and towards the tail end you could just include a simple mvn build shim that would pull down the correct version of maven and run it in a portable way (I think this was an idea borrowed from Gradle).
Maven itself, afterall, was nothing more than a java application (as was Ant before it).
Haha yes, if the IDE isn't happy, I'm not happy.
But checkout the releases under github, there you can find the magical single JPM.java file you are looking for ;)
I like the clever use of the "java prog.java" style.
I don't know how many folks know, although its been there for a bit, that you no longer have to specifically compile single file java programs.
You can just run them with with "java prog.java".
(Honestly, I haven't used the technique myself, still old school -- even with silly small x.java tests and such. Muscle memory and all that.)
I do it a lot. These single-file programs can be called Java scripts when run without compilation.
Can you add a shebang line and have it truly be a script? I do self executing JARs with a bash stub/header all the time, but haven’t tried with this.
Sadly you can't, Java doesn't support comments starting with #
Self-executable jars though, that's an interesting idea. No reason why it can't work, zip archives are read from the end, you can put anything in the beginning, including "#!/usr/bin/java -jar"I believe you can use shebang since java 11 but you can't have the filename extension be .java.
It turns out you indeed can: https://news.ycombinator.com/item?id=40912444
this has worked since the beginning but i don't think many people know about it
For the self executing JAR, I normally add a bash/shell stub for the header that ends with
The rest of it sets up the environment (JAVA_OPTS, -Xmx, etc).How do you run a Java program without compilation?
It technically compiles it to memory before running it, but the point is that you don't have to invoke javac first. It's a relatively new feature.
Do you know for which Java version this first became available?
11: https://openjdk.org/jeps/330
Oh so actually, you can use a shebang, just without the .java extension and with the "--source" flag, it's specifically written out in that spec. I was doing my experiment wrong!
Awesome, thanks for sharing!
I wonder what could be done with Java script…
Sounds like a name that could have some success. Given that the logo for Java is a cup of coffee, maybe we could also call it "Coffee script".
though, in theory java has jshell for java-based shell scripts specifically
You can run multi-file source-code programs as of JDK 22: https://openjdk.org/jeps/458
As much as I hate adding more build tools to the Java ecosystem this one is pretty interesting since it is entirely Java based and version controllable without any additional dependencies to install. Obviously this won't solve all build problems but its simplicity is attractive.
(my hate for new build tools https://javarants.com/why-your-new-jvm-build-tool-is-making-...)
Maven and Gradle are entirely version controllable too.
I also don't understand how your comment isn't in direct contradiction to the link you posted (which is from 2013!). At any rate, that there is no innovation in Gradle respective to maven is demonstrably false - you don't have to like these innovations, but they're there.
While this looks cool, isn't using a full programming language to power your build the reason why builds become fragile? e.g. Maven just works because you're limited in what you can do.
I guess that makes sense, there are pros and cons to everything. I'm trying to designing the API in such a way that power users as well as noobs can have fun with it, which is a challenging task.
There are some good points, but I disagree pretty strongly with some of the premises in your blog post. I ask this quite seriously: why should I care about the health of the jvm ecosystem? Unless I am oracle, how does that fit in with my personal or business goals?
I know definitively that for me, personally, the quality of my build tool significantly impacts my productivity. Maven does not meet my personal bar and if I needed to use java for whatever reason, I'm not making a sacrifice to the altar of the jvm ecosystem purity and subjecting myself to maven.
Even if you care about "the health of the ecosystem", a little bit of competition can help. If I'm not mistaken, the maven wrapper was a direct response to gradle introducing this feature first, for example, so the existence of gradle also made maven better.
Maven is the de facto standard for open source Java projects, and it still has a reserved seat at that table, but it falls short of what other build systems provide. For example, multi-module projects and incremental builds are more like bolted-on hacks in Maven 3 (I say this with great respect for the work put in by the maintainers). With rules_jvm_external, and other general usability improvements in recent years, Bazel is now quite easy to use. In a corporate context, I think Bazel is a better choice where Java is concerned. I do hope that Maven 4 will close the gap.
My fear is upgrading/maintaining this long term. At my current company we have Gradle build files from 10 years ago and they are really fragile.
Ten years? Try one year. I've had massive problems upgrading Gradle between consecutive major versions despite always trying to stick to the rules (as I understand them) and never using deprecated or experimental features. Maven simply doesn't have these problems.
Search for Gradle discussions on HN if you're interested, the rough consensus of this site (if there is such a thing) seems to confirm my experience.
Funny, I'd've expected the opposite in the Java ecosystem. As someone entirely outside of it: why would one then use Gradle? Haven't seen a single positive post here yet.
Gradle makes it incredibly fast and easy to bootstrap a simple project. Then, it's extraordinarily flexible after that in how you can use Groovy to add custom logic into how your build works. There are a lot of things I like about it.
What I really hate though is that it's designed around a principle of everything happening 'magically' such that when something goes wrong it is nearly impossible to mechanistically understand what happened and how to fix it. It really leans into the most negative aspects of Groovy and amplifies them.
I usually try to gen out a graphviz dotfile of a “typical” Gradle project’s task dependency in an org to demonstrate to people how much magic happens under the hood. I often have to choose the smallest, simplest project or the graphviz engine will choke on the hundreds to thousands of nodes and dependencies used.
Aren’t you displaying each and every file? Like, gradle doesn’t have all that many tasks in a default java project.
Just the default task dependency tree for a build.gradle/settings.grade. And sure, a default project might be pretty simple but add one or two plugins and it gets very unsimple very quickly. And no JVM project is using Gradle without leveraging at least a few plugins. At my last job I did this for a simple generic cron style service project (perhaps maybe 10-15 Java files, including tests) and still ended up with a task dependency tree of hundreds of nodes, due to the plugins.
While I’m not a big kotlin fan, I do believe that using it as a config language is a good direction.
Adding onto the things that other people said: Gradle is an extremely powerful build tool. It has three tiered caching (project wide, machine wide, remote, with fallbacks), complex DAG resolution, and in general is just really good at building jvm stuff. It can handle nearly every weird way that you could possibly dream of to structure your project. It’s generally not super buggy. It’s generally pretty fast if you know what you are doing. There are years and years of optimizations built into it. It is the tool to build enterprise jvm code. If you go to a jvm shop at an adult company that isn’t stuck in 2006, they are using Gradle.
The downside is that it is insanely complex, and nearly impenetrable for newbies. It’s also for the same reason pretty Perl-like (a “write-only” language)
I would also add that there isn’t too many players in its category of general build tools. Like, sure, you can have a go-specific build tool that is more ergonomic, but it chokes the instant you add a c dependency.
I guess there is only bazel and gradle that are on this level of capability, being able to compile polyglot code bases. Probably also cmake, but compared to that, gradle looks as if it was designed by God itself, even though it severely lacks in ergonomics.
Yeah, I’ll also add is that while Gradle is technically a generic build tool, in practice the ecosystem realistically only makes sense to use for JVM code. All of the JS, Docker, Python, other plugins have significant issues due to only being supported/maintained by a few people. As well as Gradle giving a lot of JVM based caching for tasks set up as part of vanilla Gradle, that aren’t set up in these other ecosystems.
I would argue Buildkit is also trying to be this kind of tool but is significantly less mature.
I strongly disagree. Gradle is extremely buggy where it matters the most. For instance, if I cancel a build part-way through and then run it again, gradle assumes that the in-progress JavaCompile task is completed, and proceeds to generate a Jar file containing resources but no classes. To fix this, I am forced to make useless changes, or clear my entire user-level gradle cache.
Doesn’t clean build (or the flag to build the incremental cache again by force) solve this?
No, running `gradle clean` only cleans the project-level cache as far as I can tell. It leaves the user-level cache untouched (as far as the issue is concerned). Not sure about that flag you mention though. I'll have to look into that.
Running "clean build" should do the trick though, it will delete the ./build directory. Or do you mean the local maven repo?
Neither. The corrupted cache is in the user-level gradle cache directory, which is untouched by `gradle clean`.
One of the main reasons for me is that incremental compilation is essentially broken on maven, which may matter on large enough projects and if you keep waiting for CI builds.
That, and the fact that anything slightly out of the ordinary that you'd want to do with maven requires a plugin - or, since most people won't bother, just extra scripts on top of maven, or no automation at all.
Gradle has faster builds due to the build daemon it uses and it has a better CLI interface. Starting a new project is just: gradle init. Some people use it just because XML == bad too.
because it was new and shiny, people complained that maven doesnt allow arbitrary code to be executed in build, etc.
And now they end up with what Ant was like.
If you think it’s like Ant, then you have absolutely zero understanding of gradle.
Only the config step is “turing-complete”, which outputs a build graph that is cached and used to do every further step, finding the tasks that need recompilation, etc.
"only the config step" - isn't that the only step users of gradle should be interested in?
If config is a code, then it makes it more complicated in the long run (people are people and will add complexity to it) - there is a reason why they work on declarative syntax.
That is just Gradle. Maven works every single time.
The Gradle team seem to come from the school of developers that aggressively break backward compatibility as if it's a best practice. Cynically I always feel like it must give them a bump in consulting revenue each time, because it often feels gratuitous. They literally just seem to rename or shuffle things around for the fun of it. Plugins are especially brittle between versions, so I will spend hours trying to find a magic combo of gradle version, plugin version and java version that will work across a multi-project build.
Gradle breaks backwards compatibility almost every year. How do you end up with a ten year old gradle build file.
You add the gradle wrapper to your project. They upgrade gradle a lot, but one doesn't have to.
Thanks! Yeah, simplicity and ease of use are definitely selling points.
It doesn't handle transitive dependencies. So it's only a "Maven/Gradle alternative" to the extent that you don't need those. Enjoy!
After having worked with Gradle for many years, I think there is a lot packed into this statement:
> 1JPM is a comparatively new project, thus does not contain all the functionalities of the other major build tools like Maven and Gradle, however should provide the basic and most used functions.
Gradle can do an insane amount of things. I would be surprised if this tool is capable of even 5% what Gradle can do.
That being said, I actually see this as a feature. I think Gradle would actually be better if it could only do 10% of what it currently does. As is it’s so complex and powerful it’s tempting to pack all of your build logic into some impossible to understand and maintain Gradle configuration. Having a pure standalone Java file that people who are familiar with Java can work with seamlessly and is easily integrated with existing test suites is probably better in the long run. I’d rather see the “cruft” of build tooling lifted into a higher level of abstraction than the quasi DSL that is Gradle - IMO it’s too similar yet different to Java/Groovy/Scala that it’s too tempting to create an unmaintainable mess otherwise.
Or do some work to rid yourself of the logic in the build.
Fit the build process into the build tool, rather than try to contort the build tool to suit the project. After all, it's unlikely that the project is such a special snowflake that it needs custom build steps, rather than just rely on the standard build steps provided in maven.
It's not at all unlikely. Most large projects i've worked on have need some element of custom building. Generation of files, compiling native code, multiple separate test suites, etc. The Gradle developers didn't just add that flexibility because they felt like it, there's a genuine need that Maven does not meet.
> a genuine need that Maven does not meet.
i really fail to believe that tbh. Making a maven plugin, in the worst case, works.
The flexibility of gradle (or any other procedural build tools) is to make the project _easy_ to customize, which means the tool encourages it.
Maven deliberately forces _all_ builds to conform to their set of phases, and assign meaning to each phase. If you're coming in fresh to a project, it's easy to see what phases are being attached to, and guess what's being done without having to have intimate understanding of the actual work.
Yeah. I think it is tempting to overload Gradle however. It runs bash and can build oci images and call other languages, which is fine in theory, but in practice it turns out to be quite limiting and full of complex pitfalls. The best setups I’ve worked with let other tools build non JVM stuff and leave Gradle to compile and test the JVM stuff only, because that is what it is good at.
Yes, that is exactly what I see as advantage. We are writing Java code, makes easy to understand/configure and tailor what we want.
For simple projects it looks great. I'll give it a try.
> I think Gradle would actually be better if it could only do 10% of what it currently does.
Sure, but resolving and fetching transitive dependencies is part of that 10%.
100% agree, that is a table stakes feature of a JVM build tool.
And everything breaks with every release.
I feel that transitive dependency is convenient, but that's what makes your application fat.
Moreover, many of those transitive dependencies aren't actually needed (they might be needed for some obscure feature that you don't use). Good libraries might declare those dependencies as optional, but not always.
And almost all dependency conflicts arise from multi-level transitive dependency problems.
May be it's better to just instruct user which transitive dependencies he has to install and let him do the job.
I, myself, miss dumb simple java build tool which would to the very minimum of job. I'm happy to assist it when necessary. Maven is nightmare and Gradle is hell of a nightmare. I don't need that complexity for my projects but I have to pay the price. I often think to downgrade to Makefile or shell script.
> I, myself, miss dumb simple java build tool which would to the very minimum of job.
I did that in ~2007 with apache ant.
I barely understood the tool (have mercy, I was 15 at the time) and had cobbled up a very basic build.xml file. It did build and it did assemble a runnable jar file, given a classpath containing the dependency jars (i wasn't using many, like 1 or 2).
I still had to download the jars and manually place them in a sub-directory.
if you want a build tool that can be very dumb I'd say that ant is what you need.
It can be as dumb or as smart as you want it to be.
Yeah I wish I could say build tools are simple. 1JPM was until I had to deal with transitive dependencies. The recursion going on there broke my mind quite a bit.
Do the downgrade. And please report back how you like it.
Have been working the last 2 days (and nights) on this. It was a headache and it still doesn't feel like I implemented transitive dependencies correctly, but give 1JPM 1.0.3 a try.
Forgot to mention, its the "resolveDependencies" task.
This would have interested me before wrappers for Maven and Gradle became common. Now that you can check in wrappers and easily upgrade the build tool version I don't see this being worth while for general use. I could see it being useful in situations where you needed full code auditability of everything involved in the build process but I've never run into that requirement in my work.
Yeah, some kind people over Reddit also shared some nice repositiories like this one: https://github.com/takari/polyglot-maven
Which would have been great if I found it earlier, since it allows you to use maven but write Java.
The only edge 1JPM has compared to that project is that auto-complete and even more advanced features of your IDE work with it, since you can also move your JPM.java file into ./src/main/java.
What's a popular Maven wrapper?
Maven: https://maven.apache.org/wrapper/
So given that its intended mode of use is to be copied into another project and modified ... when would this maven build file in it be used? Also, I don't see that the dependencies (e.g. their `jlib`) actually get used.
https://github.com/Osiris-Team/1JPM/blob/main/pom.xml
Right now I am using Maven to build 1JPM, or more accurately be able to do things in my IDE.
You won't need that pom.xml though since 1JPM is only dependent on Java 8.
Isn't this the exact opposite of what you want security wise? To even read the most basic project metadata (project name, version, deps, ... ), you have to run arbitrary in project code. So you have to do a code review of the project file before you can even open the project in your IDE. Programmatic project scanning is right off the list.
At some level of complexity/edge-case-ey-ness you just need arbitrary execution to get things done. At some point you need to accept that that if you're pulling in a dependency, you trust the authors of that code enough to execute their code. That being said, getting project version, deps, etc. should be statically available for packages, but being computed from source isn't the worst thing IMO, though it's not what I would go with.
> Isn't this the exact opposite of what you want security wise?
Quite the opposite, I'd say? Everything needed is source controlled (and signed, if commits are signed).
Also, all the metadata can be queried by the ide (any ide) via an LSP. can you do that with the xml from maven/ant ?
I like this 1JPM so much I might adopt it for all my personal java projects.
Haha glad to hear that! But really don't at the moment, the project is really fresh and I published a early access release to see if there was even demand, and I guess there is!
Contributions are welcome and I am happy to work on this project.
Gradle is no different here. Ditto many other build tool.
But maven does not.
Maven plugins and extensions can execute arbitrary code, so you should still exercise care when running an untrusted maven project.
you mean because it's xml instead of executable code?
No, because it was designed that way - declarative.
You can have xml with code-like-structures, e.g. Ant
Doing this does not preclude publishing that kind of metadata as part of the build/deploy process.
All build systems allow arbitrary code execution at some point / layer. This isn't a real criticism or issue.
Maven allows you to parse the project definition and understand its build definition without running arbitrary code, and you can configure it to only run signed code with a whitelist of keys.
does this still hold true if the project uses build plugins?
isn't this just an arbitrary distinction regarding complexity, because i can look at the gradle build script code and - theoretically - vet it in the same way i can vet the xml build file of a maven project. the main difference is just that the one's a relatively simple XML document and the other is a comparable more complex groovy or kotlin program.
or am i missing something else?
> does this still hold true if the project uses build plugins?
Build plugins are the code I was thinking of, you can check the signatures of all the build plugins and whitelist only plugins signed with particular keys, or only specific versions of them. Of course some plugins allow executing arbitrary code, so you'd have to not whitelist those plugins, and if you whitelist keys then you have to trust the holders of those keys not to publish plugins that allow running arbitrary code. But that's reasonably practical, because most maven builds don't use that kind of plugin and maven culture is generally that plugins should only do one specific thing.
> isn't this just an arbitrary distinction regarding complexity, because i can look at the gradle build script code and - theoretically - vet it in the same way i can vet the xml build file of a maven project. the main difference is just that the one's a relatively simple XML document and the other is a comparable more complex groovy or kotlin program.
Theoretically you can't, because it's code in a Turing-complete programming language, and it's theoretically impossible to check any nontrivial property of general programs reliably, because you run into the halting problem.
More practically, it's very easy to safely e.g. pull out the list of dependencies of a Maven build, you just parse the XML (you can even use an XPath expression or something if you want). How would you even begin to do that for a Gradle build? You can't do anything with it until you've executed it as code (you can do a really awful hack like regex search for common patterns, but that's not going to be reliable), and once you've executed it as code it's game over.
(Of course if the maven build is using a plugin that adds extra undeclared dependencies then you'll miss those. But that's not a common thing in maven culture, and we've already said you'd need to check and whitelist plugins)
Maven has plugins for practically every conceivable use case - if I have to implement all that, this single Java file will become another giant file that will bring its own can of worms minus the advantages of the Maven ecosystem.
You can continue using Maven if that is your choice.
I'm enjoying this approach. It can likely pull most of the Maven functionality needed for my (simple) projects.
Yeah I don't think there is much that can be done against this. Its a complex topic and simple solutions are basically just a dream.
Worked on transitive dependencies, and let me tell you, the version of such a dependency can be literally anywhere.
There is also another similar tool for building projects with Java code
https://jeka-dev.github.io/jeka/tutorials/build-projects/#ex...
https://jeka.dev/
Interesting, I guess the focus there is more on scripting. For 1JPM the focus is more Maven/Gradle similarity with Java build file.
I love seeing small Java projects like this and I always enjoy reading through the code.
On build tools: I don't actually mind Maven: I use a proper editor that can read and understand an XSD schema. But if it weren't for that I'd totally understand why people dislike it!
To those who say that it's not a good idea to use a full programming language for your build scripts.
Gradle uses "a full programming language" and I hate it but I have to use it for Android projects. Debugging Gradle problems is as fun as you'd imagine. There's a lot of dark matter in your build scripts that you don't see but that influences what happens. And because Android tooling is a clusterfuck ever since the demise of Eclipse+ADT, any change you make to your build process runs the risk of the entire thing exploding in your face.
This one is at least fully predictable, self-contained and doesn't randomly download 150 MB of crap when you're on a slow coffee shop wifi. I'm gonna try it sometime.
> Gradle uses "a full programming language" and I hate it
Yep, that's exactly why you're much better off with Maven. Last I knew it was still possible to build Android apps with Maven, even if it's not the primary/recommended way.
Gradle uses a programming language to create a static build graph that can be analyzed and efficiently executed.
I agree that gradle is not the most user-friendly software out there, but I can only think of bazel that would be up for the task of building such a complex project as android, so it’s also a testament to its strength.
Happy to hear that! 1JPM is still pretty new and I expect there to be bugs, so if you have some free time and are interested in making this something usable feel free to contribute some day :)
You can quite easily get by with the standard JDK tools (javac, jlink, etc) + a tool for fetching dependencies, such as https://github.com/coursier/coursier or https://github.com/bowbahdoe/jresolve .
As someone who doesn't dabble with Java too often, this looks nice. I do cross-platform mobile work from time to time and whenever I pick up Android I end up bashing my head against the wall with all the Maven/Gradle stuff. I'm sure it's intuitive when you're using it a ton but it always feels overcomplicated to me.
> Maven/Gradle stuff. I'm sure it's intuitive when you're using it a ton
Maven was okay, Gradle less so. It comes down to being opinionated or infinitely flexible, and being infinitely flexible means that Gradle can be infinitely complex if you have "one of those people" on your team.
Gradle, in my opinion, was a bad move.
Thats what 1JPM is also trying to prevent a bit, by leveraging the rigid structure of Java, or more accurately by proving an API that tries to satisfy noobs and power users.
That would be nice. Thanks!
I remember seeing a single file "build.java" from Cliff Click a while ago. I wonder if he's still using that technique.
It took a while to find an example:
https://github.com/edwardw/high-scale-java-lib/blob/master/b...
Wow 14 years ago! Thats great!
Those variable names are madness though haha. Or a single letter class is also pretty wild.
How is it different from: https://rife2.com/bld
> bld was created because we're not really interested in build tools. We use them because we have to, but we'd rather just get on with coding the real stuff.
no interest in build tools, so let's create our own. Baffling.
Never heard of bld before, but my read is that they were overwhelmed by the complexity of existing tools, and wanted one with minimal frills that doesn't get in the way and which looks like app code (as opposed to using a declarative language), so they wrote one. I suppose they wanted to "get it over with"... whether this is a pipe dream or not remains to be seen ;)
Build tools are complex because builds are complex. Of course, if you create a bespoke tool for your specific use case and then a bunch of other people use it but it doesn't really gain widespread adoption, you can keep stuff simple.
I'm not saying that there's not accidental complexity in current build tools and that a new build tool couldn't strike the balance better, but a rarely used build tool being simple doesn't really say much (and this much is true for almost any kind of software).
I'm not disputing anything you say, but my comment was aimed at explaining why someone who doesn't like dealing with build tools would want to write one.
I don't want to have to defend their choice or explain why build tools are often complex and cumbersome.
Sadly there's tons of code-based Java build tools, but possibly zero concise (toml/yaml- like) declarative build tools. If you're currently using Groovy or Kotlin scripts for building Java projects however, then Java build scripts are appealing.
I mostly like the Kotlin flavor of Gradle, but it still has some relatively simple workflows for which you need to deeply understand the execution model of Gradle. The ideal build tool would just work intuitively - i.e. would be geared towards developers rather than build tool nerds.
For example, I wanted a standalone database migration task that wouldn't be run by default. The magic for that is "doLast", which I don't think describes what it's actually doing particularly well.
The thing about gradle is that you need to understand its model first (especially that you're describing build steps, not executing them directly). After you do that, it's not that hard anymore, but I agree that it would be better if it was slightly more intuitive.
But then again, this is well explained in the docs, it's just that, sadly, today nobody has any time to read docs for the 5000 tools that we use anymore (which I can't fault individual engineers for).
His complaint is that it should have been something like "executeTask" or "doAction" or "lazyTask". Anything that implies something about the execution model of the task. Nobody really cares about the order of the actions within a single task most of the time.
In the example the DatabaseSetup is an existing task type that is registered under a new name. Since that has an action body, the doFirst and doLast append logic to run around that. Thus, after setting up the database it then runs a migration and code generator phase. The more straightforward way is to define a new task and use a dependsOn relationship.
It is more code to define the custom task, but then allows for adding command-line input options. The doFirst / doLast are script shortcuts for quick proof-of-concept projects, whereas custom tasks are preferred for maintainability of long-lived ones.Its not really different. Except that bld seems to only support Java 17+, whereass 1JPM support Java 8+ and there is still a lot of Java 8 projects out there I guess.
Another difference is also that 1JPM is a single file, which has its advantages and disantwages, checkout the README for more details.
You don't need to install anything. Just include the Java file in your repository.
"Install bld through Homebrew, SDKMAN!, JBang, ..."
Those are just alternatives.
Literally the first option they list is to just download the jar and run it manually, because this tool truly doesn't need any installation.
I haven't been in the java ecosystem in a while, but when I was using Maven you could just download the portable version and run it, and towards the tail end you could just include a simple mvn build shim that would pull down the correct version of maven and run it in a portable way (I think this was an idea borrowed from Gradle).
Maven itself, afterall, was nothing more than a java application (as was Ant before it).
I hate reading documentation too.
Ah a fellow tab-autocomplete power user.
Oh I expected to see a Java project with a single Java file inside, glad to see it’s nested in 3 folder levels. Java never disappoints
Haha yes, if the IDE isn't happy, I'm not happy. But checkout the releases under github, there you can find the magical single JPM.java file you are looking for ;)
Nice, that’s refreshing!
I'm fascinated by one file solutions.
Anyone have more examples?
aappleby/hancho on github (a build system in python) was discussed here some time ago
Well, thanks for reposting from Reddit! Got way more attention over here than there.
This is cool. Even if we can't use it, it's cool to see innovation in Java build tools.
Yeah, however once there are IntelliJ IDEA and VSCode plugins for 1JPM and I actually add some test cases, it should be usable.
And then there's me, still preferring make + @argfiles like a madman :p
build systems logging libraries application frameworks
Every dev at some stage early in their career always thinks that they can create a better one.
I think 1JPM is a wild idea and could be better in the future, but it's hard to compete with 20 years of development at release.