Maven 3.9.0 doesn't work with github packages

[gwendo]

Select Topic Area

Bug

Body

After the recent upgrade of runner-images and the upgrade of maven to 3.9.0 our deployments to github packages has stopped working, we are getting a 400 error (bad request) when trying to upload the pom-file.

[gwendo]

Well, I have verified all of the above and downgrading solves the issue, but I don't think I should have to downgrade when I'm using a runner provided by github against a repository provided by github. But that's what I have to do until the issue is resolved.

[michael-o]

There could be a few reasons why you are getting a 400 error when uploading the pom-file to GitHub Packages with Maven 3.9.0. Here are some things you can try:

Check your credentials: Make sure your GitHub Packages authentication credentials are correct and have the necessary permissions to upload packages.

Check your repository settings: Ensure that your repository settings are correctly configured to allow package uploads.

Check your Maven settings: Verify that your Maven settings.xml file is correctly configured with the correct repository URL and authentication details.

Downgrade to a previous version of Maven: If the above solutions do not work, consider downgrading to a previous version of Maven until the issue is resolved.

All of those reasons do not qualify for a 400. There are better status codes. If GH repos cannot handle that, then they are incorrectly implemented. As simple as that.

[dineshkannanshell]

We are also facing the same 400 error when we are trying to connect to Maven https://maven.pkg.github.com

[dwilliams-gs]

Having there same issue as above....

Error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:3.0.0:deploy (default-deploy) on project : Failed to deploy artifacts: Could not transfer artifact com.github.::pom: from/to github (https://maven.pkg.github.com/******): status code: 400, reason phrase: Bad Request (400) -> [Help 1]

We've personally had to add in this step into our Github release file in order to temporally downgrade the version of Maven being used to 3.8.7 (https://github.com/marketplace/actions/setup-maven)

      - name: Setup Maven
        uses: stCarolas/setup-maven@v.4.5
        with:
          maven-version: 3.8.7

[jramst]

We are also seeing the same issue when trying to build and push maven artifacts to our private repository.

[karussell]

We get the same error message for github packages since ~2 days (for public and private repositories). But we did not change something in our pipeline.

Downgrade to a previous version of Maven: If the above solutions do not work, consider downgrading to a previous version of Maven until the issue is resolved.

Why is this now a problem? Because the setup-java action upgraded the maven version under the hood?

The related issue is here: actions/setup-java#457

[agentgt]

Why is this now a problem? Because the setup-java action upgraded the maven version under the hood?

Yes.

I don't know about github packages but we have a custom repository using headers (basic auth).

Maven 3.9.0 appears to be completely ignoring server credentials in settings.xml:

e.g. this xml

<server>
<username></username>
<password></password>
</server>

EDIT the reason this isn't blowing up like it should in more places is because most open source projects do not use the deploy plugin but the sonatype special deploy plugin.

The deploy plugin was updated recently to 3.1.0 but it still fails.

EDIT 2: for those that are using the deploy plugin this appears to be work for me:

-Dmaven.resolver.transport=wagon

[mgm3746]

EDIT 2: for those that are using the deploy plugin this appears to be work for me:
-Dmaven.resolver.transport=wagon

Thank you, this resolved the issue for me. I updated my maven-publish.yaml as follows to add that system property, and it works again.

For example, change this:

run: mvn -B package --file pom.xml

To this:

run: mvn -Dmaven.resolver.transport=wagon -B package --file pom.xml

[cstamas]

For first bullet (Maven 3.9.0 completely ignoring settings.xml), that for sure not true, related issue https://issues.apache.org/jira/browse/MNG-7719

For second bullet, the Sonatype plugin is ratnest, healthy OSS projects are actually avoiding it ;) (as plain deploy or even curl PUT is enough to use their service to deploy to Central)

For third bullet, yes, for those having Plexus XML configuration specific for Wagon only (hence, it goes unnoticed by new transport), the way to go is to use -Dmaven.resolver.transport=wagon for start with 3.9.0, but they should update their transport configuration to be able to join the party with new transport 😄

[akrherz]

