[MNG-8609] Dependency is not an Artifact #10626

Activity

1. jira-importer commented on May 27, 2025

   

   jira-importer

   on May 27, 2025

   Author

   More actions

   Guillaume Nodet commented

   This may be a semantic problem. When we talk about a project's dependencies, we usually talk about the actual artifacts, not the requirement. So difficulty is that the resolution of an artifact is, most of the time, nothing, unless the dependency constraint undergo conflict resolution or something like that.
   Anyway, I tried to make it more clear in the API by talking about "dependency coordinates", i.e. the requirement or constraint (expressed by a <dependency> xml element usually), and the resolved Dependency, which is the actual artifact pointer, and the DownloadedDependency when the artifact has actually been downloaded.

   The javadoc may certainly be enhanced on classes and package (https://github.com/apache/maven/blob/0710deb4fd9b132183597dbaed9734eeff621fa1/api/maven-api-core/src/main/java/org/apache/maven/api/package-info.java).
2. jira-importer commented on May 28, 2025

   

   jira-importer

   on May 28, 2025

   Author

   More actions

   Elliotte Rusty Harold commented

   I don't think it's only a documentation problem, though it is a documentation problem. Most docs, both Maven's own and third party's and most discussions, have been cavalier about the distinction between dependencies and artifacts. However after spending multiple years deep in the weeds of Maven dependency management, I am increasingly convinced that being very precise about this is absolutely critical to explaining and understanding how Maven works.

   Currently package-info says this and it does describe the current class inheritance structure. However I don't think that inheritance hierarchy is correct, and it does lead to confusion.

   * <p>{@link org.apache.maven.api.DependencyCoordinates} instances represent a dependency element in a POM.
   * A {@code DependencyCoordinates} extends {@code ArtifactCoordinates} with additional information about how
   * the artifact will be used: type, scope and obligation (whether the dependency is optional or mandatory).
   * The version and the obligation may not be defined precisely.</p>
   *
   * <p>{@link org.apache.maven.api.Dependency} instances represent artifacts in the repository
   * that are dependencies of the project.
   * They are created when <dfn>resolving</dfn> a {@code DependencyCoordinates}.
   * Resolving is the process that clarifies the obligation (optional or mandatory),
   * selects a particular version, and downloads the artifact into the local repository.</p>
   

   This is a classic example of is-a/has-a confusion in OO. It is true currently that {@link org.apache.maven.api.Dependency} instances represent artifacts in the repository. However, that shouldn't be the case. Instead something like "ResolvedDependency" should contain (not inherit from) an Artifact field.
3. jira-importer

   added

   bugSomething isn't workingSomething isn't working

   priority:blockerBlocks development and/or testing work, production could not runBlocks development and/or testing work, production could not run

   on Jul 7, 2025
4. sparsick

   marked [MNG-8609] Dependency is not an Artifact #9839 as a duplicate of this issue on Jul 8, 2025