Re: NPE in AbstractMavenReport.execute, because 'this.siteTool' is null

[Alexander Kriegisch]

Reverting back to my original question, also summarised in the subject
of this thread: Why is 'this.siteTool' null and not injected properly?
If I knew how to fix that configuratively or via coding, I would no
longer need to override 'exceute()', which relies on that field being
set, as you can see in my original message's stack trace extract.

Is there a bug in my project? Or is there one in Maven Reporting Tools?

Regards
-- 
Alexander Kriegisch
https://scrum-master.de


Alexander Kriegisch schrieb am 10.10.2023 09:28 (GMT +07:00):

> Actually, my initial message already explained the situation:
> 
>   1. With 1.x, I have no issues. That was my starting point.
> 
>   2. With 2.0, I had no desire to verride 'execute()'. It was simply
>  the only thing that helped my project to function properly again.
>  I would be glad to do without it, especially given that fact that
>  now the method has been marked final.But I am still failing to
>  understand what I should do *instead*. It is nice that you
>  "expect it to work", because so do I. But in fact, it does not. I
>  gave you guys a reproducer to play with and exactly specified
>  which commits to check out and which integration test to run in
>  order to see both my situation before and after the ugly
>  workaround of overriding 'execute()'. Maybe I missed the decisive
>  hint in one of your messages, but for now, I have no idea how to
>  fix my plugin without that ugly workaround. Probably there is a
>  bug somewhere in the implementation in code I neither wrote nor
>  ever touched, which is why I was asking for help here. Feel free
>  to contact me off-list,if you think the noise is too much here.
> 
> 
> Michael Osipov schrieb am 09.10.2023 17:03 (GMT +07:00):
> 
>> I had these NPEs when I started to migrate reporting plugins and both
>> the plugin and the super class contained the same fields which
>> created conflicts. After I have removed them from the plugin and used
>> the super ones all went fine. In your case I would really do what
>> Hervé proposes:
>> 
>> * remove your execute() and retest with 1.x * in a branch try with
>> 2.x
>> 
>> I expect it to work. You can also look at all of your reporting
>> plugins in branch doxia-2.0.0 you'll see all necessary migration
>> magic from me. The PR with finalizing the method is good and already
>> merged.

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

Re: NPE in AbstractMavenReport.execute, because 'this.siteTool' is null

[Alexander Kriegisch]

Actually, my initial message already explained the situation:

  1. With 1.x, I have no issues. That was my starting point.

  2. With 2.0, I had no desire to verride 'execute()'. It was simply the
 only thing that helped my project to function properly again. I
 would be glad to do without it, especially given that fact that now
 the method has been marked final.But I am still failing to
 understand what I should do *instead*. It is nice that you "expect
 it to work", because so do I. But in fact, it does not. I gave you
 guys a reproducer to play with and exactly specified which commits
 to check out and which integration test to run in order to see both
 my situation before and after the ugly workaround of overriding
 'execute()'. Maybe I missed the decisive hint in one of your
 messages, but for now, I have no idea how to fix my plugin without
 that ugly workaround. Probably there is a bug somewhere in the
 implementation in code I neither wrote nor ever touched, which is
 why I was asking for help here. Feel free to contact me off-list,if
 you think the noise is too much here.

Best regards
-- 
Alexander Kriegisch
https://scrum-master.de


Michael Osipov schrieb am 09.10.2023 17:03 (GMT +07:00):

> I had these NPEs when I started to migrate reporting plugins and both the
> plugin and the super class contained the same fields which created conflicts.
> After I have removed them from the plugin and used the super ones all went
> fine. In your case I would really do what Hervé proposes:
> 
> * remove your execute() and retest with 1.x
> * in a branch try with 2.x
> 
> I expect it to work. You can also look at all of your reporting plugins in
> branch doxia-2.0.0 you'll see all necessary migration magic from me. The PR
> with finalizing the method is good and already merged.
> 
> M
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

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

Re: maven-polyglot

[Eric Kolotyluk]

Excellent response... thanks.

Poking around, I appreciate your POC comment the most. I will only use 
maven-polyglot in my recreational programming as a learning experience 
until there becomes some compelling advantage otherwise.


