Re: Nexus returns 400 Bad Request

[Romain Manni-Bucau]

Hi tison,

As mentionned it depends the "impl" you use but for jdk (mvn4) it will be
https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-jdk-parent/maven-resolver-transport-jdk-11/src/main/java/org/eclipse/aether/transport/jdk/JdkTransporter.java#L347
(also check out the other sibling modules since there are multiple
transport impl and as mentionned maven 3 uses another one but it is
similar) and be rethrown brutally there
https://github.com/apache/maven/blob/f2595c83d9cf9e3d30c4d808dcf4623f320c6182/maven-core/src/main/java/org/apache/maven/internal/impl/DefaultTransport.java#L122
.

An idea can be to type better the http exception, propagate the status and
a Supplier for te body maybe and compute the error message from
maven with the data propagated from the resolver?

Side note: all is not nexus so this logic should not fail on the failure
handling ;).

Best,
Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 25 janv. 2024 à 04:16, tison  a écrit :

> Thanks for your reply!
>
> > Maybe that is a bug in Nexus itself.
>
> I ever thought of it. But according to Romain's comment, it seems the
> MavenSession has the information but not printed out.
>
> > if you feel motivated to send a pr it would be welcomed I guess.
>
> I'd like to spend some time to see if I can write one. Could you show
> me some related code locations that I can start with? Maven has a lot
> of repos and I don't know which components are related to this logic.
>
> Best,
> tison.
>
> Hervé Boutemy  于2024年1月6日周六 16:05写道：
> >
> > interesting details
> >
> > IMHO, we're back to the HTTP wire protocol between Maven CLI and
> repositories
> > not being precisely defined on edge cases
> > = what to put as HTTP return code, what to put as reason phrase
> (deprecated in
> > HTTP/1.1, removed in HTTP/2), and what to get from HTTP body
> >
> > idea has been shared some time ago about using RFC 7807, but nothing has
> been
> > really done
> > see https://issues.apache.org/jira/browse/MNG-6795 , marked as
> candidate for
> > Maven 4, but did not get much traction for now
> >
> > Regards,
> >
> > Hervé
> >
> > Le vendredi 5 janvier 2024, 19:11:57 CET Romain Manni-Bucau a écrit :
> > > Hi,
> > >
> > > This is a valid error but if you want to see it you need to enable HTTP
> > > frames.
> > >
> > > For the record the error returns a HTML response with this content:
> > > *Cannot find a matching staging profile*.
> > >
> > > If you want to check them out it depends a bit of your maven version
> but
> > > for 3.9 you just comment the two last lines
> > > of $MAVEN_HOME/conf/logging/simplelogger.properties
> > > (org.slf4j.simpleLogger.log.org.apache.http) and run in debug mode (for
> > > maven 4 you can use the JVM httpclient system properties IIRC).
> > >
> > > But agree our client could be more precise on the error instead of just
> > > throwing a 400 without any message, if you feel motivated to send a pr
> it
> > > would be welcomed I guess.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> https://github.com/rmannibucau>
> > > | LinkedIn  | Book
> > > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > > Le ven. 5 janv. 2024 à 18:46, Michael Osipov  a
> écrit :
> > > > On 2024/01/04 14:00:08 tison wrote:
> > > > > Hi,
> > > > >
> > > > > When deploying artifacts to Nexus repository, 400 Bad Request can
> be
> > > > > one of the most confusing error code. See [1] as an example.
> > > > >
> > > > > Sonatype has a page to document some common causes of 400 Bad
> Request
> > > > > [2]. But I wonder if we can return an error message (diagnostic)
> along
> > > > > with the error code, so that users can get what conditions broken
> > > > > exactly.
> > > > >
> > > > > I suppose it has been discussed before. Is there any reference
> about
> > > > > this? What is the related components / code I can check for
> potential
> > > > > contributions (fixes)?
> > > > >
> > > > > Best,
> > > > > tison.
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/INFRA-25344
> > > > > [2] https://central.sonatype.org/faq/400-error/
> > > >
> > > > Looking at the INFRA issue it seems that 400 is just wrong. There is
> not
> > > > client issue here, but a permission issue which should give you 403.
> Maybe
> > > > that is a bug in Nexus itself.
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-m

Re: Nexus returns 400 Bad Request

[tison]

Thanks for your reply!

> Maybe that is a bug in Nexus itself.

I ever thought of it. But according to Romain's comment, it seems the
MavenSession has the information but not printed out.

> if you feel motivated to send a pr it would be welcomed I guess.