We ran into this issue attempting to publish to Apache Archiva. And indeed, this workaround fixed it

mvn -Dmaven.resolver.transport=wagon ...

[cstamas]

Just a heads up, while am still unsure what the real problem is (and is there), as @agentgt already noted: Maven 3.9.0 did switch default transport from ancient "Wagon" to more modern native-http (both are Apache HttpClient based, but Wagon is deeply tied to ancient DI container Plexus). In short, what you see here for example "setting custom headers" https://maven.apache.org/guides/mini/guide-http-settings.html (using Plexus XML inside settings.xml server) is Wagon specific only, and hence, does not work with new transport.

But, Maven 3.9.0 for sure is not completely ignoring server credentials in settings.xml, can you show me an example of this?

Maven 3.9.1 is coming soon with improves like addition of preemptive auth, but again, the new transport follows resolver configuration, and not Wagon specific Plexus XML based configuration, more about it here (1.9.6 resolver is staged, this is staged site for it, vote for release still ongoing): https://maven.apache.org/resolver-archives/resolver-LATEST/configuration.html

[slawekjaranowski]

There is a success deploy to oss.sonatype
https://github.com/mojohaus/mojo-parent/actions/runs/4326189519/jobs/7553323356
Maven 3.9.0 and m-deploy-p 3.1.0

Action used for deploy:
https://github.com/mojohaus/.github/blob/master/.github/workflows/maven-deploy.yml

[agentgt]

Prior to 3.9.0 the default HTTP transport on deploy would send basic auth Authorization headers (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization).

That is the <username> and <password> would become an Authorization header.

You can test this by running a proxy HTTP server or whatever and try to deploy to it and see the headers missing.

@slawekjaranowski

Are you using the default deploy plugin or sonatypes drop in replacement? I could not figure out from your mojo-parent pom. Sonatypes plugin does different things than the normal deploy plugin.

[cstamas]

Are you using preemptive auth? As native transport would respond with Authorization header on challenge... if this is very first request of Wagon, then it uses preemptive auth... as Wagon by default behave the same.

[agentgt]

No I purposely made our custom server let GET requests for pom meta-data (which is the first call IIRC) not require auth which appears to be the default.

That is Maven pre 3.9.0 does not even put Basic Auth credentials for any GET request for meta-data.

However for the PUTs it does.

Perhaps that is my mistake in that the native expects the GET to be challenged and then will send auth requests?

That is in my server I don't think I ever send WWW-Authenticate: Basic because the old transport didn't seem to care. This maybe why it is not working (e.g. maybe the GET needs the 401 and with WWW-Authenticate header).

[cstamas]

Yes, that is one of the Wagon peculiarites. Native obeys proper HTTP/1.1 protocol, and it will respond with Authorization header once challenged. If preemptive must, for native transport it comes in 3.9.1.

[agentgt]

Let me try it out and I will get back to you and update the jira bug as well.

[agentgt]

@cstamas That was the problem. I am not sure why I was not sending the challenge. There was some reason I did not do it. It slightly annoying in terms of logs and errors that the native client has to fail first before it tries. I even tried to send the WWW-Authenticate header on non blocked maven-metadata.xml requests but it will still fail to send the challenge till a 401 happens.

I suppose I can add client check to avoid logging it as an error.

[slawekjaranowski]

It is working for me https://github.com/slawekjaranowski/test

It must be a something special in your configuration.
There is no issue with Maven and with GitHub repositories.

[agentgt]

See my updates on the Jira
Bug. It is because our custom maven server did not do a proper basic auth challenge header.
I took out the response header of www-authenticate for security
a while back as wagon does not need it.

eg Wagon does not do the whole first fail request thing like native does.

[mlork]

Since I'm facing the same issue I took your example repo to figure out where the difference to my setup is. At least in my case it is the maven-deploy-plugin together with the maven-release-plugin. I have set up three different workflows at https://github.com/mlork/maven-3.9.0-deploy-test

The results:
mvn -V -B -X deploy ✔️
mvn -V -B -X release:prepare release:perform ⚠️
mvn -V -B -X -Darguments=-Dmaven.resolver.transport=wagon release:prepare release:perform ✔️

