[ANN] Maven Resolver 1.9.5 Released

2023-02-23 Thread Tamás Cservenák 
The Apache Maven team is pleased to announce the release of the
Maven Resolver 1.9.5

https://maven.apache.org/resolver/

Release Notes - Maven Resolver - Version 1.9.5

** Bug
* [MRESOLVER-314] - Getting "IllegalArgumentException: Comparison
method violates its general contract!"
* [MRESOLVER-316] - DF collector enters endless loop when collecting
org.webjars.npm:musquette:1.1.1
** New Feature
* [MRESOLVER-32] - Support parallel artifact/metadata uploads
* [MRESOLVER-319] - Support parallel deploy
** Improvement
* [MRESOLVER-287] - Get rid of deprecated finalize methods
* [MRESOLVER-317] - Improvements for BF collector
* [MRESOLVER-318] - Cleanup redundant code and centralize executor
handling
** Task
* [MRESOLVER-320] - Investigate slower resolving speeds as reported by
users

Have fun,
-The Apache Maven team

Re: maven-surefire-plugin add artifact as additionalClasspathElement

2023-02-23 Thread Alexander Kriegisch 
Would you not rather write a Maven plugin or extension for something
like that and hook it into the build process globally, so you can use it
when specifying `repository` or `pluginReporitory` entries in the POM
needing it? This does not seem to be something limited to certain
plugins, if I understand correctly.

Alexander Kriegisch
https://scrum-master.de


Stephane Passignat schrieb am 22.02.2023 um 11:27:
> Hello,
> 
> thank you everyone for these suggestions. Let's go back to my original 
> issue.
> 
> I need to add a library to maven classpath. The library I need is 
> another RepositoryLayoutFactory, to download artifact located is a 
> repository which is not yet supported by Maven. Actually it's a basic 
> HTTP server. (It could be an FTP server or a database accessed is JDBC...)
> 
> The library is made, it works (as well as I need), but to use it I need 
> to add it to maven/lib/ext which is not portable to other computer. So 
> I'm looking at alternatives. Surefire could be a candidate, or not...
> 
> 
> I hope this helps to understand.
> 
> regards,
> 
> 
> Stephane
> 
> 
> Le 2023-02-16 à 11:58, Olivier Lamy a écrit :
>> On Thu, 16 Feb 2023 at 20:52, Olivier Lamy  wrote:
>>> On Thu, 16 Feb 2023 at 20:07, Delany  wrote:
 Hi Stephane,

 You can do like this

  
maven-surefire-plugin
3.0.0-M9

  
org.apache.commons
commons-email
1.5
  

  
>>> this will add dependencies to the surefire plugin itself.
>>> I guess Stephane wants to add to the jvm running the tests?
>>>
>>> additionalClasspathElement expect a full path to a directory or a file
>>> to be added to the classpath
>>>
>>> should work with something such but you need to assume commons-email
>>> has been resolved locally as a dependency.
>>> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
>>>
>>> another solution is to use dependency:copy to copy the commons-email
>>> dependency somewhere in ./target and use this path (see
>>> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)
>>>
>> a real example here :)
>> https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
>>
>>> hth
>>> Olivier
>>>
 On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
 wrote:

> Hello,
>
> Is it possible to add a maven artifact as an additionalClasspathElement ?
>
> I tried this syntax, inspired by the exclusion mechanism, but it's not
> working.
>
> 
>  
> 
>org.apache.maven.plugins
>maven-surefire-plugin
>3.0.0-M9
>
>   
>
> org.apache.commons:commons-email:1.5
>   
>
> 
>  
> 
>
>
> thank you
>
> Stéphane
>
>> -
>> To unsubscribe, e-mail:users-unsubscr...@maven.apache.org
>> For additional commands, e-mail:users-h...@maven.apache.org
>>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: maven-surefire-plugin add artifact as additionalClasspathElement

2023-02-23 Thread Tamás Cservenák 
Stephane,

"I need to add a library to maven classpath" -> you declare it as a
dependency, or I don't get quite the problem (looking at your last but also
first mail)
You can declare the artifact as project dependency (POM/dependencies) or as
plugin dependency (surefire/dependency), which one is the one you want?

To make maven able to use your new layout, did you try ,mvn/extensions.xml ?
https://maven.apache.org/guides/mini/guide-using-extensions.html

HTH
Tamas


On Wed, Feb 22, 2023 at 11:12 PM Stephane Passignat 
wrote:

