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.
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.
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.
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.
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.
Readit News
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.)
(my hate for new build tools https://javarants.com/why-your-new-jvm-build-tool-is-making-...)
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.
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.
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.
> 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.
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.
For simple projects it looks great. I'll give it a try.
Sure, but resolving and fetching transitive dependencies is part of that 10%.
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 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.
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.
https://github.com/Osiris-Team/1JPM/blob/main/pom.xml
You won't need that pom.xml though since 1JPM is only dependent on Java 8.
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.
Contributions are welcome and I am happy to work on this project.
I'm enjoying this approach. It can likely pull most of the Maven functionality needed for my (simple) projects.
Worked on transitive dependencies, and let me tell you, the version of such a dependency can be literally anywhere.
https://jeka-dev.github.io/jeka/tutorials/build-projects/#ex...
https://jeka.dev/