1. good point... I concur
2. good point... yes, understandable synergy problems
3. good point... yes, many people claim things are easier, better than
   they really are
4. good point... yes, the sophistication of our tools increasingly
   makes diagnostics and troubleshooting more difficult

Working in a Gradle shop, many of these points also apply to my 
frustration with Gradle, and SBT from previous shops...


Cheers, Eric

On 2023-10-09 2:35 p.m., Greg Chabala wrote:

I have looked into maven-polyglot before, and come to the conclusion that
it is a proof of concept, and something that few if any people actually
use, because:

1. Professional programmers are not actually offended by using XML in
the POM, only novices would complain about such a thing.
2. All tooling will expect a pom.xml, e.g. IDEs, CI tools, linters, etc.
If any of those things are able to handle a polyglot POM in non-XML, that's
a tiny miracle.
3. maven-polyglot gets mentioned when people complain about Maven using
XML, as 'look, you don't have to, you can use whatever you want' but no one
actually does.
4. The first suspect when something doesn't work right in your build
will always be maven-polyglot, because no one uses it, so it's
potentially not compatible with every plugin. Then you get to convert back
to pom.xml and try again. So better to skip the effort and stay with XML in
the first place.

Re: maven-polyglot

[Tamás Cservenák]

Agreed,

Personally, I'd make POM XML (as de facto standard and supported in many
tools/apps/libs/etc) mandatory, so it could be:
a) you author POM XML (as today in vanilla maven), or
b) you author POM in your fave lang (as today in vanilla polyglot) and
Maven makes sure POM XML is present and up to date? [this needs maven some
internals change]

Btw, initial polyglot capabilities have been lifted into Maven 4 as well.

HTH
Tamas

On Tue, Oct 10, 2023 at 12:10 AM Greg Chabala 
wrote:

> That is a good example of the tradeoffs as well. In several places the
> pom.rb is forced to generate a pom.xml to satisfy other tooling, as
> mentioned here:
>
> https://github.com/jruby/jruby/blob/047188902e8d1d307d1f9e51d1bdc60ec1d09bc9/BUILDING.md#hacking-the-build-system
>
> On Mon, Oct 9, 2023 at 4:49 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > I am aware for example the JRuby uses polyglot:
> > https://github.com/jruby/jruby
> >
> > AFAIK, not all languages are "same done" or maybe I may risk "same
> > quality", for example JRuby/pom.rb is nicely maintained, unsure for other
> > ones...
> >
> > Thanks
> > T
> >
> >
> >
> > On Mon, Oct 9, 2023 at 11:35 PM Greg Chabala 
> > wrote:
> >
> > > I have looked into maven-polyglot before, and come to the conclusion
> that
> > > it is a proof of concept, and something that few if any people actually
> > > use, because:
> > >
> > >1. Professional programmers are not actually offended by using XML
> in
> > >the POM, only novices would complain about such a thing.
> > >2. All tooling will expect a pom.xml, e.g. IDEs, CI tools, linters,
> > etc.
> > >If any of those things are able to handle a polyglot POM in non-XML,
> > > that's
> > >a tiny miracle.
> > >3. maven-polyglot gets mentioned when people complain about Maven
> > using
> > >XML, as 'look, you don't have to, you can use whatever you want' but
> > no
> > > one
> > >actually does.
> > >4. The first suspect when something doesn't work right in your build
> > >will always be maven-polyglot, because no one uses it, so it's
> > >potentially not compatible with every plugin. Then you get to
> convert
> > > back
> > >to pom.xml and try again. So better to skip the effort and stay with
> > > XML in
> > >the first place.
> > >
> >
>

Re: maven-polyglot

[Greg Chabala]

That is a good example of the tradeoffs as well. In several places the
pom.rb is forced to generate a pom.xml to satisfy other tooling, as
mentioned here:
https://github.com/jruby/jruby/blob/047188902e8d1d307d1f9e51d1bdc60ec1d09bc9/BUILDING.md#hacking-the-build-system

On Mon, Oct 9, 2023 at 4:49 PM Tamás Cservenák  wrote:

> Howdy,
>
> I am aware for example the JRuby uses polyglot:
> https://github.com/jruby/jruby
>
> AFAIK, not all languages are "same done" or maybe I may risk "same
> quality", for example JRuby/pom.rb is nicely maintained, unsure for other
> ones...
>
> Thanks
> T
>
>
>
> On Mon, Oct 9, 2023 at 11:35 PM Greg Chabala 
> wrote:
>
> > I have looked into maven-polyglot before, and come to the conclusion that
> > it is a proof of concept, and something that few if any people actually
> > use, because:
> >
> >1. Professional programmers are not actually offended by using XML in
> >the POM, only novices would complain about such a thing.
> >2. All tooling will expect a pom.xml, e.g. IDEs, CI tools, linters,
> etc.
> >If any of those things are able to handle a polyglot POM in non-XML,
> > that's
> >a tiny miracle.
> >3. maven-polyglot gets mentioned when people complain about Maven
> using
> >XML, as 'look, you don't have to, you can use whatever you want' but
> no
> > one
> >actually does.
> >4. The first suspect when something doesn't work right in your build
> >will always be maven-polyglot, because no one uses it, so it's
> >potentially not compatible with every plugin. Then you get to convert
> > back
> >to pom.xml and try again. So better to skip the effort and stay with
> > XML in
> >the first place.
> >
>

Re: maven-polyglot

[Tamás Cservenák]

Howdy,

I am aware for example the JRuby uses polyglot:
https://github.com/jruby/jruby

AFAIK, not all languages are "same done" or maybe I may risk "same
quality", for example JRuby/pom.rb is nicely maintained, unsure for other
ones...

Thanks
T



On Mon, Oct 9, 2023 at 11:35 PM Greg Chabala  wrote:

> I have looked into maven-polyglot before, and come to the conclusion that
> it is a proof of concept, and something that few if any people actually
> use, because:
>
>1. Professional programmers are not actually offended by using XML in
>the POM, only novices would complain about such a thing.
>2. All tooling will expect a pom.xml, e.g. IDEs, CI tools, linters, etc.
>If any of those things are able to handle a polyglot POM in non-XML,
> that's
>a tiny miracle.
>3. maven-polyglot gets mentioned when people complain about Maven using
>XML, as 'look, you don't have to, you can use whatever you want' but no
> one
>actually does.
>4. The first suspect when something doesn't work right in your build
>will always be maven-polyglot, because no one uses it, so it's
>potentially not compatible with every plugin. Then you get to convert
> back
>to pom.xml and try again. So better to skip the effort and stay with
> XML in
>the first place.
>

Re: maven-polyglot

[Greg Chabala]

I have looked into maven-polyglot before, and come to the conclusion that
it is a proof of concept, and something that few if any people actually
use, because:

   1. Professional programmers are not actually offended by using XML in
   the POM, only novices would complain about such a thing.
   2. All tooling will expect a pom.xml, e.g. IDEs, CI tools, linters, etc.
   If any of those things are able to handle a polyglot POM in non-XML, that's
   a tiny miracle.
   3. maven-polyglot gets mentioned when people complain about Maven using
   XML, as 'look, you don't have to, you can use whatever you want' but no one
   actually does.
   4. The first suspect when something doesn't work right in your build
   will always be maven-polyglot, because no one uses it, so it's
   potentially not compatible with every plugin. Then you get to convert back
   to pom.xml and try again. So better to skip the effort and stay with XML in
   the first place.

Re: maven-polyglot

[Florent Biville]

Hello,

This is probably not what you're looking for, but a colleague and I created
this example for an internal training on Apache Maven that we're giving in
a regular basis: https://github.com/learning-maven/pom-as-yaml

Hope it helps,
Florent

On Mon, Oct 9, 2023, 23:16 Eric Kolotyluk  wrote:

> Does anyone have any experience with
> https://www.baeldung.com/maven-polyglot they can share?
>
> Cheers, Eric
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

maven-polyglot

[Eric Kolotyluk]

Does anyone have any experience with 
https://www.baeldung.com/maven-polyglot they can share?


Cheers, Eric


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

Re: maven.plugin.validation

[Eric Kolotyluk]

Tested ./mvn/maven.config and it works... thanks  and it's in SCM...

This is probably my preferred place for such things as the other places 
are more ephemeral... and I learned a new Maven trick 


