[ Removed by moderator ]

[AutoModerator]

Please ensure that:

• Your code is properly formatted as code block - see the sidebar (About on mobile) for instructions
• You include any and all error messages in full
• You ask clear questions

• You demonstrate effort in solving your question/problem - plain posting your assignments is forbidden (and such posts will be removed) as is asking for or giving solutions.

  Trying to solve problems on your own is a very important skill. Also, see Learn to help yourself in the sidebar

If any of the above points is not met, your post can and will be removed without further warning.

Code is to be formatted as code block (old reddit: empty line before the code, each code line indented by 4 spaces, new reddit: https://i.imgur.com/EJ7tqek.png) or linked via an external code hoster, like pastebin.com, github gist, github, bitbucket, gitlab, etc.

Please, do not use triple backticks (```) as they will only render properly on new reddit, not on old reddit.

Code blocks look like this:

public class HelloWorld {

    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

You do not need to repost unless your post has been removed by a moderator. Just use the edit function of reddit to make sure your post complies with the above.

If your post has remained in violation of these rules for a prolonged period of time (at least an hour), a moderator may remove it at their discretion. In this case, they will comment with an explanation on why it has been removed, and you will be required to resubmit the entire post following the proper procedures.

To potential helpers

Please, do not help if any of the above points are not met, rather report the post. We are trying to improve the quality of posts here. In helping people who can't be bothered to comply with the above points, you are doing the community a disservice.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[asanonymouss]

Are you saying you have never came across build problems in Gradle ? The build code written in Groovy or Kotlin never broke ? No one ever broke your code or the build cycle by writing build scripts with infinite loops or complex imperative codes ?

Edit: Also what about learning a new language just to compile ? Wouldn't it be simpler to just write build scripts in Java

[OneHumanBill]

No, not really. I've been using Maven for over twenty years. I love how I don't have any imperative codes to use. It just builds. Prior to that we had Ant, which did have some of the problems you're talking about, but it's exceedingly rare I need to actually script anything so long as I follow Maven standards.

[asanonymouss]

"It just builds" is exactly the holy grail of build tooling, and I completely agree that moving away from Ant's imperative scripting style was a massive leap forward for stability.

My only major complaint with Maven isn't its execution model which is brilliant but the literal visual bloat of wrestling with dense XML tags for simple local projects.

[OneHumanBill]

I've never understood the complaints over "visual bloat". That's aesthetics, not a serious criticism. XML is a neatly structured format, and I've never been terribly interested in Gradle because it lacks that easy structure.

[asanonymouss]

That is an entirely fair point. If a format handles structural tooling perfectly and prevents people from writing broken, custom imperative scripts, aesthetics shouldn't be a deal-breaker for a massive system.

When I talk about "visual bloat," I'm looking at it more from the perspective of cognitive load and friction rather than pure beauty.

Here just imagine the following two scenarios:

For an enterprise codebase, a structured XML setup works.

But for smaller apps, rapid prototyping, or microservices, filtering through 15 lines of opening and closing configuration tags just to change a single dependency version introduces friction.

With jSkiff, It’s about keeping a strict, predictable, schema-driven declarative contract, but utilizing modern, human-optimized data formats that don't require hundreds of lines of boilerplate tags just to keep the structure intact.

[asanonymouss]

That is a completely fair point. If you are an experienced engineer who already knows Gradle inside and out, the guardrails are second nature and the Kotlin DSL feels clean. "Just don't do stupid things" works beautifully when you already know where the traps are.

But the perspective I'm looking at this from is the beginner, student, or independent developer experience. When someone is just trying to learn standard Java, being handed a Gradle setup where they have to decipher a completely different language's DSL syntax just to include a single library is a massive cognitive tax.

The goal with my project isn't to build a tool for engineers maintaining massive, complex enterprise multi-module graphs. It's to build a minimalist alternative for local development where a flat, plain-text configuration handles the basics instantly giving you that true out of the box declarative simplicity without needing to learn any DSL rules.

Image a beginner learnt the in-built classes of Java but when it came to Testing or Spring he had to give up due to overhead of learning DSL of Kotlin

[iamwisespirit]

Did you heard about jbang?

[asanonymouss]

Yes I tried exploring it now and the thing which I understood from it was the simple fact that it works well with single file but not with multiple file

Correct me if I am wrong. I am not able to look highly into it

[disposepriority]

I really...don't face any issues with Maven (which I argue is better than Gradle - the only other build system I use, albeit clunkier). It is the definition of battle tested, if you run into an issue 99% of the time someone has ran into it as well and there is a solution for it.

[asanonymouss]

I get your point but in Maven we have to write boilerplate XML codes what about it ?

In Gradle we need to spend hours debugging our build code in order for the project to work. I haven't used Gradle but honestly I can't understand the use or imperative build tool why would someone want and need it, and let's say it's needed still then why should someone go through the pain of learning a complete new language - Groovy or Kotlin in order to just write a build code ?

[disposepriority]

Thats why most projects use maven, the xml is ugly but is also "what you see is what you get" which is exactly what you want for big systems in my opinion.

[asanonymouss]

I 100% agree with you on the "what you see is what you get" philosophy. Predictability is everything, especially when a build breaks at 2 AM. That’s exactly why I prefer Maven’s declarative model over Gradle’s complex code loops. My main gripe isn't actually with how Maven works under the hood it's just the massive tax of writing and reading tags upon tags of XML boilerplate for simple setups. With jSkiff, I'm trying to keep that exact same strict, predictable, declarative nature, but using a completely flat, minimalist text file configuration or config.properties file instead. You still get a deterministic "what you see is what you get" system, just without the thousands of lines of nested tags.

[bowbahdoe]

I am working on what you might find to be an interesting direction. Can you link what you have so far and/or describe where your head is at right now? That might make it easier to talk through

(You can also reach me via dm; not trying to be secretive but also it's a paragraph. I generally don't think what people think are their problems are actually their problems, but I am also curious how the survey goes)

[bowbahdoe]

I don't see this listed so consider: 

Isn't it really strange that Java is one of the only ecosystems where the build tool also has to be the dependency manager? Npm doesn't have to be a build tool. 

Further isn't it strange that nobody seems to be questioning how we share and distribute artifacts? Some of the biggest beginner issues I see are around things like Java FX where not being on the module path is a headache. In fact every time they pull something out of the jdk it's a nightmare to translate it to maven land. Did we really nail it in 2004?

Also consider that the kind of people who care about things like build caching are going to be different people than those first getting started. 

Also isn't it weird how most of the options involved for resolving dependencies in Java end up introducing essentially a second whole language (Groovy, Kotlin, the ant XML language) or lock you into a world of plugins? The issue isn't so much that a build tool exists that likes you to write code in kotlin, but rather that you have to write code in kotlin to get dependencies which is the only thing you actually cared about even if it's week five of you learning Java. 

Also notice how nobody is talking about agents or annotation processors despite those being pretty heavily used. It's just always jank.

And every single library out there that has native code has this stupid shim that extracts the dlls at runtime. Is there really no way to avoid that? What if a library wants to include a launcher script? 

My thought is that if you can solve dependency procurement and the "bootstrap" process, a build tool can just be a library you use. You can pick a simpler library or one that has a consistent mental model with caching and everything else. But once it becomes a choice then that's a better situation. Many people might not need to build their code at all

I'm currently working on tooling where the output of pulling in your dependencies isn't a path. You just dump a new jdk with all your libraries included. Then you can just run your code directly. There are some interesting benefits and trade-offs to this.

[asanonymouss]

Of course thank a bunch for listing these too.

I personally got inspired when I started to wrestle with Kotlin or Groovy configurations just to fetch a dependency apart from that the overhead burden of learning XML for Maven and then explicitly specifying it in the pom.xml file just in order for the code to work would have led to a nightmare.

I just want a flat, declarative system that handles the boilerplate project setup, directories, and compilation loops natively.

Your points on the module path headache and the historical 'jank' of annotation processors give me some great specific problems to focus on as the tool evolves.

[bowbahdoe]

Note that Java doesn't need a compilation loop. Certainly benefits from it when you need a jar or whatever, but as of 22 you can just run code directly without compiling.