rmannibucau commented on code in PR #913:
URL: https://github.com/apache/maven/pull/913#discussion_r1081652684
##########
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/MavenWorkspaceReader.java:
##########
@@ -28,4 +29,20 @@
public interface MavenWorkspaceReader extends WorkspaceReader {
Model findModel(Artifact artifact);
+
+ /**
+ * List all available artifacts this workspace repository manages.
+ *
+ * @return a stream of artifacts in no particular order
+ * @since 3.9.0
+ */
+ Stream<Artifact> listArtifacts();
Review Comment:
> Caching is not a concern of the API.
iterating and reitarating over the map on big project will be a topic IMHO
if these methods are useful.
> If I need to browse them twice (why?) I can again make a collection,
`I` is you in this PR? if so I agree, if the caller then no cause you can
get multiple callers and would mean your API is not relevant.
> there are literally no code except the I/O cases where it is recommended
huh, no. But anyway you can't assume the related API has no IO related.
> This is obviously not a decisions point, because then most of the time no
one would ever use streams as most of them "fit in memory".
Which is what is in most real not overkill/hype API ;).
> while a collection approach would require
this part is wrong, what you propose is to visit the whole stream and mutate
it whereas you can push back the filters and things like that in the actual
materialization stream (the impl) which is what is done at maven in general
(think scope filter for ex) and is more efficient on all the points you mention.
So ultimately, except the point we didn't understand each others, everything
converges to a collection it seems.
--
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
