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

Reply via email to