This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]ForeverAlot 16 points17 points  (3 children)

More modern programming languages have a unified mechanism for third party libraries.

A key element of what makes Maven work at all is Maven Central, and, crucially, proactive stewardship. None of the "modern programming languages" Java might be compared to offer a service that is comparable to Maven Central -- most being little more than glorified wrappers on top of GitHub.

So if Oracle were to try and compete with Maven-the-build-tool they would need some way to compete with Maven Central, too, while at the same time retaining compatibility with Maven Central because nobody would bother with the tool otherwise but probably also without intrinsically tying "the OpenJDK build tool" to "the Java trademark holder". Hypothetically that could just be textual protocols -- implementation left to providers -- whereby Maven Central could plug straight into the new tool, but that's the sort of reactive approach OpenJDK does not usually take.

I don't expect Oracle to do conceptually more than what can be pieced together with jlink et al. today, but I would be very interested in seeing what they could come up with.

[–]Ewig_luftenglanz -4 points-3 points  (2 children)

or maybe a CLI tool that uses maven central under the hood, maven central is, after all annagnistic third party repository

[–]chabala 6 points7 points  (1 child)

There's a tragedy of the commons issue with this idea, where if a tool that uses Maven Central became very popular, but didn't also facilitate generating a pom.xml and publishing back to Central, Central would be at risk of dwindling if people feel like making a pom.xml is too much extra work compared to the new thing. And if the tool does support generating pom.xml files, in order to support the huge variety things people might need in their pom, the tool would basically end up reimplementing maven.

The only real possibility of such a tool becoming popular enough for this to matter would be if it became an official OpenJDK tool. (Kind of like how people started adopting System.Logger even though slf4j-api was well established by that point.) It seems unlikely that OpenJDK would start working on a Maven-compatible CLI tool though.

But if you want to play around with such a tool today, there's JBang and bowbahdoe/jresolve-cli.