You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by GitBox <gi...@apache.org> on 2021/05/07 19:53:12 UTC
[GitHub] [maven-resolver] cstamas opened a new pull request #106: [MRESOLVER-103] Move off from HttpClient deprecated classes
cstamas opened a new pull request #106:
URL: https://github.com/apache/maven-resolver/pull/106
Just refresh the codebase to latest 4.x classes of HttpClient.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on pull request #106: [MRESOLVER-103] Move off from HttpClient deprecated classes
Posted by GitBox <gi...@apache.org>.
michael-o commented on pull request #106:
URL: https://github.com/apache/maven-resolver/pull/106#issuecomment-834756720
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-resolver] slachiewicz commented on pull request #106: [MRESOLVER-103] Move off from HttpClient deprecated classes
Posted by GitBox <gi...@apache.org>.
slachiewicz commented on pull request #106:
URL: https://github.com/apache/maven-resolver/pull/106#issuecomment-834773585
Grr same situation like with abdoned artifact-transfer
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on pull request #106: [MRESOLVER-103] Move off from HttpClient deprecated classes
Posted by GitBox <gi...@apache.org>.
cstamas commented on pull request #106:
URL: https://github.com/apache/maven-resolver/pull/106#issuecomment-834780345
@slachiewicz sorry, I did not check _closed PRs_ 😄 Also, I checked now and I see you did the "credentials charset" and some other nice changes, so will "lift them". Thanks!
@michael-o am pretty much sure http transport is used in use cases like now on ML and see Laird Nelson's project https://github.com/microbean/microbean-maven-cdi/blob/master/pom.xml
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-resolver] cstamas closed pull request #106: [MRESOLVER-103] Move off from HttpClient deprecated classes
Posted by GitBox <gi...@apache.org>.
cstamas closed pull request #106:
URL: https://github.com/apache/maven-resolver/pull/106
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-resolver] cstamas edited a comment on pull request #106: [MRESOLVER-103] Move off from HttpClient deprecated classes
Posted by GitBox <gi...@apache.org>.
cstamas edited a comment on pull request #106:
URL: https://github.com/apache/maven-resolver/pull/106#issuecomment-834844351
Wagon in Maven (if you don't count maven-compat) is used ONLY indirectly, via resolver transport API -> resolver-transport-wagon -> Wagon. So it has indirection API on top of it and is adjusted to Resolver Transport API, so using it just adds "more moving parts". Moreover, as said above, Wagon was written for Maven 2, and it's API shows it's age, is archaic, clumsy, and many methods in Wagon exists ONLY to be unused, for example those for site publishing (that we gave up on). Furthermore, Wagon introduces many overlaps with Resolver and Maven itself (same problem stands with Resolver!): Maven spends cycles to adapt Maven Repository to Resolver Repository that adapts it to Wagon Repository (and so on, just a silly example, but again, is true).
Frankly, did not follow Wagon for 5-6 years, now tried to build it (could not), but did some stats: resolver-transport-http is 2k LOC and just a 41 kB JAR (contrast that to wagon-api alone, that is 6k LOC and makes 54 kB and you still have no transport). Am not quite sure people will be happy to pull Wagon into their projects (with all of it "whistle and bells"). Am not sure I would maintain in my free time 9k LOC (6k provider-api and 3k LOC http-shared+http) instead of 2k LOC (ok, this is gross simplification, but shows my point)?
Finally, as Resolver uses it's own API for transport, unsure is it wise to have yet-another-project that is "adapted" to given API, so more projects, more source lines, more git repositories, more releases (to wait for each other), and so on endlessly. We should radically lessen all these, the direction we should take is opposite: less projects (so less 72h waits for release), less git repositories, overall less LOC to maintain.
Maybe move remaining wagon bits (http, ssh) under resolver instead?
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-resolver] cstamas edited a comment on pull request #106: [MRESOLVER-103] Move off from HttpClient deprecated classes
Posted by GitBox <gi...@apache.org>.
cstamas edited a comment on pull request #106:
URL: https://github.com/apache/maven-resolver/pull/106#issuecomment-834844351
Wagon in Maven (if you don't count maven-compat) is used ONLY indirectly, via resolver transport API -> resolver-transport-wagon -> Wagon. So it has indirection API on top of it and is adjusted to Resolver Transport API, so using it just adds "more moving parts". Moreover, as said above, Wagon was written for Maven 2, and it's API shows it's age, is archaic, clumsy, and many methods in Wagon exists ONLY to be unused, for example those for site publishing (that we gave up on). Furthermore, Wagon introduces many overlaps with Resolver and Maven itself (same problem stands with Resolver!): Maven spends cycles to adapt Maven Repository to Resolver Repository that adapts it to Wagon Repository (and so on, just a silly example, but again, is true).
Frankly, did not follow Wagon for 5-6 years, now tried to build it (could not), but did some stats: resolver-transport-http is 2k LOC and just a 42 kB JAR (contrast that to wagon-api alone, that is 6k LOC and makes 54 kB and you still have no transport). Am not quite sure people will be happy to pull Wagon into their projects (with all of it "whistle and bells"). Am not sure I would maintain in my free time 9k LOC (6k provider-api and 3k LOC http-shared+http) instead of 2k LOC (ok, this is gross simplification, but shows my point)?
Finally, as Resolver uses it's own API for transport, unsure is it wise to have yet-another-project that is "adapted" to given API, so more projects, more source lines, more git repositories, more releases (to wait for each other), and so on endlessly. We should radically lessen all these, the direction we should take is opposite: less projects (so less 72h waits for release), less git repositories, overall less LOC to maintain.
Maybe move remaining wagon bits (http, ssh) under resolver instead?
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on pull request #106: [MRESOLVER-103] Move off from HttpClient deprecated classes
Posted by GitBox <gi...@apache.org>.
michael-o commented on pull request #106:
URL: https://github.com/apache/maven-resolver/pull/106#issuecomment-835221511
Moving Wagon bits into Resolver won't work for two reasons:
1. Other Maven components use Wagon too
2. I don't want to maintain the codebase twice.
We need to think how to solve this better. If you have idea how to skim Wagon, I am all years for version 4.0.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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on pull request #106: [MRESOLVER-103] Move off from HttpClient deprecated classes
Posted by GitBox <gi...@apache.org>.
cstamas commented on pull request #106:
URL: https://github.com/apache/maven-resolver/pull/106#issuecomment-834844351
Wagon in Maven (if you don't count maven-compat) is used ONLY indirectly, via resolver transport API -> resolver-transport-wagon -> Wagon. So it has indirection API on top of it and is adjusted to Resolver Transport API, so using it just adds "more moving parts". Moreover, as said above, Wagon was written for Maven 2, and it's API shows it's age, is archaic, clumsy, and many methods in Wagon exists ONLY to be unused, for example those for site publishing (that we gave up on). Furthermore, Wagon introduces many overlaps with Resolver and Maven itself (same problem stands with Resolver!): Maven spends cycles to adapt Maven Repository to Resolver Repository that adapts it to Wagon Repository (and so on, just a silly example, but again, is true).
Frankly, did not follow Wagon for 5-6 years, now tried to build it (could not), but did some stats: resolver-transport-http is 2k LOC and just a 42 kB JAR (contrast that to wagon-api alone, that is 6k LOC and makes 50 kB and you still have no transport). Am not quite sure people will be happy to pull Wagon into their projects (with all of it "whistle and bells"). Am not sure I would maintain in my free time 9k LOC (6k provider-api and 3k LOC http-shared+http) instead of 2k LOC (ok, this is gross simplification, but shows my point)?
Finally, as Resolver uses it's own API for transport, unsure is it wise to have yet-another-project that is "adapted" to given API, so more projects, more source lines, more git repositories, more releases (to wait for each other), and so on endlessly. We should radically lessen all these, the direction we should take is opposite: less projects (so less 72h waits for release), less git repositories, overall less LOC to maintain.
Maybe move remaining wagon bits (http, ssh) under resolver instead?
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on pull request #106: [MRESOLVER-103] Move off from HttpClient deprecated classes
Posted by GitBox <gi...@apache.org>.
michael-o commented on pull request #106:
URL: https://github.com/apache/maven-resolver/pull/106#issuecomment-834786918
>
>
> @slachiewicz sorry, I did not check _closed PRs_ 😄 Also, I checked now and I see you did the "credentials charset" and some other nice changes, so will "lift them". Thanks!
> @michael-o am pretty much sure http transport is used in use cases like now on ML and see Laird Nelson's project https://github.com/microbean/microbean-maven-cdi/blob/master/pom.xml
I absolutely don't doubt that they are used. What I am not convinced is to maintain another transport impl on top of HttpClient when Wagon HTTP Provider already does the same.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on pull request #106: [MRESOLVER-103] Move off from HttpClient deprecated classes
Posted by GitBox <gi...@apache.org>.
michael-o commented on pull request #106:
URL: https://github.com/apache/maven-resolver/pull/106#issuecomment-836822782
>
>
> @michael-o @slachiewicz I think this PR is not adding any code making us work more with it (is actually removes 100 LOC). So, IMO let's just merge this one and continue "where to go next" discussion elsewhere. Ok?
Go ahead, I trust you. Won't review.
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on pull request #106: [MRESOLVER-103] Move off from HttpClient deprecated classes
Posted by GitBox <gi...@apache.org>.
cstamas commented on pull request #106:
URL: https://github.com/apache/maven-resolver/pull/106#issuecomment-836680225
@michael-o @slachiewicz I think this PR is not adding any code making us work more with it (is actually removes 100 LOC). So, IMO let's just merge this one and continue "where to go next" discussion elsewhere. Ok?
--
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.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org