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
