PR's opened, feel free to review or whatever. I'm fully expecting that they
won't be merged as is
https://github.com/apache/maven-wagon/pull/67
https://github.com/apache/maven-resolver/pull/51
On Mon, May 18, 2020 at 6:18 PM Alex O'Ree wrote:
> roger that. All the changes i've made thus far
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
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 wrote:
> Cool. i'll keep
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 wrote:
> Aether is now maven-resolver project so maintainers will look at your
> proposal :)
>
> On
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 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
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
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
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.
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
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
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
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.
> Gesendet: Dienstag, 05. Mai 2020 um 22:03 Uhr
> Von: "Alex O'Ree"
> An: "Maven Users List"
> Betreff: Accessing a nexus repository requiring a client certificate
>
> I was looking over the docs for the settings.xml file and noted that it
> looks like i
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
14 matches
Mail list logo
