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] > >
