from:"mark.yagnatinsky"

Okay, I tried again with more realistic settings and indeed it now works!
(That is, I gave it 700 megs of heap instead of one meg)
Thank you!  This actually truly works!

(I still feel that there should be a "catchall" category of compiler output so 
that anything that maven can't make sense of doesn't silently swallowed.)

But it works!

-Original Message-
From: Alexander Kriegisch  
Sent: Saturday, December 23, 2023 7:53 PM
To: users@maven.apache.org
Subject: Re: Why does Plexus Compiler parse compiler output, when forked? (was: 
maven debugging frustrations)


CAUTION: This email originated from outside our organisation - 
alexan...@kriegisch.name Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
Just found this in my spam folder. Your invalid e-mail address and the strange 
link replacements in some of your messages maybe. This kind of obfuscation 
might derail the server-side filters. Anyway, I already said

  mvn dependency:tree

a minute sago in my other message.

  mvn help:effective-pom -Doutput=effective-pom.xml

is helpful, too.
--
Alexander Kriegisch
https://clicktime.symantec.com/15t6KP9J8Qx4aAou1S5kN?h=gjD-CfhzFG_NEND692vyjsGzpBpicHoC55k2ALzIIoc==https://scrum-master.de


mark.yagnatin...@barclays.com.INVALID schrieb am 24.12.2023 01:53 (GMT +07:00):

> Actually no, wait.  I changed the pom as you described but I think the 
> build is still using the old plexus version.
> Is there a way to be sure?
>
> -Original Message-
> From: mark.yagnatin...@barclays.com.INVALID
> 
> Sent: Saturday, December 23, 2023 1:51 PM
> To: users@maven.apache.org
> Subject: RE: Why does Plexus Compiler parse compiler output, when forked? 
> (was:
> maven debugging frustrations)
>
>
> CAUTION: This email originated from outside our organisation - 
> mark.yagnatin...@barclays.com.INVALID Do not click on links, open 
> attachments, or respond unless you recognize the sender and can 
> validate the content is safe.
> Also: just tested with your new and improved version.
> To speed up the build failures I gave it even less heap (just one meg).
> It doesn't seem to help; all I get is "compilation failure"
> And thanks for putting up with my attitude; I'll try to do better.
>
> -Original Message-
> From: Yagnatinsky, Mark : Markets Pre Trade
> Sent: Saturday, December 23, 2023 12:50 PM
> To: Maven Users List 
> Subject: RE: Why does Plexus Compiler parse compiler output, when forked? 
> (was:
> maven debugging frustrations)
>
> Okay you win, stack trace below.  My bad, sorry, I should know better.
> Also, thanks for explaining the parsing picture: that's not how I 
> expected it to work at all!
> I never thought maven expected this much structure from the compiler messages.
>
> The system is out of resources.
> Consult the following stack trace for details.
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at com.sun.tools.javac.util.List.of(List.java:135)
> at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:129)
> at
> 
> com.sun.tools.javac.parser.JavacParser.variableDeclaratorsRest(JavacParser.java:3006)
> at
> 
> com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaration(JavacParser.java:3537)
> at
> 
> com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacParser.java:3436)
> at
> 
> com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.java:3285)
> at
> 
> com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclaration(JavacParser.java:3226)
> at
> 
> com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.java:3215)
> at
> 
> com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacParser.java:3155)
> at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:628)
> at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:665)
> at
> 
> com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
> at 
> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:857)
> at com.sun.tools.javac.main.Main.compile(Main.java:523)
> at com.sun.tools.javac.main.Main.compile(Main.java:381)
> at com.sun.tools.javac.main.Main.compile(Main.java:370)
> at com.sun.tools.javac.main.Main.compile(Main.java:361)
> at com.sun.tools.javac.Main.compile(Main.java:56)
> at com.sun.tools.javac.Main.main(Main.java:42)
>
> -Original Message-
> From: Alexander Kriegisch 
> Sent: Saturday, December 23, 2023 3:03 AM
> To: users@maven.apache.org
> Subject: Why does Plexus Compiler parse compiler output, when forked? (was:
> maven debugging frustrations)
>
>
> CAUTION: This email originated from outside our organisation - 
> alexan...@kriegisch.name Do not click on links, open attachments, or 
> respond unless you

RE: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations)

Actually no, wait.  I changed the pom as you described but I think the build is 
still using the old plexus version.
Is there a way to be sure?

-Original Message-
From: mark.yagnatin...@barclays.com.INVALID 

Sent: Saturday, December 23, 2023 1:51 PM
To: users@maven.apache.org
Subject: RE: Why does Plexus Compiler parse compiler output, when forked? (was: 
maven debugging frustrations)

CAUTION: This email originated from outside our organisation - 
mark.yagnatin...@barclays.com.INVALID Do not click on links, open attachments, 
or respond unless you recognize the sender and can validate the content is safe.
Also: just tested with your new and improved version.
To speed up the build failures I gave it even less heap (just one meg).
It doesn't seem to help; all I get is "compilation failure"
And thanks for putting up with my attitude; I'll try to do better.

-Original Message-
From: Yagnatinsky, Mark : Markets Pre Trade 
Sent: Saturday, December 23, 2023 12:50 PM
To: Maven Users List 
Subject: RE: Why does Plexus Compiler parse compiler output, when forked? (was: 
maven debugging frustrations)

Okay you win, stack trace below.  My bad, sorry, I should know better.
Also, thanks for explaining the parsing picture: that's not how I expected it 
to work at all!
I never thought maven expected this much structure from the compiler messages. 

The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError: GC overhead limit exceeded
at com.sun.tools.javac.util.List.of(List.java:135)
at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:129)
at 
com.sun.tools.javac.parser.JavacParser.variableDeclaratorsRest(JavacParser.java:3006)
at 
com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaration(JavacParser.java:3537)
at 
com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacParser.java:3436)
at 
com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.java:3285)
at 
com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclaration(JavacParser.java:3226)
at 
com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.java:3215)
at 
com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacParser.java:3155)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:628)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:665)
at 
com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:857)
at com.sun.tools.javac.main.Main.compile(Main.java:523)
at com.sun.tools.javac.main.Main.compile(Main.java:381)
at com.sun.tools.javac.main.Main.compile(Main.java:370)
at com.sun.tools.javac.main.Main.compile(Main.java:361)
at com.sun.tools.javac.Main.compile(Main.java:56)
at com.sun.tools.javac.Main.main(Main.java:42)

-Original Message-
From: Alexander Kriegisch  
Sent: Saturday, December 23, 2023 3:03 AM
To: users@maven.apache.org
Subject: Why does Plexus Compiler parse compiler output, when forked? (was: 
maven debugging frustrations)

CAUTION: This email originated from outside our organisation - 
alexan...@kriegisch.name Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
> There's nothing that special about MY stack trace... just run javac on 
> a largish module with a tiny heap.

Well, that is an abstract description, and instead of just sending one or two 
stack traces, now you are burdening me with trying to reproduce your problem 
without a reproducer. Do you think, that makes sense or is particularly nice? I 
just wanted *any* example stack trace for this error.

> In the meantime, I have a question. Why is maven in the business of 
> trying to "parse" the output of javac? Why can't it give me its output 
> verbatim, as if javac were a mysterious black box binary blob with 
> totally unknown behaviour?

That is actually a good question. I was wondering about the same thing, too. 
Let me remind you, I am not a maintainer or even have commit rights on Plexus 
Compiler. I am a simple user, just like you, and last week contributes a little 
patch for the very first time. The patch improved something, it was not a 
rewrite.

Basically, all Plexus compilers (Javac, C#, AspectJ, Eclipse Java) implement 
the same Compiler interface and even extend from the same AbstractCompiler base 
class. No matter if they compile in process or out of process, they are calle 
by Maven Compiler via interface method

CompilerResult Compiler.performCompile(CompilerConfiguration)
  throws CompilerException

I.e., they have to return a CompilerResult,and that one e.g. has a

List getCompilerMessages()

method. I.e., Maven Compiler does not expect a dump of output and error streams 
and a single

RE: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations)

Also: just tested with your new and improved version.
To speed up the build failures I gave it even less heap (just one meg).
It doesn't seem to help; all I get is "compilation failure"
And thanks for putting up with my attitude; I'll try to do better.

-Original Message-
From: Yagnatinsky, Mark : Markets Pre Trade 
Sent: Saturday, December 23, 2023 12:50 PM
To: Maven Users List 
Subject: RE: Why does Plexus Compiler parse compiler output, when forked? (was: 
maven debugging frustrations)

Okay you win, stack trace below.  My bad, sorry, I should know better.
Also, thanks for explaining the parsing picture: that's not how I expected it 
to work at all!
I never thought maven expected this much structure from the compiler messages. 

The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError: GC overhead limit exceeded
at com.sun.tools.javac.util.List.of(List.java:135)
at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:129)
at 
com.sun.tools.javac.parser.JavacParser.variableDeclaratorsRest(JavacParser.java:3006)
at 
com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaration(JavacParser.java:3537)
at 
com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacParser.java:3436)
at 
com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.java:3285)
at 
com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclaration(JavacParser.java:3226)
at 
com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.java:3215)
at 
com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacParser.java:3155)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:628)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:665)
at 
com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:857)
at com.sun.tools.javac.main.Main.compile(Main.java:523)
at com.sun.tools.javac.main.Main.compile(Main.java:381)
at com.sun.tools.javac.main.Main.compile(Main.java:370)
at com.sun.tools.javac.main.Main.compile(Main.java:361)
at com.sun.tools.javac.Main.compile(Main.java:56)
at com.sun.tools.javac.Main.main(Main.java:42)

-Original Message-
From: Alexander Kriegisch  
Sent: Saturday, December 23, 2023 3:03 AM
To: users@maven.apache.org
Subject: Why does Plexus Compiler parse compiler output, when forked? (was: 
maven debugging frustrations)

CAUTION: This email originated from outside our organisation - 
alexan...@kriegisch.name Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
> There's nothing that special about MY stack trace... just run javac on 
> a largish module with a tiny heap.

Well, that is an abstract description, and instead of just sending one or two 
stack traces, now you are burdening me with trying to reproduce your problem 
without a reproducer. Do you think, that makes sense or is particularly nice? I 
just wanted *any* example stack trace for this error.

> In the meantime, I have a question. Why is maven in the business of 
> trying to "parse" the output of javac? Why can't it give me its output 
> verbatim, as if javac were a mysterious black box binary blob with 
> totally unknown behaviour?

That is actually a good question. I was wondering about the same thing, too. 
Let me remind you, I am not a maintainer or even have commit rights on Plexus 
Compiler. I am a simple user, just like you, and last week contributes a little 
patch for the very first time. The patch improved something, it was not a 
rewrite.

Basically, all Plexus compilers (Javac, C#, AspectJ, Eclipse Java) implement 
the same Compiler interface and even extend from the same AbstractCompiler base 
class. No matter if they compile in process or out of process, they are calle 
by Maven Compiler via interface method

CompilerResult Compiler.performCompile(CompilerConfiguration)
  throws CompilerException

I.e., they have to return a CompilerResult,and that one e.g. has a

List getCompilerMessages()

method. I.e., Maven Compiler does not expect a dump of output and error streams 
and a single result OK or failed, but a list of error messagesof different 
kinds, such as errors, warnings, infos etc. When compiling out of process 
(fork=true) instead of Java tools interface, the compiler output must be 
parsed, which is a rather crude and imperfect heuristic approach. Actually, it 
is amazing that it works as good as it does at all. Simply running the forked 
compiler VM with a non-English locale can make the difference between an error 
correctly identified or not, because since at least JDK 8, there are 3 locales, 
since JDK 21 4 locales in OpenJDK.

I do not want to elaborate any further - you get the picture.

RE: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations)

Okay you win, stack trace below.  My bad, sorry, I should know better.
Also, thanks for explaining the parsing picture: that's not how I expected it 
to work at all!
I never thought maven expected this much structure from the compiler messages. 

The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError: GC overhead limit exceeded
at com.sun.tools.javac.util.List.of(List.java:135)
at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:129)
at 
com.sun.tools.javac.parser.JavacParser.variableDeclaratorsRest(JavacParser.java:3006)
at 
com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaration(JavacParser.java:3537)
at 
com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacParser.java:3436)
at 
com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.java:3285)
at 
com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclaration(JavacParser.java:3226)
at 
com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.java:3215)
at 
com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacParser.java:3155)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:628)
at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:665)
at 
com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:857)
at com.sun.tools.javac.main.Main.compile(Main.java:523)
at com.sun.tools.javac.main.Main.compile(Main.java:381)
at com.sun.tools.javac.main.Main.compile(Main.java:370)
at com.sun.tools.javac.main.Main.compile(Main.java:361)
at com.sun.tools.javac.Main.compile(Main.java:56)
at com.sun.tools.javac.Main.main(Main.java:42)

-Original Message-
From: Alexander Kriegisch  
Sent: Saturday, December 23, 2023 3:03 AM
To: users@maven.apache.org
Subject: Why does Plexus Compiler parse compiler output, when forked? (was: 
maven debugging frustrations)


CAUTION: This email originated from outside our organisation - 
alexan...@kriegisch.name Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
> There's nothing that special about MY stack trace... just run javac on 
> a largish module with a tiny heap.

Well, that is an abstract description, and instead of just sending one or two 
stack traces, now you are burdening me with trying to reproduce your problem 
without a reproducer. Do you think, that makes sense or is particularly nice? I 
just wanted *any* example stack trace for this error.

> In the meantime, I have a question. Why is maven in the business of 
> trying to "parse" the output of javac? Why can't it give me its output 
> verbatim, as if javac were a mysterious black box binary blob with 
> totally unknown behaviour?

That is actually a good question. I was wondering about the same thing, too. 
Let me remind you, I am not a maintainer or even have commit rights on Plexus 
Compiler. I am a simple user, just like you, and last week contributes a little 
patch for the very first time. The patch improved something, it was not a 
rewrite.

