Standard Artifact Resolution API
Ethan McCue
ethan at mccue.dev
Fri Sep 9 17:31:27 UTC 2022
> 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>
More information about the core-libs-dev
mailing list