<div dir="ltr">> 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.<br><br>Maybe it would be useful to dig into what those different philosophies are?<br><br>> I suggest looking at what Gradle has done in this area.<br>> 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. <br><br>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. <br><br>> agreeing on a single dependency management tool may be too ambitious.<br><br>Maybe, but an uncharitable combination of accepting both the statements<br><br>"it's nearly impossible to write a modern application without external dependencies"<br><br>and <br><br>"the jdk does not provide the ability to resolve external dependencies"<br><br>is <br><br>"it's nearly impossible to write a modern application with just the jdk"<br><br>Which is at least a tad unfortunate.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 9, 2022 at 12:22 PM Scott Palmer <<a href="mailto:swpalmer@gmail.com">swpalmer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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: <a href="https://docs.gradle.org/current/userguide/variant_model.html" target="_blank">https://docs.gradle.org/current/userguide/variant_model.html</a>)<br><div><br></div><div>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.</div><div><br></div><div>Scott</div><div><br></div><div><br><blockquote type="cite"><div>On Sep 9, 2022, at 9:59 AM, Ethan McCue <<a href="mailto:ethan@mccue.dev" target="_blank">ethan@mccue.dev</a>> wrote:</div><br><div><div dir="ltr">This email is mostly to test the waters, I expect some hostility.<br><br>Say, as a premise, that an API for resolving external dependencies was something that the JDK concerned itself with providing.<br><br>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.<br><br>What properties would folks want from such an API? What blockers would there be (technical/social)? Any other initial thoughts?<br></div>
</div></blockquote></div><br></div></blockquote></div>