Basically, all Plexus compilers (Javac, C#, AspectJ, Eclipse Java) implement 
the same Compiler interface and even extend from the same AbstractCompiler base 
class. No matter if they compile in process or out of process, they are calle 
by Maven Compiler via interface method

CompilerResult Compiler.performCompile(CompilerConfiguration)
  throws CompilerException

I.e., they have to return a CompilerResult,and that one e.g. has a

List getCompilerMessages()

method. I.e., Maven Compiler does not expect a dump of output and error streams 
and a single result OK or failed, but a list of error messagesof different 
kinds, such as errors, warnings, infos etc. When compiling out of process 
(fork=true) instead of Java tools interface, the compiler output must be 
parsed, which is a rather crude and imperfect heuristic approach. Actually, it 
is amazing that it works as good as it does at all. Simply running the forked 
compiler VM with a non-English locale can make the difference between an error 
correctly identified or not, because since at least JDK 8, there are 3 locales, 
since JDK 21 4 locales in OpenJDK.

I do not want to elaborate any further - you get the picture.

That in some cases, especially when the build fails for any reason, the error 
message is not parsed out correctly, is exactly what needs improvement and what 
was partly addressed by my patch, at least if a stack trace happens to be part 
of the compiler output.

Cheers
--
Alexander Kriegisch
https://clicktime.symantec.com/15t5ejaoBdG3n3Nk8C4vS?h=lY-QL6rWusTeyzIz0RujRgAvrvPPWo66hf-ZSgB36q4==https://scrum-master.de


mark.yagnatin...@barclays.com.INVALID schrieb am 23.12.2023 10:40 (GMT +07:00):

>

RE: maven debugging frustrations

2023-12-22 Thread mark.yagnatinsky

There's nothing that special about MY stack trace... just run javac on a 
largish module with a tiny heap.
(Our module was huge enough to fail with 800 megs, but there are plenty modules 
that will fail with 8 megs, let alone one meg.)
Further, the exact stack trace is very sensitive to the exact amount of heap I 
give it; I tried varying it and it fails in totally different places.
In fact, depending on the exact heap size, sometimes the stack trace doesn't go 
all the way back to main() and other times it does.
I have no idea how to explain that last part... maybe depth is limited??
I will try this again with new and improved plexus version and report back.
In the meantime, I have a question.  Why is maven in the business of trying to 
"parse" the output of javac?
Why can't it give me its output verbatim, as if javac were a mysterious black 
box binary blob with totally unknown behaviour?

-Original Message-
From: Alexander Kriegisch  
Sent: Friday, December 22, 2023 10:23 PM
To: users@maven.apache.org
Subject: Re: maven debugging frustrations


CAUTION: This email originated from outside our organisation - 
alexan...@kriegisch.name Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
>> How can I can find out EXACTLY how maven invoked javac, so I can 
>> invoke it the same way?

I think, somebody already mentioned earlier that you can just activate debug 
output in Maven. Then search for the line following "Command line
options":

$ mvn -X compile | grep --after-context 1 'Command line options'

[DEBUG] Command line options:
[DEBUG] -d ...\target\classes -classpath ... 
src\main\java\org\example\Main.java -s ... -processor ... -g -target 1.8 
-source 1.8 -encoding UTF-8

Copy everything from the last line agter "[DEBUG] " and paste it right behind 
"javac ". That should be your exact command.

> Okay, I think I got it.  Here is the error I get when running with  
> -J-Xmx800
>
>  The system is out of 
> resources.
> Consult the following stack trace for details.
> java.lang.OutOfMemoryError: GC overhead limit exceeded  stack trace from the depths of javac>

Sorry to bother you again, but two more requests:

  1. Can you please paste more of the stack trace? That would make for a
 good (as in realistic) unit or integration test.

  2. I think, my PR in the recently released Plexus Compiler 2.14.2
 should at least enable you to get the stack trace printed. The two
 header lines beginning with "The system is out of resources"
 probably will be cut off. Anyway, that would be better than
 nothing. Can you please retest? In Maven, that would go like this
 (fragmentary POM):


  2.14.2



  org.apache.maven.plugins
  maven-compiler-plugin
  3.12.0
  

  org.codehaus.plexus
  plexus-compiler-api
  ${plexusCompilerVersion}


  org.codehaus.plexus
  plexus-compiler-manager
  ${plexusCompilerVersion}


  org.codehaus.plexus
  plexus-compiler-javac
  ${plexusCompilerVersion}
  runtime

  


--
Alexander Kriegisch
https://clicktime.symantec.com/15siFBaoYbM4wmfMjZKMr?h=isWwo2pYTjyI3SuGICAE9ZFT6R_DSWTZSKkBbg1NX0E==https://scrum-master.de

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


This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__
 
If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html.

RE: maven debugging frustrations

2023-12-22 Thread mark.yagnatinsky

Okay, I think I got it.  Here is the error I get when running with  -J-Xmx800

The system is out of resources.
Consult the following stack trace for details.
java.lang.OutOfMemoryError: GC overhead limit exceeded


-Original Message-
From: mark.yagnatin...@barclays.com.INVALID 
 
Sent: Friday, December 22, 2023 9:45 AM
To: users@maven.apache.org
Subject: RE: maven debugging frustrations


CAUTION: This email originated from outside our organisation - 
mark.yagnatin...@barclays.com.INVALID Do not click on links, open attachments, 
or respond unless you recognize the sender and can validate the content is safe.
How can I can find out EXACTLY how maven invoked javac, so I can invoke it the 
same way?
(While I await your response, I'll attempt to invoke it roughly the same way 
and see if that works.)

-Original Message-
From: Alexander Kriegisch  
Sent: Thursday, December 21, 2023 8:45 PM
To: users@maven.apache.org
Subject: Re: maven debugging frustrations


CAUTION: This email originated from outside our organisation - 
alexan...@kriegisch.name Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
Mark, you asked for help here, now I am asking for your help to make Maven 
Compiler and Maven Plexus Java better. Can you please switch back to the 
too-low memory settings you used before and reproduce the javac error output 
when compiled outside Maven? Was it something as simple as:

$ javac -J-Xmx32k org/example/MySecondAnnotation.java
Error occurred during initialization of VM Initial heap size set to a larger 
value than the maximum heap size

This would be silently swallowed even after my fix, because my fix was about 
stack trace parsing. It is, however, much more difficult to separate other JVM 
or javac error output from output possibly produced by e.g. annotation 
processors. It does not get easier, given the fact, that JVM output is 
localised to a handful of languages, not just English.

Or did you get some kind of out of memory error with a stack trace? The error 
parser for forked javac undoubtedly needs more hardening and improvements to at 
least parse (and display!) the most common error messages correctly. I 
scratched my own itch lately by contributing an improvement for the first time. 
Before I forget about the source code context again and move on to other 
projects, maybe I can contribute a little bit more. But then, I need input.

Thanks in advance and kind regards
--
Alexander Kriegisch
https://clicktime.symantec.com/15siQqy2D74kaQgWiyWS2?h=K9eKgEK3KMNDQERT1qp6hASj2Lxz71_qkmqF5v0_ueU==https://clicktime.symantec.com/15t64tYyoA1WdgmTZsmn2?h=I98HUPo0DHKTqOkdZ1TN4skRFZCJraqV71xYi96Hcs0==https://scrum-master.de

mark.yagnatin...@barclays.com.INVALID schrieb am 21.12.2023 23:43 (GMT +07:00):

> Forked: yes
> Other questions: didn't check, because using a bigger heap ("maxmem") fixed 
> it.
> But thanks for this, that looks like it would have helped us!
> (in a hypothetical world where that PR was merged ten years earlier) 
> (We're mostly using version 3.8 of maven-compiler-plugin...perhaps 
> it's time to
> upgrade.)
> 
> -Original Message-
> From: Alexander Kriegisch 
> Sent: Wednesday, December 20, 2023 12:41 AM
> To: users@maven.apache.org
> Subject: Re: maven debugging frustrations
> 
> 
> CAUTION: This email originated from outside our organisation - 
> alexan...@kriegisch.name Do not click on links, open attachments, or 
> respond unless you recognize the sender and can validate the content is safe.
> Hello Mark.
> 
> Feel free to let me know if your situation is as follows:
>   -- forked build (i.e. not in process)
>   -- when disabling the fork and enabling "-e" or running the build with
>  javac directly outside of Maven, suddenly error messages appear at
>  the end of the build
>   -- optionally (not necessarily) using a JDK locale other than English
>  (e.g. javac in JDK 21 comes with localised messages in Chinese,
>  Japanese, German)
>   -- optionally (not necessarily) using an annotation processor
> 
> I recently had the symptom of build errors with forked compiler 
> swallowing error messages and scratched my own itch by adding a PR to 
> Plexus Javac which for me solves the problem. If your problem happens 
> to be the same category, you would be the perfect sentient test 
> particle for 
> https://clicktime.symantec.com/15t5ejaZW5bYZxdqr5n2v?h=L374vY2E9JSjErAq9vkYZyMzPS76MKSF_SWNxb51rVE==https://clicktime.symantec.com/15siFBZrUArbTHh6FWx5d?h%3D_vziVdl8fIA-_du7fPQDmEDaVPK6D7XlieIqn88Lnv0%3D%26u%3Dhttps://clicktime.symantec.com/15siL1mjkVPAATrbBR7HQ?h%3DsoRGieRSYIcaVDaMRpuEKiTr-X0PEnOQaKTTUdxCkog%3D%26u%3Dhttps://github.com/codehaus-plexus/plexus-compiler/pull/337.
> I can advise you how to get that running in your project.
> 
> Regards
> --
> Alexander Kriegisch
>

RE: maven debugging frustrations

2023-12-22 Thread mark.yagnatinsky

How can I can find out EXACTLY how maven invoked javac, so I can invoke it the 
same way?
(While I await your response, I'll attempt to invoke it roughly the same way 
and see if that works.)

-Original Message-
From: Alexander Kriegisch  
Sent: Thursday, December 21, 2023 8:45 PM
To: users@maven.apache.org
Subject: Re: maven debugging frustrations

CAUTION: This email originated from outside our organisation - 
alexan...@kriegisch.name Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
Mark, you asked for help here, now I am asking for your help to make Maven 
Compiler and Maven Plexus Java better. Can you please switch back to the 
too-low memory settings you used before and reproduce the javac error output 
when compiled outside Maven? Was it something as simple as:

$ javac -J-Xmx32k org/example/MySecondAnnotation.java
Error occurred during initialization of VM Initial heap size set to a larger 
value than the maximum heap size

This would be silently swallowed even after my fix, because my fix was about 
stack trace parsing. It is, however, much more difficult to separate other JVM 
or javac error output from output possibly produced by e.g. annotation 
processors. It does not get easier, given the fact, that JVM output is 
localised to a handful of languages, not just English.

Or did you get some kind of out of memory error with a stack trace? The error 
parser for forked javac undoubtedly needs more hardening and improvements to at 
least parse (and display!) the most common error messages correctly. I 
scratched my own itch lately by contributing an improvement for the first time. 
Before I forget about the source code context again and move on to other 
projects, maybe I can contribute a little bit more. But then, I need input.

Thanks in advance and kind regards
--
Alexander Kriegisch
https://clicktime.symantec.com/15siQqy2D74kaQgWiyWS2?h=K9eKgEK3KMNDQERT1qp6hASj2Lxz71_qkmqF5v0_ueU==https://scrum-master.de

mark.yagnatin...@barclays.com.INVALID schrieb am 21.12.2023 23:43 (GMT +07:00):

> Forked: yes
> Other questions: didn't check, because using a bigger heap ("maxmem") fixed 
> it.
> But thanks for this, that looks like it would have helped us!
> (in a hypothetical world where that PR was merged ten years earlier) 
> (We're mostly using version 3.8 of maven-compiler-plugin...perhaps 
> it's time to
> upgrade.)
> 
> -Original Message-
> From: Alexander Kriegisch 
> Sent: Wednesday, December 20, 2023 12:41 AM
> To: users@maven.apache.org
> Subject: Re: maven debugging frustrations
> 
> 
> CAUTION: This email originated from outside our organisation - 
> alexan...@kriegisch.name Do not click on links, open attachments, or 
> respond unless you recognize the sender and can validate the content is safe.
> Hello Mark.
> 
> Feel free to let me know if your situation is as follows:
>   -- forked build (i.e. not in process)
>   -- when disabling the fork and enabling "-e" or running the build with
>  javac directly outside of Maven, suddenly error messages appear at
>  the end of the build
>   -- optionally (not necessarily) using a JDK locale other than English
>  (e.g. javac in JDK 21 comes with localised messages in Chinese,
>  Japanese, German)
>   -- optionally (not necessarily) using an annotation processor
> 
> I recently had the symptom of build errors with forked compiler 
> swallowing error messages and scratched my own itch by adding a PR to 
> Plexus Javac which for me solves the problem. If your problem happens 
> to be the same category, you would be the perfect sentient test 
> particle for 
> https://clicktime.symantec.com/15siFBZrUArbTHh6FWx5d?h=_vziVdl8fIA-_du7fPQDmEDaVPK6D7XlieIqn88Lnv0==https://clicktime.symantec.com/15siL1mjkVPAATrbBR7HQ?h=soRGieRSYIcaVDaMRpuEKiTr-X0PEnOQaKTTUdxCkog==https://github.com/codehaus-plexus/plexus-compiler/pull/337.
> I can advise you how to get that running in your project.
> 
> Regards
> --
> Alexander Kriegisch
> https://clicktime.symantec.com/15siL1m8vnYBsEX1o5MEF?h=EIrFDp-q7MAJaGl
> zS3rT2Qpp_OrLzsXNXIASmesIlO4==https://clicktime.symantec.com/15siQqy
> 2D74kaQgWiyWS2?h=K9eKgEK3KMNDQERT1qp6hASj2Lxz71_qkmqF5v0_ueU==https:
> //scrum-master.de
> 
> 
> mark.yagnatin...@barclays.com.INVALID schrieb am 20.12.2023 05:27 (GMT 
> +07:00):
> 
>> Indeed, if there were ACTUAL error messages from the java compiler, 
>> this would be far less mysterious :) The trouble is that there are 
>> NOT any error messages coming from the Java compiler. There are a few 
>> warnings (from javac), followed soon after by "Compilation failure"
>> (from maven, NOT from javac)
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> This message is for information purposes only. It is not a 
> recommendation, advice, offer or

RE: maven debugging frustrations

2023-12-21 Thread mark.yagnatinsky

Forked: yes
Other questions: didn't check, because using a bigger heap ("maxmem") fixed it.
But thanks for this, that looks like it would have helped us!
(in a hypothetical world where that PR was merged ten years earlier)
(We're mostly using version 3.8 of maven-compiler-plugin...perhaps it's time to 
upgrade.)

-Original Message-
From: Alexander Kriegisch  
Sent: Wednesday, December 20, 2023 12:41 AM
To: users@maven.apache.org
Subject: Re: maven debugging frustrations


CAUTION: This email originated from outside our organisation - 
alexan...@kriegisch.name Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
Hello Mark.

Feel free to let me know if your situation is as follows:
  -- forked build (i.e. not in process)
  -- when disabling the fork and enabling "-e" or running the build with
 javac directly outside of Maven, suddenly error messages appear at
 the end of the build
  -- optionally (not necessarily) using a JDK locale other than English
 (e.g. javac in JDK 21 comes with localised messages in Chinese,
 Japanese, German)
  -- optionally (not necessarily) using an annotation processor

I recently had the symptom of build errors with forked compiler swallowing 
error messages and scratched my own itch by adding a PR to Plexus Javac which 
for me solves the problem. If your problem happens to be the same category, you 
would be the perfect sentient test particle for 
https://clicktime.symantec.com/15siFBZrUArbTHh6FWx5d?h=_vziVdl8fIA-_du7fPQDmEDaVPK6D7XlieIqn88Lnv0==https://github.com/codehaus-plexus/plexus-compiler/pull/337.
 I can advise you how to get that running in your project.

Regards
--
Alexander Kriegisch
https://clicktime.symantec.com/15siL1m8vnYBsEX1o5MEF?h=EIrFDp-q7MAJaGlzS3rT2Qpp_OrLzsXNXIASmesIlO4==https://scrum-master.de


mark.yagnatin...@barclays.com.INVALID schrieb am 20.12.2023 05:27 (GMT +07:00):

> Indeed, if there were ACTUAL error messages from the java compiler,
> this would be far less mysterious :) The trouble is that there are NOT
> any error messages coming from the Java compiler. There are a few
> warnings (from javac), followed soon after by "Compilation failure"
> (from maven, NOT from javac)

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


This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__
 
If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

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

RE: maven debugging frustrations

Good guess.  Turns out it doesn't though.  I checked yesterday.

My latest theory is that it's running out of memory during compilation.
But that would presumably end up in the logs, so this theory has problems.

-Original Message-
From: Tomo Suzuki  
Sent: Tuesday, December 19, 2023 6:15 PM
To: Maven Users List 
Subject: Re: maven debugging frustrations


CAUTION: This email originated from outside our organisation - 
suzt...@google.com.INVALID Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
My guess is that your Maven project uses failOnWarning.
https://clicktime.symantec.com/15siaWLuEraDnGbepBrqS?h=vm2H6AWG-3rryNUA8VNdRBNEgZsI-pOiUUzFOS7k1CM==https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html%23failOnWarning

On Tue, Dec 19, 2023 at 5:38 PM Thomas Broyer  wrote:

> In `mvn -X` you should find the arguments to javac (beware that empty 
> arguments are not displayed there, rather than being shown as "" for 
> instance), which would allow you to run javac on your own, taking 
> Maven out of the equation.
>
> Le mar. 19 déc. 2023, 23:28,  a 
> écrit :
>
> > Indeed, if there were ACTUAL error messages from the java compiler, 
> > this would be far less mysterious :) The trouble is that there are 
> > NOT any error messages coming from the Java compiler.
> > There are a few warnings (from javac), followed soon after by
> "Compilation
> > failure" (from maven, NOT from javac) I do not recommend feeling my 
> > maven-based pain :) But if you happen to know where to get some pain 
> > relief, I'd love to know
> >
> > -Original Message-
> > From: Tomo Suzuki 
> > Sent: Tuesday, December 19, 2023 5:18 PM
> > To: Maven Users List 
> > Subject: Re: maven debugging frustrations
> >
> >
> > CAUTION: This email originated from outside our organisation - 
> > suzt...@google.com.INVALID Do not click on links, open attachments, 
> > or respond unless you recognize the sender and can validate the 
> > content is safe.
> > What’s the exact error messages?
> >
> > (Maybe I’m too old to feel your pain)  If you use Java, you need to 
> > know what compilation means (converting Java code to Java bytecode). 
> > Your
> Maven
> > invocation was telling it was failing due to some error messages.
> >
> > On Tue, Dec 19, 2023 at 16:57 
> > 
> > wrote:
> >
> > > When my Java code does something I didn't expect, I can run it 
> > > under a debugger and step through it line by line until things 
> > > make sense
> again.
> > > When maven does something I didn't expect, my debugging strategy 
> > > is usually more like "try to think of something in my bag of tricks".
> > > Sometimes I suddenly have an epiphany and I realize "oh, it must 
> > > have broken because of that thing I changed".
> > > But in the absence of epiphanies, I don't have any good ways to 
> > > ask maven to tell me what on earth is going on.
> > >
> > > Example from today: some is failing on our build server with 
> > > "Compilation failure".
> > > Looking at the build log, there are no compiler errors in sight.
> > > There are a few compiler warnings, and those seem to logged twice:
> > > once at warning level, and then again at error level.
> > > It only fails on SOME (not all) of our build configs, even though 
> > > our configs are pretty darn similar to each other.
> > >
> > > So I'm left flailing around more or less at random (try compiling 
> > > on a different server!  Try copying the command line flags from 
> > > the one that work!  Etc.) What I actually want is for maven to 
> > > give me some CRUMB of visibility into what on earth is going wrong.
> > >
> > > I don't even know what "Compilation failure" actually means.
> > > Did some process exit with non-zero status?
> > > Did the process fail to launch in the first place?
> > > Maybe there is no extra process, and the compilation is taking 
> > > place in the same JVM that's running maven?
> > > If so, what went wrong?  Did an exception get thrown?  Something else?
> > >
> > > You get the idea.
> > >
> > >
> > > This message is for information purposes only. It is not a 
> > > recommendation, advice, offer or solicitation to buy or sell a 
> > > product or service, nor an official confirmation of any 
> > > transaction. It is directed at persons who are professionals and 
> > > is intended for the
> > > recipient(s) only. It is not directed at retail customers. This 
> > > message
> > is subject to the terms at:
> > >
> >
> https://clicktime.symantec.com/15sifLYAwPjLHCtCgybKg?h=ANvnaYG630AR0f2
> GLplpUfGbAsle9xaoL2f-FF_ESsU==https://clicktime.symantec.com/15sjF9u
> Aun2y5qD3Af42Q?h=bKbi7fnxDJgBguJhQEcMWKUhbV_NYuart3hdMvz044w==https:
> //www.cib.barclays/disclosures/web-and-email-disclaimer.html
> > .
> > >
> > > For important disclosures, please see:
> > > https://clicktime.symantec.com/15siVg9cnEtdNKmjGdTgp?h=GH7DdAnjwpt
> > > EFmc3uqTwo3OwLGnOewXUfpr2nzLk1F0==https://clicktime.symantec.com

RE: maven debugging frustrations

That last part sounds promising actually!  Sadly I'm not familiar with the 
maven source code but still the ability to set breakpoints sounds very tempting!

-Original Message-
From: Mark Eggers  
Sent: Tuesday, December 19, 2023 5:33 PM
To: users@maven.apache.org
Subject: Re: maven debugging frustrations


CAUTION: This email originated from outside our organisation - 
its_toas...@yahoo.com.INVALID Do not click on links, open attachments, or 
respond unless you recognize the sender and can validate the content is safe.
I think the first two will help you compare what's working to what's not 
working.

The -X does generate a LOT of output. Use -l [filename] to catch it.

When you start reading it, you'll be able to ignore a lot of the chatter.

You can also set slf4j logging options on the command line to help things out. 
Check the following article:

https://clicktime.symantec.com/15siL1m3HxmqDsdB2xGsn?h=pTSjEkzIyhSak6-_loRKkflLxKxaJtib1-d32Un99qI==https://www.baeldung.com/maven-logging

You might also play around with mvnDebug and attach an IDE to it. I've not 
tried this. The default port is 8000. It appears that you would then be able to 
set break points, etc.

. . . just my two cents
/mde/
On 12/19/2023 2:16 PM, mark.yagnatin...@barclays.com.INVALID wrote:
> Thanks, I've heard of all three; the first two don't seem like they'd help 
> here.
> The third tends to spew junk and not useful stuff
> 
> -Original Message-
> From: Mark Eggers 
> Sent: Tuesday, December 19, 2023 5:11 PM
> To: users@maven.apache.org
> Subject: Re: maven debugging frustrations
> 
> 
> CAUTION: This email originated from outside our organisation - 
> its_toas...@yahoo.com.INVALID Do not click on links, open attachments, or 
> respond unless you recognize the sender and can validate the content is safe.
> Some commands that might help you get started:
> 
> What are you using to build the artifact
> 
> mvn help:effective-pom
> mvn help:effective-pom -Dverbose
> 
> What artifacts are being brought in
> --
> mvn dependency:tree
> mvn dependency:tree -Dverbose
> 
> Debug output
> --
> mvn -X package
> 
> I'm sure that there are more, but this might get you started.
> 
> . . . just my two cents
> /mde/
> 
> On 12/19/2023 1:56 PM, mark.yagnatin...@barclays.com.INVALID wrote:
>> When my Java code does something I didn't expect, I can run it under a 
>> debugger and step through it line by line until things make sense again.
>> When maven does something I didn't expect, my debugging strategy is usually 
>> more like "try to think of something in my bag of tricks".
>> Sometimes I suddenly have an epiphany and I realize "oh, it must have broken 
>> because of that thing I changed".
>> But in the absence of epiphanies, I don't have any good ways to ask maven to 
>> tell me what on earth is going on.
>>
>> Example from today: some is failing on our build server with "Compilation 
>> failure".
>> Looking at the build log, there are no compiler errors in sight.
>> There are a few compiler warnings, and those seem to logged twice: once at 
>> warning level, and then again at error level.
>> It only fails on SOME (not all) of our build configs, even though our 
>> configs are pretty darn similar to each other.
>>
>> So I'm left flailing around more or less at random (try compiling on 
>> a different server!  Try copying the command line flags from the one that 
>> work!  Etc.) What I actually want is for maven to give me some CRUMB of 
>> visibility into what on earth is going wrong.
>>
>> I don't even know what "Compilation failure" actually means.
>> Did some process exit with non-zero status?
>> Did the process fail to launch in the first place?
>> Maybe there is no extra process, and the compilation is taking place in the 
>> same JVM that's running maven?
>> If so, what went wrong?  Did an exception get thrown?  Something else?
>>
>> You get the idea.
>>
>>
>> This message is for information purposes only. It is not a recommendation, 
>> advice, offer or solicitation to buy or sell a product or service, nor an 
>> official confirmation of any transaction. It is directed at persons who are 
>> professionals and is intended for the recipient(s) only. It is not directed 
>> at retail customers. This message is subject to the terms at: 
>> https://clicktime.symantec.com/15t5z4LpKs5nXMa3HxmPT?h=ISgjwiKtVs_26S9D5WklDpkGWg5FN4KBfDXNiomU8xw==https://clicktime.symantec.com/15sikAjTb3BoHbknkkGct?h=bfq-oC7O9ItW_Mf33WgCmqzZ-u30xQK5ACgIfxqYrkk==https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.
>>
>> For important disclosures, please see: 
>> https://clicktime.symantec.com/15t5uE9XsFQC7Qk7kQNEq?h=GqPl7-MY2KIl75o5H8ob4oRWV5EdZOb-0TiUB8Oz1g8==https://clicktime.symantec.com/15sifLYB8RWCsevsDBsUG?h=R5Z3ECCKXHBYaUVgMQkI0XUqyk0Oy3pqj5U8sC9k98A==https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html

RE: maven debugging frustrations

Indeed, if there were ACTUAL error messages from the java compiler, this would 
be far less mysterious :)
The trouble is that there are NOT any error messages coming from the Java 
compiler.
There are a few warnings (from javac), followed soon after by "Compilation 
failure" (from maven, NOT from javac)
I do not recommend feeling my maven-based pain :)
But if you happen to know where to get some pain relief, I'd love to know

-Original Message-
From: Tomo Suzuki  
Sent: Tuesday, December 19, 2023 5:18 PM
To: Maven Users List 
Subject: Re: maven debugging frustrations


CAUTION: This email originated from outside our organisation - 
suzt...@google.com.INVALID Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
What’s the exact error messages?

(Maybe I’m too old to feel your pain)  If you use Java, you need to know what 
compilation means (converting Java code to Java bytecode). Your Maven 
invocation was telling it was failing due to some error messages.

On Tue, Dec 19, 2023 at 16:57  wrote:

> When my Java code does something I didn't expect, I can run it under a 
> debugger and step through it line by line until things make sense again.
> When maven does something I didn't expect, my debugging strategy is 
> usually more like "try to think of something in my bag of tricks".
> Sometimes I suddenly have an epiphany and I realize "oh, it must have 
> broken because of that thing I changed".
> But in the absence of epiphanies, I don't have any good ways to ask 
> maven to tell me what on earth is going on.
>
> Example from today: some is failing on our build server with 
> "Compilation failure".
> Looking at the build log, there are no compiler errors in sight.
> There are a few compiler warnings, and those seem to logged twice: 
> once at warning level, and then again at error level.
> It only fails on SOME (not all) of our build configs, even though our 
> configs are pretty darn similar to each other.
>
> So I'm left flailing around more or less at random (try compiling on a 
> different server!  Try copying the command line flags from the one 
> that work!  Etc.) What I actually want is for maven to give me some 
> CRUMB of visibility into what on earth is going wrong.
>
> I don't even know what "Compilation failure" actually means.
> Did some process exit with non-zero status?
> Did the process fail to launch in the first place?
> Maybe there is no extra process, and the compilation is taking place 
> in the same JVM that's running maven?
> If so, what went wrong?  Did an exception get thrown?  Something else?
>
> You get the idea.
>
>
> This message is for information purposes only. It is not a 
> recommendation, advice, offer or solicitation to buy or sell a product 
> or service, nor an official confirmation of any transaction. It is 
> directed at persons who are professionals and is intended for the 
> recipient(s) only. It is not directed at retail customers. This message is 
> subject to the terms at:
> https://clicktime.symantec.com/15sifLYAwPjLHCtCgybKg?h=ANvnaYG630AR0f2GLplpUfGbAsle9xaoL2f-FF_ESsU==https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.
>
> For important disclosures, please see:
> https://clicktime.symantec.com/15siaWLtUn3jsG4H9RCB4?h=M6FIGRVBH8G_LIh
> m9t5V7SPthNcb5IVYLL7498zEnzg==https://www.cib.barclays/disclosures/s
> ales-and-trading-disclaimer.html regarding marketing commentary from 
> Barclays Sales and/or Trading desks, who are active market 
> participants; 
> https://clicktime.symantec.com/15siL1m36vzxdRaWWjzjC?h=G7ajSU4AyuCbxlw
> vIlksn83RCALP2_zHmu0XbnqwDpE==https://www.cib.barclays/disclosures/b
> arclays-global-markets-disclosures.html
> regarding our standard terms for Barclays Corporate and Investment 
> Bank where we trade with you in principal-to-principal wholesale 
> markets transactions; and in respect to Barclays Research, including 
> disclosures relating to specific issuers, see: 
> https://clicktime.symantec.com/15siFBZkeKKNDUkayBbaa?h=G2aTqP2GUKb-ZJb3VDe2qGDqjn4glmlwiYEU-U9Qp08==http://publicresearch.barclays.com.
> __
> 
>
> If you are incorporated or operating in Australia, read these 
> important
> disclosures:
> https://clicktime.symantec.com/15siQqxKZYgZ3NQS4JPsp?h=_wyBE5fSRVnrjCX
> _RdiyqX2Tzqlr_fF2jEBUkk9zsjg==https://www.cib.barclays/disclosures/i
> mportant-disclosures-asia-pacific.html
> .
>
> __
>  For more details about how we use personal information, 
> see our privacy
> notice: 
> https://clicktime.symantec.com/15siVg9c2AN9TKEMbro2S?h=YTZNN6svma8VJfLaKz8L06dizNzYH3spp4UdRQF7gVo==https://www.cib.barclays/disclosures/personal-information-use.html.
>
>
> __
> 

This message is for information purposes only. It

RE: maven debugging frustrations

Thanks, I've heard of all three; the first two don't seem like they'd help here.
The third tends to spew junk and not useful stuff

-Original Message-
From: Mark Eggers  
Sent: Tuesday, December 19, 2023 5:11 PM
To: users@maven.apache.org
Subject: Re: maven debugging frustrations


CAUTION: This email originated from outside our organisation - 
its_toas...@yahoo.com.INVALID Do not click on links, open attachments, or 
respond unless you recognize the sender and can validate the content is safe.
Some commands that might help you get started:

What are you using to build the artifact

mvn help:effective-pom
mvn help:effective-pom -Dverbose

What artifacts are being brought in
--
mvn dependency:tree
mvn dependency:tree -Dverbose

Debug output
--
mvn -X package

I'm sure that there are more, but this might get you started.

. . . just my two cents
/mde/

On 12/19/2023 1:56 PM, mark.yagnatin...@barclays.com.INVALID wrote:
> When my Java code does something I didn't expect, I can run it under a 
> debugger and step through it line by line until things make sense again.
> When maven does something I didn't expect, my debugging strategy is usually 
> more like "try to think of something in my bag of tricks".
> Sometimes I suddenly have an epiphany and I realize "oh, it must have broken 
> because of that thing I changed".
> But in the absence of epiphanies, I don't have any good ways to ask maven to 
> tell me what on earth is going on.
> 
> Example from today: some is failing on our build server with "Compilation 
> failure".
> Looking at the build log, there are no compiler errors in sight.
> There are a few compiler warnings, and those seem to logged twice: once at 
> warning level, and then again at error level.
> It only fails on SOME (not all) of our build configs, even though our configs 
> are pretty darn similar to each other.
> 
> So I'm left flailing around more or less at random (try compiling on a 
> different server!  Try copying the command line flags from the one that work! 
>  Etc.) What I actually want is for maven to give me some CRUMB of visibility 
> into what on earth is going wrong.
> 
> I don't even know what "Compilation failure" actually means.
> Did some process exit with non-zero status?
> Did the process fail to launch in the first place?
> Maybe there is no extra process, and the compilation is taking place in the 
> same JVM that's running maven?
> If so, what went wrong?  Did an exception get thrown?  Something else?
> 
> You get the idea.
> 
> 
> This message is for information purposes only. It is not a recommendation, 
> advice, offer or solicitation to buy or sell a product or service, nor an 
> official confirmation of any transaction. It is directed at persons who are 
> professionals and is intended for the recipient(s) only. It is not directed 
> at retail customers. This message is subject to the terms at: 
> https://clicktime.symantec.com/15t5z4LpKs5nXMa3HxmPT?h=ISgjwiKtVs_26S9D5WklDpkGWg5FN4KBfDXNiomU8xw==https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.
> 
> For important disclosures, please see: 
> https://clicktime.symantec.com/15t5uE9XsFQC7Qk7kQNEq?h=GqPl7-MY2KIl75o5H8ob4oRWV5EdZOb-0TiUB8Oz1g8==https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html
>  regarding marketing commentary from Barclays Sales and/or Trading desks, who 
> are active market participants; 
> https://clicktime.symantec.com/15t5ejZgVQMQsaGM7jAny?h=TSMoSLWLMSCFVE_msBvk3E-bNX152eJ1jQtsfE-VVu0==https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html
>  regarding our standard terms for Barclays Corporate and Investment Bank 
> where we trade with you in principal-to-principal wholesale markets 
> transactions; and in respect to Barclays Research, including disclosures 
> relating to specific issuers, see: 
> https://clicktime.symantec.com/15t5ZuNQ2nfpTdSRaAmeM?h=skuGBe0-9p6Q6bKdLkfmjGMNe-r_OrCz4yP_Du-cGJI==http://publicresearch.barclays.com.
> __
>  If you are incorporated or operating in Australia, read 
> these important disclosures: 
> https://clicktime.symantec.com/15t5jZkxx231HX6GfHZwb?h=59l9AYOa74derd2shOK9ydN_NsfU5EV4DDyy0lC20Qk==https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
> __
>  For more details about how we use personal information, 
> see our privacy notice: 
> https://clicktime.symantec.com/15t5pPxFQdibhTvCCqy6D?h=M5qHmn-V09pHP54DC8CQtxPowDPpTqQn567A_MYEi38==https://www.cib.barclays/disclosures/personal-information-use.html.
> __
> 
> 


-
To unsubscribe, e-mail:

maven debugging frustrations

When my Java code does something I didn't expect, I can run it under a debugger 
and step through it line by line until things make sense again.
When maven does something I didn't expect, my debugging strategy is usually 
more like "try to think of something in my bag of tricks".
Sometimes I suddenly have an epiphany and I realize "oh, it must have broken 
because of that thing I changed".
But in the absence of epiphanies, I don't have any good ways to ask maven to 
tell me what on earth is going on.

Example from today: some is failing on our build server with "Compilation 
failure".
Looking at the build log, there are no compiler errors in sight.
There are a few compiler warnings, and those seem to logged twice: once at 
warning level, and then again at error level.
It only fails on SOME (not all) of our build configs, even though our configs 
are pretty darn similar to each other.

So I'm left flailing around more or less at random (try compiling on a 
different server!  Try copying the command line flags from the one that work!  
Etc.)
What I actually want is for maven to give me some CRUMB of visibility into what 
on earth is going wrong.

I don't even know what "Compilation failure" actually means.
Did some process exit with non-zero status?
Did the process fail to launch in the first place?
Maybe there is no extra process, and the compilation is taking place in the 
same JVM that's running maven?
If so, what went wrong?  Did an exception get thrown?  Something else?

You get the idea.


This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__
 
If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

RE: Maven 4.0 release timeline

Thank you!  I'd seen [4] but not sure if I've seen [2]

-Original Message-
From: Maarten Mulders  
Sent: Tuesday, December 19, 2023 9:07 AM
To: users@maven.apache.org
Subject: Re: Maven 4.0 release timeline


CAUTION: This email originated from outside our organisation - 
mthmuld...@apache.org Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
On 18/12/2023 21:38, mark.yagnatin...@barclays.com.INVALID wrote:
> I'm not the original asker but this kind of answer tends to annoy me.
> Yes, there is no "official" release timeline, you're obviously not going to 
> promise anything, all this is (hopefully?) clear, BUT!
> You no doubt have GUESSES.  And your guesses are no doubt better than that of 
> most uninformed outsiders.
> As an outsider, I have no idea what the "status" of maven 4 is, and I can't 
> even begin to guess how I would find out.
> Should I try to catch up on the last few years of traffic on the developer 
> email lists?
> Or perhaps the answer can be divined from the issue tracker?  If so, how?
> Is it expected that alpha-10 will be the last alpha, and the next build will 
> be a beta?
> If that is NOT what you expect, then what's the primary hold up?
> Are there major features that have yet to be implemented?
> Or perhaps the features are mostly done but they're still a bit buggy?
> Or perhaps the code quality is pretty solid and you just want to reserve the 
> right to make backwards incompatible changes, and there's a policy to not do 
> that after hitting beta?
> 
> You get the idea.  As an insider, you probably think to yourself "there's no 
> telling when we'll be done; it depends on a zillion unpredictable things".
> But as outsiders, we don't even know whether the ETA is a few months or a few 
> years or a few decades or perhaps just a few weeks.
> 
> Sorry if that came off as a bit of a rant :)
The good news is, you don't have to read the mailing list history, nor dive 
into the issue tracker, nor read the git history. If you're curious what Maven 
4 will bring, I can highly recommend watching Karl-Heinz' 
talk [1]. Don't feel like watching somebody talk? You can read about some 
interesting articles and documentation: [2], [3], [4].

Hope this helps,


Maarten


[1] 
https://clicktime.symantec.com/15sMvS6QDE6q6Jf47vc58?h=tZSjeMLRMnL1sHS93b7vt02NnPNvJwK6-ee8iyLMi5Q==https://youtu.be/fHeVMbQNbgQ
[2] 
https://clicktime.symantec.com/15sMFnY8YJe5nk3fmTQtA?h=sQem5P67RYOhsiW9Hm_YeD-PIfsaReOsBbMYvlLdgRk==https://maven.apache.org/guides/mini/guide-multiple-modules-4.html
[3] 
https://clicktime.symantec.com/15sM1HxHATbJYuZu8nDSJ?h=s87AfscrtMWpDN9FZxBHl_MjXK1i_ohGn2TWRZhFFZ4==https://cwiki.apache.org/confluence/display/MAVEN/Build%2Bvs%2BConsumer%2BPOM
[4] 
https://clicktime.symantec.com/15sMqbu7kcREgMq8aNCvW?h=2OV2Xb8OY1yozkosb4XLJzGzmH5eCx0rkkaq0thqbr4==https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html

PS. Most of the above was exactly one Google search away...: "Maven 4"

> -Original Message-
> From: Karl Heinz Marbaise 
> Sent: Monday, December 18, 2023 3:18 PM
> To: Maven Users List ; Debraj Manna 
> 
> Subject: Re: Maven 4.0 release timeline
> 
> 
> CAUTION: This email originated from outside our organisation - 
> khmarba...@gmx.de.INVALID Do not click on links, open attachments, or respond 
> unless you recognize the sender and can validate the content is safe.
> On 18.12.23 06:27, Debraj Manna wrote:
>> Can someone let me know when Maven 4 is expected to be released? 
>> Where can I view its release timelines?
>>
> 
> We are an open source project. We don't have a release timeline.
> 
> Maven 4.0.0 will be there when it's there.
> 
> 
> If you want to help testing, there is 4.0.0-alpha-9 version available (at the 
> moment the VOTE for 4.0.0-alpha-10 is running developers list)..
> 
> 
> https://clicktime.symantec.com/15t5ejZL3AGSyEFA9Aedx?h=ABJzOQGm-e1Zxyu
> IqUZPLWnHHC2LmzcP6V9UINAuTSc==https://clicktime.symantec.com/15sMAxL
> r5gxVNoDkDu1jY?h=lGNs3g5AnciCA2HSNIITSI2TzCNDkS7EjB0SRrsw440==https:
> //maven.apache.org/download.cgi 
> https://clicktime.symantec.com/15t5ZuN3aYarZHREbcFVL?h=f4YJm-aS7T_bpjO
> AtqB_jneksRphxbi0aG911AdXT1E==https://clicktime.symantec.com/15sM689
> Zd5GtxrPpgLcav?h=8GPvTtEcgEXNG4zPkAQ3LoyxGccbyRmjBVaF3LY1HGg==https:
> //maven.apache.org/docs/history.html
> https://clicktime.symantec.com/15t5jZkcVmx3PB55gj3na?h=L9e7tA5cT0v2zyk
> QUoinwwWFS6c1VuE5zuM7Lmb8XwE==https://clicktime.symantec.com/15sMLcj
> QzvKgCgsbK1p2n?h=jkEzmq-Y4oP85Q2r7HHtDgUjlaVOr5JoAdOAtuuV1_M==https:
> //maven.apache.org/mailing-lists.html
> 
> Kind regards
> Karl Heinz Marbaise
> Apache Maven PMC Chairman
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> This message is for information purposes only. It is not a recommendation, 
> advice,

RE: Maven 4.0 release timeline

Maybe in a few days; bit busy now

-Original Message-
From: Karl Heinz Marbaise  
Sent: Monday, December 18, 2023 5:31 PM
To: Maven Users List ; Tamás Cservenák 

Cc: subharaj.ma...@gmail.com
Subject: Re: Maven 4.0 release timeline


CAUTION: This email originated from outside our organisation - 
khmarba...@gmx.de.INVALID Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
Hi,

first try to build your whole project on plain command lineand see if there 
are issuesafter that you can try your IDE .. because IntelliJ has an 
integrated version and also the support is not really ready to use...

Kind regards
Karl Heinz Marbaise

On 18.12.23 23:19, Tamás Cservenák wrote:
> Well, IDE integrations are completely different stuff... What IDE do 
> you use?
> Can I recommend you to try it out in Terminal instead?
>
> T
>
> On Mon, Dec 18, 2023 at 11:18 PM 
> 
> wrote:
>
>> Thanks!  Just tried in my IDE and it failed, but not sure if that's 
>> an issue with maven or with IDE.
>> (I have a multi-module project and it tried to download the 
>> submodules instead of using the local source code)
>>
>> -Original Message-
>> From: Tamás Cservenák 
>> Sent: Monday, December 18, 2023 5:08 PM
>> To: Maven Users List 
>> Cc: subharaj.ma...@gmail.com
>> Subject: Re: Maven 4.0 release timeline
>>
>>
>> CAUTION: This email originated from outside our organisation - 
>> ta...@cservenak.net Do not click on links, open attachments, or 
>> respond unless you recognize the sender and can validate the content is safe.
>> Howdy,
>>
>> And to reply to the "longer stuff":
>>
>> Current Maven 4 (on vote, so 3 days if vote passes OK and files land 
>> on
>> Central) is alpha-10.
>>
>> As with any previous alphas, the _minimal_ requirement is that UT 
>> passes, Maven can build itself, and that to pass Maven IT suite. IT 
>> suite is currently, in this very moment 909 IT tests, but they grow 
>> constantly, as new bugs or new features are added, this link 
>> https://clicktime.symantec.com/15sM1Hx4Zk69FcT4Re31T?h=WCNYF5iZoo32qX
>> 5Hxyc8Qrzhc1t-HKpREAcWNL1r7t8==https://clicktime.symantec.com/15sj5
>> VWGSSW9CHmqwWrJs?h=N31csPuuuQTu-1oAB5Fetjawr4BnXA0U0_-zq3Bs0Sc==htt
>> ps://github.com/apache/maven-integration-testing/pulse/monthly
>> shows there were 3 ITs added last, two bugs from alpha-9 and new 
>> feature regarding plugin validation.
>>
>> As a downer, Maven 4 alpha-11 is FOR SURE expected, already scheduled:
>>
>> https://clicktime.symantec.com/15sMAxLdUyTL5W6uWkqJh?h=KbxkwIqLoMQYfH
>> x5OCZ4V-Mu7NdrW7MXjqNgyyl25so==https://clicktime.symantec.com/15sjF
>> 9tqMfsL2BRh2dec7?h=1evXF26Gzpa0Krssovdj2HNo6CGS1V6y26hJOwANd2k==htt
>> ps://issues.apache.org/jira/issues/?jql%253Dproject%252520%25253D%252
>> 520MNG%252520AND%252520fixVersion%252520%25253D%2525204.0.0-alpha-11
>>
>> Currently we work on stabilizing resolver and maven (both are 
>> alphas!), and ironing out the new Maven 4 API (thus converting MANY 
>> core plugins to use new API), see here:
>> https://clicktime.symantec.com/15sM689M2MmjfZGyyCSA5?h=7_-nR2qTzP6RIZ
>> LBqH9pHMeQfYQjGw5njIatpLSW6_U==https://clicktime.symantec.com/15sjA
>> KhYu4BjcEbmV5FTV?h=1QJfXyg3BSkXmL-qwnGLUV0OfnM-gcu_tzDmFwTiVJM==htt
>> ps://github.com/apache/maven/pull/1048
>>
>> Basically we make sure that the new API delivers _everything_ we need 
>> in core plugins, and even more, as some information trickles from 
>> third party plugins as well. We have to do this "intelligence" work 
>> in alpha, where we can break APIs, as we really need to adjust, adapt 
>> and make sure all this once is set in stone (released as final), will 
>> work out for everyone doing plugin development.
>>
>> Good news is that Resolver 2.0.0 is pretty much "done":
>>
>> https://clicktime.symantec.com/15sMFnXuwb8vVSvq4KETK?h=djE-5RAYZwC_J0
>> iiRHe3cw4LXST_S1deoAEfdJrJlfU==https://clicktime.symantec.com/15sjK
>> z67pHYvS8FcaC3kj?h=u5oDOalOCJxUi7MPsFnuy7trUegXhRSa2RzOsLrQgks==htt
>> ps://issues.apache.org/jira/issues/?jql%253Dproject%252520%25253D%252
>> 520MRESOLVER%252520AND%252520fixVersion%252520%25253D%2525202.0.0-alp
>> ha-6
>>
>> I am not saying "resolver is done-done", just that we are "over the 
>> hill", as regarding issue numbers over there. Most probably will have 
>> some lurking bugs, like the last one was in Resolver 2 alpha-3 
>> (plagues Maven 4 alpha-9) about new "jdk" transport. And for sure 
>> will have bugs regarding new transport features, as they are not ironed out 
>> fully.
>>
>> Maven core is completely different, especially due to its API. Hence, 
>> the more (intel) we get the merrier, as we see "core plugins" only.
>>
>> So please try out, test it and report back.
>>
>> Thanks
>> T
>>
>> On Mon, Dec 18, 2023 at 9:39 PM 
>> 
>> wrote:
>>
>>> I'm not the original asker but this kind of answer tends to annoy me.
>>> Yes, there is no "official" release timeline, you're obviously not 
>>> going to promise anything,

RE: Maven 4.0 release timeline

IntelliJ ... usually I just use whatever maven version it happens to bundle, 
but I've heard rumors that maven 4 should handle multi-module stuff better so 
I've vaguely been keeping an eye on it

-Original Message-
From: Tamás Cservenák  
Sent: Monday, December 18, 2023 5:20 PM
To: Maven Users List 
Cc: subharaj.ma...@gmail.com
Subject: Re: Maven 4.0 release timeline


CAUTION: This email originated from outside our organisation - 
ta...@cservenak.net Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.
Well, IDE integrations are completely different stuff... What IDE do you use?
Can I recommend you to try it out in Terminal instead?

T

On Mon, Dec 18, 2023 at 11:18 PM 
wrote:

> Thanks!  Just tried in my IDE and it failed, but not sure if that's an 
> issue with maven or with IDE.
> (I have a multi-module project and it tried to download the submodules 
> instead of using the local source code)
>
> -Original Message-
> From: Tamás Cservenák 
> Sent: Monday, December 18, 2023 5:08 PM
> To: Maven Users List 
> Cc: subharaj.ma...@gmail.com
> Subject: Re: Maven 4.0 release timeline
>
>
> CAUTION: This email originated from outside our organisation - 
> ta...@cservenak.net Do not click on links, open attachments, or 
> respond unless you recognize the sender and can validate the content is safe.
> Howdy,
>
> And to reply to the "longer stuff":
>
> Current Maven 4 (on vote, so 3 days if vote passes OK and files land 
> on
> Central) is alpha-10.
>
> As with any previous alphas, the _minimal_ requirement is that UT 
> passes, Maven can build itself, and that to pass Maven IT suite. IT 
> suite is currently, in this very moment 909 IT tests, but they grow 
> constantly, as new bugs or new features are added, this link 
> https://clicktime.symantec.com/15sM1Hx4Zk69FcT4Re31T?h=WCNYF5iZoo32qX5
> Hxyc8Qrzhc1t-HKpREAcWNL1r7t8==https://clicktime.symantec.com/15sj5VW
> GHwgCHZYsZ3nnh?h=O7iEWm-fEX6HdY2D9eYFiUaEdjHxnPwBRubwTpoAm1o==https:
> //github.com/apache/maven-integration-testing/pulse/monthly
> shows there were 3 ITs added last, two bugs from alpha-9 and new 
> feature regarding plugin validation.
>
> As a downer, Maven 4 alpha-11 is FOR SURE expected, already scheduled:
>
> https://clicktime.symantec.com/15sMAxLdUyTL5W6uWkqJh?h=KbxkwIqLoMQYfHx
> 5OCZ4V-Mu7NdrW7MXjqNgyyl25so==https://clicktime.symantec.com/15sjF9t
> qDB3P7TCieAb5w?h=UMU_-mbldlcP65eQDNf5hy6U3NVj6fPnwEOOTVDWUdg==https:
> //issues.apache.org/jira/issues/?jql%253Dproject%252520%25253D%252520M
> NG%252520AND%252520fixVersion%252520%25253D%2525204.0.0-alpha-11
>
> Currently we work on stabilizing resolver and maven (both are 
> alphas!), and ironing out the new Maven 4 API (thus converting MANY 
> core plugins to use new API), see here:
> https://clicktime.symantec.com/15sM689M2MmjfZGyyCSA5?h=7_-nR2qTzP6RIZL
> BqH9pHMeQfYQjGw5njIatpLSW6_U==https://clicktime.symantec.com/15sjAKh
> YkZMnhWNo6cBwK?h=Svfe2pjKCEc8Mk7k_t1v2Lzcapu-QgXgTLrpQ5O7LAE==https:
> //github.com/apache/maven/pull/1048
>
> Basically we make sure that the new API delivers _everything_ we need 
> in core plugins, and even more, as some information trickles from 
> third party plugins as well. We have to do this "intelligence" work in 
> alpha, where we can break APIs, as we really need to adjust, adapt and 
> make sure all this once is set in stone (released as final), will work 
> out for everyone doing plugin development.
>
> Good news is that Resolver 2.0.0 is pretty much "done":
>
> https://clicktime.symantec.com/15sMFnXuwb8vVSvq4KETK?h=djE-5RAYZwC_J0i
> iRHe3cw4LXST_S1deoAEfdJrJlfU==https://clicktime.symantec.com/15sjKz6
> 7fniyXQ2eBizEZ?h=LIaaif-xB_9uU3fb-LNgpaSq3WSbzJHuW2lTuF16AJU==https:
> //issues.apache.org/jira/issues/?jql%253Dproject%252520%25253D%252520M
> RESOLVER%252520AND%252520fixVersion%252520%25253D%2525202.0.0-alpha-6
>
> I am not saying "resolver is done-done", just that we are "over the 
> hill", as regarding issue numbers over there. Most probably will have 
> some lurking bugs, like the last one was in Resolver 2 alpha-3 
> (plagues Maven 4 alpha-9) about new "jdk" transport. And for sure will 
> have bugs regarding new transport features, as they are not ironed out fully.
>
> Maven core is completely different, especially due to its API. Hence, 
> the more (intel) we get the merrier, as we see "core plugins" only.
>
> So please try out, test it and report back.
>
> Thanks
> T
>
> On Mon, Dec 18, 2023 at 9:39 PM 
> 
> wrote:
>
> > I'm not the original asker but this kind of answer tends to annoy me.
> > Yes, there is no "official" release timeline, you're obviously not 
> > going to promise anything, all this is (hopefully?) clear, BUT!
> > You no doubt have GUESSES.  And your guesses are no doubt better 
> > than that of most uninformed outsiders.
> > As an outsider, I have no idea what the "status" of maven 4 is, and 
> > I can't even begin to guess how I would find out.
> >

RE: Maven 4.0 release timeline

Thanks!  Just tried in my IDE and it failed, but not sure if that's an issue 
with maven or with IDE.
(I have a multi-module project and it tried to download the submodules instead 
of using the local source code)

-Original Message-
From: Tamás Cservenák  
Sent: Monday, December 18, 2023 5:08 PM
To: Maven Users List 
Cc: subharaj.ma...@gmail.com
Subject: Re: Maven 4.0 release timeline

CAUTION: This email originated from outside our organisation - 
ta...@cservenak.net Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.
Howdy,

And to reply to the "longer stuff":

Current Maven 4 (on vote, so 3 days if vote passes OK and files land on
Central) is alpha-10.

As with any previous alphas, the _minimal_ requirement is that UT passes, Maven 
can build itself, and that to pass Maven IT suite. IT suite is currently, in 
this very moment 909 IT tests, but they grow constantly, as new bugs or new 
features are added, this link 
https://clicktime.symantec.com/15sM1Hx4Zk69FcT4Re31T?h=WCNYF5iZoo32qX5Hxyc8Qrzhc1t-HKpREAcWNL1r7t8==https://github.com/apache/maven-integration-testing/pulse/monthly
 shows there were 3 ITs added last, two bugs from alpha-9 and new feature 
regarding plugin validation.

As a downer, Maven 4 alpha-11 is FOR SURE expected, already scheduled:
https://clicktime.symantec.com/15sMAxLdUyTL5W6uWkqJh?h=KbxkwIqLoMQYfHx5OCZ4V-Mu7NdrW7MXjqNgyyl25so==https://issues.apache.org/jira/issues/?jql%3Dproject%2520%253D%2520MNG%2520AND%2520fixVersion%2520%253D%25204.0.0-alpha-11

Currently we work on stabilizing resolver and maven (both are alphas!), and 
ironing out the new Maven 4 API (thus converting MANY core plugins to use new 
API), see here: 
https://clicktime.symantec.com/15sM689M2MmjfZGyyCSA5?h=7_-nR2qTzP6RIZLBqH9pHMeQfYQjGw5njIatpLSW6_U==https://github.com/apache/maven/pull/1048

Basically we make sure that the new API delivers _everything_ we need in core 
plugins, and even more, as some information trickles from third party plugins 
as well. We have to do this "intelligence" work in alpha, where we can break 
APIs, as we really need to adjust, adapt and make sure all this once is set in 
stone (released as final), will work out for everyone doing plugin development.

Good news is that Resolver 2.0.0 is pretty much "done":
https://clicktime.symantec.com/15sMFnXuwb8vVSvq4KETK?h=djE-5RAYZwC_J0iiRHe3cw4LXST_S1deoAEfdJrJlfU==https://issues.apache.org/jira/issues/?jql%3Dproject%2520%253D%2520MRESOLVER%2520AND%2520fixVersion%2520%253D%25202.0.0-alpha-6

I am not saying "resolver is done-done", just that we are "over the hill", as 
regarding issue numbers over there. Most probably will have some lurking bugs, 
like the last one was in Resolver 2 alpha-3 (plagues Maven 4 alpha-9) about new 
"jdk" transport. And for sure will have bugs regarding new transport features, 
as they are not ironed out fully.

Maven core is completely different, especially due to its API. Hence, the more 
(intel) we get the merrier, as we see "core plugins" only.

So please try out, test it and report back.

Thanks
T

On Mon, Dec 18, 2023 at 9:39 PM 
wrote:

> I'm not the original asker but this kind of answer tends to annoy me.
> Yes, there is no "official" release timeline, you're obviously not 
> going to promise anything, all this is (hopefully?) clear, BUT!
> You no doubt have GUESSES.  And your guesses are no doubt better than 
> that of most uninformed outsiders.
> As an outsider, I have no idea what the "status" of maven 4 is, and I 
> can't even begin to guess how I would find out.
> Should I try to catch up on the last few years of traffic on the 
> developer email lists?
> Or perhaps the answer can be divined from the issue tracker?  If so, how?
> Is it expected that alpha-10 will be the last alpha, and the next 
> build will be a beta?
> If that is NOT what you expect, then what's the primary hold up?
> Are there major features that have yet to be implemented?
> Or perhaps the features are mostly done but they're still a bit buggy?
> Or perhaps the code quality is pretty solid and you just want to 
> reserve the right to make backwards incompatible changes, and there's 
> a policy to not do that after hitting beta?
>
> You get the idea.  As an insider, you probably think to yourself 
> "there's no telling when we'll be done; it depends on a zillion 
> unpredictable things".
> But as outsiders, we don't even know whether the ETA is a few months 
> or a few years or a few decades or perhaps just a few weeks.
>
> Sorry if that came off as a bit of a rant :)
>
>
> -Original Message-
> From: Karl Heinz Marbaise 
> Sent: Monday, December 18, 2023 3:18 PM
> To: Maven Users List ; Debraj Manna < 
> subharaj.ma...@gmail.com>
> Subject: Re: Maven 4.0 release timeline
>
>
> CAUTION: This email originated from outside our organisation - 
> khmarba...@gmx.de.INVALID Do not click on links, open attachments, or 
> respond unless you recognize the

RE: Maven 4.0 release timeline

Ah, much better!  I guess I can ignore the cyclondex files and grab a plain old 
zip?

-Original Message-
From: Tamás Cservenák  
Sent: Monday, December 18, 2023 3:49 PM
To: Maven Users List 
Cc: subharaj.ma...@gmail.com
Subject: Re: Maven 4.0 release timeline


CAUTION: This email originated from outside our organisation - 
ta...@cservenak.net Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.
I really recommend alpha10, distros are here 
https://clicktime.symantec.com/15t6V3WB3Q9UkWhf5JPD6?h=DNfkwbsM2Nbwr9Re8FSzo--npL69CABPYMYoaHsSC-A==https://repository.apache.org/content/repositories/maven-2050/org/apache/maven/apache-maven/4.0.0-alpha-10/

Thanks
T

On Mon, Dec 18, 2023, 21:48  wrote:

> Navigating that directory tree seems a bit intimidating... can I try
> alpha-8 or better wait for alpha-10 to officially come out?
>
> -Original Message-
> From: Tamás Cservenák 
> Sent: Monday, December 18, 2023 3:43 PM
> To: Maven Users List 
> Cc: subharaj.ma...@gmail.com
> Subject: Re: Maven 4.0 release timeline
>
>
> CAUTION: This email originated from outside our organisation - 
> ta...@cservenak.net Do not click on links, open attachments, or 
> respond unless you recognize the sender and can validate the content is safe.
> ...or,.just go to staging repo
>
> https://clicktime.symantec.com/15siaWLYGbnA1MrGqWQwt?h=qkVv-eG-rGmVca6
> UeWqg9iHAifq1sVHsvsDmSfLKZ2o==https://clicktime.symantec.com/15t6QDJ
> tanTtLZsjXjz4U?h=4Jzcps2egc7Hk1dplHDiulcv9nRA0wSTiAQlv1W8Bro==https:
> //repository.apache.org/content/repositories/maven-2050
> download the distro and try on some of your projects?
>
> In case of problems be so kind to report the issues so we can iron 
> them out.
>
> Imho, alpha 10 is in very good shape. Alpha-9 had a nasty bug and 
> could remain running the process. Do not use it.
>
> Thanks
> T
>
> On Mon, Dec 18, 2023, 21:39  wrote:
>
> > I'm not the original asker but this kind of answer tends to annoy me.
> > Yes, there is no "official" release timeline, you're obviously not 
> > going to promise anything, all this is (hopefully?) clear, BUT!
> > You no doubt have GUESSES.  And your guesses are no doubt better 
> > than that of most uninformed outsiders.
> > As an outsider, I have no idea what the "status" of maven 4 is, and 
> > I can't even begin to guess how I would find out.
> > Should I try to catch up on the last few years of traffic on the 
> > developer email lists?
> > Or perhaps the answer can be divined from the issue tracker?  If so, how?
> > Is it expected that alpha-10 will be the last alpha, and the next 
> > build will be a beta?
> > If that is NOT what you expect, then what's the primary hold up?
> > Are there major features that have yet to be implemented?
> > Or perhaps the features are mostly done but they're still a bit buggy?
> > Or perhaps the code quality is pretty solid and you just want to 
> > reserve the right to make backwards incompatible changes, and 
> > there's a policy to not do that after hitting beta?
> >
> > You get the idea.  As an insider, you probably think to yourself 
> > "there's no telling when we'll be done; it depends on a zillion 
> > unpredictable things".
> > But as outsiders, we don't even know whether the ETA is a few months 
> > or a few years or a few decades or perhaps just a few weeks.
> >
> > Sorry if that came off as a bit of a rant :)
> >
> >
> > -Original Message-
> > From: Karl Heinz Marbaise 
> > Sent: Monday, December 18, 2023 3:18 PM
> > To: Maven Users List ; Debraj Manna < 
> > subharaj.ma...@gmail.com>
> > Subject: Re: Maven 4.0 release timeline
> >
> >
> > CAUTION: This email originated from outside our organisation - 
> > khmarba...@gmx.de.INVALID Do not click on links, open attachments, 
> > or respond unless you recognize the sender and can validate the 
> > content is safe.
> > On 18.12.23 06:27, Debraj Manna wrote:
> > > Can someone let me know when Maven 4 is expected to be released?
> > > Where can I view its release timelines?
> > >
> >
> > We are an open source project. We don't have a release timeline.
> >
> > Maven 4.0.0 will be there when it's there.
> >
> >
> > If you want to help testing, there is 4.0.0-alpha-9 version 
> > available (at the moment the VOTE for 4.0.0-alpha-10 is running developers 
> > list)..
> >
> >
> >
> > https://clicktime.symantec.com/15t6EYvKfZ6hWgDtSdBmE?h=enuexfuM5c9xR
> > Z5X0oZzhj669n395kTA5hIdhUOxXyY==https://clicktime.symantec.com/15t
> > 5ejZL3AGSyEFA9Aedx?h%3DABJzOQGm-e1Zxyu
> > IqUZPLWnHHC2LmzcP6V9UINAuTSc==https://clicktime.symantec.com/15t5j
> > Zkcus1931GMBGnsW?h=aAZLedKsowXWW-3Z-WnWmkI4H71A9BrQiqYTxH6hqWk==ht
> > tps://clicktime.symantec.com/15siQqw
> > yMNQyBUCRkPcee?h=-wnFgkT4h16bjz0t2Vuc_NutxQbPp0L_p6KY3P3WB2E==https:
> > //maven.apache.org/download.cgi
> >
> > https://clicktime.symantec.com/15t69ij3CwR76jPxu4ncc?h=GfK7jRGQ-5KWG
> >

RE: Maven 4.0 release timeline

Navigating that directory tree seems a bit intimidating... can I try alpha-8 or 
better wait for alpha-10 to officially come out?

-Original Message-
From: Tamás Cservenák  
Sent: Monday, December 18, 2023 3:43 PM
To: Maven Users List 
Cc: subharaj.ma...@gmail.com
Subject: Re: Maven 4.0 release timeline


CAUTION: This email originated from outside our organisation - 
ta...@cservenak.net Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.
...or,.just go to staging repo
https://clicktime.symantec.com/15siaWLYGbnA1MrGqWQwt?h=qkVv-eG-rGmVca6UeWqg9iHAifq1sVHsvsDmSfLKZ2o==https://repository.apache.org/content/repositories/maven-2050
 download the distro and try on some of your projects?

In case of problems be so kind to report the issues so we can iron them out.

Imho, alpha 10 is in very good shape. Alpha-9 had a nasty bug and could remain 
running the process. Do not use it.

Thanks
T

On Mon, Dec 18, 2023, 21:39  wrote:

> I'm not the original asker but this kind of answer tends to annoy me.
> Yes, there is no "official" release timeline, you're obviously not 
> going to promise anything, all this is (hopefully?) clear, BUT!
> You no doubt have GUESSES.  And your guesses are no doubt better than 
> that of most uninformed outsiders.
> As an outsider, I have no idea what the "status" of maven 4 is, and I 
> can't even begin to guess how I would find out.
> Should I try to catch up on the last few years of traffic on the 
> developer email lists?
> Or perhaps the answer can be divined from the issue tracker?  If so, how?
> Is it expected that alpha-10 will be the last alpha, and the next 
> build will be a beta?
> If that is NOT what you expect, then what's the primary hold up?
> Are there major features that have yet to be implemented?
> Or perhaps the features are mostly done but they're still a bit buggy?
> Or perhaps the code quality is pretty solid and you just want to 
> reserve the right to make backwards incompatible changes, and there's 
> a policy to not do that after hitting beta?
>
> You get the idea.  As an insider, you probably think to yourself 
> "there's no telling when we'll be done; it depends on a zillion 
> unpredictable things".
> But as outsiders, we don't even know whether the ETA is a few months 
> or a few years or a few decades or perhaps just a few weeks.
>
> Sorry if that came off as a bit of a rant :)
>
>
> -Original Message-
> From: Karl Heinz Marbaise 
> Sent: Monday, December 18, 2023 3:18 PM
> To: Maven Users List ; Debraj Manna < 
> subharaj.ma...@gmail.com>
> Subject: Re: Maven 4.0 release timeline
>
>
> CAUTION: This email originated from outside our organisation - 
> khmarba...@gmx.de.INVALID Do not click on links, open attachments, or 
> respond unless you recognize the sender and can validate the content 
> is safe.
> On 18.12.23 06:27, Debraj Manna wrote:
> > Can someone let me know when Maven 4 is expected to be released? 
> > Where can I view its release timelines?
> >
>
> We are an open source project. We don't have a release timeline.
>
> Maven 4.0.0 will be there when it's there.
>
>
> If you want to help testing, there is 4.0.0-alpha-9 version available 
> (at the moment the VOTE for 4.0.0-alpha-10 is running developers list)..
>
>
>
> https://clicktime.symantec.com/15t5ejZL3AGSyEFA9Aedx?h=ABJzOQGm-e1Zxyu
> IqUZPLWnHHC2LmzcP6V9UINAuTSc==https://clicktime.symantec.com/15siQqw
> yMNQyBUCRkPcee?h=-wnFgkT4h16bjz0t2Vuc_NutxQbPp0L_p6KY3P3WB2E==https:
> //maven.apache.org/download.cgi
>
> https://clicktime.symantec.com/15t5ZuN3aYarZHREbcFVL?h=f4YJm-aS7T_bpjO
> AtqB_jneksRphxbi0aG911AdXT1E==https://clicktime.symantec.com/15siL1k
> gtkjNmXNWCqDW2?h=BX1saw3vPZ85tRY4Qc9ZmbpOGkojF6vC2umq1TvP1eM==https:
> //maven.apache.org/docs/history.html
>
> https://clicktime.symantec.com/15t5jZkcVmx3PB55gj3na?h=L9e7tA5cT0v2zyk
> QUoinwwWFS6c1VuE5zuM7Lmb8XwE==https://clicktime.symantec.com/15siVg9
> Foz6ZbR2MHx1oG?h=C_JJFO_gli3dfK9BJoJ1t22_wu2YHA7V4ywpVxFiPlA==https:
> //maven.apache.org/mailing-lists.html
>
> Kind regards
> Karl Heinz Marbaise
> Apache Maven PMC Chairman
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
> This message is for information purposes only. It is not a 
> recommendation, advice, offer or solicitation to buy or sell a product 
> or service, nor an official confirmation of any transaction. It is 
> directed at persons who are professionals and is intended for the 
> recipient(s) only. It is not directed at retail customers. This message is 
> subject to the terms at:
> https://clicktime.symantec.com/15sizfJxZgC855ytZJQgz?h=3voR8g2XaCqfAjjZLcBvchvlPd7niApVYl9kKJuW4X0==https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.
>
> For important disclosures, please see:
>

RE: Maven 4.0 release timeline

