News for hackers. Stuff that matters.
Re:A Proposal for Package Versioning in Go by bhaak on Monday March 26, 2018 @01:56PM (#16680958)
For java, I would look at gradle, not maven.

Of course, gradle hooks into the whole maven ecosystem but that is one of its advantages. Everybody in Java land understands Maven packages but how you generate doesn't matter.

Re:A Proposal for Package Versioning in Go by nvarsj on Monday March 26, 2018 @04:43PM (#16682400)
Gradle degraded the dependency experience significantly from maven. Maven had a deterministic, sensible (and selectable) way of dealing with conflicts - gradle just defaults to "largest version wins". Similarly, gradle chucked the whole idea of being able to manage common sets of dependencies across multiple projects easily (the maven super pom). I mean, it's all programmable in gradle, but it pretty much ignored the excellent work maven had done except to use its repos.
Re:A Proposal for Package Versioning in Go by pjmlp on Monday March 26, 2018 @03:44PM (#16681835)
Android builds have renewed by love for Maven.

If it wasn't for Android, I wouldn't bother 1 second to learn Gradle.

But I guess Groovy needs some project to keep it alive, now that no one remebers the days JSF beans would be written in Groovy or JUGs were holding Grails talks month after month.

Re:A Proposal for Package Versioning in Go by kuschku on Monday March 26, 2018 @04:49PM (#16682458)
Don’t worry, Gradle is moving to kotlin for build scripts already. Groovy will soon be a (failed) thing of the past.
Re:A Proposal for Package Versioning in Go by vorg on Monday March 26, 2018 @03:49PM (#16681882)
Seems like every other site is converting its Gradle builds into Bazel.