[slawekjaranowski]

I added more debug output in jira issue.

And confirm deploy for release version is not working - But I'm not sure where is issue

[byronic]

Seconding this issue, attempting to do a maven release at 3.9.0 to GitHub Packages fails with 400 Bad Request as seen above, but does not experience the issue on 3.8.7 with no other changes. Internal deploys/releases targeting a current Sonatype Nexus work with 3.9.0 and 3.8.7

[pmouawad]

I confirm issue related to upgrade to 3.9.0 fixed by reverting to 3.8.7.
Currently unable to deploy to internal github packages due to error 400.
Issue appeared following upgrade of github runners.

Using mvnw instead of mvn fixed the problem as we were able to control mvn version used.

[cstamas]

Maven dev here, just to keep you folks in the loop:

First, Maven 3.9.1 is about to happen soon (week-ish): https://lists.apache.org/thread/jmgrdgmm2c6rw2xgrsffj59hvm2025h7 with all issues addressed.

Second, Maven 3.9.0 seems to confuse GH Package Registry only (due behavior change, stemming from changed transport Wagon -> transport-http). It is confirmed that Maven 3.9.0 does work OK with other Maven Repository Managers (Artifactory, Nexus, etc). Transport really just became HTTP RFC compliant (and some users had issues from it, as they had non-HTTP compliant servers, like challenge was never sent, hence, client never authed either). Something similar happens with GH Package Registry as well, but I have no details, did not see it's source 😉 (all we know it sends HTTP 400 Bad Request out of the blue). But the issue is addressed and tested, and 3.9.1 should work OK with GH registry as well (using transport-http, for this user still has to "move off" from Wagon specific configuration, if there is any used). Maven 3.9.0 w/ Wagon transport does work.

We added new page (sorry for being late about it) to explain changes: https://maven.apache.org/guides/mini/guide-resolver-transport.html

[michael-o]

I totally consider a preemptive auth with request bodies just braindead. There is expect continue. Any decent server must support that. Yes, there are clients which don't, e.g., py-requests but that is their problem. Wagon will remove all legacy hacks. Time to clean up.

[michael-o]

@agentgt I fully agree with the last couple of paragraphs. We have completely failed to reasonably document what you can expect from Wagon HTTP transport. Frankly, I have been the sole Maintainer of it for the past five years. Haven't found the time to clean up.docs. Too many vital components.

[agentgt]

I appreciate anybody or any work that has been put towards Maven!

Maybe I can try to put together a pseudo reference HTTP server implementation using Java builtin HTTP server (our current one does not but it would be interesting to try using the builtin one).