> Hello,
>
> thank you everyone for these suggestions. Let's go back to my original
> issue.
>
> I need to add a library to maven classpath. The library I need is
> another RepositoryLayoutFactory, to download artifact located is a
> repository which is not yet supported by Maven. Actually it's a basic
> HTTP server. (It could be an FTP server or a database accessed is JDBC...)
>
> The library is made, it works (as well as I need), but to use it I need
> to add it to maven/lib/ext which is not portable to other computer. So
> I'm looking at alternatives. Surefire could be a candidate, or not...
>
>
> I hope this helps to understand.
>
> regards,
>
>
> Stephane
>
>
> Le 2023-02-16 à 11:58, Olivier Lamy a écrit :
> > On Thu, 16 Feb 2023 at 20:52, Olivier Lamy  wrote:
> >> On Thu, 16 Feb 2023 at 20:07, Delany
> wrote:
> >>> Hi Stephane,
> >>>
> >>> You can do like this
> >>>
> >>>  
> >>>maven-surefire-plugin
> >>>3.0.0-M9
> >>>
> >>>  
> >>>org.apache.commons
> >>>commons-email
> >>>1.5
> >>>  
> >>>
> >>>  
> >> this will add dependencies to the surefire plugin itself.
> >> I guess Stephane wants to add to the jvm running the tests?
> >>
> >> additionalClasspathElement expect a full path to a directory or a file
> >> to be added to the classpath
> >>
> >> should work with something such but you need to assume commons-email
> >> has been resolved locally as a dependency.
> >>
> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
> >>
> >> another solution is to use dependency:copy to copy the commons-email
> >> dependency somewhere in ./target and use this path (see
> >>
> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html
> )
> >>
> > a real example here :)
> >
> https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml
> >
> >> hth
> >> Olivier
> >>
> >>> On Thu, 16 Feb 2023 at 11:25, Stephane Passignat >
> >>> wrote:
> >>>
>  Hello,
> 
>  Is it possible to add a maven artifact as an
> additionalClasspathElement ?
> 
>  I tried this syntax, inspired by the exclusion mechanism, but it's not
>  working.
> 
>  
>   
>  
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M9
> 
>    
> 
> 
> org.apache.commons:commons-email:1.5
>    
> 
>  
>   
>  
> 
> 
>  thank you
> 
>  Stéphane
> 
> > -
> > To unsubscribe, e-mail:users-unsubscr...@maven.apache.org
> > For additional commands, e-mail:users-h...@maven.apache.org
> >
> --
> *Stéphane Passignat*
> ✆ +33 6 62 57 47 86 
> ✉ passig...@hotmail.com
> 📍 3 place Jacques Marette, 75015 PARIS
>

Re: [m-deploy-plugin] Deploy javadoc archive only

2023-02-23 Thread Tamás Cservenák 
Howdy,

so, personally I am in "limbo" about this, and let me explain why.

First let me state that I lack some context here:
- why is Bernhard doing this? (is he editing and then "testing" the edited
Javadoc? I mean, why is roundtrip needed [the deploy])
- where is he deploying it (some shared local repository? or his personal
one-man-show MrM?)
- is the project he works on a RELEASE or a SNAPSHOT?
- etc

And about my limbo opinion:
I do agree with the part of the original discussion, about the "general
repo hygiene" bit, that with pre-3.9.0 Maven this project would deploy
"incomplete" (the POM would state packaging is JAR, but there is no JAR
present). A lot of further conclusions depend on the context above (where
is deployed, etc). I have a feeling like Bernhard should do something like
this instead:

$ mvn javadoc:javadoc assembly:single deploy:deploy-file

As "deploy" means "deploy the project", that is obviously in "incomplete
state". One more point for this is Bernhard saying "I am building a JavaDoc
archive for a jar", so he also states he is NOT building the whole project
intentionally, only one archive from it.

OTOH, I disagree with implementation (or the behaviour change) of both
issues (see below), as for me, this really looks like some sort of
"validation" (or "sanity check"), and install/deploy plugins should NOT be
smart at all, in fact, they should be as "dumb" as possible. If there is
some validation needed, these plugins are for sure not the place to have
them.


Issues:
https://issues.apache.org/jira/browse/MDEPLOY-205
https://issues.apache.org/jira/browse/MINSTALL-118

T

On Wed, Feb 22, 2023 at 8:20 PM Greg Chabala  wrote:

> Am I correct in my reading, that they found a similar use case for why
> installing/deploying without a main artifact was allowed, and thus why a
> test was guarding that behavior, but then decided it wasn't 'the Maven Way'
> enough and ripped it out?
>
> That makes it seem like a dummy jar is the only solution to Bernhard's
> problem (or hanging back on an older version of the deploy plugin).
>
> On Wed, Feb 22, 2023 at 12:43 PM Tamás Cservenák 
> wrote:
>
> > Found this thread discussing this very change, may be helpful:
> > https://markmail.org/message/cmu5rh6i4cbmkh6e
> >
> > HTH
> > Tamas
> >
> > On Wed, Feb 22, 2023 at 7:27 PM Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > Not directly helpful, but this change was introduced in early 3.0.0-M1:
> > > https://issues.apache.org/jira/browse/MDEPLOY-205
> > >
> > > By reading the issue, I am really unsure about the exact intent.
> > > But, there is already a comment on issue (someone else having similar
> > > problem)
> > >
> > > Let's see if anyone else chimes in.
> > >
> > > HTH
> > > Tamas
> > >
> > > On Wed, Feb 22, 2023 at 7:20 PM Bernhard Schuhmann <
> > > bernhard.schuhm...@jedox.com> wrote:
> > >
> > >> Hello!
> > >>
> > >>
> > >>
> > >> I'm building a JavaDoc archive for a jar file with
> > >>
> > >>
> > >>
> > >>   mvn javadoc:javadoc assembly:single deploy
> > >>
> > >>
> > >>
> > >> and maven-jar-plugin disabled so that only the JavaDoc archive gets
> > >> deployed. This has been working until updating to 3.9.0
> > >> (maven-deploy-plugin 3.x) -because I only attach the JavaDoc archive I
> > now
> > >> get
> > >>
> > >>
> > >>
> > >>   The packaging plugin for this project did not assign a main file to
> > the
> > >> project but it has attachments. Change packaging to 'pom'.
> > >>
> > >>
> > >>
> > >> However, when I change packaging to pom as suggested,
> > >> maven-javadoc-plugin no longer generates the Javadoc files that I want
> > to
> > >> assemble into the zip archive.
> > >>
> > >>
> > >>
> > >> Any help how to still do that in a single command? How can I deploy an
> > >> attachment without a main file assigned?
> > >>
> > >>
> > >>
> > >> Bernhard
> > >>
> > >>
> > >>
> > >>
> > >> <
> >
> https://www.jedox.com/en/resources/analyst-gartner-critical-capabilities/?utm_source=signature&utm_medium=email&utm_campaign=gartner_cc
> > >
> > >>
> > >> *Bernhard Schuhmann**​*
> > >>
> > >> Senior Software Engineer
> > >>
> > >> *Jedox*
> > >>
> > >> Bismarckallee 7a
> > >>
> > >> 79098
> > >>
> > >> Freiburg im Breisgau
> > >>
> > >> Germany
> > >>
> > >> Jedox GmbH
> > >> Chief Executive Officer (Geschäftsführer): Florian Winterstein
> > >>
> > >> Place of Business: Freiburg i. Br. | Registry Court: Amtsgericht
> > Freiburg | HRB 723467
> > >>
> > >>
> > >> ​​[TM.V06112018]
> > >>
> > >>
> > >>
> > >
> >
>

Re: maven-surefire-plugin add artifact as additionalClasspathElement

2023-02-23 Thread Stephane Passignat 

thanks,

I gave a second try to extensions and it seems works now.


stephane



Le 2023-02-23 à 09:52, Alexander Kriegisch a écrit :

Would you not rather write a Maven plugin or extension for something
like that and hook it into the build process globally, so you can use it
when specifying `repository` or `pluginReporitory` entries in the POM
needing it? This does not seem to be something limited to certain
plugins, if I understand correctly.

Alexander Kriegisch
https://scrum-master.de


Stephane Passignat schrieb am 22.02.2023 um 11:27:

Hello,

thank you everyone for these suggestions. Let's go back to my original
issue.

I need to add a library to maven classpath. The library I need is
another RepositoryLayoutFactory, to download artifact located is a
repository which is not yet supported by Maven. Actually it's a basic
HTTP server. (It could be an FTP server or a database accessed is JDBC...)

The library is made, it works (as well as I need), but to use it I need
to add it to maven/lib/ext which is not portable to other computer. So
I'm looking at alternatives. Surefire could be a candidate, or not...


