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 <ol...@apache.org> 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 <spyhunte...@gmail.com> 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 <ol...@apache.org> 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 <alexo...@apache.org> > 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 <micha...@apache.org> > > > > 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 < > micha...@apache.org> > > > > > 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 < > alexo...@apache.org> > > > > > 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 < > > > micha...@apache.org> > > > > > >> 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: users-unsubscr...@maven.apache.org > > > > > >> For additional commands, e-mail: users-h...@maven.apache.org > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > > > > > > > > -- > > > Olivier Lamy > > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > > > > > -- > Olivier Lamy > http://twitter.com/olamy | http://linkedin.com/in/olamy >
