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 >
