> 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? > > >