Its a shame so many repositories have made it really complicated particularly Google when modern HTTP is plenty fast enough and secure with HTTPS particularly when the transport on deploy does not seem to be the bottleneck (I'm still trying to figure out why this is the case. I assume it is something to do with resolution.).

Speaking of deploy... deployAtEnd should probably be the default but the problem is it doesn't take advantage of any concurrency. It will just serially PUT artifact, GET metadata, modify metadata locally, PUT metadata regardless of -T settings. It's a shame because deployAtEnd ideally minimizes the deploy window but in modern times that is hardly the truth. It is better to do compile and testing w/o packaging. Then run deploy (which will also package) with a super high -T.

I'm not sure if @cstamas aware of the above or it is fixed but I was going to look into later this month as I owe it to you guys (especially because of the misleading basic auth credentials bug... sorry about that).

[cstamas]

😄 See https://issues.apache.org/jira/browse/MRESOLVER-319, is coming in resolver 1.9.7, that will come with Maven 3.9.1

In action (the stash part is just ensuring 3.1.0 of m-deploy-p is being used) https://asciinema.org/a/26zfCcSAQ0llQ66E41xNhruGK

In action against real remote Proximity (52s vs 37s): https://asciinema.org/a/fBTcOTSJF0cRmHsr8hZuIQrpw
(at this stage it had to be enabled explicitly, the staged release has this enabled by default, see staged site https://maven.apache.org/resolver-archives/resolver-LATEST/configuration.html for key aether.connector.basic.parallelPut)

[agentgt]

@cstamas Super exciting. I can't tell you how much this help our build time now but I'm fairly sure it will be massive savings. Deploy is one of the slowest part of our builds. I'll be trying this new feature once 3.9.1 comes out and give you an update on speed as we have hundreds of artifacts.

[cstamas]

Sure, but resolver 1.9.7 was put on vote today, 72h is ticking, then 3.9.1 on vote, etc.

In you want to try NOW, you can do it:

1. mvn install https://github.com/apache/maven-resolver master branch (as we are post release, it will build 1.9.8-SNAPSHOT)
2. check out [MNG-7723] Upgrade to Maven Resolver 1.9.7 apache/maven#1037 and mvn package (apache-maven/target will have bin distro), steps:

git clone git@github.com:apache/maven.git
git checkout -b cstamas-maven-3.9.x-MNG-7723-resolver-197 maven-3.9.x
git pull git@github.com:cstamas/maven.git maven-3.9.x-MNG-7723-resolver-197
...edit locally root POM to set resolverVersion to 1.9.8-SNAPSHOT
mvn package

You will end up with Maven 3.9.1-SNAPSHOT having all the changes. Ping me if more help needed.

Any feedback appreciated!

[cstamas]

Apache Maven 3.9.1 released: https://maven.apache.org/docs/3.9.1/release-notes.html

[alexsuter]

Trying to upgrade to maven 3.9.4. I've the same issue when I try to upload a p2 repository to drone package registry.

We don't have a settings.xml with server configuration. We define the user and password directly in the url.

  <distributionManagement>
    <snapshotRepository>
      <id>drone.ivyteam.io</id>
      <url>https://USER:PASSWORD@drone.ivyteam.io/maven/ivy-core/</url>
    </snapshotRepository>
  </distributionManagement>

It seems, it can't upload the checksum but other artifacts are fine. Switching to wagon is working. Do you have any ideas?

INFO] --- ****:3.1.1:**** (default-****) @ ch.****team.****.core.p2 ---
[INFO] Downloading from drone.****team.io: [https://****:****@drone.****team.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/maven-metadata.xml](https://****:****@drone.%2A%2A%2A%2Ateam.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/maven-metadata.xml)
[INFO] Downloaded from drone.****team.io: [https://****:****@drone.****team.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/maven-metadata.xml](https://****:****@drone.%2A%2A%2A%2Ateam.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/maven-metadata.xml) (1.1 kB at 19 kB/s)
[INFO] Uploading to drone.****team.io: [https://****:****@drone.****team.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/ch.****team.****.core.p2-11.2.0-20230904.061244-1.pom](https://****:****@drone.%2A%2A%2A%2Ateam.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/ch.****team.****.core.p2-11.2.0-20230904.061244-1.pom)
[WARNING] Failed to upload checksum to ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/ch.****team.****.core.p2-11.2.0-20230904.061244-1.pom.sha1
org.apache.http.client.HttpResponseException: status code: 401, reason phrase: Unauthorized (401)
    at org.eclipse.aether.transport.http.HttpTransporter.handleStatus (HttpTransporter.java:527)
    at org.eclipse.aether.transport.http.HttpTransporter.execute (HttpTransporter.java:396)
    at org.eclipse.aether.transport.http.HttpTransporter.implPut (HttpTransporter.java:377)
    at org.eclipse.aether.spi.connector.transport.AbstractTransporter.put (AbstractTransporter.java:107)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$PutTaskRunner.uploadChecksum (BasicRepositoryConnector.java:608)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$PutTaskRunner.uploadChecksums (BasicRepositoryConnector.java:591)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$PutTaskRunner.runTask (BasicRepositoryConnector.java:565)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run (BasicRepositoryConnector.java:414)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector.put (BasicRepositoryConnector.java:297)
    at org.eclipse.aether.internal.impl.DefaultDeployer.**** (DefaultDeployer.java:270)
    at org.eclipse.aether.internal.impl.DefaultDeployer.**** (DefaultDeployer.java:201)
    at org.eclipse.aether.internal.impl.DefaultRepositorySystem.**** (DefaultRepositorySystem.java:392)
    at org.apache.maven.plugins.****.AbstractDeployMojo.**** (AbstractDeployMojo.java:139)
    at org.apache.maven.plugins.****.DeployMojo.execute (DeployMojo.java:203)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:342)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:330)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:175)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:76)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:163)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:160)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:910)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:568)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:283)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:226)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:407)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:348)