I'd like to spend some time to see if I can write one. Could you show
me some related code locations that I can start with? Maven has a lot
of repos and I don't know which components are related to this logic.

Best,
tison.

Hervé Boutemy  于2024年1月6日周六 16:05写道：
>
> interesting details
>
> IMHO, we're back to the HTTP wire protocol between Maven CLI and repositories
> not being precisely defined on edge cases
> = what to put as HTTP return code, what to put as reason phrase (deprecated in
> HTTP/1.1, removed in HTTP/2), and what to get from HTTP body
>
> idea has been shared some time ago about using RFC 7807, but nothing has been
> really done
> see https://issues.apache.org/jira/browse/MNG-6795 , marked as candidate for
> Maven 4, but did not get much traction for now
>
> Regards,
>
> Hervé
>
> Le vendredi 5 janvier 2024, 19:11:57 CET Romain Manni-Bucau a écrit :
> > Hi,
> >
> > This is a valid error but if you want to see it you need to enable HTTP
> > frames.
> >
> > For the record the error returns a HTML response with this content:
> > *Cannot find a matching staging profile*.
> >
> > If you want to check them out it depends a bit of your maven version but
> > for 3.9 you just comment the two last lines
> > of $MAVEN_HOME/conf/logging/simplelogger.properties
> > (org.slf4j.simpleLogger.log.org.apache.http) and run in debug mode (for
> > maven 4 you can use the JVM httpclient system properties IIRC).
> >
> > But agree our client could be more precise on the error instead of just
> > throwing a 400 without any message, if you feel motivated to send a pr it
> > would be welcomed I guess.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github 
> > | LinkedIn  | Book
> >  > >
> > Le ven. 5 janv. 2024 à 18:46, Michael Osipov  a écrit :
> > > On 2024/01/04 14:00:08 tison wrote:
> > > > Hi,
> > > >
> > > > When deploying artifacts to Nexus repository, 400 Bad Request can be
> > > > one of the most confusing error code. See [1] as an example.
> > > >
> > > > Sonatype has a page to document some common causes of 400 Bad Request
> > > > [2]. But I wonder if we can return an error message (diagnostic) along
> > > > with the error code, so that users can get what conditions broken
> > > > exactly.
> > > >
> > > > I suppose it has been discussed before. Is there any reference about
> > > > this? What is the related components / code I can check for potential
> > > > contributions (fixes)?
> > > >
> > > > Best,
> > > > tison.
> > > >
> > > > [1] https://issues.apache.org/jira/browse/INFRA-25344
> > > > [2] https://central.sonatype.org/faq/400-error/
> > >
> > > Looking at the INFRA issue it seems that 400 is just wrong. There is not
> > > client issue here, but a permission issue which should give you 403. Maybe
> > > that is a bug in Nexus itself.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

How to test lifecycle extension?

[tison]

Hi,

I'm writing a Mojo with an Extension extending
AbstractMavenLifecycleParticipant.

Now, I'd like to write some tests on the extension logic. Although
Maven provides docs about writing tests over Mojos[1], it doesn't tell
how to test if an extension [2] is properly loaded and executed.

Are there some examples of such test cases?

Best,
tison.

[1] 
https://maven.apache.org/plugin-developers/plugin-testing.html#using-plexustestcase
[2] https://maven.apache.org/guides/mini/guide-using-extensions.html

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

Re: Using .git-blame-ignore-revs with reordered lines

[Konrad Windszus]

Ping, does anyone have any input on this? Would be much appreciated,
Thanks,
Konrad

> On 8. Jan 2024, at 19:16, Konrad Windszus  wrote:
> 
> Hi,
> 
> According to https://maven.apache.org/pom/maven/#the-format-profile the git 
> commits created through applying the spotless formatting should be ignored 
> via a .git-blame-ignore-revs file. This file is automatically evaluated by 
> GitHub blame view. This doesn’t work well if the formatting also does some 
> reordering of lines (most prominently through 
> https://github.com/diffplug/spotless/tree/main/plugin-maven#sortpom). An 
> example can be found in 
> https://github.com/apache/sling-parent/blame/master/sling-parent/pom.xml#L270 
> which obviously shows a non-related commit in line 270 due to the ignored 
> reordering commit (this is a different ASF projects but follows the same 
> approach as Maven).
> 
> The same may happen with reordering of lines  in Java.
> I am wondering if there is a better approach, or we should rather not 
> generally recommend to add those reformatting commits to 
> .git-blame-ignore-revs. WDYT?
> Konrad


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