Okay so from what I can parse there are different streams of work here 1. The JDK could be well served by a "standard" build tool.
I don't think this is controversial, but I'm nowhere near qualified enough to say what the "right" choice is. Maybe it is just taking gradle, who knows. What I do posit, though, is that the problem space is underexplored. I will claim this is partially because things like dependency resolution have been out of reach of the kinds of low stakes amateur exploration that drives innovation. The Node ecosystem churns through a build system a season, but they are at least actively exploring options - y'know? Let's call this hypothetical tool "jproject". 2. The JDK has the power to standardize improvements to dependency metadata and resolution The gradle team has done what they think is a good extension of the classifier system. There is some other analogous work in the rust ecosystem around features that could be interesting to incorporate. Maybe even ABI-level tool enforced minimum semver bumps like Elm, where we make something similar to Scala's Tasty metadata. Of all the players in the ecosystem, the JDK probably has the most power to make a given answer "happen", and being comfortable that the right answer has been reached may or may not be a blocker for "jproject" being real. 3. A standard dependency resolution api In order to successfully drive improvements to dependency resolution the JDK needs a tool, but I don't think that needs to be dependent on either knowing the "best-path-forward" metadata or deciding on a JDK build tool. There is enough prior work in tools like coursier (https://get-coursier.io/), shrinkwrap resolver (https://github.com/shrinkwrap/resolver), maven aether ( https://maven.apache.org/aether.html), and tools deps ( https://github.com/clojure/tools.deps.alpha) to at least start to talk about what a "jresolve" cli tool or "java.util.resolve"' api could look like. (apologies if that is only mildly coherent) On Sat, Sep 10, 2022 at 12:19 PM Scott Palmer <swpal...@gmail.com> wrote: > After thinking about it a bit more, I agree that a canonical dependency > format wouldn’t be much good without the tool to go with it. In my > particular case, I have builds that incorporate native code and Java. I > use Gradle partly because it handles both (though it could do a better job > with C and cross-compiling), and also because it can handle complex build > logic for putting the pieces together. One thing I dislike about tools > such as Rusts’ cargo or Node’s npm, is that they seem to make the > assumption that my project is based on a single language. That’s one reason > I don’t use Maven - it assumes you have a vanilla Java project and is > painful to use for anything beyond that. Any tool integrated into the JDK > should be able to build the JDK itself, including all the native bits, and > dealing with the multiple platforms and conditions. There should be no > need for external scripts to hack it together and very few external tools. > E.g. a C/C++ compiler would be needed to b build the JDK, but not > bash/Cygwin. > > I’ve often thought, why don’t they just use Gradle for building the JDK? > It seems to me that it would be so much simpler (and faster), but I can > imagine the mess of build-logic history that would need to be untangled. > I haven’t looked into alternatives like Bazel, as Gradle is working well > for me, but in the design of any tool for the JDK all of these other tools > should be looked at. Perhaps in the end the JDK could simply settle on one > of the modern tools already available and integrate or endorse it? That to > me would make more sense than building yet another tool ( > https://xkcd.com/927/). For example, if the JDK were to adopt Gradle as > the tool to use to build the JDK, it could de-facto become the “JDK build > tool”. Other projects formerly part of the JDK, like JavaFX, are already > using Gradle (though not as effectively as they could). > > Anyway, that’s just my 2 cents on the subject. > > Regards, > > Scott > > > On Sep 9, 2022, at 1:31 PM, Ethan McCue <et...@mccue.dev> wrote: > > > We already have Ant+Ivy, Maven, Gradle and they have significantly > different philosophies such that agreeing on a single dependency management > tool may be too ambitious. > > Maybe it would be useful to dig into what those different philosophies are? > > > I suggest looking at what Gradle has done in this area. > > It would be a reasonable goal for Java to have a canonical format (like > Rust’s ‘cargo’ format) for external dependencies that addressed all the > issues and tools could use it and benefit from the potential cross-tool > compatibility. > > I don't disagree per-se, but without an actual tool the JDK doesn't > exactly have much leverage to drive adoption of whatever > dependency-metadata.[xml|json|toml|tar.gz] would address all the issues. It > also would still need to handle "the world as is" for published artifacts. > > > agreeing on a single dependency management tool may be too ambitious. > > Maybe, but an uncharitable combination of accepting both the statements > > "it's nearly impossible to write a modern application without external > dependencies" > > and > > "the jdk does not provide the ability to resolve external dependencies" > > is > > "it's nearly impossible to write a modern application with just the jdk" > > Which is at least a tad unfortunate. > > On Fri, Sep 9, 2022 at 12:22 PM Scott Palmer <swpal...@gmail.com> wrote: > >> I suggest looking at what Gradle has done in this area. For example they >> found that the POM format didn’t have information required to properly >> identify variants so they added additional metadata. (See: >> https://docs.gradle.org/current/userguide/variant_model.html) >> >> It would be a reasonable goal for Java to have a canonical format (like >> Rust’s ‘cargo’ format) for external dependencies that addressed all the >> issues and tools could use it and benefit from from the potential >> cross-tool compatibility. I think however that the focus would be on the >> repository format & metadata, not the tool. We already have Ant+Ivy, >> Maven, Gradle and they have significantly different philosophies such that >> agreeing on a single dependency management tool may be too ambitious. >> >> Scott >> >> >> On Sep 9, 2022, at 9:59 AM, Ethan McCue <et...@mccue.dev> wrote: >> >> This email is mostly to test the waters, I expect some hostility. >> >> Say, as a premise, that an API for resolving external dependencies was >> something that the JDK concerned itself with providing. >> >> I think the foundation for that is there - the POM v4 format is more or >> less around forever, maven style repositories aren't going anywhere, and >> it's nearly impossible to write a modern application without some degree of >> dependence on code that was written by other people. >> >> What properties would folks want from such an API? What blockers would >> there be (technical/social)? Any other initial thoughts? >> >> >> >