I hope this helps to understand.

regards,


Stephane


Le 2023-02-16 à 11:58, Olivier Lamy a écrit :

On Thu, 16 Feb 2023 at 20:52, Olivier Lamy   wrote:

On Thu, 16 Feb 2023 at 20:07, Delany   wrote:

Hi Stephane,

You can do like this

  
maven-surefire-plugin
3.0.0-M9

  
org.apache.commons
commons-email
1.5
  

  

this will add dependencies to the surefire plugin itself.
I guess Stephane wants to add to the jvm running the tests?

additionalClasspathElement expect a full path to a directory or a file
to be added to the classpath

should work with something such but you need to assume commons-email
has been resolved locally as a dependency.
${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar

another solution is to use dependency:copy to copy the commons-email
dependency somewhere in ./target and use this path (see
https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html)


a real example here :)
https://github.com/apache/maven-surefire/blob/master/surefire-providers/common-junit48/pom.xml


hth
Olivier


On Thu, 16 Feb 2023 at 11:25, Stephane Passignat
wrote:


Hello,

Is it possible to add a maven artifact as an additionalClasspathElement ?

I tried this syntax, inspired by the exclusion mechanism, but it's not
working.


  
 
org.apache.maven.plugins
maven-surefire-plugin
3.0.0-M9

   

org.apache.commons:commons-email:1.5
   

 
  



thank you

Stéphane


-
To unsubscribe,e-mail:users-unsubscr...@maven.apache.org
For additional commands,e-mail:users-h...@maven.apache.org


-
To unsubscribe, e-mail:users-unsubscr...@maven.apache.org
For additional commands, e-mail:users-h...@maven.apache.org


--
*Stéphane Passignat*
✆ +33 6 62 57 47 86 
✉ passig...@hotmail.com
📍 3 place Jacques Marette, 75015 PARIS

RE: unexpected behavior between inheritance and -dtest with surefire

2023-02-23 Thread DJ Kim 
This issue seems to be similar to SUREFIRE-1452. The fix was only applied
for TestNG.




Sent from Mail  for Windows



*From: *Tamás Cservenák 
*Sent: *Wednesday, February 22, 2023 12:19 PM
*To: *Maven Users List 
*Subject: *Re: unexpected behavior between inheritance and -dtest with
surefire



Howdy,



unrelated to your question, and unsure if this is intentional from your

side, but Maven user properties (like the "test" is) on CLI should be set

using "-Dtest=foo" (uppercase letter D) and not "-dtest=foo" as you wrote.



HTH

T



On Wed, Feb 22, 2023 at 5:43 PM DJ Kim  wrote:



> Hi there,

>

> Yesterday I posted a question about -dtest.

>

>

>

> To give a bit more of a context. I have a child class that extends parent,

> and I would only like to run -dtest=childclass#MethodinheritedfromParent.

> Unfortunately, the surefire executed all the test cases inherited from

> parent (unexpected behavior) and omits test from child class (expected).

>

> This feels like a bug. Any help is greatly appreciated.

>

> Thank you,

>

> Kim

>

>

>

> Sent from Mail  for

> Windows

>

3.9.0 not respecting proxy settings

2023-02-23 Thread Max Allan 
Hi,

I've got 2 separate maven builds configured like :

mvn clean install -Dhttps.proxyHost=$HTTPS_PROXY_HOST
-Dhttps.proxyPort=$HTTPS_PROXY_PORT -Dhttp.proxyHost=$HTTP_PROXY_HOST
-Dhttp.proxyPort=$HTTP_PROXY_PORT

That works fine on maven 3.8.7 but does not seem to even be trying to
connect to the proxy on 3.9.0.

The job fails with a load of errors like :