Thanks for the explanation of 'project properties' and I can understand 
such implementation issues. The only cure really is in the diagnostic 
message, and it looks you're on top of that... and many thanks there too.


As an aside, I don't use Maven as much these days as the team I am on 
are (overly) committed to Gradle. Compared to Maven, Gradle is very low 
quality with respect to large projects. We are considering Idiomatic 
Gradle , but that adds 
another layer of complexity because native Gradle lacks important features.


Your responses to my email prove that the Maven maintainers are far more 
professional in how they treat the product and consumers.


Cheers, Eric

On 2023-10-09 3:20 a.m., Tamás Cservenák wrote:

And addendum:

Yet another way to set this "for good": using .mvn/maven.config:
https://gist.github.com/cstamas/0f07b4b045ae5c98f60ecd530f928201

I think this above is what you want, as I assume you wanted to enable
validation for the project (in which POM you defined this property) and
have it enabled always. This file .mvn/maven.config should be checked in
into SCM along with POMs and sources, and you are good to go.

On Mon, Oct 9, 2023 at 12:02 PM Tamás Cservenák  wrote:


Errata:
my "as Maven System Property" example is wrong (I had leftover `export
MAVEN_OPTS` from previous run)... so please neglect that example.

On Mon, Oct 9, 2023 at 11:58 AM Tamás Cservenák
wrote:


Howdy Eric,

You are right, and sorry for this, I am (we all are) a bit overwhelmed
these days

So you are right, that line should say "use 'maven.plugin.validation'
**user** property". User properties (as told by mvn -h) are defined by the
"-D" CLI switch.

Re adding URL to message: Herve started already doing that, and many
thanks to him for improving the horrible UX of this (IMHO important)
feature.
For start, he started refining the page and add it to release notes:
https://github.com/apache/maven-site/pull/461

And finally, regarding my answer to the 2nd part... to me it seems that
the message was not fully delivered (for a non-core developer, it may, but
for sake of completeness let me elaborate it):

I just wanted to explain why Project Property CANNOT be used here... as
if you think about Maven starting: JVM boots and Java System Properties are
available, then Maven core "boots" (where Maven System Properties and Maven
User Properties are assembled), and once booted, only then is model being
loaded/parsed/built.

Now, this where the validation should kick in (either for plugins defined
in current project POM or in current project but with plugin goal directly
invoked on CLI), hence, Project Properties (those on POM) are simply put
"too late" for this, or are like chicken-and-egg problem (to load, we need
to validate, but to report validation issues we need properties loaded).

In conclusion, `maven.plugin.validation` may be defined as ANY Maven
property EXCEPT Project property :)

