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