[FATAL] Non-resolvable parent POM for com.obfuscated:ldap:1.0.0-SNAPSHOT:
Could not transfer artifact
org.springframework.boot:spring-boot-starter-parent:pom:3.0.2 from/to
gitlab-maven (https://gitlab.domain/api/v4/groups/123/-/packages/maven):
Connect to gitlab.domain:443 [gitlab.domain/192.1.2.61] failed: Connect
timed out and 'parent.relativePath' points at wrong local POM @ line 6,
column 11
(URLs and paths obfuscated)

I cannot easily set the values in a settings.xml or elsewhere because the
proxy host is always different for each build and the proxy settings are
only needed in CICD, so adding them to settings would break local developer
builds.

If I move to a machine that has access to my GitLab without a proxy, then
the job works in 3.9.0. Even though there is no proxy and it should be
trying to use it. (so it should fail).

Is there a new requirement for specifying proxies in 3.9.0 or is it broken?

Max

Deploy javadoc archive only

2023-02-23 Thread Bernhard Schuhmann 
Hello!

I'm building a JavaDoc archive for a jar file with

  mvn javadoc:javadoc assembly:single deploy

and maven-jar-plugin disabled so that only the JavaDoc archive gets deployed. 
This has been working until updating to 3.9.0 (maven-deploy-plugin 3.x) 
-because I only attach the JavaDoc archive I now get

  The packaging plugin for this project did not assign a main file to the 
project but it has attachments. Change packaging to 'pom'.

However, when I change packaging to pom as suggested, maven-javadoc-plugin no 
longer generates the Javadoc files that I want to assemble into the zip archive.

Any help how to still do that in a single command? How can I deploy an 
attachment without a main file assigned?

Bernhard


Bernhard Schuhmann
Senior Software Engineer
Jedox
Bismarckallee 7a
79098Freiburg im Breisgau
Germany
Jedox GmbH
Chief Executive Officer (Geschäftsführer): Florian Winterstein
Place of Business: Freiburg i. Br. | Registry Court: Amtsgericht Freiburg | HRB 
723467


​​[TM.V06112018]

Re: 3.9.0 not respecting proxy settings

2023-02-23 Thread Tamás Cservenák 
Howdy,

Maven 3.9.0 changes default transport from Wagon to Native HTTP. Native
would respect proxy IF set in settings.xml, that as you explain, does not
fit your use case.

For now, with 3.9.0 you can fallback to Wagon using this
"-Dmaven.resolver.transport=wagon"

HTH
Tamas

On Fri, Feb 24, 2023 at 8:16 AM Max Allan  wrote:

> Hi,
>
> I've got 2 separate maven builds configured like :
>
> mvn clean install -Dhttps.proxyHost=$HTTPS_PROXY_HOST
> -Dhttps.proxyPort=$HTTPS_PROXY_PORT -Dhttp.proxyHost=$HTTP_PROXY_HOST
> -Dhttp.proxyPort=$HTTP_PROXY_PORT
>
> That works fine on maven 3.8.7 but does not seem to even be trying to
> connect to the proxy on 3.9.0.
>
> The job fails with a load of errors like :
>
> [FATAL] Non-resolvable parent POM for com.obfuscated:ldap:1.0.0-SNAPSHOT:
> Could not transfer artifact
> org.springframework.boot:spring-boot-starter-parent:pom:3.0.2 from/to
> gitlab-maven (https://gitlab.domain/api/v4/groups/123/-/packages/maven):
> Connect to gitlab.domain:443 [gitlab.domain/192.1.2.61] failed: Connect
> timed out and 'parent.relativePath' points at wrong local POM @ line 6,
> column 11
> (URLs and paths obfuscated)
>
> I cannot easily set the values in a settings.xml or elsewhere because the
> proxy host is always different for each build and the proxy settings are
> only needed in CICD, so adding them to settings would break local developer
> builds.
>
> If I move to a machine that has access to my GitLab without a proxy, then
> the job works in 3.9.0. Even though there is no proxy and it should be
> trying to use it. (so it should fail).
>
> Is there a new requirement for specifying proxies in 3.9.0 or is it broken?
>
> Max
>

Re: 3.9.0 not respecting proxy settings

2023-02-23 Thread Konrad Windszus 
Why not changing Native to call 
https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/impl/client/HttpClientBuilder.html#useSystemProperties()
 by default (if nothing conflicting is explicitly configured)?
That way it would be more compatible with the Wagon impl.

> Am 24.02.2023 um 08:31 schrieb Tamás Cservenák :
> 
> Howdy,
> 
> Maven 3.9.0 changes default transport from Wagon to Native HTTP. Native
> would respect proxy IF set in settings.xml, that as you explain, does not
> fit your use case.
> 
> For now, with 3.9.0 you can fallback to Wagon using this
> "-Dmaven.resolver.transport=wagon"
> 
> HTH
> Tamas
> 
>> On Fri, Feb 24, 2023 at 8:16 AM Max Allan  wrote:
>> 
>> Hi,
>> 
>> I've got 2 separate maven builds configured like :
>> 
>> mvn clean install -Dhttps.proxyHost=$HTTPS_PROXY_HOST
>> -Dhttps.proxyPort=$HTTPS_PROXY_PORT -Dhttp.proxyHost=$HTTP_PROXY_HOST
>> -Dhttp.proxyPort=$HTTP_PROXY_PORT
>> 
>> That works fine on maven 3.8.7 but does not seem to even be trying to
>> connect to the proxy on 3.9.0.
>> 
>> The job fails with a load of errors like :
>> 
>> [FATAL] Non-resolvable parent POM for com.obfuscated:ldap:1.0.0-SNAPSHOT:
>> Could not transfer artifact
>> org.springframework.boot:spring-boot-starter-parent:pom:3.0.2 from/to
>> gitlab-maven (https://gitlab.domain/api/v4/groups/123/-/packages/maven):
>> Connect to gitlab.domain:443 [gitlab.domain/192.1.2.61] failed: Connect
>> timed out and 'parent.relativePath' points at wrong local POM @ line 6,
>> column 11
>> (URLs and paths obfuscated)
>> 
>> I cannot easily set the values in a settings.xml or elsewhere because the
>> proxy host is always different for each build and the proxy settings are
>> only needed in CICD, so adding them to settings would break local developer
>> builds.
>> 
>> If I move to a machine that has access to my GitLab without a proxy, then
>> the job works in 3.9.0. Even though there is no proxy and it should be
>> trying to use it. (so it should fail).
>> 
>> Is there a new requirement for specifying proxies in 3.9.0 or is it broken?
>> 
>> Max
>>

Re: 3.9.0 not respecting proxy settings

2023-02-23 Thread Tamás Cservenák 
Sure, but Max cannot do that.
Will be done in 1.9.6: https://issues.apache.org/jira/browse/MRESOLVER-327

T

On Fri, Feb 24, 2023 at 8:39 AM Konrad Windszus  wrote:

> Why not changing Native to call
> https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/impl/client/HttpClientBuilder.html#useSystemProperties()
> by default (if nothing conflicting is explicitly configured)?
> That way it would be more compatible with the Wagon impl.
>
> > Am 24.02.2023 um 08:31 schrieb Tamás Cservenák :
> >
> > Howdy,
> >
> > Maven 3.9.0 changes default transport from Wagon to Native HTTP. Native
> > would respect proxy IF set in settings.xml, that as you explain, does not
> > fit your use case.
> >
> > For now, with 3.9.0 you can fallback to Wagon using this
> > "-Dmaven.resolver.transport=wagon"
> >
> > HTH
> > Tamas
> >
> >> On Fri, Feb 24, 2023 at 8:16 AM Max Allan 
> wrote:
> >>
> >> Hi,
> >>
> >> I've got 2 separate maven builds configured like :
> >>
> >> mvn clean install -Dhttps.proxyHost=$HTTPS_PROXY_HOST
> >> -Dhttps.proxyPort=$HTTPS_PROXY_PORT -Dhttp.proxyHost=$HTTP_PROXY_HOST
> >> -Dhttp.proxyPort=$HTTP_PROXY_PORT
> >>
> >> That works fine on maven 3.8.7 but does not seem to even be trying to
> >> connect to the proxy on 3.9.0.
> >>
> >> The job fails with a load of errors like :
> >>
> >> [FATAL] Non-resolvable parent POM for
> com.obfuscated:ldap:1.0.0-SNAPSHOT:
> >> Could not transfer artifact
> >> org.springframework.boot:spring-boot-starter-parent:pom:3.0.2 from/to
> >> gitlab-maven (https://gitlab.domain/api/v4/groups/123/-/packages/maven
> ):
> >> Connect to gitlab.domain:443 [gitlab.domain/192.1.2.61] failed: Connect
> >> timed out and 'parent.relativePath' points at wrong local POM @ line 6,
> >> column 11
> >> (URLs and paths obfuscated)
> >>
> >> I cannot easily set the values in a settings.xml or elsewhere because
> the
> >> proxy host is always different for each build and the proxy settings are
> >> only needed in CICD, so adding them to settings would break local
> developer
> >> builds.
> >>
> >> If I move to a machine that has access to my GitLab without a proxy,
> then
> >> the job works in 3.9.0. Even though there is no proxy and it should be
> >> trying to use it. (so it should fail).
> >>
> >> Is there a new requirement for specifying proxies in 3.9.0 or is it
> broken?
> >>
> >> Max
> >>
>