Examples (did them on maven-3.9.x branch of
https://github.com/apache/maven):

- as Java System Property:
https://gist.github.com/cstamas/ecb5170d61de79117c4181c7f3cbfe78
- as Maven System Property (env):
https://gist.github.com/cstamas/a03eacc66a01eb12896199d846ebc339
- as Maven User Property:
https://gist.github.com/cstamas/14d5aed712720d558bff704944f46d21

HTH
Tamas

On Sun, Oct 8, 2023 at 11:51 PM Eric Kolotyluk
wrote:


Wow... great response...

Since you offered such a thoughtful response, I will try to do
likewise...

As someone who used to teach UI/UX in a third year university course,
and now an old curmudgeon , if I am going to see a message like

[WARNING] For more or less details, use 'maven.plugin.validation'
property with one of the values (case insensitive): [BRIEF, DEFAULT,
VERBOSE]

I should not have to care what kind of property I am dealing with
because the message lacks context.

Now, in many places I admire the skill, craftsmanship, intelligence, and
pure genius of Maven maintainers who add hyperlinks to their messages
for more context.  Indeed, a link to this amazing bit of knowledge,
https://maven.apache.org/guides/plugins/validation/index.html, would
have added such context. Maybe I should get off my lazy ass, fork the
repo, make the change, and submit a pull request...

In the larger picture, these distinctions over properties is, IMHO,
unnecessary complexity to the UX. Good design leverages good intuition.
IMHO, the plugin should accept the project property
maven.plugin.validation, but I am willing to entertain a cogent argument
why this should not be the case.

And thanks again for such a great response. I really enjoyed following
your explanation and references, and understanding better.

Cheers, Eric

P.S. Dealing with Maven people is way easier than 

Re: Why does one of our archetypes work, and the other gets "The defined artifact is not an archetype"

[David Karr]

Ok, I'll address some points in order.  My current command line is this:
--
mvn -e archetype:generate -DgroupId=com.att.idp -DartifactId=MyApplication
-Dpackage=com.att.idp -DarchetypeGroupId=com.att.idse
-DarchetypeArtifactId=idse-springmvc-archetype
-DarchetypeVersion=2.0.0-SNAPSHOT
--

And this is a relevant excerpt of the pom.xml from the archetype:
--
 com.att.idse
idse-springmvc-archetype
2.0.0-SNAPSHOT

IDP Jersey Archetype
Maven Archetype for creating the IDP microservices
project

jar


Note that it uses the "jar" packaging, but I'll come back to that later in
this message.

Running this results in the following:
--
10:41:09 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-archetype-plugin:3.2.1:generate
(default-cli) on project standalone-pom: The defined artifact is not an
archetype -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-archetype-plugin:3.2.1:generate
(default-cli) on project standalone-pom: The defined artifact is not an
archetype
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
Caused by: org.apache.maven.plugin.MojoFailureException: The defined
artifact is not an archetype
at
org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute
(CreateProjectFromArchetypeMojo.java:225)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode

Re: maven.plugin.validation

[Tamás Cservenák]

And addendum:

Yet another way to set this "for good": using .mvn/maven.config:
https://gist.github.com/cstamas/0f07b4b045ae5c98f60ecd530f928201

I think this above is what you want, as I assume you wanted to enable
validation for the project (in which POM you defined this property) and
have it enabled always. This file .mvn/maven.config should be checked in
into SCM along with POMs and sources, and you are good to go.

On Mon, Oct 9, 2023 at 12:02 PM Tamás Cservenák  wrote:

> Errata:
> my "as Maven System Property" example is wrong (I had leftover `export
> MAVEN_OPTS` from previous run)... so please neglect that example.
>
> On Mon, Oct 9, 2023 at 11:58 AM Tamás Cservenák 
> wrote:
>
>> Howdy Eric,
>>
>> You are right, and sorry for this, I am (we all are) a bit overwhelmed
>> these days
>>
>> So you are right, that line should say "use 'maven.plugin.validation'
>> **user** property". User properties (as told by mvn -h) are defined by the
>> "-D" CLI switch.
>>
>> Re adding URL to message: Herve started already doing that, and many
>> thanks to him for improving the horrible UX of this (IMHO important)
>> feature.
>> For start, he started refining the page and add it to release notes:
>> https://github.com/apache/maven-site/pull/461
>>
>> And finally, regarding my answer to the 2nd part... to me it seems that
>> the message was not fully delivered (for a non-core developer, it may, but
>> for sake of completeness let me elaborate it):
>>
>> I just wanted to explain why Project Property CANNOT be used here... as
>> if you think about Maven starting: JVM boots and Java System Properties are
>> available, then Maven core "boots" (where Maven System Properties and Maven
>> User Properties are assembled), and once booted, only then is model being
>> loaded/parsed/built.
>>
>> Now, this where the validation should kick in (either for plugins defined
>> in current project POM or in current project but with plugin goal directly
>> invoked on CLI), hence, Project Properties (those on POM) are simply put
>> "too late" for this, or are like chicken-and-egg problem (to load, we need
>> to validate, but to report validation issues we need properties loaded).
>>
>> In conclusion, `maven.plugin.validation` may be defined as ANY Maven
>> property EXCEPT Project property :)
>>
>> Examples (did them on maven-3.9.x branch of
>> https://github.com/apache/maven):
>>
>> - as Java System Property:
>> https://gist.github.com/cstamas/ecb5170d61de79117c4181c7f3cbfe78
>> - as Maven System Property (env):
>> https://gist.github.com/cstamas/a03eacc66a01eb12896199d846ebc339
>> - as Maven User Property:
>> https://gist.github.com/cstamas/14d5aed712720d558bff704944f46d21
>>
>> HTH
>> Tamas
>>
>> On Sun, Oct 8, 2023 at 11:51 PM Eric Kolotyluk 
>> wrote:
>>
>>> Wow... great response...
>>>
>>> Since you offered such a thoughtful response, I will try to do
>>> likewise...
>>>
>>> As someone who used to teach UI/UX in a third year university course,
>>> and now an old curmudgeon , if I am going to see a message like
>>>
>>> [WARNING] For more or less details, use 'maven.plugin.validation'
>>> property with one of the values (case insensitive): [BRIEF, DEFAULT,
>>> VERBOSE]
>>>
>>> I should not have to care what kind of property I am dealing with
>>> because the message lacks context.
>>>
>>> Now, in many places I admire the skill, craftsmanship, intelligence, and
>>> pure genius of Maven maintainers who add hyperlinks to their messages
>>> for more context.  Indeed, a link to this amazing bit of knowledge,
>>> https://maven.apache.org/guides/plugins/validation/index.html, would
>>> have added such context. Maybe I should get off my lazy ass, fork the
>>> repo, make the change, and submit a pull request...
>>>
>>> In the larger picture, these distinctions over properties is, IMHO,
>>> unnecessary complexity to the UX. Good design leverages good intuition.
>>> IMHO, the plugin should accept the project property
>>> maven.plugin.validation, but I am willing to entertain a cogent argument
>>> why this should not be the case.
>>>
>>> And thanks again for such a great response. I really enjoyed following
>>> your explanation and references, and understanding better.
>>>
>>> Cheers, Eric
>>>
>>> P.S. Dealing with Maven people is way easier than Gradle people...
>>>
>>> On 2023-10-08 3:49 a.m., Tamás Cservenák wrote:
>>> > Howdy,
>>> >
>>> > regarding plugin validation we have this documentation
>>> > https://maven.apache.org/guides/plugins/validation/index.html
>>> >
>>> > that tries to explain what's and why's (given naming is constantly
>>> brought
>>> > up, let me tell in advance, the output uses "currently built project
>>> POV",
>>> > so internal issue is something one can fix by editing POM, while
>>> external
>>> > issue depends on external plugin, that needs fix and new release).
>>> >
>>> > As it stands on page, the `maven,plugin.validation` property is "maven
>>> user
>>> > property" (set with -D on cli) and is not "Maven project 

Re: NPE in AbstractMavenReport.execute, because 'this.siteTool' is null

[Michael Osipov]

I had these NPEs when I started to migrate reporting plugins and both the 
plugin and the super class contained the same fields which created conflicts. 
After I have removed them from the plugin and used the super ones all went 
fine. In your case I would really do what Hervé proposes:

* remove your execute() and retest with 1.x
* in a branch try with 2.x

I expect it to work. You can also look at all of your reporting plugins in 
branch doxia-2.0.0 you'll see all necessary migration magic from me. The PR 
with finalizing the method is good and already merged.

M

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

Re: maven.plugin.validation

[Tamás Cservenák]

Errata:
my "as Maven System Property" example is wrong (I had leftover `export
MAVEN_OPTS` from previous run)... so please neglect that example.

On Mon, Oct 9, 2023 at 11:58 AM Tamás Cservenák  wrote:

> Howdy Eric,
>
> You are right, and sorry for this, I am (we all are) a bit overwhelmed
> these days
>
> So you are right, that line should say "use 'maven.plugin.validation'
> **user** property". User properties (as told by mvn -h) are defined by the
> "-D" CLI switch.
>
> Re adding URL to message: Herve started already doing that, and many
> thanks to him for improving the horrible UX of this (IMHO important)
> feature.
> For start, he started refining the page and add it to release notes:
> https://github.com/apache/maven-site/pull/461
>
> And finally, regarding my answer to the 2nd part... to me it seems that
> the message was not fully delivered (for a non-core developer, it may, but
> for sake of completeness let me elaborate it):
>
> I just wanted to explain why Project Property CANNOT be used here... as if
> you think about Maven starting: JVM boots and Java System Properties are
> available, then Maven core "boots" (where Maven System Properties and Maven
> User Properties are assembled), and once booted, only then is model being
> loaded/parsed/built.
>
> Now, this where the validation should kick in (either for plugins defined
> in current project POM or in current project but with plugin goal directly
> invoked on CLI), hence, Project Properties (those on POM) are simply put
> "too late" for this, or are like chicken-and-egg problem (to load, we need
> to validate, but to report validation issues we need properties loaded).
>
> In conclusion, `maven.plugin.validation` may be defined as ANY Maven
> property EXCEPT Project property :)
>
> Examples (did them on maven-3.9.x branch of
> https://github.com/apache/maven):
>
> - as Java System Property:
> https://gist.github.com/cstamas/ecb5170d61de79117c4181c7f3cbfe78
> - as Maven System Property (env):
> https://gist.github.com/cstamas/a03eacc66a01eb12896199d846ebc339
> - as Maven User Property:
> https://gist.github.com/cstamas/14d5aed712720d558bff704944f46d21
>
> HTH
> Tamas
>
> On Sun, Oct 8, 2023 at 11:51 PM Eric Kolotyluk 
> wrote:
>
>> Wow... great response...
>>
>> Since you offered such a thoughtful response, I will try to do likewise...
>>
>> As someone who used to teach UI/UX in a third year university course,
>> and now an old curmudgeon , if I am going to see a message like
>>
>> [WARNING] For more or less details, use 'maven.plugin.validation'
>> property with one of the values (case insensitive): [BRIEF, DEFAULT,
>> VERBOSE]
>>
>> I should not have to care what kind of property I am dealing with
>> because the message lacks context.
>>
>> Now, in many places I admire the skill, craftsmanship, intelligence, and
>> pure genius of Maven maintainers who add hyperlinks to their messages
>> for more context.  Indeed, a link to this amazing bit of knowledge,
>> https://maven.apache.org/guides/plugins/validation/index.html, would
>> have added such context. Maybe I should get off my lazy ass, fork the
>> repo, make the change, and submit a pull request...
>>
>> In the larger picture, these distinctions over properties is, IMHO,
>> unnecessary complexity to the UX. Good design leverages good intuition.
>> IMHO, the plugin should accept the project property
>> maven.plugin.validation, but I am willing to entertain a cogent argument
>> why this should not be the case.
>>
>> And thanks again for such a great response. I really enjoyed following
>> your explanation and references, and understanding better.
>>
>> Cheers, Eric
>>
>> P.S. Dealing with Maven people is way easier than Gradle people...
>>
>> On 2023-10-08 3:49 a.m., Tamás Cservenák wrote:
>> > Howdy,
>> >
>> > regarding plugin validation we have this documentation
>> > https://maven.apache.org/guides/plugins/validation/index.html
>> >
>> > that tries to explain what's and why's (given naming is constantly
>> brought
>> > up, let me tell in advance, the output uses "currently built project
>> POV",
>> > so internal issue is something one can fix by editing POM, while
>> external
>> > issue depends on external plugin, that needs fix and new release).
>> >
>> > As it stands on page, the `maven,plugin.validation` property is "maven
>> user
>> > property" (set with -D on cli) and is not "Maven project property",
>> hence
>> > setting it in POM/properties does not make sense (nor has it's effect).
>> > This should be done in `.mvn/maven.config` instead, if you want it
>> always
>> > ON.
>> >
>> > On the other hand, as we talk about properties, I'd like to remind you
>> > about other change ongoing in 3.9.x line, that is the cleanup of
>> property
>> > notion: in Maven (and Java) land, we deal with:
>> > - Java System Properties
>> > - Maven System Properties
>> > - Maven User Properties
>> > - Maven Project Properties
>> >
>> > In release notes "Breaking changes" there is last bullet that 

Re: maven.plugin.validation

[Tamás Cservenák]

Howdy Eric,

You are right, and sorry for this, I am (we all are) a bit overwhelmed
these days

So you are right, that line should say "use 'maven.plugin.validation'
**user** property". User properties (as told by mvn -h) are defined by the
"-D" CLI switch.

Re adding URL to message: Herve started already doing that, and many thanks
to him for improving the horrible UX of this (IMHO important) feature.
For start, he started refining the page and add it to release notes:
https://github.com/apache/maven-site/pull/461

And finally, regarding my answer to the 2nd part... to me it seems that the
message was not fully delivered (for a non-core developer, it may, but for
sake of completeness let me elaborate it):

I just wanted to explain why Project Property CANNOT be used here... as if
you think about Maven starting: JVM boots and Java System Properties are
available, then Maven core "boots" (where Maven System Properties and Maven
User Properties are assembled), and once booted, only then is model being
loaded/parsed/built.

Now, this where the validation should kick in (either for plugins defined
in current project POM or in current project but with plugin goal directly
invoked on CLI), hence, Project Properties (those on POM) are simply put
"too late" for this, or are like chicken-and-egg problem (to load, we need
to validate, but to report validation issues we need properties loaded).

In conclusion, `maven.plugin.validation` may be defined as ANY Maven
property EXCEPT Project property :)

Examples (did them on maven-3.9.x branch of https://github.com/apache/maven
):

- as Java System Property:
https://gist.github.com/cstamas/ecb5170d61de79117c4181c7f3cbfe78
- as Maven System Property (env):
https://gist.github.com/cstamas/a03eacc66a01eb12896199d846ebc339
- as Maven User Property:
https://gist.github.com/cstamas/14d5aed712720d558bff704944f46d21

HTH
Tamas

On Sun, Oct 8, 2023 at 11:51 PM Eric Kolotyluk 
wrote:

> Wow... great response...
>
> Since you offered such a thoughtful response, I will try to do likewise...
>
> As someone who used to teach UI/UX in a third year university course,
> and now an old curmudgeon , if I am going to see a message like
>
> [WARNING] For more or less details, use 'maven.plugin.validation' property
> with one of the values (case insensitive): [BRIEF, DEFAULT, VERBOSE]
>
> I should not have to care what kind of property I am dealing with
> because the message lacks context.
>
> Now, in many places I admire the skill, craftsmanship, intelligence, and
> pure genius of Maven maintainers who add hyperlinks to their messages
> for more context.  Indeed, a link to this amazing bit of knowledge,
> https://maven.apache.org/guides/plugins/validation/index.html, would
> have added such context. Maybe I should get off my lazy ass, fork the
> repo, make the change, and submit a pull request...
>
> In the larger picture, these distinctions over properties is, IMHO,
> unnecessary complexity to the UX. Good design leverages good intuition.
> IMHO, the plugin should accept the project property
> maven.plugin.validation, but I am willing to entertain a cogent argument
> why this should not be the case.
>
> And thanks again for such a great response. I really enjoyed following
> your explanation and references, and understanding better.
>
> Cheers, Eric
>
> P.S. Dealing with Maven people is way easier than Gradle people...
>
> On 2023-10-08 3:49 a.m., Tamás Cservenák wrote:
> > Howdy,
> >
> > regarding plugin validation we have this documentation
> > https://maven.apache.org/guides/plugins/validation/index.html
> >
> > that tries to explain what's and why's (given naming is constantly
> brought
> > up, let me tell in advance, the output uses "currently built project
> POV",
> > so internal issue is something one can fix by editing POM, while external
> > issue depends on external plugin, that needs fix and new release).
> >
> > As it stands on page, the `maven,plugin.validation` property is "maven
> user
> > property" (set with -D on cli) and is not "Maven project property", hence
> > setting it in POM/properties does not make sense (nor has it's effect).
> > This should be done in `.mvn/maven.config` instead, if you want it always
> > ON.
> >
> > On the other hand, as we talk about properties, I'd like to remind you
> > about other change ongoing in 3.9.x line, that is the cleanup of property
> > notion: in Maven (and Java) land, we deal with:
> > - Java System Properties
> > - Maven System Properties
> > - Maven User Properties
> > - Maven Project Properties
> >
> > In release notes "Breaking changes" there is last bullet that gives some
> > hint about these:
> >
> https://maven.apache.org/docs/3.9.5/release-notes.html#potentially-breaking-core-changes-if-migrating-from-3-8-x
> >
> > HTH
> > Tamas
> >
> > On Sat, Oct 7, 2023 at 11:57 PM Eric Kolotyluk  >
> > wrote:
> >
> >> When I run
> >>
> >>  |mvn clean site -Dmaven.plugin.validation=VERBOSE|
> >>
> >> I get verbose output, but