notice that the change is not in Maven itself: the reporting API has been
extracted from Maven 2 to a separate reporting-api [1] artifact in Maven 3
I moved the MNG issue to https://issues.apache.org/jira/browse/MSHARED-1032
Regards,
Hervé
[1]
Hi,
What do you think ...
Maven Core and important components (list needed)
- RTC obligatory, approve from X committers, no request changes
Common rules:
- build and tests always pass or are under control
- after each commit project is ready to next release
- as maintainer add page
Sounds like a good improvement.
On a related note, we also have
http://issues.apache.org/jira/projects/MNG/issues/MNG-7351 for which I
think the outcome of the discussion at
https://github.com/apache/maven/pull/632 leads to the fact that both
exceptions are handled the same, so we should simply
Hi everyone,
I would like to change the API from the ReportMojo.
I was recently looking at
https://github.com/apache/maven-reporting-impl/blob/9050da0e7c2defed851621b62c0160b52716ba11/src/main/java/org/apache/maven/reporting/AbstractMavenReport.java#L338-L342
But it seems the method boolean
makes sense for core and it looks to be a de facto standard.
but plugins and components maintained by only 1 (maybe 2) persons.
we already have plenty of PRs from external contributors never reviewed...
And I do not mention some PRs which take weeks to review..
I feel like adding this will:
-
Howdy,
In your example rule, between 1st and 2nd step I'd insert some "invite
interested parties" step, that is either request review using GH UI, or
ping party via mail... As currently our incoming email amount is huge,
it is way too easy to miss some.
Also, when asked for review, the one asked
Il giorno mer 26 gen 2022 alle ore 07:44 Benjamin Marwell
ha scritto:
>
> Hi!
>
> Aside from typo fixes, PRs might slow down the dev speed, but greatly
> improve code quality.
> Even small PRs might have side effects you might not notice at first glance.
>
> But then, even with typo fixes I have
