[HN Gopher] 1JPM: A Maven/Gradle alternative in a single Java file
___________________________________________________________________
1JPM: A Maven/Gradle alternative in a single Java file
Author : thunderbong
Score : 83 points
Date : 2024-07-08 15:45 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| invalidname wrote:
| How is it different from: https://rife2.com/bld
| spullara wrote:
| You don't need to install anything. Just include the Java file
| in your repository.
|
| "Install bld through Homebrew, SDKMAN!, JBang, ..."
| the_af wrote:
| 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.
| devman0 wrote:
| 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).
| pandemic_region wrote:
| > 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.
| the_af wrote:
| 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 ;)
| Tainnor wrote:
| 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).
| smallerfish wrote:
| 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.
| tasks.register("db-migrate", DatabaseSetup::class) {
| doLast { println("Now migrating")
| migrate() jooqGenerate() }
| }
| Tainnor wrote:
| 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).
| spullara wrote:
| 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-...)
| from-nibly wrote:
| 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.
| vips7L wrote:
| That is just Gradle. Maven works every single time.
| ethanol wrote:
| 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.
| brnt wrote:
| 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.
| vips7L wrote:
| 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.
| zmmmmm wrote:
| 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.
| zmmmmm wrote:
| 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.
| Tainnor wrote:
| 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.
| nogridbag wrote:
| 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.
| diffxx wrote:
| 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.
| Tainnor wrote:
| 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.
| abeppu wrote:
| 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
| jareds wrote:
| 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.
| brnt wrote:
| What's a popular Maven wrapper?
| svieira wrote:
| Maven: https://maven.apache.org/wrapper/
| systemerror wrote:
| I hate reading documentation too.
| sgammon wrote:
| This is cool. Even if we can't use it, it's cool to see
| innovation in Java build tools.
| mohaine wrote:
| 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.
| mvc wrote:
| Doing this does not preclude publishing that kind of metadata
| as part of the build/deploy process.
| andylynch wrote:
| Gradle is no different here. Ditto many other build tool.
| packetlost wrote:
| 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.
| znpy wrote:
| > 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.
| whartung wrote:
| 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.)
| bokchoi wrote:
| 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...
| hu3 wrote:
| I'm fascinated by one file solutions.
|
| Anyone have more examples?
___________________________________________________________________
(page generated 2024-07-08 23:00 UTC)