Maven Site vs Reporting Plugin workflows?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Maven Site vs Reporting Plugin workflows?

Alex O'Ree-2
Hi everyone, I'm trying to troubleshoot an issue with the PDF plugin,
https://issues.apache.org/jira/browse/MPDF-62. Root cause seems to be
that the reportPlugins:
    @Parameter( readonly = true )
    private org.apache.maven.reporting.exec.ReportPlugin[] reportPlugins;

are not injected to the Mojo plugin and that at some point in time the
behavior had changed. Does anyone know approximately when this
occurred or what version the change was in effect?

Moving on, I also checked out the maven-site plugin as it performs the
same task and found nearly identical code for the parts referring to
the reporting plugins, except that when ran, the reportPlugins
parameter is populated by maven. I'm not too sure what the delta is
here nor do I know where to look, but if anyone has any clues or
pointers to what could be wrong or areas to look at it, I'm all ears.
Is there perhaps some resource file or magic string in play?

Related question, where does the parameter injection happen?

Finally, I also didn't find any other references to how the site
plugin causes the report plugins to fire off. Is there any good
resources that I can read up on the current workflow and/or
architecture of all things related to report plugins and site
generation?

Thanks!

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven Site vs Reporting Plugin workflows?

Hervé BOUTEMY
Hi,

The change is explained here:
http://maven.apache.org/plugins/maven-site-plugin/maven-3.html

The injection is done in DefaultReportingConverter [1]

At the beginning, the dream was to remove <reporting> element from pom.xml:
then we later found that we could not since this is the only place where
reporting plugin inheritance can happen (no inheritance in reportPlugin
parameter of maven-site-plugin).

Then this idea about <reportinp> removal was abandonned, I took time to
document the strategy revert as much as possible. But I didn't take time to do
some cleanup: this parameter that is magically injected by Maven core should
probably be changed into a classical "${project.reporting}" parameter default
value.

Regards,

Hervé

[1] http://maven.apache.org/ref/3-LATEST/maven-model-builder/apidocs/org/
apache/maven/model/plugin/DefaultReportingConverter.html

Le mardi 14 mars 2017, 00:03:45 CET Alex O'Ree a écrit :

> Hi everyone, I'm trying to troubleshoot an issue with the PDF plugin,
> https://issues.apache.org/jira/browse/MPDF-62. Root cause seems to be
> that the reportPlugins:
>     @Parameter( readonly = true )
>     private org.apache.maven.reporting.exec.ReportPlugin[] reportPlugins;
>
> are not injected to the Mojo plugin and that at some point in time the
> behavior had changed. Does anyone know approximately when this
> occurred or what version the change was in effect?
>
> Moving on, I also checked out the maven-site plugin as it performs the
> same task and found nearly identical code for the parts referring to
> the reporting plugins, except that when ran, the reportPlugins
> parameter is populated by maven. I'm not too sure what the delta is
> here nor do I know where to look, but if anyone has any clues or
> pointers to what could be wrong or areas to look at it, I'm all ears.
> Is there perhaps some resource file or magic string in play?
>
> Related question, where does the parameter injection happen?
>
> Finally, I also didn't find any other references to how the site
> plugin causes the report plugins to fire off. Is there any good
> resources that I can read up on the current workflow and/or
> architecture of all things related to report plugins and site
> generation?
>
> Thanks!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven Site vs Reporting Plugin workflows?

Alex O'Ree-2
Hervé thanks for the pointer. The Default Reporting Converter looks
like it reads and normalizes content from the pom's various formats to
the maven model. I don't see anything in that class that would
indicate it converting into
`org.apache.maven.reporting.exec.ReportPlugin` and injecting that into
the maven site plugin (or any other mojo). I'm a bit new to maven
plugin development. Again I'm doing this to try and revitalize the PDF
plugin, which should basically do the same as the maven site plugin
(convert markdown/etc to the output format and run the report
plugins), only the output is to PDF instead.

On Wed, Mar 15, 2017 at 6:20 PM, Hervé BOUTEMY <[hidden email]> wrote:

