PR's opened, feel free to review or whatever. I'm fully expecting that they won't be merged as is
https://github.com/apache/maven-wagon/pull/67 https://github.com/apache/maven-resolver/pull/51 On Mon, May 18, 2020 at 6:18 PM Alex O'Ree <[email protected]> wrote: > roger that. All the changes i've made thus far should be non-breaking. > Hopefully. > > And some good news to report, I had some initial success late last night. > Tested on windows using the windows certificate store which is usually the > odd ball test case. I'll make some forks and branches and open a PR > shortly. I'm not super satisfied with it though. I feel that the code base > has probably 3 or 4 too many locations for storing the same information in > memory which i'm sure is due to evolutionary reasons. It'll be obvious in > the PRs > > On Sun, May 17, 2020 at 9:59 PM Olivier Lamy <[email protected]> wrote: > >> You may have to change some APIs >> Wagon is a very old API (back to when Maven2 was born... yup that's long >> time ago now :) ) >> so definitely it could be changed BUT we have to maintain a backward >> compat >> as much as we can.... >> >> On Mon, 18 May 2020 at 11:36, Alex O'Ree <[email protected]> wrote: >> >> > Cool. i'll keep hacking away when i have time. Looks like it'll have to >> > merged in order... >> > wagon >> > resolver >> > maven proper >> > >> > assuming i can get it to work >> > >> > >> > On Sun, May 17, 2020 at 8:15 PM Olivier Lamy <[email protected]> wrote: >> > >> > > Aether is now maven-resolver project so maintainers will look at your >> > > proposal :) >> > > >> > > On Mon, 18 May 2020 at 10:11 am, Alex O'Ree <[email protected]> >> wrote: >> > > >> > > > Well after a few different experiments with what i've describe >> above, >> > the >> > > > issue i'm having setting ensuring that setting.xml parameters get >> > passed >> > > > into wagon. Currently, it looks like i need to change both maven >> core, >> > > some >> > > > of the wagon based code and aether wagonTransporter. Hopefully >> aether >> > > > maintainers will be open to this >> > > > >> > > > >> > > > On Sun, May 17, 2020 at 5:47 PM Michael Osipov <[email protected] >> > >> > > > wrote: >> > > > >> > > > > It completely depends how Resolver is created and how/when a Wagon >> > > > > instance is created. If Resolver exists once during a Maven >> session >> > and >> > > > > hopefully Wagon only once, but I don't know. Another issue with >> the >> > > > > current code is that the client is never properly shut down. >> I.e.g, >> > no >> > > > > sockets are freed and the peer has to handle broken connections. >> > > > > >> > > > > M >> > > > > >> > > > > Am 2020-05-17 um 23:42 schrieb Olivier Lamy: >> > > > > > Oh Yes I agree the current API would need major (breaking?) >> > changes. >> > > > > > But openConnectionInternal creating client would not reuse http >> > > > > connection >> > > > > > (or you have another idea?) >> > > > > > It was a bit of hackish to have http connection pooling due to >> > > current >> > > > > > design but especially with https it saves some IO. >> > > > > > >> > > > > > >> > > > > > >> > > > > > On Mon, 18 May 2020 at 01:53, Michael Osipov < >> [email protected]> >> > > > > wrote: >> > > > > > >> > > > > >> Alex, I will get back to you in a couple of days because it is >> a >> > lot >> > > > of >> > > > > >> work. But already agree, the current approach in Wagon makes it >> > > > > >> impossible to hook in TLS mutual auth and >> > #openConnectionInternal() >> > > > must >> > > > > >> create the client upon call. >> > > > > >> >> > > > > >> M >> > > > > >> >> > > > > >> Am 2020-05-17 um 17:31 schrieb Alex O'Ree: >> > > > > >>> Pinging you back again on this. Adding support for this (i >> think) >> > > it >> > > > > >> going >> > > > > >>> to require some significant changes to the abstract http >> client >> > > wagon >> > > > > >>> class. Client certificate authentication, on a per endpoint >> > > > basis,would >> > > > > >>> require separate ssl socket factories, which is constructed >> > before >> > > > the >> > > > > >>> pooling http client connection manager. Having everything >> static >> > > > makes >> > > > > >> this >> > > > > >>> difficult to implement without potentially breaking any other >> > > plugin >> > > > > that >> > > > > >>> uses this class programmatically. Would perhaps changing >> > > > > >>> 'openConnectionInternal' be a better option for hooking this? >> > I.e. >> > > if >> > > > > we >> > > > > >>> have a user defined key/trust setup, make a new configuration >> > > within >> > > > > this >> > > > > >>> method, otherwise fallback to the default static pool? >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> On Mon, May 11, 2020 at 7:10 PM Alex O'Ree < >> [email protected]> >> > > > > wrote: >> > > > > >>> >> > > > > >>>> I did some work on this over the weekend. Maintaining >> backwards >> > > > > >>>> compatibility is going to be challenging due to the http >> > > connection >> > > > > pool >> > > > > >>>> being static. Since the http client now needs to be specific >> to >> > a >> > > > > >>>> repository or destination, i'm not sure if that configuration >> > will >> > > > > still >> > > > > >>>> work. Anyhow, i ended up down a rat role of trying to >> understand >> > > why >> > > > > >> some >> > > > > >>>> of the unit tests were failing and making it worse in the >> > process. >> > > > > >>>> >> > > > > >>>> On Wed, May 6, 2020 at 6:38 AM Michael Osipov < >> > > [email protected]> >> > > > > >> wrote: >> > > > > >>>> >> > > > > >>>>> Am 2020-05-05 um 22:03 schrieb Alex O'Ree: >> > > > > >>>>>> I was looking over the docs for the settings.xml file and >> > noted >> > > > that >> > > > > >> it >> > > > > >>>>>> looks like it's possible to access a nexus repository >> using a >> > > > client >> > > > > >>>>>> certificate of sorts. It's not clear the docs if a JKS can >> be >> > > used >> > > > > or >> > > > > >>>>> if it >> > > > > >>>>>> must be a ssh private key or what. >> > > > > >>>>>> >> > > > > >>>>>> http://maven.apache.org/settings.html#servers >> > > > > >>>>>> >> > > > > >>>>>> I wanted to confirm that the linked docs is still >> accurate? I >> > > > have a >> > > > > >> few >> > > > > >>>>>> different use cases and may need to reference a client cert >> > key >> > > > pair >> > > > > >> in >> > > > > >>>>> a >> > > > > >>>>>> JKS or perhaps from the windows certificate store for >> > > > authentication >> > > > > >> to >> > > > > >>>>> the >> > > > > >>>>>> nexus repository. Is still a supported configuration by >> > maven? I >> > > > > found >> > > > > >>>>> some >> > > > > >>>>>> references to support here: >> > > > > >>>>> https://issues.apache.org/jira/browse/MNG-1560 >> > > > > >>>>>> which references setting maven options for javax.net.ssl.* >> > > > settings. >> > > > > >>>>>> Considering the environment, i'll probably need to be able >> to >> > > > > specify >> > > > > >>>>> the >> > > > > >>>>>> key alias name too, just in case there's multiple >> certificates >> > > > > >>>>> available. >> > > > > >>>>>> >> > > > > >>>>> >> > > > > >>>>> MNG-5583. I have intentionally closed this one since no was >> > > willing >> > > > > to >> > > > > >>>>> work on it. If someone wants to work on it, I'd be happy to >> > > > discuss. >> > > > > >>>>> >> > > > > >>>> >> > > > > >>> >> > > > > >> >> > > > > >> >> > > > > >> >> > > --------------------------------------------------------------------- >> > > > > >> To unsubscribe, e-mail: [email protected] >> > > > > >> For additional commands, e-mail: [email protected] >> > > > > >> >> > > > > >> >> > > > > > >> > > > > >> > > > > >> > > > > >> --------------------------------------------------------------------- >> > > > > To unsubscribe, e-mail: [email protected] >> > > > > For additional commands, e-mail: [email protected] >> > > > > >> > > > > >> > > > >> > > -- >> > > Olivier Lamy >> > > http://twitter.com/olamy | http://linkedin.com/in/olamy >> > > >> > >> >> >> -- >> Olivier Lamy >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >
