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.