[MDEPLOY-266] More verbose output for deployment to trace down errors (esp. 401)

[jira-importer]

Jörg Hohwiller opened MDEPLOY-266 and commented

There are many reasons why a deployment of maven artifacts can fail:

• network error
• error on server side in repo server
• no login configured
• wrong login configured 
• no password configured
• wrong password configured (password may be encrypted so even almost impossible to determine)
• repository ID in distribution-management and server ID in settings.xml do not match
• etc.

It is really hard to check all the possibilities (please note that the distributionManagement may be configured in a parent^N pom and out of sight so you need to print the effective-pom. Many Maven users even do not have a clue how to do that). However, maven-deploy-plugin only prints that the deployment failed and an HTTP status code (typically 401). But this is very little information. Tons of users are therefore waisting their own time and especially also the time of others (e.g. OSSRH team) to trace down the reason.

It should be trivial for maven-deploy-plugin to log some more information:

• ID of repository that deployment is going to use
• whether a server tag from settings.xml could be resolved for this ID
• the login that is used for the deployment or a WARNING if login is undefined
• WARNING if password is undefined (obviously you should not log the password)

With this simple information users could save many hours/days of valuable time to trace down errors more easily.

 

---

Affects: 2.8.2

Issue Links:

• WAGON-558 log credentials source when failing to access a repository

1 votes, 4 watchers

[jira-importer]

Jörg Hohwiller commented

Another day of analysis lost due to complex parent structures and the lack of simple log output (the logged repo-id would have immediately made it clear):

devonfw/devon4j#198

[jira-importer]

Michael Osipov commented

Here is a similar case which cannot be implemented in Wagon.

[jira-importer]

Michael Osipov commented

The request is quite broad. As a last resort, one can always enable wire and context logging for the HttpClient.

[jira-importer]

Jörg Hohwiller commented

The request is quite broad.

I was asking for four concrete and obvious aspects to write to the log. You can even consider the second as optional.

The last two points should be trivial if you know the place in the code that is triggering the HTTP request. Already implementing these two would be a great improvement.

I can not see why this should be too "broad"...

As a last resort, one can always enable wire and context logging for the HttpClient.

The problem is that coders are facing this problems in external environments such as travis-ci.org or Jenkins. They are technically unable to "enable wire and context logging" and in travis-ci.org this would even expose the password to the public if they could.

Further I am proposing a feature that should be enabled by default. So if the problem occurred I get the proper eror details. Isn't it a best practice to give contextual information in case of an error? Why not for maven?

 

[jira-importer]

Michael Osipov commented

I need to see how the code is structured in MDEPLOY. I will get back to you in the next couple of days.

[jira-importer]

Michael Osipov commented

So, I have checked the code. MDEPLOY calls Maven Artifact Transfer which calls Maven Resolver which calls Maven Wagon. The deeper you get the less information of the Maven source you have. Wagon is competely decoupled from. There is no notion of repo id, settings.xml or whatsoever. One needs to identify where the required information needs to be collected...

[jira-importer]

Jörg Hohwiller commented

Surely this can not be addressed easily in wagen for instance.

However, it should be easy to find code where the password is resolved and passed to a lower-level component such as wagon.

In that place it should be possible to log a warning when the password is empty/null.

Further it could be possible to log on info the username that is passed.

With these two log statements a lot of value could be created preventing hours of debugging and analysis in the entire community.

[jira-importer]

Elliotte Rusty Harold commented

"In that place it should be possible to log a warning when the password is empty/null."

This sounds to me like this case should be an exception thrown up the chain, not a simple log statement. Same thing for empty/null username.

Logging a non-null username might help.

[jira-importer]

Tamas Cservenak commented

I believe since plugin 2.x version (as this issue was reported against) things changed a LOT: 2.x version used compat layer of Maven, while 3.x uses Resolver and resolver DO report very detailed errors coming from endpoints. I guess this issue can be closed.