[WARNING] Failed to upload checksum to ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/ch.****team.****.core.p2-11.2.0-20230904.061244-1.pom.md5
org.apache.http.client.HttpResponseException: status code: 401, reason phrase: Unauthorized (401)
    at org.eclipse.aether.transport.http.HttpTransporter.handleStatus (HttpTransporter.java:527)
    at org.eclipse.aether.transport.http.HttpTransporter.execute (HttpTransporter.java:396)
    at org.eclipse.aether.transport.http.HttpTransporter.implPut (HttpTransporter.java:377)
    at org.eclipse.aether.spi.connector.transport.AbstractTransporter.put (AbstractTransporter.java:107)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$PutTaskRunner.uploadChecksum (BasicRepositoryConnector.java:608)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$PutTaskRunner.uploadChecksums (BasicRepositoryConnector.java:591)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$PutTaskRunner.runTask (BasicRepositoryConnector.java:565)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run (BasicRepositoryConnector.java:414)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector.put (BasicRepositoryConnector.java:297)
    at org.eclipse.aether.internal.impl.DefaultDeployer.**** (DefaultDeployer.java:270)
    at org.eclipse.aether.internal.impl.DefaultDeployer.**** (DefaultDeployer.java:201)
    at org.eclipse.aether.internal.impl.DefaultRepositorySystem.**** (DefaultRepositorySystem.java:392)
    at org.apache.maven.plugins.****.AbstractDeployMojo.**** (AbstractDeployMojo.java:139)
    at org.apache.maven.plugins.****.DeployMojo.execute (DeployMojo.java:203)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:342)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:330)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:175)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:76)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:163)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:160)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:910)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:568)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:283)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:226)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:407)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:348)
[INFO] Uploaded to drone.****team.io: [https://****:****@drone.****team.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/ch.****team.****.core.p2-11.2.0-20230904.061244-1.pom](https://****:****@drone.%2A%2A%2A%2Ateam.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/ch.****team.****.core.p2-11.2.0-20230904.061244-1.pom) (1.0 kB at 205 B/s)
[INFO] Uploading to drone.****team.io: [https://****:****@drone.****team.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/ch.****team.****.core.p2-11.2.0-20230904.061244-1.zip](https://****:****@drone.%2A%2A%2A%2Ateam.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/ch.****team.****.core.p2-11.2.0-20230904.061244-1.zip)
[INFO] Uploading to drone.****team.io: [https://****:****@drone.****team.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/ch.****team.****.core.p2-11.2.0-20230904.061244-1-p2metadata.xml](https://****:****@drone.%2A%2A%2A%2Ateam.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/ch.****team.****.core.p2-11.2.0-20230904.061244-1-p2metadata.xml)
[INFO] Uploading to drone.****team.io: [https://****:****@drone.****team.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/ch.****team.****.core.p2-11.2.0-20230904.061244-1-p2artifacts.xml](https://****:****@drone.%2A%2A%2A%2Ateam.io/maven/****-core/ch/****team/****/ch.****team.****.core.p2/11.2.0-SNAPSHOT/ch.****team.****.core.p2-11.2.0-20230904.061244-1-p2artifacts.xml)

[alexsuter]

Guys I'm sorry!

We also have defined the server in server.xml with the CORRECT password. It seems that the new transport is now prefering the user and password from the url. The wagon transport is first using the the user and password from server.xml.

A small change in behavior :) Which has confused me. Maybe someone else is happy about this thread. ;)

[michael-o]

Please consider that the userinfo in the URL is deprecated with RFC 9110.

[alexsuter]

Yep! So it would be cool if the new transport would not consider it ;)

[michael-o]

FTR: apache/httpcomponents-core#418