[GitHub] [maven-resolver] laeubi commented on pull request #230: MRESOLVER-307 - Support listing of workspace artifacts
laeubi commented on PR #230: URL: https://github.com/apache/maven-resolver/pull/230#issuecomment-1397943417 As @cstamas has explained, this might not be useful for resolver if it never has a need to call the API, so lets close this, probabbly some time later but it won't be hard to recover or re-implement it. -- 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
[GitHub] [maven-resolver] laeubi commented on pull request #230: MRESOLVER-307 - Support listing of workspace artifacts
laeubi commented on PR #230: URL: https://github.com/apache/maven-resolver/pull/230#issuecomment-1346120213 @cstamas I now adjusted the code, the only think left is that one might want to move the interface from `org.eclipse.aether.repository.WorkspaceReader` > `org.eclipse.aether.spi.repository.WorkspaceReader` but I don't know if this is sufficient. -- 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
[GitHub] [maven-resolver] laeubi commented on pull request #230: MRESOLVER-307 - Support listing of workspace artifacts
laeubi commented on PR #230: URL: https://github.com/apache/maven-resolver/pull/230#issuecomment-1346011941 > implement any newly added methods in support class, to retain source compatibility I still don'T get why this is considdered more "source compatible" than a default interface method because both seem only source compatible?!? But anyways so I would 1. add `noimplement` / `noextend` 2. add an `AbstractWorkspaceReaderClass` (?) 3. Wait for 2.0 ... -- 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
[GitHub] [maven-resolver] laeubi commented on pull request #230: MRESOLVER-307 - Support listing of workspace artifacts
laeubi commented on PR #230: URL: https://github.com/apache/maven-resolver/pull/230#issuecomment-1345995022 > allows us to introduce methods that would be otherwise breaking, and provide some default logic. I'm not really understand the difference to a default implemented interface method?!? > FORBIDS direct implementation At laest maven extends AND implements this interface, I think this will still be possible but "discouraged"? -- 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
[GitHub] [maven-resolver] laeubi commented on pull request #230: MRESOLVER-307 - Support listing of workspace artifacts
laeubi commented on PR #230: URL: https://github.com/apache/maven-resolver/pull/230#issuecomment-1345910655 > implements this class, but also Tycho, m2e Tycho/m2e is actually the reason I'd like to have such method :-) > so a LOT of breakage here... That's the question, do we really "break" anything? As it is a default implemented method, everything will compile as before and no one will really notice even though it is not 100% binary compatible. > Ideally, I'd make this in 2.0 of resolver, Is there actually any plan for 2.0 release anywhere soon or is it more "sometimes in the future"? Should I target another branch? If 2.x is the way to go I'll update this to not use a default method then, beside this do you think this can be done that way or are there any other concerns? > and would introduce "safety measures" like for the rest: iface directly should not be implemented, but provide a "support class"? What do you mean by "support class"? And how is it more safe than in interface? I think interfaces are more appropriate for this and are as safe as an (abstract) class? -- 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
[GitHub] [maven-resolver] laeubi commented on pull request #230: MRESOLVER-307 - Support listing of workspace artifacts
laeubi commented on PR #230: URL: https://github.com/apache/maven-resolver/pull/230#issuecomment-1345467776 @cstamas @olamy maybe you can take a look here? -- 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