I'm not the original asker but this kind of answer tends to annoy me.
Yes, there is no "official" release timeline, you're obviously not going to 
promise anything, all this is (hopefully?) clear, BUT!
You no doubt have GUESSES.  And your guesses are no doubt better than that of 
most uninformed outsiders.
As an outsider, I have no idea what the "status" of maven 4 is, and I can't 
even begin to guess how I would find out.
Should I try to catch up on the last few years of traffic on the developer 
email lists?
Or perhaps the answer can be divined from the issue tracker?  If so, how?
Is it expected that alpha-10 will be the last alpha, and the next build will be 
a beta?
If that is NOT what you expect, then what's the primary hold up?
Are there major features that have yet to be implemented?
Or perhaps the features are mostly done but they're still a bit buggy?
Or perhaps the code quality is pretty solid and you just want to reserve the 
right to make backwards incompatible changes, and there's a policy to not do 
that after hitting beta?

You get the idea.  As an insider, you probably think to yourself "there's no 
telling when we'll be done; it depends on a zillion unpredictable things".
But as outsiders, we don't even know whether the ETA is a few months or a few 
years or a few decades or perhaps just a few weeks.

Sorry if that came off as a bit of a rant :)

-Original Message-
From: Karl Heinz Marbaise  
Sent: Monday, December 18, 2023 3:18 PM
To: Maven Users List ; Debraj Manna 

Subject: Re: Maven 4.0 release timeline

CAUTION: This email originated from outside our organisation - 
khmarba...@gmx.de.INVALID Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
On 18.12.23 06:27, Debraj Manna wrote:
> Can someone let me know when Maven 4 is expected to be released? Where 
> can I view its release timelines?
>

We are an open source project. We don't have a release timeline.

Maven 4.0.0 will be there when it's there.

If you want to help testing, there is 4.0.0-alpha-9 version available (at the 
moment the VOTE for 4.0.0-alpha-10 is running developers list)..

https://clicktime.symantec.com/15t5ejZL3AGSyEFA9Aedx?h=ABJzOQGm-e1ZxyuIqUZPLWnHHC2LmzcP6V9UINAuTSc==https://maven.apache.org/download.cgi
https://clicktime.symantec.com/15t5ZuN3aYarZHREbcFVL?h=f4YJm-aS7T_bpjOAtqB_jneksRphxbi0aG911AdXT1E==https://maven.apache.org/docs/history.html
https://clicktime.symantec.com/15t5jZkcVmx3PB55gj3na?h=L9e7tA5cT0v2zykQUoinwwWFS6c1VuE5zuM7Lmb8XwE==https://maven.apache.org/mailing-lists.html

Kind regards
Karl Heinz Marbaise
Apache Maven PMC Chairman

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

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__

If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

RE: Question about HTTP blocking WARN

2023-12-13 Thread mark.yagnatinsky

