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
