[
https://issues.apache.org/jira/browse/MNG-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678850#comment-17678850
]
ASF GitHub Bot commented on MNG-7630:
-------------------------------------
laeubi commented on code in PR #913:
URL: https://github.com/apache/maven/pull/913#discussion_r1081687942
##########
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:
> So ultimately, except the point we didn't understand each others,
everything converges to a collection it seems.
It does not, implementors are free to cache items internally in what ever
way they like, this must not be exposed as API, callers are also free to hold
their own copy in whatever type they seems fit their needs, this must not
exposed in the API. Collection return types on the other hand has major
drawbacks that need to be documented and mitigated streams do not have that are:
1. Carefully document if the returned collection is the property of the
caller or the callee
2. Carefully document if the returned collection is safe to be shared across
threads
3. Carefully document if the returned collection is safe to be cached
4. Carefully document if it is modifiable or not (just see recent bug in
3.8.6 ([MNG-7316](https://issues.apache.org/jira/browse/MNG-7316))
And yes I proposed the API and I designed the API and no one ever cared to
do so before so it was designed with what I have in mind here and like to use,
collections are not, especially not just for the sake "because we always did it
that way" or some strange assumtions, otherwhise all Maven methods need to
throw `Exception` and return AutoClosable objects because you "never can know".
Thats why we have API contracts and the Contract says that a Stream (with no
particular order) must be returned, it does not claim that the Stream must be
closed nor that it throws `IOException` so if *any* I/O is performed as part of
the implementation it is the fully responsibility of this hypothetical
implementation to take action that ensure appropriate closing of system
resources is performed and I/O problems are properly handled.
> Support listing of workspace models and implement upcomming interface methods
> -----------------------------------------------------------------------------
>
> Key: MNG-7630
> URL: https://issues.apache.org/jira/browse/MNG-7630
> Project: Maven
> Issue Type: Improvement
> Reporter: Christoph Läubrich
> Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-4, 4.0.0
>
>
> This is the Maven counterpart of MRESOLVER-307.
> As this will be most likely be released in resolver 2.0 only maven can still
> already have an implementation for the new methods to:
> - show how they would look like
> - if upgrading source is already prepared
> - Maven has an own extension of that interface that should have similar
> behaviour
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
