Standard Artifact Resolution API

[Ethan McCue]

> 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 <swpalmer at 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 <ethan at 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?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20220909/d9a9de64/attachment.htm>