Look at the second answer to this stack overflow question (the one with 151 
votes, not the one with 209)
https://stackoverflow.com/questions/67001968/how-to-disable-maven-blocking-external-http-repositories
Direct link to answer: https://stackoverflow.com/a/68394404/3273929
(but read the question first!  It's short and has good background)

-Original Message-
From: Asaf Mesika  
Sent: Wednesday, December 13, 2023 1:41 PM
To: Maven Users List 
Subject: Re: Question about HTTP blocking WARN


CAUTION: This email originated from outside our organisation - 
asaf.mes...@gmail.com Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
How do I unblock ? I searched in .mvn directory and found nothing. I don’t have 
a settings file

On Wed, 13 Dec 2023 at 17:50  wrote:

> Sorry, I failed to read your email carefully enough.
> Idea: try un-blocking HTTP, and see where it ends up downloading 
> things from.
>
> -Original Message-
> From: mark.yagnatin...@barclays.com.INVALID
> 
> Sent: Wednesday, December 13, 2023 10:47 AM
> To: users@maven.apache.org
> Subject: RE: Question about HTTP blocking WARN
>
>
> CAUTION: This email originated from outside our organisation - 
> mark.yagnatin...@barclays.com.INVALID Do not click on links, open 
> attachments, or respond unless you recognize the sender and can 
> validate the content is safe.
> See release notes for 3.8.1:
>
> https://clicktime.symantec.com/15sM687dBQmsAHdZzRg2R?h=vGmJxLiSHcBmfng
> K9X2tEIMgJvGX3EQZ2p_ZA8IE8vo==https://clicktime.symantec.com/15sM687
> fTyGuMBLR2CM2R?h=vJEKCCwUrBkrxG9qvgpjtvj4UuijkPM-jYzq_09Gv_8==https:
> //maven.apache.org/docs/3.8.1/release-notes.html
>
> -Original Message-
> From: Asaf Mesika 
> Sent: Wednesday, December 13, 2023 6:07 AM
> To: users@maven.apache.org
> Subject: Question about HTTP blocking WARN
>
>
> CAUTION: This email originated from outside our organisation - 
> asaf.mes...@gmail.com Do not click on links, open attachments, or 
> respond unless you recognize the sender and can validate the content is safe.
> Hi,
>
> I'm running Apache Maven 3.8.5 (using Maven Wrapper) for building 
> Apache Pulsar.
>
> I get the following WARN:
>
> [WARNING] Could not transfer metadata
> org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
> http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
> [WARNING] org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xmlfailed to 
> transfer from http://0.0.0.0/ during a previous attempt. This failure 
> was cached in the local repository and resolution will not be 
> reattempted until the update interval of maven-default-http-blocker 
> has elapsed or updates are forced. Original error: Could not transfer 
> metadata org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
> http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
> Downloading from maven-default-http-blocker:
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> [WARNING] Could not transfer metadata
> org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> [WARNING] org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xmlfailed to 
> transfer from http://0.0.0.0/ during a previous attempt. This failure 
> was cached in the local repository and resolution will not be 
> reattempted until the update interval of maven-default-http-blocker 
> has elapsed or updates are forced. Original error: Could not transfer 
> metadata org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> Downloading from maven-default-http-blocker:
> http://0.0.0.0/org/mongodb/bson/4.5.0-SNAPSHOT/maven-metadata.xml
> [WARNING] Could not transfer metadata
> org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> [
>
> I can't understand how to understand which repository in my pom.xml 
> has an http and not https repository based on this WARN message.
>
> I searched for  over any pom.xml file and didn't find 
> any http repository.
>
> Any help would be greatly appreciated. This is the latest master 
> branch of
> pulsar:
> https://clicktime.symantec.com/15sM1HvP1MbJwEWVUdwso?h=BeG4fi1jEwX3x_F
> z_0dLLaDa6HE7dTKsqsKwVd67Tcg==https://clicktime.symantec.com/15sLvTi
> zaiLPdE4JXAvu7?h%3DMSjyi1VB4cPbNJsglaLsboIIC2w3PxVFwT0C3b3tJjE%3D%26u%
> 3Dhttps://clicktime.symantec.com/15sM1HvLio6GkLoeSsGso?h%3Da4l_3miTQ9J
> pp9kBhV4g1A6nK9z3Xc4ThYeLnyNM6NM%3D%26u%3Dhttps://github.com/apache/pu

RE: Question about HTTP blocking WARN

2023-12-13 Thread mark.yagnatinsky

Sorry, I failed to read your email carefully enough.
Idea: try un-blocking HTTP, and see where it ends up downloading things from.

-Original Message-
From: mark.yagnatin...@barclays.com.INVALID 

Sent: Wednesday, December 13, 2023 10:47 AM
To: users@maven.apache.org
Subject: RE: Question about HTTP blocking WARN

CAUTION: This email originated from outside our organisation - 
mark.yagnatin...@barclays.com.INVALID Do not click on links, open attachments, 
or respond unless you recognize the sender and can validate the content is safe.
See release notes for 3.8.1:
https://clicktime.symantec.com/15sM687dBQmsAHdZzRg2R?h=vGmJxLiSHcBmfngK9X2tEIMgJvGX3EQZ2p_ZA8IE8vo==https://maven.apache.org/docs/3.8.1/release-notes.html

-Original Message-
From: Asaf Mesika  
Sent: Wednesday, December 13, 2023 6:07 AM
To: users@maven.apache.org
Subject: Question about HTTP blocking WARN

CAUTION: This email originated from outside our organisation - 
asaf.mes...@gmail.com Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
Hi,

I'm running Apache Maven 3.8.5 (using Maven Wrapper) for building Apache Pulsar.

I get the following WARN:

[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
[WARNING] org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xmlfailed to transfer 
from http://0.0.0.0/ during a previous attempt. This failure was cached in the 
local repository and resolution will not be reattempted until the update 
interval of maven-default-http-blocker has elapsed or updates are forced. 
Original error: Could not transfer metadata 
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[WARNING] org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xmlfailed to transfer 
from http://0.0.0.0/ during a previous attempt. This failure was cached in the 
local repository and resolution will not be reattempted until the update 
interval of maven-default-http-blocker has elapsed or updates are forced. 
Original error: Could not transfer metadata 
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/org/mongodb/bson/4.5.0-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[

I can't understand how to understand which repository in my pom.xml has an http 
and not https repository based on this WARN message.

I searched for  over any pom.xml file and didn't find any http 
repository.

Any help would be greatly appreciated. This is the latest master branch of
pulsar: 
https://clicktime.symantec.com/15sLvTizaiLPdE4JXAvu7?h=MSjyi1VB4cPbNJsglaLsboIIC2w3PxVFwT0C3b3tJjE==https://clicktime.symantec.com/15sM1HvLio6GkLoeSsGso?h=a4l_3miTQ9Jpp9kBhV4g1A6nK9z3Xc4ThYeLnyNM6NM==https://github.com/apache/pulsar

Thanks,

Asaf

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://clicktime.symantec.com/15sMWH63UVBqE1mBiDfmX?h=DIqE4zifGAeQprKQUyrnrW7RczY3fI3DZ9CksSTeo3A==https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.

For important disclosures, please see: 
https://clicktime.symantec.com/15sMRStm1sWEp4wGAfGcu?h=o9osYrwRO8Nk9pRhDXC5l0HduDMhhY22d5g2I2QVwuc==https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html
 regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://clicktime.symantec.com/15sMAxJue2TTaETVXz5B3?h=_YvyWi2JtvO3gSgRRKCpC0ImVYSd52rWl07eYNFwfaY==https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html
 regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to

RE: Question about HTTP blocking WARN

2023-12-13 Thread mark.yagnatinsky

See release notes for 3.8.1:
https://maven.apache.org/docs/3.8.1/release-notes.html

-Original Message-
From: Asaf Mesika  
Sent: Wednesday, December 13, 2023 6:07 AM
To: users@maven.apache.org
Subject: Question about HTTP blocking WARN

CAUTION: This email originated from outside our organisation - 
asaf.mes...@gmail.com Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
Hi,

I'm running Apache Maven 3.8.5 (using Maven Wrapper) for building Apache Pulsar.

I get the following WARN:

[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
[WARNING] org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xmlfailed to transfer 
from http://0.0.0.0/ during a previous attempt. This failure was cached in the 
local repository and resolution will not be reattempted until the update 
interval of maven-default-http-blocker has elapsed or updates are forced. 
Original error: Could not transfer metadata 
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[WARNING] org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xmlfailed to transfer 
from http://0.0.0.0/ during a previous attempt. This failure was cached in the 
local repository and resolution will not be reattempted until the update 
interval of maven-default-http-blocker has elapsed or updates are forced. 
Original error: Could not transfer metadata 
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/org/mongodb/bson/4.5.0-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[

I can't understand how to understand which repository in my pom.xml has an http 
and not https repository based on this WARN message.

I searched for  over any pom.xml file and didn't find any http 
repository.

Any help would be greatly appreciated. This is the latest master branch of
pulsar: 
https://clicktime.symantec.com/15sLvTizaiLPdE4JXAvu7?h=MSjyi1VB4cPbNJsglaLsboIIC2w3PxVFwT0C3b3tJjE==https://github.com/apache/pulsar

Thanks,

Asaf

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__

If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

RE: Inclusion of Failsafe plugin by default

2023-12-09 Thread mark.yagnatinsky

It would need to be added to the super pom, I suppose...
https://maven.apache.org/ref/3.9.6/maven-model-builder/super-pom.html
Note that based on the comment on line 50, I suspect they are not likely to 
want to do this

-Original Message-
From: Damiano Albani  
Sent: Saturday, December 9, 2023 5:28 PM
To: users@maven.apache.org
Subject: Inclusion of Failsafe plugin by default

CAUTION: This email originated from outside our organisation - 
damiano.alb...@gmail.com Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
Hello,

I'm a long-time Maven user but I've just recently discovered that, unless I'm 
mistaken, the Failsafe plugin isn't part of the default set of plugins which 
are configured "out of the box".
Is this correct?

If so, I find this quite strange given that Failsafe is mentioned on 
https://clicktime.symantec.com/15t5ejWR7ZXQJ7SejrESU?h=Qd-1cRIUr7dtc-zYyImHm56sVUcbukg2-o2L3nNyhvA==https://maven.apache.org/plugins/index.html
 as a "core plugin", just like its sibling Surefire, the latter being indeed 
included.

In order to change that, would it simply be a matter of adding Failsafe to 
https://clicktime.symantec.com/15t5ZuK8ewqotAcjCHqHr?h=-VNU9pFgfbgyo-3dqUgSPtAvthtlLSzDQLuUFwCOv04==https://github.com/apache/maven/blob/maven-3.9.6/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml
?
Or are there locations in the Maven codebase that would need to be changed?

Regards,

--
Damiano Albani

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__

If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

RE: creating a source directory on the fly

2023-12-06 Thread mark.yagnatinsky

Pretty sure that plugin is flexible enough to just copy what you tell it to?
https://maven.apache.org/plugins/maven-resources-plugin/examples/include-exclude.html

-Original Message-
From: Dave Dyer  
Sent: Tuesday, December 5, 2023 10:35 PM
To: Maven Users List ; Maven Users List 
; Maven Users List 
Subject: creating a source directory on the fly

CAUTION: This email originated from outside our organisation - 
dd...@real-me.net Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.

I'm trying to tune up my maven build, which requires that I construct a source 
directory on the fly by copying from the canonical location.

The best advice I've found is to use mavin-resources-plugin, but that's a bit 
inelegant because it copies everything, not just the sources.

Is there a better approach?

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

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__

If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

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

RE: How to unsubscribe from this list?

2023-11-13 Thread mark.yagnatinsky

Maybe try the help address mentioned here:
https://maven.apache.org/general.html#unsubscribing-from-mailing-lists

-Original Message-
From: Alex Orlov  
Sent: Monday, November 13, 2023 2:44 PM
To: users 
Subject: How to unsubscribe from this list?

CAUTION: This email originated from outside our organisation - 
ooo_satu...@mail.ru.INVALID Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.

Hi all,

I am trying to unsubscribe from this mailing list but I can’t do that. I’ve 
sent two messages to ` users-unsubscr...@maven.apache.org ` but I still get 
messages from users mailing list.

Could anyone say how to unsubscribe?

--
Best regards, Alex Orlov

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__

If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

RE: Version Management in 'mvn dependency:tree'

2023-10-31 Thread mark.yagnatinsky

Can't quite make sense of all this; given that you got no replies, maybe no one 
else understood either.
Could you explain a bit better?

-Original Message-
From: yukai zhao  
Sent: Monday, October 30, 2023 9:10 PM
To: users@maven.apache.org
Subject: Version Management in 'mvn dependency:tree'

CAUTION: This email originated from outside our organisation - yukz...@163.com 
Do not click on links, open attachments, or respond unless you recognize the 
sender and can validate the content is safe.
Hello,
Recently, I attempted to use 'mvn dependency:tree' to retrieve the project's 
dependency tree. However, in the output, I noticed that for the same dependency 
with different scopes, its version doesn't appear to be consistent. The 
specific scenario is as follows:

(org.checkerframework:checker-qual:jar:3.5.0:compile - scope updated from 
runtime; omitted for duplicate)

org.checkerframework:checker-qual:jar:3.12.0:compile

I made sure that these two pieces of information are present in the dependency 
tree of the same JAR. However, in the compilation information, I found that the 
first entry was hidden, and only the second entry was displayed. I'm curious 
about what happened here. In the actual compilation process, were both versions 
utilized, or was only the first version used?

Additionally, I attempted to remove the existing dependency package of version 
3.5.0 and recompile the project. Surprisingly, even after removing the 3.5.0 
version dependency package, Maven still downloads and utilizes it. Does this 
indicate that the project is still using the 3.5.0 version of the dependency 
package? Of course, I need to add a clarification: the 3.5.0 version of the 
dependency package is an indirect dependency of the project, while version 
3.12.0 is a direct dependency.

Best regards,

Yukai zhao
This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__

If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

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

RE: how to log exact HTTP request and response maven sends over the wire?

Much better... thanks!
So, basically I can just take the stuff on this page:
https://support.sonatype.com/hc/en-us/articles/213464088-Configuring-Maven-HTTP-Wagon-Detailed-Logging
And add it on command line instead of editing the properties file.  I'm going 
to try this now!

-Original Message-
From: mark  
Sent: Monday, October 30, 2023 1:10 PM
To: users@maven.apache.org
Subject: Re: how to log exact HTTP request and response maven sends over the 
wire?

CAUTION: This email originated from outside our organisation - 
mc.pr...@gmail.com Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.
Op 30-10-2023 om 16:14 schreef mark.yagnatin...@barclays.com.INVALID:
> I have to edit the file?  There's no way to set this from command line?

You can set them as properties on the Maven commandline eg.
-Dorg.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient=debug

like here:
https://clicktime.symantec.com/15t5Zu5z7gGfLkhnq58xS?h=Mqr1LTp3xWVk8NSuTORqAWcm2nPEBZUDY6MnoH-t-6o==https://github.com/B3Partners/tailormap-api/blob/205fbe509d3498292f39654f5abe351a256725f7/.github/workflows/owasp-dependency-check.yml%23L33

-M

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

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__

If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

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

RE: how to log exact HTTP request and response maven sends over the wire?

I have to edit the file?  There's no way to set this from command line?
The issue is an a shared build server and I'd rather not affect all builds.
In fact, I'm not sure where the maven installation lives, or whether I have 
write permissions for it.

-Original Message-
From: Stefan CORDES  
Sent: Monday, October 30, 2023 10:56 AM
To: Maven Users List 
Subject: RE: how to log exact HTTP request and response maven sends over the 
wire?


CAUTION: This email originated from outside our organisation - 
stefan.cor...@canda.com.INVALID Do not click on links, open attachments, or 
respond unless you recognize the sender and can validate the content is safe.
Hi,
in your

MAVEN_HOME\conf\logging\simplelogger.properties

you can enable (set from off to debug)

org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient=debug
org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient.wire=debug

and

org.slf4j.simpleLogger.log.org.apache.http.headers=debug
org.slf4j.simpleLogger.log.org.apache.http.wire=debug

to see all http traffic header and body.

Gruß,
Stefan

-Original Message-
From: mark.yagnatin...@barclays.com.INVALID 

Sent: Monday, October 30, 2023 3:32 PM
To: users@maven.apache.org
Subject: RE: how to log exact HTTP request and response maven sends over the 
wire?

Maven 3.6.3 ... no overides

-Original Message-
From: Tamás Cservenák 
Sent: Monday, October 30, 2023 10:04 AM
To: Maven Users List 
Subject: Re: how to log exact HTTP request and response maven sends over the 
wire?


CAUTION: This email originated from outside our organisation - 
ta...@cservenak.net Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.
Howdy,

for start we'd need:
- what Maven (best to just `mvn -v` and copy that)
- if you override transport, what you override transport to?

Thanks
T

On Mon, Oct 30, 2023 at 2:54 PM 
wrote:

> I'm getting HTTP 400 errors from a repo I'm trying to connect to and I 
> don't understand why.
> Is there an easy way to get maven to show exactly what HTTP request 
> gets sent over the wire and what comes back?
>
> This message is for information purposes only. It is not a 
> recommendation, advice, offer or solicitation to buy or sell a product 
> or service, nor an official confirmation of any transaction. It is 
> directed at persons who are professionals and is intended for the
> recipient(s) only. It is not directed at retail customers. This message is 
> subject to the terms at:
> https://clicktime.symantec.com/15t5z44MqsZDPQVLm81br?h=BrzHY6XfU_3PtXDVTfgozx94KdEjrdka42d0K8tf3ao==https://clicktime.symantec.com/15sjF9ciGqWEJGxU8LcYE?h=OHDSIYWAt38WqQRJtTyU2TIz_9uDoigwTWWnAFajPyk==https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.
>
> For important disclosures, please see:
> https://clicktime.symantec.com/15siaW4Sbv3UziM5msRMG?h=gIDhrz6dMY9sY8m
> 6dAfEC2ufjHhBiO0NgzMNRWvvIrk==https://clicktime.symantec.com/15t5uDs
> 5PFscyTfRDZcTE?h%3DZCG-UUcnRQGU2WD
> 44hE5RxT2sotnkCDtp-MRqevDkp4==https://clicktime.symantec.com/15sj5VE
> 9Mc93UPJd3DpEz?h=wRWx3UkNQmaNawsZcHR2C-reShlLRAqHu9IQo4_szjw==https:
> //www.cib.barclays/disclosures/s ales-and-trading-disclaimer.html 
> regarding marketing commentary from Barclays Sales and/or Trading 
> desks, who are active market participants;
> https://clicktime.symantec.com/15siQqfsgggJAphEgkd42?h=RnywXWdfeNfMiIX
> y_NNzFXsNEustknB-uvfaMvqwG7o==https://clicktime.symantec.com/15t5ejH
> E1QpqjdBeatR1N?h%3DDkNaTHLjb8eqZ08
> gO5EjbAJk1H41HZcwrkQOGHmbSjg==https://clicktime.symantec.com/15sifLF
> j4Xj5QfB1KRpVt?h=MLK8MPic8YdfSSGgV1OXMTlEXEhkCHqJ2KAvzq0K4Ww==https:
> //www.cib.barclays/disclosures/b 
> arclays-global-markets-disclosures.html
> regarding our standard terms for Barclays Corporate and Investment 
> Bank where we trade with you in principal-to-principal wholesale 
> markets transactions; and in respect to Barclays Research, including 
> disclosures relating to specific issuers, see: 
> https://clicktime.symantec.com/15t5Zu5wYo9FKgMj3L1rk?h=AJ0ZI4oxSqFdQEGEQd-g03qCgsmtTNLkJBQJHsSCBTI==https://clicktime.symantec.com/15siFBHJmTK7Lw3Pbdpkn?h=wHFX61zsWj1PQJC6oXDHtJSzhfnJiJZmsElfTmMY9aI==http://publicresearch.barclays.com.
> __
> 
>
> If you are incorporated or operating in Australia, read these 
> important
> disclosures:
> https://clicktime.symantec.com/15siVfsA9JMtamXAEK2Ce?h=t5Nx75fJE6TAsTq
> IHsAnxMuZ5DiVYKBdADJ6ZpHHBsU==https://clicktime.symantec.com/15t5jZU
> WU2WS9a1a8Sp9z?h%3Djq3kfLHvz1eyXO5
> 5VDKwe1rnJ6Z9_El5xwJfKSd4iek==https://clicktime.symantec.com/15sipze
> Hym6GEYprQYco8?h=GwPmsxfnvrqsGgGzZkxVxTtp8b8DgKf3x1WuYdtG_Hs==https:
> //www.cib.barclays/disclosures/i 
> mportant-disclosures-asia-pacific.html
> .
>
> __
>  For more details about how we use personal

RE: how to log exact HTTP request and response maven sends over the wire?

Maven 3.6.3 ... no overides

-Original Message-
From: Tamás Cservenák  
Sent: Monday, October 30, 2023 10:04 AM
To: Maven Users List 
Subject: Re: how to log exact HTTP request and response maven sends over the 
wire?

CAUTION: This email originated from outside our organisation - 
ta...@cservenak.net Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.
Howdy,

for start we'd need:
- what Maven (best to just `mvn -v` and copy that)
- if you override transport, what you override transport to?

Thanks
T

On Mon, Oct 30, 2023 at 2:54 PM 
wrote:

> I'm getting HTTP 400 errors from a repo I'm trying to connect to and I 
> don't understand why.
> Is there an easy way to get maven to show exactly what HTTP request 
> gets sent over the wire and what comes back?
>
> This message is for information purposes only. It is not a 
> recommendation, advice, offer or solicitation to buy or sell a product 
> or service, nor an official confirmation of any transaction. It is 
> directed at persons who are professionals and is intended for the 
> recipient(s) only. It is not directed at retail customers. This message is 
> subject to the terms at:
> https://clicktime.symantec.com/15t5z44MqsZDPQVLm81br?h=BrzHY6XfU_3PtXDVTfgozx94KdEjrdka42d0K8tf3ao==https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.
>
> For important disclosures, please see:
> https://clicktime.symantec.com/15t5uDs5PFscyTfRDZcTE?h=ZCG-UUcnRQGU2WD
> 44hE5RxT2sotnkCDtp-MRqevDkp4==https://www.cib.barclays/disclosures/s
> ales-and-trading-disclaimer.html regarding marketing commentary from 
> Barclays Sales and/or Trading desks, who are active market 
> participants; 
> https://clicktime.symantec.com/15t5ejHE1QpqjdBeatR1N?h=DkNaTHLjb8eqZ08
> gO5EjbAJk1H41HZcwrkQOGHmbSjg==https://www.cib.barclays/disclosures/b
> arclays-global-markets-disclosures.html
> regarding our standard terms for Barclays Corporate and Investment 
> Bank where we trade with you in principal-to-principal wholesale 
> markets transactions; and in respect to Barclays Research, including 
> disclosures relating to specific issuers, see: 
> https://clicktime.symantec.com/15t5Zu5wYo9FKgMj3L1rk?h=AJ0ZI4oxSqFdQEGEQd-g03qCgsmtTNLkJBQJHsSCBTI==http://publicresearch.barclays.com.
> __
> 
>
> If you are incorporated or operating in Australia, read these 
> important
> disclosures:
> https://clicktime.symantec.com/15t5jZUWU2WS9a1a8Sp9z?h=jq3kfLHvz1eyXO5
> 5VDKwe1rnJ6Z9_El5xwJfKSd4iek==https://www.cib.barclays/disclosures/i
> mportant-disclosures-asia-pacific.html
> .
>
> __
>  For more details about how we use personal information, 
> see our privacy
> notice: 
> https://clicktime.symantec.com/15t5pPfnveC2ZWqVg1DJc?h=uYHykXL4S6qcxw0SK9tlahK-n0t6KWADPJKu7Tm2W7M==https://www.cib.barclays/disclosures/personal-information-use.html.
>
>
> __
> 

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__

If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

how to log exact HTTP request and response maven sends over the wire?

I'm getting HTTP 400 errors from a repo I'm trying to connect to and I don't 
understand why.
Is there an easy way to get maven to show exactly what HTTP request gets sent 
over the wire and what comes back?

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__
 
If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

RE: question on maven dependency scope

2023-10-02 Thread mark.yagnatinsky

That sounds like it might actually work

-Original Message-
From: Siddharth Jain  
Sent: Sunday, October 1, 2023 8:47 PM
To: Maven Users List 
Subject: question on maven dependency scope

CAUTION: This email originated from outside our organisation - 
siddh...@gmail.com Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.
hello.

https://clicktime.symantec.com/15siFB7xf2QcUHAdxCz1m?h=rHBhQF_TXrl6Mj2r5j5v0vCyG83lV5yoa6fcxP1NDwY==https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html%23Dependency_Scope

   - *provided*
   This is much like compile, but indicates you expect the JDK or a
   container to provide the dependency at runtime. For example, when building
   a web application for the Java Enterprise Edition, you would set the
   dependency on the Servlet API and related Java EE APIs to scope provided 
because
   the web container provides those classes. A dependency with this scope is
   added to the classpath used for compilation and test, but not the runtime
   classpath. It is not transitive.

what does the runtime classpath mean here? does it mean the classpath when 
running the application using the maven-exec-plugin? does it make any 
difference to the maven-assembly-plugin whether scope is provided or not?

context: I am trying to build an application with different levels of 
subscription. there will be a common core but i will provide premium features 
as addons. so I want to treat them as dependencies with provided scope in the 
core and package the application differently depending on the customer's 
subscription level. as the packing into a jar is done with the assembly plugin, 
I would like to know whether it makes any difference to the assembly plugin 
whether the scope is provided or not.

if not, what is the best way to achieve my goal?

thanks.

S.

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__

If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

suggesting books for book list

2023-07-29 Thread mark.yagnatinsky

This list has some books and articles about maven:
https://maven.apache.org/articles.html
Sonatype has 3 free maven books available on its website in both HTML and pdf 
form
Is the policy to list basically anything or does someone have vouch that the 
books are good or...?

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__
 
If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

maven class path order documentation

2023-07-29 Thread mark.yagnatinsky

In the release notes for Maven 2.0.9:
http://people.apache.org/~jvanzyl/maven-3.1.1/docs/2.0.9/release-notes.html
It says: "introduced deterministic ordering of dependencies on the classpath. 
In the past, natural set ordering was used and this lead to odd results. The 
ordering is now preserved from your pom, with dependencies added by inheritance 
added last"
Is this info still current?  Is it documented anywhere aside from this release 
note?  If not, perhaps it should be?  And more details would be nice too.  For 
instance:

* Suppose my module M has parent P and grandparent G.   Also, M depends 
on A and B, in that order.  Further, suppose A depends on X, which in turn 
depends on Y.  Meanwhile, B depends on Z.

Based on the sentence above, both of these are plausible orders:

a.M, A, B, X, Z, Y, P, G

b.M, A, X, Y, B, Z, P, G

c. Maybe others too?

* How does this relate to the dependency "mediation" algorithm maven 
uses when there are conflicting versions of a dependency requested?

As far as I understand, that uses a breadth-first search, where the parent pom 
comes FIRST rather than last.

Does that mean that mediation algorithm is basically unrelated to class path 
algorithm, or do they still have some things in common?

E.g., ordering (a) above is also a breadth-first search, whereas (b) is 
depth-first.
Any words of wisdom would be nice.

Thanks,
Mark.

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__
 
If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

RE: enforcing class path order using maven enforcer

Nice catch!

-Original Message-
From: Nick Stolwijk  
Sent: Friday, July 28, 2023 7:10 PM
To: Maven Users List 
Subject: Re: enforcing class path order using maven enforcer


CAUTION: This email originated from outside our organisation - 
nick.stolw...@gmail.com Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
I see there is one little mistake in that blogpost.

You should add the original dependency with provided to
prevent it from entering the classpath, or else you still end up with both
dependencies on your classpath.

Hth,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell


On Sat, 29 Jul 2023 at 01:05, Nick Stolwijk  wrote:

> I shamelessly copied it from stackoverflow, but here is a blogpost
> explaining it better:
> https://clicktime.symantec.com/15tB9ZbM7fEjPnvVhz6WJ?h=-9MCeGkLCSU_WckipmaNUaXUCoq3OyZhZ8uCvSKGrPo==https://gochev.blogspot.com/2014/07/patching-maven-library-with-your-custom.html
>
> And I have used this hack in the past, but in the end I found it was more
> easy to go with the "upload your own version of the artifact once to the
> repository" way, but that depends on how much control you have over your
> repository.
>
> Hth,
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Sat, 29 Jul 2023 at 01:02, 
> wrote:
>
>> Thanks!  That makes sense.  Ideally don't want to slow down the build.
>> Actually, on second thought, it doesn't quite make sense.
>> Suppose I were willing to slow down the build.
>> How does unpacking help me with ... wait!
>> Okay, I just read the pom.xml fragment you posted much more carefully.
>> Now I think I get it.  The destination directory is not arbitrary!
>> Instead, you unpack the dependency exactly where maven intends to put
>> compiled class files.
>> Okay, wow.  That is hacky.  And seriously clever.  Is this a standard
>> trick or did you think of this just now?
>>
>> Re: how long to support this: probably pretty long.
>>
>> -Original Message-
>> From: Nick Stolwijk 
>> Sent: Friday, July 28, 2023 6:47 PM
>> To: Maven Users List 
>> Subject: Re: enforcing class path order using maven enforcer
>>
>>
>> CAUTION: This email originated from outside our organisation -
>> nick.stolw...@gmail.com Do not click on links, open attachments, or
>> respond unless you recognize the sender and can validate the content is
>> safe.
>> That is indeed one way of doing it, quick, easy, but costly for every
>> build.
>>
>> Another solution is to clone the upstream repository and checkout the
>> version you are on. Then fix the class and change the version of the
>> artifact to something you recognize, like -barclay-1.
>> Then upload the result once to your own artifact repository and start
>> using
>> that version in your project.
>>
>> It all depends on how long you are expecting to support the solution.
>>
>> Nick Stolwijk
>>
>> ~~~ Try to leave this world a little better than you found it and, when
>> your turn comes to die, you can die happy in feeling that at any rate you
>> have not wasted your time but have done your best ~~~
>>
>> Lord Baden-Powell
>>
>>
>> On Sat, 29 Jul 2023 at 00:43, 
>> wrote:
>>
>> > Oh, I see, you're suggesting doing that as part of every build, instead
>> of
>> > once, statically?
>> >
>> > -Original Message-
>> > From: Nick Stolwijk 
>> > Sent: Friday, July 28, 2023 6:40 PM
>> > To: Maven Users List 
>> > Subject: Re: enforcing class path order using maven enforcer
>> >
>> >
>> > CAUTION: This email originated from outside our organisation -
>> > nick.stolw...@gmail.com Do not click on links, open attachments, or
>> > respond unless you recognize the sender and can validate the content is
>> > safe.
>> > I admit it is a trick to not have duplicate classes on your classpath
>> and
>> > I think you understood what I meant.
>> >
>> > In your small module you unpack the Big Bad Evil Dependency and
>> overwrite
>> > one of the classes with your own. Then you repackage the whole thing and
>> > use that in your project, instead of the BBED.
>> >
>> > Nick Stolwijk
>> >
>> > ~~~ Try to leave this world a little better than you found it and, when
>> > your turn comes to die, you can die happy in feeling that at any rate
>> you
>> > have not wasted your time but have done your best ~~~
>> >
>> > Lord Baden-Powell
>> >
>> >
>> > On Sat, 29 Jul 2023 at 00:33, 
>> > wrote:
>> >
>> > > I think I'm missing something.  Currently there is a big module on
>> > > maven central with many classes, including one called TextFormat.
>> > > In my project there is a small maven module

RE: enforcing class path order using maven enforcer

We have enough control that it's doable, but little enough that I'm reluctant 
to bother.
Thanks again for everything, things make much more sense now!

-Original Message-
From: Nick Stolwijk  
Sent: Friday, July 28, 2023 7:06 PM
To: Maven Users List 
Subject: Re: enforcing class path order using maven enforcer


CAUTION: This email originated from outside our organisation - 
nick.stolw...@gmail.com Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
I shamelessly copied it from stackoverflow, but here is a blogpost
explaining it better:
https://clicktime.symantec.com/15tB9ZbM5BfychLbVR9NN?h=5UUQrRV1gNe3jx94XNoB8DTPasrbH9f1706lgdhIUBI==https://gochev.blogspot.com/2014/07/patching-maven-library-with-your-custom.html

And I have used this hack in the past, but in the end I found it was more
easy to go with the "upload your own version of the artifact once to the
repository" way, but that depends on how much control you have over your
repository.

Hth,

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell


On Sat, 29 Jul 2023 at 01:02,  wrote:

> Thanks!  That makes sense.  Ideally don't want to slow down the build.
> Actually, on second thought, it doesn't quite make sense.
> Suppose I were willing to slow down the build.
> How does unpacking help me with ... wait!
> Okay, I just read the pom.xml fragment you posted much more carefully.
> Now I think I get it.  The destination directory is not arbitrary!
> Instead, you unpack the dependency exactly where maven intends to put
> compiled class files.
> Okay, wow.  That is hacky.  And seriously clever.  Is this a standard
> trick or did you think of this just now?
>
> Re: how long to support this: probably pretty long.
>
> -Original Message-
> From: Nick Stolwijk 
> Sent: Friday, July 28, 2023 6:47 PM
> To: Maven Users List 
> Subject: Re: enforcing class path order using maven enforcer
>
>
> CAUTION: This email originated from outside our organisation -
> nick.stolw...@gmail.com Do not click on links, open attachments, or
> respond unless you recognize the sender and can validate the content is
> safe.
> That is indeed one way of doing it, quick, easy, but costly for every
> build.
>
> Another solution is to clone the upstream repository and checkout the
> version you are on. Then fix the class and change the version of the
> artifact to something you recognize, like -barclay-1.
> Then upload the result once to your own artifact repository and start using
> that version in your project.
>
> It all depends on how long you are expecting to support the solution.
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Sat, 29 Jul 2023 at 00:43, 
> wrote:
>
> > Oh, I see, you're suggesting doing that as part of every build, instead
> of
> > once, statically?
> >
> > -Original Message-
> > From: Nick Stolwijk 
> > Sent: Friday, July 28, 2023 6:40 PM
> > To: Maven Users List 
> > Subject: Re: enforcing class path order using maven enforcer
> >
> >
> > CAUTION: This email originated from outside our organisation -
> > nick.stolw...@gmail.com Do not click on links, open attachments, or
> > respond unless you recognize the sender and can validate the content is
> > safe.
> > I admit it is a trick to not have duplicate classes on your classpath and
> > I think you understood what I meant.
> >
> > In your small module you unpack the Big Bad Evil Dependency and overwrite
> > one of the classes with your own. Then you repackage the whole thing and
> > use that in your project, instead of the BBED.
> >
> > Nick Stolwijk
> >
> > ~~~ Try to leave this world a little better than you found it and, when
> > your turn comes to die, you can die happy in feeling that at any rate you
> > have not wasted your time but have done your best ~~~
> >
> > Lord Baden-Powell
> >
> >
> > On Sat, 29 Jul 2023 at 00:33, 
> > wrote:
> >
> > > I think I'm missing something.  Currently there is a big module on
> > > maven central with many classes, including one called TextFormat.
> > > In my project there is a small maven module with just ONE class: a
> > > tweaked version of TextFormat.
> > > If I understand you correctly (doubt it), the "right" way to do this
> > > is for the small module to actually absorb the entire third-party
> module.
> > > But if that's what you mean, then why are we doing weird stuff in the
> > > process-resources phase?
> > >
> > > -Original Message-
> > > From: Nick Stolwijk 
> > > Sent: Friday, July 28, 2023 6:24 PM
> > > To: Maven Users List 
> > > Subject: Re: enforcing class path order

RE: enforcing class path order using maven enforcer

Thanks!  That makes sense.  Ideally don't want to slow down the build.
Actually, on second thought, it doesn't quite make sense.
Suppose I were willing to slow down the build.
How does unpacking help me with ... wait!
Okay, I just read the pom.xml fragment you posted much more carefully.
Now I think I get it.  The destination directory is not arbitrary!
Instead, you unpack the dependency exactly where maven intends to put compiled 
class files.
Okay, wow.  That is hacky.  And seriously clever.  Is this a standard trick or 
did you think of this just now?

Re: how long to support this: probably pretty long.

-Original Message-
From: Nick Stolwijk  
Sent: Friday, July 28, 2023 6:47 PM
To: Maven Users List 
Subject: Re: enforcing class path order using maven enforcer


CAUTION: This email originated from outside our organisation - 
nick.stolw...@gmail.com Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
That is indeed one way of doing it, quick, easy, but costly for every build.

Another solution is to clone the upstream repository and checkout the
version you are on. Then fix the class and change the version of the
artifact to something you recognize, like -barclay-1.
Then upload the result once to your own artifact repository and start using
that version in your project.

It all depends on how long you are expecting to support the solution.

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when
your turn comes to die, you can die happy in feeling that at any rate you
have not wasted your time but have done your best ~~~

Lord Baden-Powell


On Sat, 29 Jul 2023 at 00:43,  wrote:

> Oh, I see, you're suggesting doing that as part of every build, instead of
> once, statically?
>
> -Original Message-
> From: Nick Stolwijk 
> Sent: Friday, July 28, 2023 6:40 PM
> To: Maven Users List 
> Subject: Re: enforcing class path order using maven enforcer
>
>
> CAUTION: This email originated from outside our organisation -
> nick.stolw...@gmail.com Do not click on links, open attachments, or
> respond unless you recognize the sender and can validate the content is
> safe.
> I admit it is a trick to not have duplicate classes on your classpath and
> I think you understood what I meant.
>
> In your small module you unpack the Big Bad Evil Dependency and overwrite
> one of the classes with your own. Then you repackage the whole thing and
> use that in your project, instead of the BBED.
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Sat, 29 Jul 2023 at 00:33, 
> wrote:
>
> > I think I'm missing something.  Currently there is a big module on
> > maven central with many classes, including one called TextFormat.
> > In my project there is a small maven module with just ONE class: a
> > tweaked version of TextFormat.
> > If I understand you correctly (doubt it), the "right" way to do this
> > is for the small module to actually absorb the entire third-party module.
> > But if that's what you mean, then why are we doing weird stuff in the
> > process-resources phase?
> >
> > -Original Message-
> > From: Nick Stolwijk 
> > Sent: Friday, July 28, 2023 6:24 PM
> > To: Maven Users List 
> > Subject: Re: enforcing class path order using maven enforcer
> >
> >
> > CAUTION: This email originated from outside our organisation -
> > nick.stolw...@gmail.com Do not click on links, open attachments, or
> > respond unless you recognize the sender and can validate the content
> > is safe.
> > I was in the understanding you already had your own Maven artifact, as
> > you were talking about two different dependencies. It doesn't have to
> > be a new artifact in the sense that it has to live in a different
> > repository, you can also have this artifact as a module in your project.
> >
> > You can unpack the dependency with the Maven dependency plugin and
> > repackage it with your own classes.
> >
> > 
> > org.apache.maven.plugins
> > maven-dependency-plugin
> > 2.8
> > 
> >
> >
> >process-resources
> >
> >unpack
> >
> >
> >
> >  
> >commons-lang
> >commons-lang
> >2.6
> >  
> >
> >
> >  ${project.build.outputDirectory}
> >
> >
> > 
> > 
> >
> > Nick Stolwijk
> >
> > ~~~ Try to leave this world a little better than you found it and,
> > when your turn comes to die, you can die happy in feeling that at any
> > rate you have not wasted your time but have done your best ~~~
> >
> > Lord Baden-Powell
> >
> >
> > On Sat, 29 Jul 2023 at 00:16, 
> > wrote:
> >
> > > I see, so the "proper" way to do this is to create a brand new maven
> > > artifact.

RE: enforcing class path order using maven enforcer

Oh, I see, you're suggesting doing that as part of every build, instead of 
once, statically?

-Original Message-
From: Nick Stolwijk  
Sent: Friday, July 28, 2023 6:40 PM
To: Maven Users List 
Subject: Re: enforcing class path order using maven enforcer


CAUTION: This email originated from outside our organisation - 
nick.stolw...@gmail.com Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
I admit it is a trick to not have duplicate classes on your classpath and I 
think you understood what I meant.

In your small module you unpack the Big Bad Evil Dependency and overwrite one 
of the classes with your own. Then you repackage the whole thing and use that 
in your project, instead of the BBED.

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when your 
turn comes to die, you can die happy in feeling that at any rate you have not 
wasted your time but have done your best ~~~

Lord Baden-Powell


On Sat, 29 Jul 2023 at 00:33,  wrote:

> I think I'm missing something.  Currently there is a big module on 
> maven central with many classes, including one called TextFormat.
> In my project there is a small maven module with just ONE class: a 
> tweaked version of TextFormat.
> If I understand you correctly (doubt it), the "right" way to do this 
> is for the small module to actually absorb the entire third-party module.
> But if that's what you mean, then why are we doing weird stuff in the 
> process-resources phase?
>
> -Original Message-
> From: Nick Stolwijk 
> Sent: Friday, July 28, 2023 6:24 PM
> To: Maven Users List 
> Subject: Re: enforcing class path order using maven enforcer
>
>
> CAUTION: This email originated from outside our organisation - 
> nick.stolw...@gmail.com Do not click on links, open attachments, or 
> respond unless you recognize the sender and can validate the content 
> is safe.
> I was in the understanding you already had your own Maven artifact, as 
> you were talking about two different dependencies. It doesn't have to 
> be a new artifact in the sense that it has to live in a different 
> repository, you can also have this artifact as a module in your project.
>
> You can unpack the dependency with the Maven dependency plugin and 
> repackage it with your own classes.
>
> 
> org.apache.maven.plugins
> maven-dependency-plugin
> 2.8
> 
>
>
>process-resources
>
>unpack
>
>
>
>  
>commons-lang
>commons-lang
>2.6
>  
>
>
>  ${project.build.outputDirectory}
>
>
> 
> 
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, 
> when your turn comes to die, you can die happy in feeling that at any 
> rate you have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Sat, 29 Jul 2023 at 00:16, 
> wrote:
>
> > I see, so the "proper" way to do this is to create a brand new maven 
> > artifact.  Sigh.  That is more trouble than I was hoping for.
> > Re: upstream: they've already learned their lesson and newer 
> > versions don't have this issue.
> > But they're also not backwards compatible with the version we're on.
> >
> > -Original Message-
> > From: Nick Stolwijk 
> > Sent: Friday, July 28, 2023 6:10 PM
> > To: Maven Users List 
> > Subject: Re: enforcing class path order using maven enforcer
> >
> >
> > CAUTION: This email originated from outside our organisation - 
> > nick.stolw...@gmail.com Do not click on links, open attachments, or 
> > respond unless you recognize the sender and can validate the content 
> > is safe.
> > Ah, that sounds like a good usecase to fix in your own dependency.
> > Unpack the "faulty" dependency there, overwrite it with your own 
> > implementation and repackage it again. Then in your consuming 
> > project forbid the use of the "faulty" dependency, using the Maven 
> > Enforcer[1] and fix any violation with an  clause.
> >
> > And, of course, try to push your change upstream as soon as 
> > possible, so you don't have to maintain this dependency hell forever.
> >
> > Hth,
> >
> > [1]
> > https://clicktime.symantec.com/15sMb6WJh8RM5WXFcSr6B?h=R4_565lG5nlvP
> > 2DLXCqnUIqZca7taYsicdvaaAfAjwM==https://clicktime.symantec.com/15s
> > Mqb69g4ndT6CkJRSfW?h%3DWpHk9xFV9vRGzKQ
> > LbhSmi7KXJ9z78ttlOaGHNvrUkDE==https://clicktime.symantec.com/15sPv
> > MxFYMXxdyf6r62FZ?h=hLzdx-yh9f9YhEz85mXZRk7Eb5LWmOEajf8lPKAsH8k==ht
> > tps://clicktime.symantec.com/15t7uA1
> > Gc7vLAPeBMLGEi?h=blO9yaZi0bbl5JQdo9BJpLSvyl-Jm4359goetQrNQJA==https:
> > //maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html
> >
> > Nick Stolwijk
> >
> > ~~~ Try to leave this world a little better than you found it and, 
> > when your turn comes to die, you can die happy in feeling that at 
> > any rate you have not wasted your time but have

RE: enforcing class path order using maven enforcer

I think I'm missing something.  Currently there is a big module on maven 
central with many classes, including one called TextFormat.
In my project there is a small maven module with just ONE class: a tweaked 
version of TextFormat.
If I understand you correctly (doubt it), the "right" way to do this is for the 
small module to actually absorb the entire third-party module.
But if that's what you mean, then why are we doing weird stuff in the 
process-resources phase?

-Original Message-
From: Nick Stolwijk  
Sent: Friday, July 28, 2023 6:24 PM
To: Maven Users List 
Subject: Re: enforcing class path order using maven enforcer


CAUTION: This email originated from outside our organisation - 
nick.stolw...@gmail.com Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
I was in the understanding you already had your own Maven artifact, as you were 
talking about two different dependencies. It doesn't have to be a new artifact 
in the sense that it has to live in a different repository, you can also have 
this artifact as a module in your project.

You can unpack the dependency with the Maven dependency plugin and repackage it 
with your own classes.


org.apache.maven.plugins
maven-dependency-plugin
2.8

   
   
   process-resources
   
   unpack
   
   
   
 
   commons-lang
   commons-lang
   2.6
 
   

 ${project.build.outputDirectory}
   
   



Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when your 
turn comes to die, you can die happy in feeling that at any rate you have not 
wasted your time but have done your best ~~~

Lord Baden-Powell


On Sat, 29 Jul 2023 at 00:16,  wrote:

> I see, so the "proper" way to do this is to create a brand new maven 
> artifact.  Sigh.  That is more trouble than I was hoping for.
> Re: upstream: they've already learned their lesson and newer versions 
> don't have this issue.
> But they're also not backwards compatible with the version we're on.
>
> -Original Message-
> From: Nick Stolwijk 
> Sent: Friday, July 28, 2023 6:10 PM
> To: Maven Users List 
> Subject: Re: enforcing class path order using maven enforcer
>
>
> CAUTION: This email originated from outside our organisation - 
> nick.stolw...@gmail.com Do not click on links, open attachments, or 
> respond unless you recognize the sender and can validate the content 
> is safe.
> Ah, that sounds like a good usecase to fix in your own dependency. 
> Unpack the "faulty" dependency there, overwrite it with your own 
> implementation and repackage it again. Then in your consuming project 
> forbid the use of the "faulty" dependency, using the Maven Enforcer[1] 
> and fix any violation with an  clause.
>
> And, of course, try to push your change upstream as soon as possible, 
> so you don't have to maintain this dependency hell forever.
>
> Hth,
>
> [1]
> https://clicktime.symantec.com/15sMqb69g4ndT6CkJRSfW?h=WpHk9xFV9vRGzKQ
> LbhSmi7KXJ9z78ttlOaGHNvrUkDE==https://clicktime.symantec.com/15t7uA1
> Gc7vLAPeBMLGEi?h=blO9yaZi0bbl5JQdo9BJpLSvyl-Jm4359goetQrNQJA==https:
> //maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, 
> when your turn comes to die, you can die happy in feeling that at any 
> rate you have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Fri, 28 Jul 2023 at 23:53, 
> wrote:
>
> > I'd like to clarify one point about why I care about order:
> > I have a class name which clashes on purpose!
> > That is, I have a third-party dependency from maven central that 
> > does the Wrong Thing in one of its classes.
> > I have my own "fork" of that class which does the Right Thing.
> > I want to make sure that my version gets picked up!
> >
> > -Original Message-
> > From: Tamás Cservenák 
> > Sent: Friday, July 28, 2023 5:29 PM
> > To: Maven Users List 
> > Subject: Re: enforcing class path order using maven enforcer
> >
> >
> > CAUTION: This email originated from outside our organisation - 
> > ta...@cservenak.net Do not click on links, open attachments, or 
> > respond unless you recognize the sender and can validate the content 
> > is
> safe.
> > Yup,
> >
> > My "coinciding" work was not to fix people depending in cp ordering, 
> > but was more related to my guts telling that "level order" 
> > (introduced in experiment PR) is more correct than "pre order".
> >
> > Latter may cause that your 3rd or 4th level transitive dep be 
> > enlisted on CP before your 2nd first level dependency (ie.if you 
> > consider a pom with 2 dependencies, 1st dep nth level transitive 
> > dependency may "shadow" your 2nd direct dependency).
> >
> > Thanks
> > T
> >
> > On Fri, Jul 28, 2023, 23:14 Nick Stolwijk 
> wrote:
> >
> > > Hi Tamás,
> > >
> > > Thanks for

RE: enforcing class path order using maven enforcer

I see, so the "proper" way to do this is to create a brand new maven artifact.  
Sigh.  That is more trouble than I was hoping for.
Re: upstream: they've already learned their lesson and newer versions don't 
have this issue.
But they're also not backwards compatible with the version we're on.

-Original Message-
From: Nick Stolwijk  
Sent: Friday, July 28, 2023 6:10 PM
To: Maven Users List 
Subject: Re: enforcing class path order using maven enforcer


CAUTION: This email originated from outside our organisation - 
nick.stolw...@gmail.com Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
Ah, that sounds like a good usecase to fix in your own dependency. Unpack the 
"faulty" dependency there, overwrite it with your own implementation and 
repackage it again. Then in your consuming project forbid the use of the 
"faulty" dependency, using the Maven Enforcer[1] and fix any violation with an 
 clause.

And, of course, try to push your change upstream as soon as possible, so you 
don't have to maintain this dependency hell forever.

Hth,

[1] 
https://clicktime.symantec.com/15sMqb69g4ndT6CkJRSfW?h=WpHk9xFV9vRGzKQLbhSmi7KXJ9z78ttlOaGHNvrUkDE==https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html

Nick Stolwijk

~~~ Try to leave this world a little better than you found it and, when your 
turn comes to die, you can die happy in feeling that at any rate you have not 
wasted your time but have done your best ~~~

Lord Baden-Powell


On Fri, 28 Jul 2023 at 23:53,  wrote:

> I'd like to clarify one point about why I care about order:
> I have a class name which clashes on purpose!
> That is, I have a third-party dependency from maven central that does 
> the Wrong Thing in one of its classes.
> I have my own "fork" of that class which does the Right Thing.
> I want to make sure that my version gets picked up!
>
> -Original Message-
> From: Tamás Cservenák 
> Sent: Friday, July 28, 2023 5:29 PM
> To: Maven Users List 
> Subject: Re: enforcing class path order using maven enforcer
>
>
> CAUTION: This email originated from outside our organisation - 
> ta...@cservenak.net Do not click on links, open attachments, or 
> respond unless you recognize the sender and can validate the content is safe.
> Yup,
>
> My "coinciding" work was not to fix people depending in cp ordering, 
> but was more related to my guts telling that "level order" (introduced 
> in experiment PR) is more correct than "pre order".
>
> Latter may cause that your 3rd or 4th level transitive dep be enlisted 
> on CP before your 2nd first level dependency (ie.if you consider a pom 
> with 2 dependencies, 1st dep nth level transitive dependency may 
> "shadow" your 2nd direct dependency).
>
> Thanks
> T
>
> On Fri, Jul 28, 2023, 23:14 Nick Stolwijk  wrote:
>
> > Hi Tamás,
> >
> > Thanks for the corrections! I was still in the belief that it wasn't 
> > explicitly ordered, but it seems that changed in the years. I still 
> > think it is easier to reason about your application if you don't 
> > depend on the order of dependencies. I have always used the Enforcer 
> > plugin to at first give warnings about duplicate classes and later 
> > in a project (when (almost) every duplicate was solved) to start 
> > failing the build if someone introduced a new duplicate.
> >
> > I have seen a lot of "strange" behaviour because the IDE used a 
> > different ordering than Maven did, and don't start about the runtime.
> > If you have duplicate classes and Maven "behaves", who says that the 
> > runtime behaves in the same way?
> >
> > I would make it a bigger issue that you have duplicate classes, 
> > instead of trying to live with those duplicates.
> >
> > With regards,
> >
> > Nick Stolwijk
> >
> > ~~~ Try to leave this world a little better than you found it and, 
> > when your turn comes to die, you can die happy in feeling that at 
> > any rate you have not wasted your time but have done your best ~~~
> >
> > Lord Baden-Powell
> >
> >
> > On Fri, 28 Jul 2023 at 22:56, Tamás Cservenák 
> wrote:
> >
> > > Nick,
> > >
> > > I have to correct you, as what you wrote is not true (anymore). 
> > > But
> > first,
> > > I think this mail was on hold by moderator, as we had a 
> > > same/similar discussion already on this thread:
> > > https://clicktime.symantec.com/15sM67LbYXeHjamSQPrKv?h=vxZZY3izFeq
> > > lPG2oAGQqqxxfPZSoaeUZH6mYPCPUQ5E==https://clicktime.symantec.com
> > > /15t5jYwsx6K5Z7UziRch6?h%3DVKa9Ey2evQPqt
> > > ITYTqeL8EywPKBX_Y4PmejsjmKDpPE==https://clicktime.symantec.com/1
> > > 5sMkktsDT7339Npks3Wt?h=yuPM_pKiMhcXrkpDfmfCxN_suUc5M9SM7Jm7p9i18k4
> > > ==https://lists.apache.org/thread/16
> > > 055md5s2d5fqch5t4vkn13j7czfybr
> > >
> > > But in short:
> > > - since 2.0.9 dependencies ARE ordered in deterministic way 
> > > (unsure how), but since Maven 3+ they are pre-order (graph 
> > > "flattened" into list, that
> > is
> > > then used to create CP and

RE: enforcing class path order using maven enforcer

I'd like to clarify one point about why I care about order:
I have a class name which clashes on purpose!
That is, I have a third-party dependency from maven central that does the Wrong 
Thing in one of its classes.
I have my own "fork" of that class which does the Right Thing.
I want to make sure that my version gets picked up!

-Original Message-
From: Tamás Cservenák  
Sent: Friday, July 28, 2023 5:29 PM
To: Maven Users List 
Subject: Re: enforcing class path order using maven enforcer


CAUTION: This email originated from outside our organisation - 
ta...@cservenak.net Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.
Yup,

My "coinciding" work was not to fix people depending in cp ordering, but was 
more related to my guts telling that "level order" (introduced in experiment 
PR) is more correct than "pre order".

Latter may cause that your 3rd or 4th level transitive dep be enlisted on CP 
before your 2nd first level dependency (ie.if you consider a pom with 2 
dependencies, 1st dep nth level transitive dependency may "shadow" your 2nd 
direct dependency).

Thanks
T

On Fri, Jul 28, 2023, 23:14 Nick Stolwijk  wrote:

> Hi Tamás,
>
> Thanks for the corrections! I was still in the belief that it wasn't 
> explicitly ordered, but it seems that changed in the years. I still 
> think it is easier to reason about your application if you don't 
> depend on the order of dependencies. I have always used the Enforcer 
> plugin to at first give warnings about duplicate classes and later in 
> a project (when (almost) every duplicate was solved) to start failing 
> the build if someone introduced a new duplicate.
>
> I have seen a lot of "strange" behaviour because the IDE used a 
> different ordering than Maven did, and don't start about the runtime. 
> If you have duplicate classes and Maven "behaves", who says that the 
> runtime behaves in the same way?
>
> I would make it a bigger issue that you have duplicate classes, 
> instead of trying to live with those duplicates.
>
> With regards,
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, 
> when your turn comes to die, you can die happy in feeling that at any 
> rate you have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Fri, 28 Jul 2023 at 22:56, Tamás Cservenák  wrote:
>
> > Nick,
> >
> > I have to correct you, as what you wrote is not true (anymore). But
> first,
> > I think this mail was on hold by moderator, as we had a same/similar 
> > discussion already on this thread:
> > https://clicktime.symantec.com/15t5jYwsx6K5Z7UziRch6?h=VKa9Ey2evQPqt
> > ITYTqeL8EywPKBX_Y4PmejsjmKDpPE==https://lists.apache.org/thread/16
> > 055md5s2d5fqch5t4vkn13j7czfybr
> >
> > But in short:
> > - since 2.0.9 dependencies ARE ordered in deterministic way (unsure 
> > how), but since Maven 3+ they are pre-order (graph "flattened" into 
> > list, that
> is
> > then used to create CP and similar things)
> > - the plugins are ordered as well (and Maven 4 got or is about to 
> > get
> even
> > finer solution)
> > - and in above mentioned thread, this is where we at
> >
> >
> https://clicktime.symantec.com/15t5eikbVUdV9Af5AsDYU?h=sAaRELxca8Z4PlY
> jvO260Lq5WEBvkad0aTt_3p0wSb0==https://issues.apache.org/jira/browse/
> MNG-6357?focusedCommentId%3D17748655%26page%3Dcom.atlassian.jira.plugi
> n.system.issuetabpanels%253Acomment-tabpanel%23comment-17748655
> > - for the rest (overlapping classes) I do agree fully, but life is
> life...
> >
> > HTH
> > T
> >
> > On Fri, Jul 28, 2023 at 10:45 PM Nick Stolwijk 
> > 
> > wrote:
> >
> > > Hi Mark,
> > >
> > > I don't think there is any guarantee for ordering in Maven. The 
> > > dependencies are not ordered, the plugins in the build section are 
> > > not ordered. I remember that with a Java upgrade the plugins were 
> > > executed
> > in a
> > > different ordering due to a new implementation of HashMap. (Only 
> > > the plugins in the same phase in a lifecycle, of course). The only 
> > > thing ordered are the phases in the lifecycle.
> > >
> > > I think it would be more feasible to make sure you don't have
> > dependencies
> > > with overlapping classes (you can use the Maven Enforcer Plugin 
> > > for that[1]). If you really need those 2 dependencies on the 
> > > classpath,
> maybe
> > > you can try something with the Maven Shade Plugin, to give one of 
> > > those dependencies their unique package names[2].
> > >
> > > [1]
> > https://clicktime.symantec.com/15t6QCW9d1mprg6P4tot4?h=37l3X1rUMHCNa
> > zx5tx73nMPMatZatBRkIVE73EVfz5s==https://www.mojohaus.org/extra-enf
> > orcer-rules/banDuplicateClasses.html
> > > [2]
> > >
> > >
> >
> https://clicktime.symantec.com/15t5pP9AQhzfy4JvFz1qi?h=454YA129nQl0eUE
> Uetl13kca-YVeudTafYsvmeO1vd0==https://maven.apache.org/plugins/maven
> -shade-plugin/examples/class-relocation.html
> > >
> > > Hth,
> > >
> > > Nick Stolwijk
> > >
> > > ~~~ Try to

enforcing class path order using maven enforcer

I already asked this question on Stack Overflow but got no takers so I'm trying 
again here:

Suppose I have a maven module M which declares a direct dependency on modules X 
and Y.
I want the classes from X to come before classes from Y in the class path.
Is there any easy way to add a rule in maven enforcer to ensure that I don't 
accidentally swap the order sometime in the future?

Copied from here:
https://stackoverflow.com/questions/76766623/maven-enforcer-enforce-class-path-order


This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__
 
If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

RE: maven class path order documentation

I'm kind of glad you didn't notice ... I appreciated a peek behind the scenes :)
Re: effective POM ... THANK YOU for that bit of info.
You just saved me some un-countably large number of hours

-Original Message-
From: Tamás Cservenák  
Sent: Thursday, July 27, 2023 11:34 AM
To: Maven Users List 
Subject: Re: maven class path order documentation


CAUTION: This email originated from outside our organisation - 
ta...@cservenak.net Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.
1 - yes
2 - yes (Maven tries hard to simplify things for users, but heh)
3 - yes, model ordering matters, most easily checked with `mvn 
help:effective-pom`, so to say if depency A is before dependency B in effective 
POM, same should be true for classpath as well.

HTH
T

PS: Sorry for bloated answers, a I just spotted that this is user ML not dev 
ML



On Thu, Jul 27, 2023 at 5:29 PM 
wrote:

> Thank you!  I think my main takeaway here is that things (1) in flux 
> (and hopefully will improve in Maven 4) and (2) a bit complicated but
> (3) I can still guarantee something comes first by listing it as the 
> first thing in the pom (is that right?)
>
> Thanks once more!
> Mark.
>
> -Original Message-
> From: Tamás Cservenák 
> Sent: Thursday, July 27, 2023 10:52 AM
> To: Maven Users List 
> Subject: Re: maven class path order documentation
>
>
> CAUTION: This email originated from outside our organisation - 
> ta...@cservenak.net Do not click on links, open attachments, or 
> respond unless you recognize the sender and can validate the content is safe.
> What a coincidence...
>
> I just started looking at an old issue (was looking at some edge 
> cases) where even reproducer exists and tackles similar topic:
>
> https://clicktime.symantec.com/15t5z3XK8nENdtkfvA1F3?h=Efy8jMRjTS28CUJ
> yvgBnMOlaMr07e6ETXpi8khKLG3k==https://clicktime.symantec.com/15t6KNJ
> TXrTg4ycqwxBMc?h=jjrDqGSUIIzfItPuUlNL0cZ6EcbEUAyYjGsGWHa9PZs==https:
> //issues.apache.org/jira/browse/MNG-6357
>
> Then I went to maven sources and resolver sources to ensure what is 
> happening.
>
> Sadly, maven is not quite consistent in this matter, but is at least
> aligned:
> - at some places it uses PreorderNodeListGenerator to generate 
> classpath (and/or ordered artifacts)
> - at some other places it relies on resolver ordering (that ALSO 
> implicitly uses preorder)
>
> The class in question:
>
> https://clicktime.symantec.com/15t5pP8kDYsBp16pq3Cwo?h=8f2DByrPlQLfzEc
> ejbPLFPQGuQ8TsuWhXGbnYcguXpQ==https://clicktime.symantec.com/15t69hu
> tcd6VF5xzrqP4N?h=R8m2xl2plsLnGvWe4ykYwCzHW1JLzwvSPr1ZPXuWF94==https:
> //github.com/apache/maven-resolver/blob/maven-resolver-1.9.14/maven-re
> solver-util/src/main/java/org/eclipse/aether/util/graph/visitor/Preord
> erNodeListGenerator.java
>
> The example output:
>
> https://clicktime.symantec.com/15t5jYwTkwBbQ4GuHUooB?h=T619edEwyisQy-K
> WGy3VvRfMFWDbZCgujjHUqdh8Wfg==https://clicktime.symantec.com/15t64si
> cA1Qtq995KGyuk?h=WyCartbzFZ88lUfGKNkZl9EnZRGo4W-wpcagJX0Jv_I==https:
> //gist.github.com/cstamas/ca113c1d6697540a4cf55c3098b9a550
>
> As you can see in example, the classpath is basically ordered as 
> "reading the tree", this causes that for example maven-dependency-tree 
> (2nd level
> dependency) comes BEFORE enforcer-api (1sd level) dependency.
>
> So, I myself find this wrong as well, but at least the statement you 
> found "introduced deterministic ordering of dependencies on the 
> classpath" still stands today: is PreOrder.
>
> Then occurred to me that this is easily customisable, so I went for 
> start to create this:
>
> https://clicktime.symantec.com/15t5uDL2gAYnDwvkNbc6R?h=Oo9ciO2fkPcfkh2
> 9sRGMpRA_gqMZXDNvOTPIvINgw_A==https://clicktime.symantec.com/15t6EY7
> B5En5f2nvQPnCz?h=RAMVKqx23S9dHMSzavpisUWoKjVPuHmkZdU9MV01Es0==https:
> //github.com/apache/maven-resolver/pull/322
>
> But this is only half of the story, as the Maven part is missing, 
> especially where Maven sorts itself...
>
> All in all, an interesting coincidence
>
> As for your other question: what resolver does is
> - builds a "dirty tree" (graph more precisely, it may have loops), we 
> have two algorithms for this: original depth-first (DF) and new 
> breadth-first
> (BF)
> - applies conflict resolution (this is where "winners" are set, ie.
> "closest wins" in case of duplicates)
> - resulted "clean tree" is transformed into list of (resolved) 
> artifacts, possibly into classpath as well
> - OR the resolved graph is with class like (but
> consistently) PreorderNodeListGenerator used to create classpath -- so 
> PreOrder is applied always
>
> Thanks
> T
>
>
> On Thu, Jul 27, 2023 at 3:51 PM 
> 
> wrote:
>
> > Re-sending... didn't go through I think:
> >
> > In the release notes for Maven 2.0.9:
> > https://clicktime.symantec.com/15t5jYwUKYgXBMqP93PKG?h=B3zpy8Wm3QKeJ
> > 3HpKUt5HE7QUPHkZpQLqv7all73das==https://clicktime.symantec.com/15t
> >

RE: maven class path order documentation

Wow, so this stuff is literally "hot off the press"!  Is this likely to end up 
in the 3.x series, or need to upgrade to 4?
Also, once it goes in, can this please be documented somewhere more "official" 
than a release notes thingy?

-Original Message-
From: Tamás Cservenák  
Sent: Thursday, July 27, 2023 11:29 AM
To: Maven Users List 
Subject: Re: maven class path order documentation


CAUTION: This email originated from outside our organisation - 
ta...@cservenak.net Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.
And here it is:
https://clicktime.symantec.com/15sipz7F5STrvRGrevHBY?h=7Y8hfhGCp9uBBufC8Pdra11MjKQK1pB9sZxKj0WyVT4==https://github.com/apache/maven/pull/1212

To have this tested, first build this
https://clicktime.symantec.com/15sik9uxcpnGWUSw7Mt2v?h=Ykgfx9FlWtp9Mzx3hItBj6j3zdtVOq7AohrAHo-SEhg==https://github.com/apache/maven-resolver/pull/322
then this:
https://clicktime.symantec.com/15sipz7F5STrvRGrevHBY?h=7Y8hfhGCp9uBBufC8Pdra11MjKQK1pB9sZxKj0WyVT4==https://github.com/apache/maven/pull/1212

And you will end up with maven:
- that fully delegates to resolver classpath ordering (removed all places where 
they are "sorted", it is done by resolver)
- resolver supports "preOrder, "postOrder" and "levelOrder" transformation

Examples:
preOrder 
https://clicktime.symantec.com/15siaVXPhbR5gao62F5jg?h=ZNj2Gfw4KUWOqAboOy7hrW4_dA-8ANFsatojmBQ23HU==https://gist.github.com/cstamas/d1cb11d96938cdb9e6da2b46eec449b6
levelOrder 
https://clicktime.symantec.com/15siQq8pnN3trh9Ew8HSS?h=SFbeFNH1ZOnGqJUbSsU15ER7BNDe9eZuFYruemWExQo==https://gist.github.com/cstamas/6498cfb31afe74ded1471c02d982eee6

Observe how collected trees are TOTALLY SAME, but classpath order differs.

Thanks
T

On Thu, Jul 27, 2023 at 4:51 PM Tamás Cservenák  wrote:

> What a coincidence...
>
> I just started looking at an old issue (was looking at some edge 
> cases) where even reproducer exists and tackles similar topic:
> https://clicktime.symantec.com/15siupJXY49TLN6nCUgLA?h=7vkUPM03eakDwHh
> dabKdvr3cDonDm1gylwtF58tHzag==https://issues.apache.org/jira/browse/
> MNG-6357
>
> Then I went to maven sources and resolver sources to ensure what is 
> happening.
>
> Sadly, maven is not quite consistent in this matter, but is at least
> aligned:
> - at some places it uses PreorderNodeListGenerator to generate 
> classpath (and/or ordered artifacts)
> - at some other places it relies on resolver ordering (that ALSO 
> implicitly uses preorder)
>
> The class in question:
>
> https://clicktime.symantec.com/15sifKigAD6g6Xd1ZoUtJ?h=SEFwjM88CuRbMjD
> -_g1kUUwvb0y9AuM49l0EoicAJ_o==https://github.com/apache/maven-resolv
> er/blob/maven-resolver-1.9.14/maven-resolver-util/src/main/java/org/ec
> lipse/aether/util/graph/visitor/PreorderNodeListGenerator.java
>
> The example output:
> https://clicktime.symantec.com/15siVfL7EyjVGdyAUggb4?h=eKPHFWmgDwUy2Jd
> 9zqj7FZMg0YLR8cEQ_HTJ5N88EVk==https://gist.github.com/cstamas/ca113c
> 1d6697540a4cf55c3098b9a550
>
> As you can see in example, the classpath is basically ordered as 
> "reading the tree", this causes that for example maven-dependency-tree 
> (2nd level
> dependency) comes BEFORE enforcer-api (1sd level) dependency.
>
> So, I myself find this wrong as well, but at least the statement you 
> found "introduced deterministic ordering of dependencies on the 
> classpath" still stands today: is PreOrder.
>
> Then occurred to me that this is easily customisable, so I went for 
> start to create this:
> https://clicktime.symantec.com/15sik9uxcpnGWUSw7Mt2v?h=Ykgfx9FlWtp9Mzx
> 3hItBj6j3zdtVOq7AohrAHo-SEhg==https://github.com/apache/maven-resolv
> er/pull/322
>
> But this is only half of the story, as the Maven part is missing, 
> especially where Maven sorts itself...
>
> All in all, an interesting coincidence
>
> As for your other question: what resolver does is
> - builds a "dirty tree" (graph more precisely, it may have loops), we 
> have two algorithms for this: original depth-first (DF) and new 
> breadth-first
> (BF)
> - applies conflict resolution (this is where "winners" are set, ie.
> "closest wins" in case of duplicates)
> - resulted "clean tree" is transformed into list of (resolved) 
> artifacts, possibly into classpath as well
> - OR the resolved graph is with class like (but
> consistently) PreorderNodeListGenerator used to create classpath -- so 
> PreOrder is applied always
>
> Thanks
> T
>
>
> On Thu, Jul 27, 2023 at 3:51 PM 
> 
> wrote:
>
>> Re-sending... didn't go through I think:
>>
>> In the release notes for Maven 2.0.9:
>>
>> https://clicktime.symantec.com/15siFAkFs8gi2oVPr1V9C?h=CzqA8kBOdhB05Y
>> fPbEvxwyofbPnfsaxl96JNiQ24c3U==http://people.apache.org/~jvanzyl/ma
>> ven-3.1.1/docs/2.0.9/release-notes.html
>> It says: "introduced deterministic ordering of dependencies on the 
>> classpath. In the past, natural set ordering was used and this lead 
>> to odd results. The ordering is now preserved from your

RE: maven class path order documentation

Thank you!  I think my main takeaway here is that things (1) in flux (and 
hopefully will improve in Maven 4) and (2) a bit complicated but
(3) I can still guarantee something comes first by listing it as the first 
thing in the pom (is that right?)

Thanks once more!
Mark.

-Original Message-
From: Tamás Cservenák  
Sent: Thursday, July 27, 2023 10:52 AM
To: Maven Users List 
Subject: Re: maven class path order documentation


CAUTION: This email originated from outside our organisation - 
ta...@cservenak.net Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.
What a coincidence...

I just started looking at an old issue (was looking at some edge cases) where 
even reproducer exists and tackles similar topic:
https://clicktime.symantec.com/15t5z3XK8nENdtkfvA1F3?h=Efy8jMRjTS28CUJyvgBnMOlaMr07e6ETXpi8khKLG3k==https://issues.apache.org/jira/browse/MNG-6357

Then I went to maven sources and resolver sources to ensure what is happening.

Sadly, maven is not quite consistent in this matter, but is at least
aligned:
- at some places it uses PreorderNodeListGenerator to generate classpath 
(and/or ordered artifacts)
- at some other places it relies on resolver ordering (that ALSO implicitly 
uses preorder)

The class in question:
https://clicktime.symantec.com/15t5pP8kDYsBp16pq3Cwo?h=8f2DByrPlQLfzEcejbPLFPQGuQ8TsuWhXGbnYcguXpQ==https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.14/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PreorderNodeListGenerator.java

The example output:
https://clicktime.symantec.com/15t5jYwTkwBbQ4GuHUooB?h=T619edEwyisQy-KWGy3VvRfMFWDbZCgujjHUqdh8Wfg==https://gist.github.com/cstamas/ca113c1d6697540a4cf55c3098b9a550

As you can see in example, the classpath is basically ordered as "reading the 
tree", this causes that for example maven-dependency-tree (2nd level
dependency) comes BEFORE enforcer-api (1sd level) dependency.

So, I myself find this wrong as well, but at least the statement you found 
"introduced deterministic ordering of dependencies on the classpath" still 
stands today: is PreOrder.

Then occurred to me that this is easily customisable, so I went for start to 
create this:
https://clicktime.symantec.com/15t5uDL2gAYnDwvkNbc6R?h=Oo9ciO2fkPcfkh29sRGMpRA_gqMZXDNvOTPIvINgw_A==https://github.com/apache/maven-resolver/pull/322

But this is only half of the story, as the Maven part is missing, especially 
where Maven sorts itself...

All in all, an interesting coincidence

As for your other question: what resolver does is
- builds a "dirty tree" (graph more precisely, it may have loops), we have two 
algorithms for this: original depth-first (DF) and new breadth-first
(BF)
- applies conflict resolution (this is where "winners" are set, ie.
"closest wins" in case of duplicates)
- resulted "clean tree" is transformed into list of (resolved) artifacts, 
possibly into classpath as well
- OR the resolved graph is with class like (but
consistently) PreorderNodeListGenerator used to create classpath -- so PreOrder 
is applied always

Thanks
T


On Thu, Jul 27, 2023 at 3:51 PM 
wrote:

> Re-sending... didn't go through I think:
>
> In the release notes for Maven 2.0.9:
> https://clicktime.symantec.com/15t5ZtYtqhpQaAd4CN1Vw?h=XDVhSYMduTltP5c
> FPTLr7pXDMQ0hXrn_euWrugDjQoo==http://people.apache.org/~jvanzyl/mave
> n-3.1.1/docs/2.0.9/release-notes.html
> It says: "introduced deterministic ordering of dependencies on the 
> classpath. In the past, natural set ordering was used and this lead to 
> odd results. The ordering is now preserved from your pom, with 
> dependencies added by inheritance added last"
> Is this info still current?  Is it documented anywhere aside from this 
> release note?  If not, perhaps it should be?  And more details would 
> be nice too.  For instance:
>
> * Suppose my module M has parent P and grandparent G.   Also, M
> depends on A and B, in that order.  Further, suppose A depends on X, 
> which in turn depends on Y.  Meanwhile, B depends on Z.
>
> Based on the sentence above, both of these are plausible orders:
>
> a.M, A, B, X, Z, Y, P, G
>
> b.M, A, X, Y, B, Z, P, G
>
> c. Maybe others too?
>
> * How does this relate to the dependency "mediation" algorithm
> maven uses when there are conflicting versions of a dependency requested?
>
> As far as I understand, that uses a breadth-first search, where the 
> parent pom comes FIRST rather than last.
>
> Does that mean that mediation algorithm is basically unrelated to 
> class path algorithm, or do they still have some things in common?
>
> E.g., ordering (a) above is also a breadth-first search, whereas (b) 
> is depth-first.
> Any words of wisdom would be nice.
>
> Thanks,
> Mark.
>
> This message is for information purposes only. It is not a 
> recommendation, advice, offer or solicitation to buy or sell a product 
> or service, nor an official confirmation of any

maven class path order documentation

Re-sending... didn't go through I think:

In the release notes for Maven 2.0.9:
http://people.apache.org/~jvanzyl/maven-3.1.1/docs/2.0.9/release-notes.html
It says: "introduced deterministic ordering of dependencies on the classpath. 
In the past, natural set ordering was used and this lead to odd results. The 
ordering is now preserved from your pom, with dependencies added by inheritance 
added last"
Is this info still current?  Is it documented anywhere aside from this release 
note?  If not, perhaps it should be?  And more details would be nice too.  For 
instance:

* Suppose my module M has parent P and grandparent G.   Also, M depends 
on A and B, in that order.  Further, suppose A depends on X, which in turn 
depends on Y.  Meanwhile, B depends on Z.

Based on the sentence above, both of these are plausible orders:

a.M, A, B, X, Z, Y, P, G

b.M, A, X, Y, B, Z, P, G

c. Maybe others too?

* How does this relate to the dependency "mediation" algorithm maven 
uses when there are conflicting versions of a dependency requested?

As far as I understand, that uses a breadth-first search, where the parent pom 
comes FIRST rather than last.

Does that mean that mediation algorithm is basically unrelated to class path 
algorithm, or do they still have some things in common?

E.g., ordering (a) above is also a breadth-first search, whereas (b) is 
depth-first.
Any words of wisdom would be nice.

Thanks,
Mark.

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__
 
If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

RE: request for documentation update about mirrors

True, it is "just a file". It was actually my first idea, before I emailed
this list. But though it's "just a file", it's a file I'd have to keep editing
every time I updated maven.
It's likewise a file everyone else on the team needs to be taught to edit every
time they update maven.

Fun fact: the way I discovered this issue is via an accidental maven update. I
was using the maven bundled with my IDE. I then updated my IDE.
The release "highlights" page for the IDE did not even mention it comes bundled
with a new maven version.

So, another way to describe editing this file is "maintaining our own private
fork of maven".
As far as forks go, it's a pretty mild one. It doesn't require us to compile
maven from source, or anything scary like that.

But it's still a fork. And it's still annoying. I'm looking for something
more like this:
https://stackoverflow.com/questions/67001968/how-to-disable-maven-blocking-external-http-repositores/68394404#68394404

(in fact, maybe that's exactly what I'm looking for.)
_
This message is for information purposes only, it is not a recommendation,
advice, offer or solicitation to buy or sell a product or service nor an
official confirmation of any transaction. It is directed at persons who are
professionals and is not intended for retail customer use. Intended for
recipient only. This message is subject to the terms at:
www.barclays.com/emaildisclaimer.

For important disclosures, please see:
www.barclays.com/salesandtradingdisclaimer regarding market commentary from
Barclays Sales and/or Trading, who are active market participants;
https://www.investmentbank.barclays.com/disclosures/barclays-global-markets-disclosures.html
regarding our standard terms for the Investment Bank of Barclays where we
trade with you in principal-to-principal wholesale markets transactions; and in
respect of Barclays Research, including disclosures relating to specific
issuers, please see http://publicresearch.barclays.com.
_
If you are incorporated or operating in Australia, please see
https://www.home.barclays/disclosures/importantapacdisclosures.html for
important disclosure.
_
How we use personal information see our privacy notice
https://www.investmentbank.barclays.com/disclosures/personalinformationuse.html
_

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

RE: request for documentation update about mirrors

> But if you insist, I heared you can remove the blocked tag in your maven/conf
> settings.. ;)
But I can't, right? I'd have edit the global settings file bundled with maven
itself.
Or no?

_
This message is for information purposes only, it is not a recommendation,
advice, offer or solicitation to buy or sell a product or service nor an
official confirmation of any transaction. It is directed at persons who are
professionals and is not intended for retail customer use. Intended for
recipient only. This message is subject to the terms at:
www.barclays.com/emaildisclaimer.

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

RE: request for documentation update about mirrors

Sorry for broken threading; I wasn't subscribed to the mailing list so I never
got your reply; not sure how to fix it now. Now I'm subscribed.

Yes, we are using nexus. One of our nexus servers is even using HTTPS. The
rest are not.
As for why we have "many" ... I'm not entirely sure. It was like that when I
got here.
I could ask around, but I'm not sure how much it matters. Could be

* Historical reasons

* Bureaucratic reasons

* Or maybe even very good reasons that I happen to not know.
As it happens, many of these "separate" nexus repositories are on the same
server, but maven treats them all as if they are distinct, because they have
different paths. E.g. one might be
http://nexus.example.com:8080/nexus/content/groups/main/
while another might be
http://nexus.example.com:8080/nexus/content/repositories/UPLOAD-EXTERNAL-RELEASES/

Not sure if any of this answers your question.

request for documentation update about mirrors