Our great sponsors
-
rife2
Full-stack, no-declaration, framework to quickly and effortlessly create web applications with modern Java.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
Thanks for the suggestions, might be a good opportunity to contribute, adding support for anything new can be done through an extension, which is basically any jar that you want to add to the classpath. Typically you'd expose an operation that bld users that call from a command. Here's an example of an ANTLR4 extension: https://github.com/rife2/bld-antlr4
Yes, you can drop any lib in the `lib/bld` directory and use it at build time. You can also use bld's dependency resolution to download those libs if you would like to. Those can be any maven style dependency, so you can really pull in any available logic that you might need. If you want, you can package that up and use it everywhere you need it. This is an example we create to do ANTLR4 code generation for RIFE2 itself: https://github.com/rife2/bld-antlr4
I recently came across another build system and similar to gbevin the authors (the fusion auth guys) make a lot of there own tools and libs: Savant. However it has its own language.
On a related note I have been really liking the newer Java feature of being able to execute .java files directly. I have been using them frequently to execute what would normally be a Bash or Python script. I actually have a Java .java script that mimics some parts of the Maven release plugin and because Java speaks XML really well it was easier to implement it in Java than Bash or some other scripting language which makes me think /u/bowbahdoe point on including a JSON parser with the standard lib would be very useful.
I don't understand why the java community has this anti-innovation behaviour... Why invent planes when we have our good ol'reliable ships? Why invent cars when a horse is so affordable? Why bump java 8 to 17, try a new build system, a new log backend (yes, I heard the same when I was starting out penna)? This is a common pattern on the java community... Seems like we're conformed to an old standard that suffices... It's good enough...
Maven works marvellous with BOMs for the larger stacks like Quarkus - no need for manual dependency hell. Its gradle fast with mvnd. I'm just hard pressed to imagine projects spending so much time in build debugging these days.
Except that they're not, all the potential, maybe relevant parameters available to the entire project are. Go inside the base {} task is build.gradle.kts, press ctrl+space ... yay hundreds of potential things that could or could not be appropriate, Go inside the java {} task, same thing, anywhere really. Without opening the documentation on gradle.org, there's no way to know what is actually relevant. It doesn't stop there, some of these things only work in setup time, others only work during task execution time, on to the docs to find which ones are which, but the docs are not completely in that regard, on and on it goes.
Lets be specific. This is the gradle build file for Squares okhttp client library. How exactly would your bld tool "predict" or "help" with all the parameters needed? There is no need to be defensive. Replace those large build files with your own, show where your approach is better and then understanding will lead to better solutions.
An important point is that this kind of metadata often needs to be accessible from outside the build system itself. You need that for example in order to integration with renovate-bot or github's dependabot, to check your dependencies against CVEs, to build SBOMs and various other additional tasks that are not part of the build itself, but related to the build's metadata. This is all functionality I don't want to reimplement, I want to use what's already out there. And for that the build system needs to have some minimum amount of compatibility with existing standard metadata files like pom.xml or build.gradle
An important point is that this kind of metadata often needs to be accessible from outside the build system itself. You need that for example in order to integration with renovate-bot or github's dependabot, to check your dependencies against CVEs, to build SBOMs and various other additional tasks that are not part of the build itself, but related to the build's metadata. This is all functionality I don't want to reimplement, I want to use what's already out there. And for that the build system needs to have some minimum amount of compatibility with existing standard metadata files like pom.xml or build.gradle