Improvement in a maven-reporting-api design

[Slawomir Jaranowski <s....@gmail.com>]

Hi,

Currently Maven report plugin implements MavenReport by
extending AbstractMavenReport

Interface MavenReport is in maven-reporting-api
Class AbstractMavenReport is in maven-reporting-impl

maven-reporting-impl - has many transitive dependencies.

We have also AbstractMavenReportRenderer which hide some of method from
Doxia Sink,

Proposition:

Move AbstractMavenReport to maven-reporting-api
Add similar method from AbstractMavenReportRenderer to AbstractMavenReport

We can have something like:

class AbstractMavenReport ...
{

  @Component
  private DoxiaSupport doxiaSupport;

  public void paragraph( String paragraph )
  {
    doxiaSupport.paragraph( paragraph );
  }

 ....
}

Interface DoxiaSupport will be also in maven-reporting-api.

m-site-p by m-exec will add needed implementation of DoxiaSupport on plugin
classpath.

Advantage:
 - plugin report will only need maven-reporting-api without any
transitive dependencies.

Disadvantage:
 - plugin report can be only executed by m-site-p

WDYT?

-- 
Sławomir Jaranowski

Re: Improvement in a maven-reporting-api design

[Michael Osipov <mi...@apache.org>]

Am 2022-08-07 um 23:56 schrieb Slawomir Jaranowski:
> Hi,
> 
> Currently Maven report plugin implements MavenReport by
> extending AbstractMavenReport
> 
> Interface MavenReport is in maven-reporting-api
> Class AbstractMavenReport is in maven-reporting-impl
> 
> maven-reporting-impl - has many transitive dependencies.
> 
> We have also AbstractMavenReportRenderer which hide some of method from
> Doxia Sink,
> 
> Proposition:
> 
> Move AbstractMavenReport to maven-reporting-api
> Add similar method from AbstractMavenReportRenderer to AbstractMavenReport
> 
> We can have something like:
> 
> class AbstractMavenReport ...
> {
> 
>    @Component
>    private DoxiaSupport doxiaSupport;
> 
>    public void paragraph( String paragraph )
>    {
>      doxiaSupport.paragraph( paragraph );
>    }
> 
>   ....
> }
> 
> Interface DoxiaSupport will be also in maven-reporting-api.
> 
> m-site-p by m-exec will add needed implementation of DoxiaSupport on plugin
> classpath.
> 
> Advantage:
>   - plugin report will only need maven-reporting-api without any
> transitive dependencies.
> 
> Disadvantage:
>   - plugin report can be only executed by m-site-p

Hi Slawek,

this is a hard nut to crack. As you noticed -impl is required to run the 
report standalone and having the dependency tree is unavoidable, either 
direct or transitive. Moving the abstract renderer to abstract report 
isn't really good, IMHO, because if you look at our codebase we have 
many renderers using it. Decoupled form the report logic which is nice 
and clean.
I need to think about this. The remake I am doing is supposed to be 
minimal invasive to all reporting plugins, but dropping a lot of luggage 
and fixing issues from the last 10 years which do not affect UX.
Have you looked through our reporting plugins whether this would be 
possible?
Please also note that testing the plugin will always require the complex 
setup of Maven Site Plugin.
Given that I have currently already to test every single plugin to make 
it work with -impl properly this proposal would make it even more 
complex and breaking in a GA release. I think we can/should reconsider 
this after all of the cleanup has been done and I have a clean picture. 
My idea with Maven Site Plugin 4.0.0 is that people update the our 
plugins, and that's it. Other reporting plugins require minimal effort. 
That above means a logical rewrite...

M

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