Hi,
On Fri, 25 Feb 2022 at 07:57, Slawomir Jaranowski
wrote:
> Hi
> In next version of Maven parent
> - detectLinks from javadoc configurations was removed, so javadoc will not
> download remote resource, it was fails many times in this case
> - findbugs was removed - it also took a lot of
Hi,
Regarding CI of javadoc and site on PRs, I personally prefer to have
failures as early as possible rather than during a last manual minute check
before a release.
Personal opinion again, I prefer to have this automated rather than manual.
especially for javadoc which can have different results
Hi
In next version of Maven parent
- detectLinks from javadoc configurations was removed, so javadoc will not
download remote resource, it was fails many times in this case
- findbugs was removed - it also took a lot of time
My proposition is to remove from reports:
- surefire
- checkstyle
Olivier,
please remove all the Jenkins checks from all of the Maven builds you added
without asking anyone about adding it.
The release manager should ensure beforehand it is all ok, if not, try to
fix it, if the issue is bigger, still can decide to rollback the change.
Thanks
T
On Thu, Feb
This reminds me one of issues I was working some time ago - version
range resolution. It is also an element provided by core.
If problem is related to proper handling of repository layout (not model
parsing) it might be that you have only "default" repository layout
provider which wins
Building javadoc is slow and very fragile (fetches remote resources, chews
on stuff etc).
Why not have a savvy release manager ensuring it is building, and calling
out PR authors to fix it?
The Worst can happen is rel mgr rollback the chnge if the PR author is
unresponsive.
On Thu, Feb 24, 2022
Sure, why not?
Naturally, the workflow would have a step "ensure site passes" before doing
it, so the workflow would not end up with javadoc failing in the middle of
release.
And I'd hope that workflow would not mind (or have any pain) just reporting
this and stopping w/o attempting to perform a
We have tried that on GitHub Actions and it was not terribly slow.
It was only useless to force every build configuration to run the
maven site.
Notice that the GH Actions are quite fast and if you employ only one
special run for "mvn site" with a deployment to a web container or gh_pages
then it
Please read what I say. I'm just mentioning javadoc as contributors
and committers can fail the build with bad javadoc but we will not see it.
On Fri, 25 Feb 2022 at 06:47, Tamás Cservenák wrote:
> Building everything for each commit is insane.
>
> Also, I find a release mgr that does NOT check
On Fri, 25 Feb 2022 at 06:53, Tamás Cservenák wrote:
> Or, to rephrase; being a release mgr is not just about "a person doing $
> mvn release:prepare release:perform and pressing ENTER".
> As if it is really just that, we would automate it, right?
>
why not? :)
>
> T
>
> On Thu, Feb 24, 2022
Or, to rephrase; being a release mgr is not just about "a person doing $
mvn release:prepare release:perform and pressing ENTER".
As if it is really just that, we would automate it, right?
T
On Thu, Feb 24, 2022 at 9:47 PM Tamás Cservenák wrote:
> Building everything for each commit is insane.
Building everything for each commit is insane.
Also, I find a release mgr that does NOT check is site building beforehand
release as sloppy.
Hence, building everything on each commit just to suit sloppy release mgrs
is insane IMHO.
My 5 cents.
T
On Thu, Feb 24, 2022 at 9:30 PM Olivier Lamy
Sounds good.
But who has never released something and having javadoc failing in the
middle of the release or the site generation failing once tag done and
artifacts staged… I find this a pain
Maybe only testing javadoc works at least ?
Btw I agree some reports could be removed
On Fri, 25 Feb
There is such a situation where the contributor changes the site, we vote
for his PR on GH but we lately find out that the site is broken in some
way. If I could see the site deployed to gh_pages which is a Git branch and
visualized on GH then the contributor would fix it much better.
Of course
and reporting profile was done for this:
- without reporting profile, just light site generation
- with reporting profile, full documentation site
disabling reporting profile for CI should do the job
- Mail original -
De: "herve boutemy"
À: "Maven Developers List"
Envoyé: Jeudi 24
done on GH and Jenkins, then on each commit?
we're heating oceans for nothing
IMHO, we need to differentiate CI vs release documentation: CI should be much
lighter than release
- Mail original -
De: "Slawomir Jaranowski"
À: "Maven Developers List"
Envoyé: Jeudi 24 Février 2022
Yes is done after release but also on jenkins for plugins and on GH builds
czw., 24 lut 2022 o 20:43 napisał(a):
> full site building with reports enabled (through reporting profile) is
> just done after release, isn't it?
>
> - Mail original -
> De: "Slawomir Jaranowski"
> À: "Maven
full site building with reports enabled (through reporting profile) is just
done after release, isn't it?
- Mail original -
De: "Slawomir Jaranowski"
À: "Maven Developers List"
Envoyé: Jeudi 24 Février 2022 20:24:56
Objet: Review of used reports for Maven project sites.
Hi,
Building
Hi,
Building the Maven site takes a long time for our projects.
Before releasing the next version of maven-parent, I have a proposal to
review used Maven site reports.
So
- without reporting profile, standard maven-project-info-reports-plugin -
build very quick - no problems
- with reporting
+1
czw., 24 lut 2022, 16:35 użytkownik Tamás Cservenák
napisał:
> +1
>
> On Mon, Feb 21, 2022, 21:23 Michael Osipov wrote:
>
> > Hi,
> >
> > we solved 2 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821=12351375
> >
> > There are still a couple of
+1
On Mon, Feb 21, 2022, 21:23 Michael Osipov wrote:
> Hi,
>
> we solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821=12351375
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPIR/issues
>
> Staging repo:
+1
build from source-release - ok
pgp signature ok - by key 0x1A2A1C94BDE89688
pon., 21 lut 2022 o 21:23 Michael Osipov napisał(a):
> Hi,
>
> we solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821=12351375
>
> There are still a couple of issues left
22 matches
Mail list logo
