cstamas commented on code in PR #1391: URL: https://github.com/apache/maven/pull/1391#discussion_r1466221747
########## api/maven-api-core/src/main/java/org/apache/maven/api/Artifact.java: ########## @@ -105,6 +105,14 @@ default String key() { */ boolean isSnapshot(); + /** + * The artifact properties. + * + * @return the artifact properties, never {@code null} + */ + @Nonnull + ArtifactProperties getArtifactProperties(); Review Comment: > ...we already have some properties (is added to classpath etc) no? @rmannibucau That method is one of the main sources of confusion :smile: This is what happens: * Maven2 had `ArtifactHandler#isAddedToClasspath()` which meant exactly that: "is artifact to be added to classpath" as Maven2 was aware only of classpath, nothing else. * in Maven3 resolver came, and introduced this flag: https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactProperties.java#L54-L62 (note the javadoc nor any string literal **does not mention classpath or anything**). * In development of Maven3 early, at one point these two were "shortcut into one": https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/RepositoryUtils.java#L247-L268 * so essentially the "classpath" notion in core coming from Maven2 and "buildpath" abstraction, intentionally defined in Resolver as such (new in Maven3), was blurred to mean "same thing", which was obviously not the intent. Typical example: the POM packaging, see definition here: https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/impl/types/PomTypeProvider.java Long time ago, before BOMs were a thing, people used it to "group dependencies" (see for example this blog: https://blog.sonatype.com/2009/10/maven-tips-and-tricks-grouping-dependencies/). In essence, you create a POM that has your grouped dependencies and deploy that. So you have: ``` G:A:pom:V +- D1 +- D2 +- D3 ``` On consuming side, when you declare in your project dependency (yes, a dependency, not `import` as today you do with BOMs) like `G:A:pom:V`, hence as: ``` <dependency> <groupId>G</groupId> <artifactId>A</artifactId> <version>V</version> <type>pom</type> </dependency> ``` On resolving (for @gnodet collect+resolve) this project "compile" build path scope, assuming is the only dependency you have, you would end up with this list of artifacts: [D1, D2, D3] despite resolution started as `P` (root) where P had 1 dependency `G:A:pom:V`. Simply put, the Type definition (lack of "constitutes build path") causes that intermediate "grouping POM" be completely omitted (left out) from the results, as it is not part of the build path. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org