> Hi,
>
> The change is explained here:
> http://maven.apache.org/plugins/maven-site-plugin/maven-3.html
>
> The injection is done in DefaultReportingConverter [1]
>
> At the beginning, the dream was to remove <reporting> element from pom.xml:
> then we later found that we could not since this is the only place where
> reporting plugin inheritance can happen (no inheritance in reportPlugin
> parameter of maven-site-plugin).
>
> Then this idea about <reportinp> removal was abandonned, I took time to
> document the strategy revert as much as possible. But I didn't take time to do
> some cleanup: this parameter that is magically injected by Maven core should
> probably be changed into a classical "${project.reporting}" parameter default
> value.
>
> Regards,
>
> Hervé
>
> [1] http://maven.apache.org/ref/3-LATEST/maven-model-builder/apidocs/org/
> apache/maven/model/plugin/DefaultReportingConverter.html
>
> Le mardi 14 mars 2017, 00:03:45 CET Alex O'Ree a écrit :
>> Hi everyone, I'm trying to troubleshoot an issue with the PDF plugin,
>> https://issues.apache.org/jira/browse/MPDF-62. Root cause seems to be
>> that the reportPlugins:
>>     @Parameter( readonly = true )
>>     private org.apache.maven.reporting.exec.ReportPlugin[] reportPlugins;
>>
>> are not injected to the Mojo plugin and that at some point in time the
>> behavior had changed. Does anyone know approximately when this
>> occurred or what version the change was in effect?
>>
>> Moving on, I also checked out the maven-site plugin as it performs the
>> same task and found nearly identical code for the parts referring to
>> the reporting plugins, except that when ran, the reportPlugins
>> parameter is populated by maven. I'm not too sure what the delta is
>> here nor do I know where to look, but if anyone has any clues or
>> pointers to what could be wrong or areas to look at it, I'm all ears.
>> Is there perhaps some resource file or magic string in play?
>>
>> Related question, where does the parameter injection happen?
>>
>> Finally, I also didn't find any other references to how the site
>> plugin causes the report plugins to fire off. Is there any good
>> resources that I can read up on the current workflow and/or
>> architecture of all things related to report plugins and site
>> generation?
>>
>> Thanks!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven Site vs Reporting Plugin workflows?

Hervé BOUTEMY
as you can read in latest comments on MPDF-48, I prepared in MSHARED-628
maven-reporting-exec code for execution of reports taken from <reporting>
section

Does it look clear to you now?

Regards,

Hervé

Le mercredi 15 mars 2017, 20:29:41 CET Alex O'Ree a écrit :

> Hervé thanks for the pointer. The Default Reporting Converter looks
> like it reads and normalizes content from the pom's various formats to
> the maven model. I don't see anything in that class that would
> indicate it converting into
> `org.apache.maven.reporting.exec.ReportPlugin` and injecting that into
> the maven site plugin (or any other mojo). I'm a bit new to maven
> plugin development. Again I'm doing this to try and revitalize the PDF
> plugin, which should basically do the same as the maven site plugin
> (convert markdown/etc to the output format and run the report
> plugins), only the output is to PDF instead.
>
> On Wed, Mar 15, 2017 at 6:20 PM, Hervé BOUTEMY <[hidden email]>
wrote:

> > Hi,
> >
> > The change is explained here:
> > http://maven.apache.org/plugins/maven-site-plugin/maven-3.html
> >
> > The injection is done in DefaultReportingConverter [1]
> >
> > At the beginning, the dream was to remove <reporting> element from
> > pom.xml:
> > then we later found that we could not since this is the only place where
> > reporting plugin inheritance can happen (no inheritance in reportPlugin
> > parameter of maven-site-plugin).
> >
> > Then this idea about <reportinp> removal was abandonned, I took time to
> > document the strategy revert as much as possible. But I didn't take time
> > to do some cleanup: this parameter that is magically injected by Maven
> > core should probably be changed into a classical "${project.reporting}"
> > parameter default value.
> >
> > Regards,
> >
> > Hervé
> >
> > [1] http://maven.apache.org/ref/3-LATEST/maven-model-builder/apidocs/org/
> > apache/maven/model/plugin/DefaultReportingConverter.html
> >
> > Le mardi 14 mars 2017, 00:03:45 CET Alex O'Ree a écrit :
> >> Hi everyone, I'm trying to troubleshoot an issue with the PDF plugin,
> >> https://issues.apache.org/jira/browse/MPDF-62. Root cause seems to be
> >>
> >> that the reportPlugins:
> >>     @Parameter( readonly = true )
> >>     private org.apache.maven.reporting.exec.ReportPlugin[] reportPlugins;
> >>
> >> are not injected to the Mojo plugin and that at some point in time the
> >> behavior had changed. Does anyone know approximately when this
> >> occurred or what version the change was in effect?
> >>
> >> Moving on, I also checked out the maven-site plugin as it performs the
> >> same task and found nearly identical code for the parts referring to
> >> the reporting plugins, except that when ran, the reportPlugins
> >> parameter is populated by maven. I'm not too sure what the delta is
> >> here nor do I know where to look, but if anyone has any clues or
> >> pointers to what could be wrong or areas to look at it, I'm all ears.
> >> Is there perhaps some resource file or magic string in play?
> >>
> >> Related question, where does the parameter injection happen?
> >>
> >> Finally, I also didn't find any other references to how the site
> >> plugin causes the report plugins to fire off. Is there any good
> >> resources that I can read up on the current workflow and/or
> >> architecture of all things related to report plugins and site
> >> generation?
> >>
> >> Thanks!
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...