Re: Apache Maven is quite amazing - Thank you

[Enrico Olivelli]

Il Sab 4 Mag 2024, 20:51 Joe Witt  ha scritto:

> Dear Anyone that Ever Contributed to Apache Maven and especially the Maven
> PMC
>
> I've been working on what is now Apache NiFi since 2006.  I don't
> recall exactly when the switch to Maven occurred but it was close to the
> 2008 release of the definitive guide book.
>
> When we first open sourced in late 2014 Karl Heinz Marbaise contributed a
> PR and I remember how awesome that was for us if for no other reason
> than we relied on Maven so much and even then were getting help from Maven
> folks to do it right.
>
> NiFi is a fairly large codebase with a wild amount of modules and so on.  I
> cannot imagine NiFi ever making it to even become an ASF project nor scale
> the way it has without Maven and what it does.  I get that it isn't perfect
> but it is really darn good.
>
> In the past several weeks I've really dove into building on some great work
> of other members of our community to improve our dependency management and
> I am quite stunned at all the tools and mechanisms Maven offer both
> built-in and through its impressive plugin ecosystem.
>
> You are all doing insanely good work.
>
> The Java community as a whole owes you tremendously.
>

Indeed!


Thank you for sharing your voice!

Enrico



> Thank you
> Joe
>

Re: [VOTE] Move AFS Parent POM and Maven Parent POMs issues to GitHub

[Enrico Olivelli]

+1

Enrico

Il Sab 13 Apr 2024, 16:48 zhongming hua  ha scritto:

> +1
> I think generating release notes from the Github release drafter is
> more convenient.
> Can we close the project on Jira after we have resolved the remaining
> issues?
>
> Best regards!
> Zhongming Hua
>
> Slawomir Jaranowski  于2024年4月13日周六 21:56写道：
> >
> > Hi,
> >
> > Rationale:
> >
> > - more of changes in those projects are the dependencies updates make by
> > the Dependabot,  next we create issues in Jira by manual copy paste to
> have
> > a release notes
> > - we can use Release Drafter for preparing release notes on GitHub - no
> > manual works and easy to publish
> > - release notes on GitHub are more easier to find
> > - it is our internal project used in ASF
> >
> > Taks to do:
> >
> > - release next version ASF 32 / Maven 42 as is
> > - make jira project MPOM - read only
> > - leave current open issues in jira as is - with notes about migration -
> if
> > someone want to work on it, will copy it to GitHub
> > - enable issues on GitHub
> > - update project documentation
> >
> > If the vote passes - I will take care of it.
> >
> > Jira project:
> > https://issues.apache.org/jira/projects/MPOM
> >
> > GitHub repositories:
> > https://github.com/apache/maven-apache-parent
> > https://github.com/apache/maven-parent
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > --
> > Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Require Java 17 for Maven 4

[Enrico Olivelli]

+1 (Non binding)

Enrico

Il Gio 29 Feb 2024, 09:01 Tim te Beek  ha scritto:

> +1  from occasional contributor
>
> Would unblock phasing out more utils methods & dependencies.
>
> On Thu, Feb 29, 2024 at 8:53 AM Thomas Matthijs  wrote:
>
> > +1
> >
> >
> > On Wed, Feb 28, 2024, at 08:30, Benjamin Marwell wrote:
> > > Hi Maven Devs/Users/Committers and PMC members!
> > >
> > > After several discussions on the mailing lists, I would like to
> > > start a vote in favour of setting the minimal Java bytecode target
> > > of Maven-Core 4 to 17 and hence require Java 17 for Maven 4.
> > >
> > > This is a procedural majority vote [1*]:
> > > You can also vote with fractions and negative votes are not vetoes.
> > >
> > > Please also notice:
> > > * Maven 3 will stay at Java 8 no matter what.
> > > * We may raise Maven 4 to JDK 21 later if we feel like it (depending
> > > on the release date).
> > >   This is not part of this vote.
> > > * The linked PR is not part of this vote (this is not a code vote).
> > >   But you may take a look at it to understand the intended change.
> > >
> > > PR: https://github.com/apache/maven/pull/1430
> > >
> > > Maven-Parent will not be raised with this vote, the other PR is not
> > > part of this vote.
> > >
> > > Please refrain from starting discussions in this thread, but do
> > > include a reasoning on downvotes and feel free to start a new
> > > discussion on the mailing list, or comment on the existing ones.
> > >
> > > ---
> > >
> > > Vote open for 72 hours:
> > >
> > > [ ] +1 (set JDK17 min version for Maven 4.x)
> > > [ ] +0
> > > [ ] -1 (please include reasoning)
> > >
> > > ---
> > >
> > > - Ben
> > >
> > > [1*]: https://www.apache.org/foundation/voting.html
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] Release Maven Surefire version 3.2.5

[Enrico Olivelli]

+1

Enrico

Il Lun 8 Gen 2024, 08:10 Herve Boutemy  ha scritto:

> +1
>
> Reproducible Builds ok: reference build done with JDK 8 on Windows with
> umask
> 022
>
> Regards,
>
> Hervé
>
> On 2024/01/06 20:05:47 Michael Osipov wrote:
> > Hi,
> >
> > we solved 7 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12354100
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20resolution%20%3D%20Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-2055/
> >
> https://repository.apache.org/content/repositories/maven-2055/org/apache/maven/surefire/surefire/3.2.5/surefire-3.2.5-source-release.zip
> >
> > Source release checksum(s):
> > surefire-3.2.5-source-release.zip
> > sha512:
> >
> 5c894574b5c13813e5cdfec20f47d92e632f625aa53a135d22477b996998119b0c4fbfcabd0bdd35aed20be2d6fa221310e28ce6be6967411f48a7c19aa52dde
> >
> > Staging site:
> > https://maven.apache.org/surefire-archives/surefire-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Retire Maven Docck Plugin

[Enrico Olivelli]

+1 (non binding)

Enrico

Il Mar 17 Ott 2023, 21:57 Karl Heinz Marbaise  ha
scritto:

> Hi,
>
> +1 from me.
>
> Kind regards
> Karl Heinz Marbaise
> On 17.10.23 00:50, Slawomir Jaranowski wrote:
> > Hi,
> >
> > - Last release was in 2015
> > - use Maven 2.2.1
> > - we have a Maven Plugin Tools - which should be one project for build
> and
> > check Maven plugins
> > - no active development ...
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MDOCCK%20AND%20(%20resolution%20%3D%20Unresolved%20OR%20fixVersion%20%3D%203.0.0)
> > - no working with current plugins
> >
> > I therefore propose that we retire maven-docck-plugin -
> > https://maven.apache.org/plugins/maven-docck-plugin/
> >
> > If this vote is successful I will make one final release of the plugin,
> > making it clear on the plugin site that it has been retired.
> > After that the source code will be moved into read-only mode.
> >
> > The process for retiring a plugin is described here:
> > https://maven.apache.org/developers/retirement-plan-plugins.html
> >
> > The vote is open for 72 hours.
> >
> > [ ] +1 Yes, it's about time
> > [ ] -1 No, because...
> >
> > [1]
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: GH issues and GH discussions

[Enrico Olivelli]

I am +1 to move to GH issues.
In Apache BookKeeper and Pulsar we had a script that did the migration
pretty seamlessly and I used that script also for other OSS projects
outside of the ASF. (I can't find it now, but it should be buried in some
git repo somewhere)

Enrico

Il Sab 27 Mag 2023, 13:02 tison  ha scritto:

> > It occurs to me that not that long ago, Jira used to be open signup.
> > is there a specific reason it changed? Does that reason still apply?
>
> It's still open and self-serving at [1]. Just need one more moderate step
> from committers or PMC members. To reduce spam, yes.
>
> Best,
> tison.
>
> [1] https://selfserve.apache.org/jira-account.html
>
>
> Gary Gregory  于2023年5月27日周六 18:55写道：
>
> > How does StackOverflow fit in if at all? Any pros and cons to share?
> >
> > Gary
> >
> > On Sat, May 27, 2023, 06:43 tison  wrote:
> >
> > > > single point of entrance
> > >
> > > One last comment - it's a maintainer strategy to reduce the burden of
> > > monitoring multiple channels, and users generally gather to where their
> > > questions can be answered. But it's not a user strategy; they ask on
> the
> > > platform they are used to or closest to where the issue happens.
> > >
> > > So we may not say "a specific channel is _not_ supported, you should
> not
> > > ask there", but "most of the critical mass answering questions on
> > platform
> > > X". Users make their choice reflected to where the critical mass work
> > > instead of being forced there.
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > tison  于2023年5月27日周六 18:36写道：
> > >
> > > > I agree with Tamas' suggestion about the single point of entrance.
> Here
> > > > are several examples I experienced:
> > > >
> > > > 1. Apache SkyWalking[1] uses a single GH Issue to track all its
> issues
> > > and
> > > > Discussions for user questions and some rough ideas.
> > > > 2. Apache Pulsar[2] (I'm one of its committers) uses multiple GH
> Issues
> > > > for different repos, while for the tightly coupled site repo[3], I
> > merge
> > > > the Issue tracker to the main repo. Single Discussions instance for
> all
> > > > "Pulsar" related questions.
> > > > 3. Apache Flink[3] (I'm one of its committers) uses a single JIRA
> > project
> > > > for all its repos issue trackers, and only user@ and user-zh@
> mailing
> > > > lists for user questions. Given their high responsiveness, it works
> > well
> > > > for most of its users. Although other unofficial channels (with PMC
> > > members
> > > > there) (like DingTalk group or Slack workspace) exist to answer
> > > questions,
> > > > most users can be guided to the mailing list since it's still the
> most
> > > > active channel.
> > > >
> > > > Maven has a more complex repo cluster[4], and decisions can differ.
> > > >
> > > > Best,
> > > > tison.
> > > >
> > > > [1] https://github.com/apache/skywalking
> > > > [2] http://github.com/apache/pulsar
> > > > [3] http://github.com/apache/pulsar-site
> > > > [4] https://maven.apache.org/scm.html
> > > >
> > > >
> > > > tison  于2023年5月27日周六 18:28写道：
> > > >
> > > >> As a Maven user experiencing finding issue tracker recently[1][2],
> > here
> > > >> are my two coins:
> > > >>
> > > >> 1. GitHub Issues help to get issues reported at the exact code repo.
> > > >>
> > > >> I found a usage question for ASF parent pom and find the code repo
> > > at[3],
> > > >> no GitHub Issues and I jump to the linked JIRA project MPOM, while
> the
> > > >> maintainer tells me it's not the correct place.
> > > >>
> > > >> I'm familiar with the mailing list way so it's not quite a trouble
> to
> > > ask
> > > >> here. But as time goes on, more and more developers and users get
> used
> > > to
> > > >> the GitHub platform. No matter if it's a good thing, it's a fact[4].
> > > >>
> > > >> So, for lowering the bar for user participation, I agree we can give
> > GH
> > > >> issues and GH discussions a try.
> > > >>
> > > >> 2. GitHub is a proprietary service that is unreliable in an
> > > >> organization's view.
> > > >>
> > > >> I agree.
> > > >>
> > > >> Part of them can be resolved by we sync all traffic back to an ASF
> > > >> mailing list, like most of the ASF projects I participated in[5]. We
> > can
> > > >> thus archive most of the context but since they are for archiving
> > only,
> > > the
> > > >> readability can be bad.
> > > >>
> > > >> To sum up, as new generation developers and users grow and they are
> > more
> > > >> familiar with the GitHub platform, before we find a competitor to
> > > compare
> > > >> with, and since we can more or less sync the conversation back to
> ASF
> > > >> INFRA, I'm +1 for giving GH issue and GH discussion a chance.
> > > >>
> > > >> But, in the other hand, if we can link the JIRA project and the code
> > > repo
> > > >> properly, given that our mailing list's and JIRA's responsiveness is
> > > high,
> > > >> it's good enough for me that we use GH PR for the patching process
> > only,
> > > >> keep issues on JIRA and make most significant 

Re: [HEADS UP] Release of surefire

[Enrico Olivelli]

+1
yes, please

Enrico

Il giorno ven 10 mar 2023 alle ore 10:33 Christian Stein
 ha scritto:
>
> + M10
>
> ... erm +1 for releasing 3.0.0
>
> On Thu, Mar 9, 2023 at 10:36 AM Slawomir Jaranowski 
> wrote:
>
> > Hi,
> >
> > According to https://issues.apache.org/jira/browse/MNG-7725
> > I would like to release the next version of surefire.
> >
> > Next radical proposal: switch version to 3.0.0 and stop producing next
> > milestone like 3.0.0-M10.
> >
> > We have the first millstone version from 2018 .. and it looks like it can
> > not stop in the near future.
> > So I think that we should stop producing the next milestone and allow more
> > users to use the released version.
> > In such a way we can receive more valuable feedback.
> >
> > Yes I know there is much work to do in surefire.
> >
> > If there are no objections - I will do it today evening or tomorrow at
> > least.
> >
> > --
> > Sławomir Jaranowski
> >

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

Re: And while I'm on the subject of logging

[Enrico Olivelli]

Sometimes it is helpful to see that kind of logging when you run on CI
and you are troubleshooting why the build is slow.
In that case it would be useful to log only in the case that the
download took more than X seconds or the speed was too low (then it
would become debatable the default values for the thresholds...)

my 2 cents

Enrico

Il giorno lun 20 feb 2023 alle ore 15:46 Christoph Läubrich
 ha scritto:
>
> Well you can just reduce it to a single '.' who cares WHAT is download
> and where it is placed and from where... now put a line break after say
> 50 dots
>
>
> Am 20.02.23 um 15:42 schrieb Tamás Cservenák:
> > Howdy,
> >
> > completely agree, the default could be something along those lines:
> >
> > [DL] central
> > https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> >
> > So something like
> > [DL|UP] $repoId $artifactUrl
> >
> > Full URL is handy as one can click on it in Terminal.app. But
> > redundant "Downloaded" is not. Maybe go for some emoji even? (arrow
> > down/arrow up?)
> >
> > T
> >
> > On Mon, Feb 20, 2023 at 3:34 PM Elliotte Rusty Harold 
> > wrote:
> >
> >> Typical log message in build:
> >>
> >> Downloaded from central:
> >>
> >> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> >> (14 kB at 776 kB/s)
> >>
> >> I have never, ever needed or wanted to know how fast a single artifact
> >> was downloaded. And in the extremely unlikely event  I cared how big
> >> it was, I'd look in .m2/repo, not a build log. Can we remove (14 kB at
> >> 776 kB/s)?
> >>
> >> Maven log files today are often multiple megabytes. Many continuous
> >> integration Web UIs truncate them to a 1 MB or so. Any unread info we
> >> can remove to bring the size down is helpful, and also makes it much
> >> easier for devs to find the lines they actually care about.
> >>
> >> --
> >> Elliotte Rusty Harold
> >> elh...@ibiblio.org
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: [RESULT] [VOTE] Release Maven Surefire version 3.0.0-M8

[Enrico Olivelli]

For reference:

This is the issue
https://issues.apache.org/jira/browse/SUREFIRE-2141

The problem is about the compatibility of a third party library used
in the tests, that doesn't work on ARM platforms

There is no quick fix

Enrico

Il giorno gio 12 gen 2023 alle ore 02:24 Nick Stolwijk
 ha scritto:
>
> Hi Michael,
>
> Thanks for the release! A little side note for next time, the link in the
> announcement mail is not working. It should be
> https://maven.apache.org/surefire/ instead of
> https://maven.apache.org/maven-surefire/.
>
> With regards,
>
> Nick Stolwijk
>
> ~~~ Try to leave this world a little better than you found it and, when
> your turn comes to die, you can die happy in feeling that at any rate you
> have not wasted your time but have done your best ~~~
>
> Lord Baden-Powell
>
>
> On Wed, 11 Jan 2023 at 22:24, Michael Osipov  wrote:
>
> > Hi,
> >
> > The vote has passed with the following result:
> >
> > +1: Herve Boutemy, Slawomir Jaranowski, Romain Manni-Bucau, Karl Heinz
> > Marbaise, Petr Široký
> >
> > PMC quorum: reached
> >
> > I will promote the artifacts to the central repo, the source release ZIP
> > file
> > and add this release the board report.
> >

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

Re: [VOTE] Release Maven Surefire version 3.0.0-M8

[Enrico Olivelli]

Il giorno mer 11 gen 2023 alle ore 13:48 Gary Gregory
 ha scritto:
>
> What happens if you try Java 8 and 11 and nothing else changes?

Java 11 fails the same way.

I will run with Java 8 now

Enrico

>
> Gary
>
>
> On Tue, Jan 10, 2023, 02:51 Enrico Olivelli  wrote:
>
> > I am seeing this problem
> >
> > This test Surefire1295AttributeJvmCrashesToTestsIT.test is
> > consistently failing on my laptop.
> > I am running on JDK17 on Mac ARM
> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > Maven home: /Users/enricoolivelli/maven
> > Java version: 17.0.5, vendor: Eclipse Adoptium, runtime:
> > /Users/enricoolivelli/.sdkman/candidates/java/17.0.5-tem
> > Default locale: en_IT, platform encoding: UTF-8
> > OS name: "mac os x", version: "13.0", arch: "aarch64", family: "mac"
> >
> > I will try to re-run in with a different JVM
> >
> > Enrico
> >
> > Il giorno lun 9 gen 2023 alle ore 13:05 Petr Široký
> >  ha scritto:
> > >
> > > +1 (non-binding). Tested with several projects on Linux. No issue found.
> > >
> > >
> > >
> > > --- Original Message ---
> > > On Saturday, January 7th, 2023 at 14:07, Michael Osipov <
> > micha...@apache.org> wrote:
> > >
> > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > We solved 18 issues:
> > > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12351809
> > > >
> > > > There are still a couple of issues left in JIRA:
> > > > https://issues.apache.org/jira/issues/?jql=project %3D SUREFIRE AND
> > resolution %3D Unresolved
> > > >
> > > > Staging repo:
> > > > https://repository.apache.org/content/repositories/maven-1846/
> > > >
> > https://repository.apache.org/content/repositories/maven-1846/org/apache/maven/surefire/surefire/3.0.0-M8/surefire-3.0.0-M8-source-release.zip
> > > >
> > > > Source release checksum(s):
> > > > surefire-3.0.0-M8-source-release.zip
> > > > sha512:
> > > >
> > d2a533fc8c89f92c40b20c104beb8da69a45683821cb5432e99e2d12b469067659b117e140ddf66e8ba71f12b1af7aa07207d279289957a52940162ce27599ba
> > > >
> > > > Staging site:
> > > > https://maven.apache.org/surefire-archives/surefire-LATEST/
> > > >
> > > > Guide to testing staged releases:
> > > >
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> > > >
> > > > Vote open for 72 hours.
> > > >
> > > > [ ] +1
> > > > [ ] +0
> > > > [ ] -1
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >

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

Re: [VOTE] Release Maven Surefire version 3.0.0-M8

[Enrico Olivelli]

I am seeing this problem

This test Surefire1295AttributeJvmCrashesToTestsIT.test is
consistently failing on my laptop.
I am running on JDK17 on Mac ARM
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Users/enricoolivelli/maven
Java version: 17.0.5, vendor: Eclipse Adoptium, runtime:
/Users/enricoolivelli/.sdkman/candidates/java/17.0.5-tem
Default locale: en_IT, platform encoding: UTF-8
OS name: "mac os x", version: "13.0", arch: "aarch64", family: "mac"

I will try to re-run in with a different JVM

Enrico

Il giorno lun 9 gen 2023 alle ore 13:05 Petr Široký
 ha scritto:
>
> +1 (non-binding). Tested with several projects on Linux. No issue found.
>
>
>
> --- Original Message ---
> On Saturday, January 7th, 2023 at 14:07, Michael Osipov  
> wrote:
>
>
> >
> >
> > Hi,
> >
> > We solved 18 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12351809
> >
> > There are still a couple of issues left in JIRA:
> > https://issues.apache.org/jira/issues/?jql=project %3D SUREFIRE AND 
> > resolution %3D Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1846/
> > https://repository.apache.org/content/repositories/maven-1846/org/apache/maven/surefire/surefire/3.0.0-M8/surefire-3.0.0-M8-source-release.zip
> >
> > Source release checksum(s):
> > surefire-3.0.0-M8-source-release.zip
> > sha512:
> > d2a533fc8c89f92c40b20c104beb8da69a45683821cb5432e99e2d12b469067659b117e140ddf66e8ba71f12b1af7aa07207d279289957a52940162ce27599ba
> >
> > Staging site:
> > https://maven.apache.org/surefire-archives/surefire-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: [DISCUSS] Speed up release process?

[Enrico Olivelli]

Tamas,

Il giorno mer 23 nov 2022 alle ore 14:22 Tamás Cservenák
 ha scritto:
>
> Romain,
>
> Ok, I accept your response.
>
> Would be interested about feedback for the rest of 152 projects... :)
> (actually not, is rhetorical really, just shows my point)
>
> As I still stand with my conclusion: "Maven might be quite atypical ASF
> project by juggling with many more artifacts than others".
>
> Is Maven really a "typical" ASF project? How it relates to others by:
> - number of reposes used (actually irrelevant, like svn vs git etc)
> - more importantly, number of different (!) artifacts released per project?
>
> But I will stop here and finish my attempt to speed up releases, let it be
> 72h.
> (despite my gut telling it is wrong, at least for some of those among the
> 152 artifacts we juggle).


I think that maybe we could try to merge some repositories.

It is cool that Maven is so "modular", but I am not sure how much is
it really "useful"
to need to release so many pieces all together.

We could keep the plugins as independent projects and most of the
"shared" components
collapsed into "maven core".

Please note that I know that this has been discussed before,
butmaybe sometimes it is better
to restart a discussion, because the community changes, new ideas, new
energy.
I don't have pointers to previous discussions...
we can start a brand new thread if you want

Enrico

>
> Thanks
> T
>
>
>
> On Sat, Nov 19, 2022 at 6:05 PM Romain Manni-Bucau 
> wrote:
>
> > Le sam. 19 nov. 2022 à 15:23, Tamás Cservenák  a
> > écrit :
> >
> > > Romain,
> > >
> > > Who talks here about "release without feedback"?
> > >
> >
> > Well there are two kind of consequences to reduce release time (making a
> > minimum a maximum):
> >
> > * You drop part of the opportunity of feedback you had (by construction)
> > * You enable a 5mn release since you can "easily" agree with a small set of
> > people (literally 3) to release without asking anyone else
> >
> > These two looks bad from my small and far window.
> >
> >
> > >
> > > Or explain to me what you mean by "feedback" (as obviously you don't
> > count
> > > the mandatory votes as "feedback").
> > >
> >
> > I do count it obviously but they are not the most important community wise.
> > User feedbacks we saw in last releases (several non-binding ones) are key
> > for the community and ASF is only about community at the end, nothing else.
> >
> >
> > >
> > > And, to help me in better understanding, can you point me to any example
> > of
> > > "feedback" (in your understanding) that happened on some Maven release?
> > >
> >
> >
> > https://www.mail-archive.com/dev@maven.apache.org/msg126418.html
> > https://www.mail-archive.com/dev@maven.apache.org/msg125247.html
> > https://www.mail-archive.com/dev@maven.apache.org/msg120439.html
> > https://www.mail-archive.com/dev@maven.apache.org/msg120452.html
> > ...
> >
> > We often get non-binding feedback, they are likely the most valuable and
> > limiting the voting period too strictly sounds like dropping them (they
> > often happen +4 days after the opening of the vote.
> >
> > Side note: I'd like to emphasis once again that our delay induced by the
> > voting period, even if we put 10 days, does not prevent to release the
> > whole maven ecosystem in 10 days so I would really love to refine the goal
> > of changing this widely adopted practise at asf which put people at the
> > center of our production and not software, we are *not* about software and
> > Apache is not a place to put software before people IMHO.
> >
> >
> > >
> > > Thanks
> > > T
> > >
> > > On Sat, Nov 19, 2022 at 2:55 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Agree asf enables to release without feedbackquestion is not if it
> > is
> > > > legal IMHO but is it what maven wants to do for thz mentionned reasons?
> > > >
> > > > For me it would clearly be negative - even at asf level - and the sign
> > > the
> > > > project does not belong to asf anymore (people first) so ultimately
> > means
> > > > it should find another home. Luckily we are not there :).
> > > >
> > > > Le sam. 19 nov. 2022 à 12:50, Tamás Cservenák  a
> > > > écrit :
> > > >
> > > > > Howdy,
> > > > >
> > > > > Let's all step back a little bit. Let's go back to my original
> > > > "postulate".
> > > > >
> > > > > - release vote SHOULD take 72h
> > > > > - release vote CANNOT be vetoed (only release mgr can cancel it)
> > > > > - release vote MUST reach PMC quorum
> > > > >
> > > > > Hence, in my reading, the above set of constraints does not conflicts
> > > > with
> > > > > this one below:
> > > > >
> > > > > => release vote is "done done" in a moment release has a PMC quorum
> > > > within
> > > > > 72h.
> > > > >
> > > > > And IMO this conclusion does not violate anything from those
> > > constraints
> > > > > above. As I see, none of the responses I got tackled my original
> > > > deduction
> > > > > (simplified above) :)
> > > > >
> > > > > ===
> > 

Re: [DISCUSS] Speed up release process?

[Enrico Olivelli]

Sorry for top posting.
At least 72 hours is needed because we are all volunteers and it takes time
to validate a release.

Also I see that in a few projects (maybe not Maven) the VOTE starts during
the weekend and this is a problem because sometimes in the weekend you are
not at the keyboard and we miss the opportunity to have VOTEs from people
that could cast their vote during regular work days


Just my two cents

Enrico

Il Sab 19 Nov 2022, 10:12 Romain Manni-Bucau  ha
scritto:

> Le ven. 18 nov. 2022 à 21:40, Tamás Cservenák  a
> écrit :
>
> > So Maven cares for us, hence the 72h? I don't get how one is deduced from
> > another.
> >
> > And as they are (and usually are) dependent on each other from
> perspective
> > of single release mgr local repo we could release all 150+, at the cost
> of
> > breaking all the 150+ CI jobs and all source builds in the wild for at
> > least 72+2h (actually more, as _during_ release preparation they would
> > start breaking, not only during vote). So, thank you, but no, thank you
> :D
> >
> > Strange, that you say "no user complained of waiting". From where did you
> > source this information, or from where can you support this claim?
> >
> > Just as an example, complaints on Slack do happen, quite often and
> > regularly.
> >
>
> Not of the 72h, just of the months they need to wait, please dont mix it.
> Also which % compared to the user base?
>
> Also note that all your computations sounds false since the release can be
> ran by multiple clients at once in the same staging, dont play the extreme
> game, in practise a single repo works for 5-6 projects - way bigger than 10
> maven projects ;) - in a very controlled time. If you need 30 maven
> projects it will work without any issuebut once again it is likely not
> an issue maven hits, the process being heavy - didnt say only for bads - is
> way more hurting and slowing us down (even make features abandonned) than 3
> days.
>
>
>
> > T
> >
> >
> >
> > On Fri, Nov 18, 2022 at 9:19 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Side note: asf is about people not code so maven must care about people
> > and
> > > this is why 72h came from.
> > >
> > > For me dependencies is not a reason to make release < 72h since you can
> > > release 10 projects in a single staging - anyone failling rolls back
> them
> > > all but that is the intent anyway right?
> > > It means releasing 150+ projects can be done in72h ;).
> > >
> > > It is done with success at apache by multiple projects and respects the
> > > core of our foundation, human beings.
> > >
> > > Now no user complained of waiting for 72h and if we are good enough in
> > > votes it is the needed time so think the issue you want to tackle is
> > > elsewhere, really.
> > >
> > > Le ven. 18 nov. 2022 à 20:55, Tamás Cservenák  a
> > > écrit :
> > >
> > > > As I wrote, we did have examples of changes + cascading, it is okay.
> > > >
> > > > But I don't agree with your statement about the board, as they
> > themselves
> > > > state "should" not "must" for 72h. If it does not cut with them, they
> > > > should modify the refd page(s).
> > > >
> > > > And it's not "we're impatient" either, part of the response for that
> is
> > > in
> > > > "hasty changes" canned response.
> > > >
> > > > Simply put:
> > > > - people see releases as a chore, as some "burden" that needs to be
> > done
> > > > once in a while (see refd Slack messages in 1st mail), and when it
> > comes
> > > to
> > > > be done, "let's do it when it's worth". We have MANY user questions
> on
> > ML
> > > > of type "when is X released? As the issue [the user is interested in]
> > is
> > > > fixed". And we have too many "dropped balls" in our court. IMHO,
> > > modifying
> > > > the process (to take less than 72+2h) is one step toward making
> release
> > > > less painful, less blocker.
> > > >
> > > > Fun fact: maven project consists of (not sure of exact count, just
> > > > guessing) 150+ repositories (GH on ASF org gives 153 when I type in
> > > > "maven-" in the repo search bar). This is a LOT. If we'd, for some
> > > reason,
> > > > start releasing all of those in 72h windows, it would be 10800 hours,
> > or
> > > > 450 days, more than a year.
> > > >
> > > >
> > > > On Fri, Nov 18, 2022 at 8:34 PM David Jencks <
> david.a.jen...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Which developers have to pause what activities?
> > > > >
> > > > > From previous discussions elsewhere, I’m strongly of the opinion
> > that <
> > > > 72
> > > > > hr release votes are intended only for emergency security fixes and
> > > > similar
> > > > > events, and that “we’re impatient” isn’t going to cut it with the
> > > board.
> > > > > It certainly wouldn’t with me.
> > > > >
> > > > > How many of these annoyances would be eliminated by an easy way to
> > > > release
> > > > > and vote on a set of changed artifacts + the cascading dependencies
> > all
> > > > at
> > > > > once?
> > > > >
> > > > > 

Re: [DISCUSS] Change maven code style

[Enrico Olivelli]

+1
thanks for bringing up this topic

Enrico

Il giorno gio 13 ott 2022 alle ore 06:42 Guillaume Nodet
 ha scritto:
>
> Le mer. 12 oct. 2022 à 22:02, Łukasz Dywicki  a écrit :
>
> > Maybe its time to think of getting something like spotless [1] applied
> > to all maven sources?
> >
>
> I think I started the other discussion exactly for that purpose.  It's not
> specifically about spotless, but that one is just one tool, i was using a
> different one to achieve the exact same result : a maven plugin which
> reformats during the build.
>
>
> > I've seen it used in openhab [2] to rule multiple things and it works
> > well with large codebases with multiple contributors.
> >
> > While it looks like there might be a middle ground between all IDEs,
> > such ground never going to exist for several reasons. Code formatters
> > have a lot of options, sometimes incompatible, depending on how AST and
> > processing is being built. There are less popular IDEs/editors who lag
> > behind, finally there are various sources and maybe exceptions.
> > Spotless seems to be good in doing it as an external tool which is able
> > to format and verify (limited) set of sources.
> >
>
> Agreed, that's exactly what I'm proposing on the other thread.
>
>
> >
> > Best,
> > Łukasz
> >
> > [1] https://github.com/diffplug/spotless/tree/main/plugin-maven
> > [2] https://github.com/openhab/static-code-analysis
> >
> > On 12.10.2022 20:54, Arnaud Héritier wrote:
> > > +1.
> > >
> > > If useful we can also add an editorconfig file to automatically configure
> > > IDEs but it’s a bit redundant with checkstyle
> > >
> > >
> > > Le mer. 12 oct. 2022 à 18:24, Guillaume Nodet  a
> > écrit :
> > >
> > >> Related to the discussion about automatically formatting and sorting
> > >> imports, I think it would be nice, given the big reformat commits if
> > those
> > >> PRs are to be merged, to eventually discuss some changes to those code
> > >> style.  In particular, I found out that the code is very sparse and my
> > >> screen is more wide than height, which means I can usually only see
> > 30-40
> > >> lines of code, where sometime half of them do not really carry any
> > semantic
> > >> (open braces, or things like close brace + else + open brace on 3
> > lines).
> > >> This makes me scroll a lot even on quite small methods to be able to
> > read
> > >> the full code, and that's a pain imho.
> > >> So I'd like to propose the following changes that would make maven code
> > >> more readable imho (and also closer to the usual java coding style) :
> > >>* move open braces to the end of the previous line on all places
> > >>* allow the else keyword to be directly following a closing brace to
> > >> allow "} else {" to be on the same line
> > >>* eventually relax a bit the checkstyle line length as described in
> > >> https://github.com/gnodet/maven-shared-resources/pull/2.  This has not
> > >> much
> > >> effect, as the formatter will automatically format the lines and wrap
> > them
> > >> at 120. However, in certain cases, the formatter can find in difficult
> > to
> > >> wrap the line (for example with a variable declaration and cast with a
> > >> fully qualified name) and there is either a need to manually force the
> > wrap
> > >> (using an end of line comment for example) or disabling the check with a
> > >> @SuppressWarning( "checkstyle:LineLength" ) annotation. This change only
> > >> removes the checks so that in those rare cases, the formatter can be
> > left
> > >> without any need to force things.
> > >>
> > >> If this is to be accepted, I'd amend the PRs from the other thread to
> > >> follow those changes.
> > >>
> > >> Cheers,
> > >> Guillaume
> > >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> 
> Guillaume Nodet

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

Re: [VOTE] Release Apache Maven Shade Plugin version 3.4.0

[Enrico Olivelli]

+1 (non binding)

Enrico

Il giorno lun 12 set 2022 alle ore 11:51 Slawomir Jaranowski
 ha scritto:
>
> +1
>
> niedz., 11 wrz 2022 o 12:38 Karl Heinz Marbaise 
> napisał(a):
>
> > Hi,
> >
> > We solved 6 issues:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12351491
> >
> > There are still a couple of issues left in JIRA:
> >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
> >
> >
> > Staging repo:
> >
> > https://repository.apache.org/content/repositories/maven-1806/org/apache/maven/plugins/maven-shade-plugin/3.4.0/maven-shade-plugin-3.4.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-shade-plugin-3.4.0-source-release.zip sha512:
> >
> > 3470a1316f65b1efff7309a9890f1c4d70ce549919004e682565a62cb204b3925ba325b62818f6fc3390e5aae55fb15b631392965bfc97fc3bf2fafe6e0bc797
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Sławomir Jaranowski

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

Re: reopening closed tickets

[Enrico Olivelli]

Delany,
the issue you are referring to seems to have been "closed as
incomplete" in 2014.
I think that it is legit to re-open it (and I did it).

I don't know the details, but especially now that you have a PR there
is enough to resume the discussion.

You did well in writing here in dev@, most of the people don't care
much about the flood of JIRA notifications.

I hope that helps
Enrico

Il giorno mer 7 set 2022 alle ore 16:31 Delany
 ha scritto:
>
> Hi Maven,
>
> What factors are necessary to reopen a ticket?
> Given that a closed ticket cannot be voted on, and will probably not appear
> on most people's radar, it seems futile to comment on the ticket itself.
>
> Between adding myself to the "Watchers" list and offering up an
> incontestable PR to banish the problem once and for all, what are my
> options?
>
> Kind regards,
> Delany
>
> ( I'm specifically thinking of
> https://issues.apache.org/jira/browse/MNG-2751 )

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

Re: [VOTE] Apache Maven Surefire 3.0.0-M7

[Enrico Olivelli]

+1 (non binding)
built and run all tests on MacOS on AdoptOpenJDK 1.8.0_275


Enrico

Il giorno ven 3 giu 2022 alle ore 13:03 Olivier Lamy
 ha scritto:
>
> Hi,
> We fixed 19 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351502=Text=12317927=Create
>
> Staged repository:
> https://repository.apache.org/content/repositories/maven-1757/
>
> sources:
> https://repository.apache.org/content/repositories/maven-1757/org/apache/maven/surefire/surefire/3.0.0-M7/surefire-3.0.0-M7-source-release.zip
>
> sha512: 
> d83a4d3389de003d11d764f228f37ff4771a2b64dff24fa645b94406679eecc72c07d271b21562772b0537e9bc158ce87dc59bebdac666dd95e38c39ee2020d5
>
> Staging site:
> https://maven.apache.org/surefire-archives/surefire-LATEST/index.html
>
> Vote open for 72H [1]
>
> cheers
> Olivier
>
> [1]: countdown
> https://www.timeanddate.com/countdown/generic?iso=20220606T2105=47=cursive

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

Re: release of surefire M7

[Enrico Olivelli]

+1

Enrico

Il giorno mer 25 mag 2022 alle ore 08:54 Slawomir Jaranowski
 ha scritto:
>
> Hi,
>
> Good idea.
>
> Please also update "road map" [1] before release to be consistent ... with
> released content :-)
>
> https://maven.apache.org/surefire/maven-surefire-plugin/
>
>
> śr., 25 maj 2022 o 01:54 Olivier Lamy  napisał(a):
>
> > Hi
> > I'd like to release M7 because of this blocker issue
> > https://issues.apache.org/jira/browse/SUREFIRE-2057
> >
> > I will start release process by the end of this week and move current non
> > fixed issue to M8
> >
> > cheers
> > Olivier
> >
>
>
> --
> Sławomir Jaranowski

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

Re: [VOTE] Release Apache Parent POM version 26

[Enrico Olivelli]

+1

Good to see the switch out from google analytics


Enrico

Il Sab 9 Apr 2022, 19:50 Slawomir Jaranowski  ha
scritto:

> Hi,
>
> We solved 7 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12351372=Text=12311250
>
> Changes since the last release for Maven Apache Parent POM:
> https://github.com/apache/maven-apache-parent/compare/apache-25...apache-26
>
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheapache-1024/
>
> https://repository.apache.org/content/repositories/orgapacheapache-1024/org/apache/apache/26/apache-26-source-release.zip
>
> Source release checksum(s):
> apache-26-source-release.zip - SHA-512 :
>
> f3dda2215de74de96b4ac7fa99fae7394ba06ad1e592112556330dd9c2b51ce6fddc8fea1684ce76b9d1bc247b815db306fb5fa65a4828f2600a1d81c1a848fc
>
> Staging site:
> https://maven.apache.org/pom-archives/asf-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Sławomir Jaranowski
>

Re: MSOURCES-130

[Enrico Olivelli]

Hi,
Are you referring to the compiler plugin or to the sources plugin?

Il Sab 26 Mar 2022, 04:48 bukaj_s  ha scritto:

> Hi.
> Please could someone provide some feedback on issue
> https://issues.apache.org/jira/browse/MSOURCES-130?
> Thank you
>


Enrico

>

Re: [VOTE] - Release Apache Maven Shade Plugin Version 3.3.0

[Enrico Olivelli]

+1 (non binding)
Great feature set!

Enrico

Il Gio 24 Mar 2022, 19:21 Karl Heinz Marbaise  ha
scritto:

> Hi,
>
> We solved 16 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921=12348391=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHADE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1730
>
>
> https://repository.apache.org/service/local/repositories/maven-1730/content/org/apache/maven/plugins/maven-shade-plugin/3.3.0/maven-shade-plugin-3.3.0-source-release.zip
>
> Source release checksum(s):
> maven-shade-plugin-3.3.0-source-release.zip sha512:
>
> f88196508ca14442c7b6e6cf8e09b9e6d5ad7139e5c95d27b4f0ae390c4339277248ded7ddef5fd43151b9bc6abaaab6157d478fe4a73f941004cb8429bbfefd
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-shade-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Radical Fast Forward to 3.5.4

[Enrico Olivelli]

+1

Thanks for bringing this up

Enrico

Il giorno dom 13 mar 2022 alle ore 20:58 Elliotte Rusty Harold
 ha scritto:
>
> What do all the various package managers install? I'm pretty sure I've
> seen one lately whose default was 3.3.1. Debian perhaps?
>
> I think before we make any such move it would make sense to audit what
> people who don't manually install Maven are likely to have. First we
> should raise all those to 3.5.4 or later. Then we can upgrade the
> minimum version.
>
> Even more ambitiously, perhaps we should rethink how maven is
> installed. Why should it come from anywhere but Maven Central, and why
> can't a pom.xml specify the version of Maven itself? All we really
> should install is a very simple bootstrap script. But that's probably
> a discussion for another day. Let's get the package managers
> straightened out first.
>
> On Sun, Mar 13, 2022 at 11:48 AM Michael Osipov  wrote:
> >
> > Folks,
> >
> > as you might now we are dragging old luggage over and over with every
> > new year. We are making (little) progress with cleansing, skimming and
> > updating of our components.
> >
> > I'll will make a radical proposal I have already discussed privately
> > with other fellow committers over Slack:
> > Raise the entire baseline to Maven 3.5.4, all of our raises have been
> > intermediaries. Reasoning:
> > * Maven 3.5.4 is almost 4 old, it is settled
> > * Everything before we shouls consider ancient, if you haven't moved
> > yet, you will not and it will be your problem.
> > * It is the first version which uses Maven Resolver [1]
> > * It will free resources to test with previous releases which most don't
> > do anyway
> > * Maybe this will make it even easier to migrate to the upcoming Maven
> > Core API
> >
> > WDYT?
> >
> > Michael
> >
> > PS: I don't even mind 3.6.3 personally, thought I don't this benefit.
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup#MavenEcosystemCleanup-ResolverandMaven
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Enrico Olivelli]

Juraj,
I have run this command on your reproducer and in "tmp" I cannot find
log4j versions other then 2.17.1

mvn clean install -X -Dmaven.repo.local=tmp > out.txt

Enrico

Il giorno lun 28 feb 2022 alle ore 13:52 Juraj Veverka
 ha scritto:
>
> Hi David
>
> Many thanks for your email, I really appreciate your reply. This is an
> isolated example of the problem.
> https://github.com/jveverka/mvn-dependency-log4j
> You can find all repro steps there. In case of any questions, feel free
> to contact me.
>
> Kind regards
> Juraj Veverka
>
>
>
> On Mon, Feb 28, 2022 at 12:14 PM David Milet  wrote:
>
> > Where I work we decided to address log4j vulnerabilities only for
> > components directly used by the application and actually performing logging.
> > We ignored transitive dependencies and maven plug-ins.
> > I’m curious about this use case from Venu though, what application would
> > rely on the maven dependency plugin at runtime? Does it mean you’re pulling
> > maven dependencies after application startup?
> >
> > > On Feb 28, 2022, at 03:30, Slawomir Jaranowski 
> > wrote:
> > >
> > > Hi,
> > >
> > > Please provide more information, like plugin, mven, os version.
> > >
> > > We also need an example project which reproduces your issue.
> > > When we can't reproduce we can't help.
> > >
> > > pon., 28 lut 2022 o 08:55 Jaladi, Venumadhav
> > >  napisał(a):
> > >
> > >> Hi team,
> > >>
> > >> Can I expect any response?  Is this the right email address for my
> > >> question?
> > >>
> > >> Thanks,
> > >> Venu
> > >>
> > >>
> > >>> On Thu, Feb 24, 2022 at 6:47 AM Jaladi, Venumadhav <
> > >>> jaladi.venumad...@verizon.com> wrote:
> > >>>
> > >>> Hi team,
> > >>>
> > >>> We are using the Maven Dependency Plugin in one of our projects and our
> > >>> scanning tools are showing multiple vulnerabilities related to Log4j
> > >>> (CVE-2019-17571, CVE-2020-9488, CVE-2022-23302, CVE-2022-23305,
> > >>> CVE-2022-23307 and CVE-2021-4104).
> > >>>
> > >>> We would  like to know if there are any plans to release a newer
> > version
> > >>> of Maven Dependency Plugin with the fixes of these
> > >>> vulnerabilities(referring to the latest version of Log4j libraries).
> > If
> > >>> so, is there any planned date for this release?
> > >>>
> > >>> Please let us know any any more information is required.
> > >>>
> > >>> Thanks,
> > >>> Venu
> > >>>
> > >>
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> >
> >
>
> --
>
> Best Regards
>
>
> --
>
> Juraj Veverka  | Solution Design Architect
>
> M +421 917 521 285
>
> www.globallogic.sk  
>
>    [image: GLTwitter]
> 
> 
> 
> 
>
> http://www.globallogic.com/Disclaimer.htm

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

Re: Commit Review Policy

[Enrico Olivelli]

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 seen people introducing more
> fixes or unintentionally
> thought they would fix something when in fact they introduced a type.
>
> In my humble opinion, reviews BEFORE commit should be the default case.

- review from at least 2 committers (so only one if the patch comes
from a committer)
- CI passing



+1

Enrico

>
> Am Di., 25. Jan. 2022 um 20:47 Uhr schrieb Slawomir Jaranowski
> :
> >
> > Hi,
> >
> > On the page "Apache Maven Project Roles" [1] we have paragraph
> > about Committers with:
> >
> > The Apache Maven project uses a Commit then Review policy and has a number
> > of conventions which should be followed.
> >
> >
> > Looks like Review then Commit policy is from svn time, so should be
> > refreshed or confirmed that is actual.
> >
> > When we want Review than Commit policy, we need some rules which allow us
> > to effectively work if nobody is interested for feedback.
> > We also need rules / examples for direct commits, when they are acceptable.
> >
> > Do we need different rules for Maven core, plugins, shared ... etc
> >
> > Example of rule:
> >
> > PR -> no feedback for X days -> send a mail on dev@, if still not feedback
> > after X days after mail  -> proceed alone
> >
> > [1] https://maven.apache.org/project-roles.html#committers
> >
> > --
> > Sławomir Jaranowski
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: GitHub notification: dev@ or issues@?

[Enrico Olivelli]

+1

Enrico

Il giorno gio 23 dic 2021 alle ore 09:08 Slawomir Jaranowski <
s.jaranow...@gmail.com> ha scritto:

> +1
>
> On the dev list should be no messages sent by robots.
>
> czw., 23 gru 2021 o 08:19 Hervé BOUTEMY 
> napisał(a):
>
> > Hi,
> >
> > It seems that many Git repositories are configured to send issues
> > notifications to dev@maven [1] instead of issues@maven [2] = the
> > classical target of some Git repositories and of classical Jira issues
> >
> > Any objection to me configuring back GitHub notifications to issues@maven
> ?
> > (using .asf.yaml [3], for the "how?")
> >
> > Regards,
> >
> > Hervé
> >
> > [1] https://lists.apache.org/list.html?dev@maven.apache.org
> >
> > [2] https://lists.apache.org/list.html?iss...@maven.apache.org
> >
> > [3]
> >
> https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-Notificationsettingsforrepositories
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Sławomir Jaranowski
>

Re: Surefire next release

[Enrico Olivelli]

Il giorno mar 21 dic 2021 alle ore 13:49 Slawomir Jaranowski <
s.jaranow...@gmail.com> ha scritto:

> Hi,
>
> Summary for today.
>
> Decisions waiting to take:
>
> 1. What version do we want to release 3.0.0 or the next milestone?
>

3.0.0 or 3.0.1 (this should be > 3.0.0Mxx) is good for me


> 2. What with the road map on the first page ...?
>

What about dropping it ? we are an OS project and usually OS projects move
forward thanks to individual contributions


> 3. JDK 8 as target - without refactor - will it be acceptable? - cause to
> stop upgrading some dependencies like commons-io
>

+1


> 4. Final list of acceptable PR to merge before release
>

I would not commit anything that is not strictly needed to make the release
"stable"

Enrico


>
> My proposition of PR to merge before release - please comment on PR.
> If no objections in PR I will try process one by one - to mitigate big load
> on ci
>
>
> https://issues.apache.org/jira/browse/SUREFIRE-1398
> https://github.com/apache/maven-surefire/pull/160
>
> https://issues.apache.org/jira/browse/SUREFIRE-1939
> https://github.com/apache/maven-surefire/pull/387
>
> https://issues.apache.org/jira/browse/SUREFIRE-1962
> https://github.com/apache/maven-surefire/pull/398
>
> https://issues.apache.org/jira/browse/SUREFIRE-1963
> https://github.com/apache/maven-surefire/pull/399
>
> https://issues.apache.org/jira/browse/SUREFIRE-1964
> https://github.com/apache/maven-surefire/pull/400
>
> https://issues.apache.org/jira/browse/SUREFIRE-1967
> https://github.com/apache/maven-surefire/pull/407
>
> https://issues.apache.org/jira/browse/SUREFIRE-1959
> https://github.com/apache/maven-surefire/pull/412
>
>
> niedz., 19 gru 2021 o 20:27 Romain Manni-Bucau 
> napisał(a):
>
> > In my opinion onmy M9 would be worth it but I don't think users care too
> so
> > we should go with 3.0.0, do other Mx in 3.0.x and if we want to tackle M9
> > items do a 3.1.0 (but not sure it bothers that much to be honest, it is
> > more about being "clean" than anything else IMHO).
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le dim. 19 déc. 2021 à 20:17, Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> > a écrit :
> >
> > > And what with the road map ...
> > >
> > > https://maven.apache.org/surefire/maven-surefire-plugin/index.html
> > >
> > >
> > >
> > > niedz., 19 gru 2021 o 19:32 Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> > > napisał(a):
> > >
> > > > For Maven Api at the moment I think only change requirements and
> > > > dependency ... without using new features - We are not sure if it
> works
> > > > with earlier versions anyway - minimal Maven on jenkins is 3.2.5
> > > > JDK 8 - also only target change - will open possibility to refactor
> in
> > > the
> > > > feature
> > > >
> > > > But we needed to breaker compatibility for next 3.x releases.
> > > > So we can start 3.x with such requirements.
> > > >
> > > >
> > > >
> > > > niedz., 19 gru 2021 o 19:18 Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > > > napisał(a):
> > > >
> > > >> Don't think both are important to release, we can mention we only
> > target
> > > >> j8
> > > >> without doing the change I think, this one is more than ok now.
> > > >> About JSR330 I think we are better staying away from it due to the
> > > related
> > > >> threads but it is internals anyway so not a big deal for surefire
> > IMHO.
> > > >>
> > > >> Releasing the default change for trimstacktrace is a bigger thing
> > > awaited
> > > >> since the toggle was introduced for ex, and having a maintained
> final
> > > >> release is key for users so the only path we can take IMHO.
> > > >>
> > > >> Romain Manni-Bucau
> > > >> @rmannibucau  |  Blog
> > > >>  | Old Blog
> > > >>  | Github <
> > > >> https://github.com/rmannibucau> |
> > > >> LinkedIn  | Book
> > > >> <
> > > >>
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >> >
> > > >>
> > > >>
> > > >> Le dim. 19 déc. 2021 à 19:10, Slawomir Jaranowski <
> > > s.jaranow...@gmail.com
> > > >> >
> > > >> a écrit :
> > > >>
> > > >> > What do you think about:
> > > >> >
> > > >> > https://issues.apache.org/jira/browse/SUREFIRE-1959 - even 3.2.5
> > > >> > https://issues.apache.org/jira/browse/SUREFIRE-1955 ... yes i
> know
> > > not
> > > >> all
> > > >> > like it, but when ... if we think about 3.0.0 version it be ok i
> > think
> > > >> >
> > > >> > before release ...
> > > >> >
> > > >> > niedz., 19 gru 2021 o 19:02 Romain Manni-Bucau <
> > rmannibu...@gmail.com
> 

Re: [VOTE] Release Maven Wagon version 3.5.0

[Enrico Olivelli]

+1 (non binding)


Enrico

Il Dom 19 Dic 2021, 19:46 Michael Osipov  ha scritto:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122=12351097
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1680/
>
> https://repository.apache.org/content/repositories/maven-1680/org/apache/maven/wagon/wagon/3.5.0/wagon-3.5.0-source-release.zip
>
> Source release checksum(s):
> wagon-3.5.0-source-release.zip
> sha512:
>
> c24c05c37b621c6ce160ef30675ca94c683b8581a2252a6b383d852d779816cbd80688f2e14d8eb1722e56984f97b301379762a9ebba77e9366ece03bef69d52
>
> Staging site:
> https://maven.apache.org/wagon-archives/wagon-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Wrapper version 3.1.0

[Enrico Olivelli]

I have checked the artifacts and they look good.
The build passes on Mac on JDK11 (Adoptium)

I am trying to use the binary produced by the build

I am facing this error:

enrico.olivelli@xxx target % MVNW_VERBOSE=true ./mvnw


Found .mvn/wrapper/maven-wrapper.jar

/Users/enrico.olivelli/dev/tmp/maven-wrapper-parent-3.1.0/maven-wrapper-distribution/target

Apache Maven Wrapper 3.1.0

Exception in thread "main" java.lang.RuntimeException: Wrapper properties
file
'/Users/enrico.olivelli/dev/tmp/maven-wrapper-parent-3.1.0/maven-wrapper-distribution/target/.mvn/wrapper/maven-wrapper.properties'
does not exist.

at
org.apache.maven.wrapper.WrapperExecutor.forWrapperPropertiesFile(WrapperExecutor.java:66)

at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:71)

Is there something wrong ?

There README file does not tell much about how to use it
(same contents as here https://github.com/apache/maven-wrapper)


Enrico



Enrico

Il giorno mar 14 dic 2021 alle ore 12:17 Hervé BOUTEMY <
herve.bout...@free.fr> ha scritto:

> SNAPSHOTs are available from
>   https://repository.apache.org/content/repositories/snapshots/
>
> Le mardi 14 décembre 2021, 07:53:40 CET Dan Tran a écrit :
> > Hi
> >
> > Could you deploy a snapshot?  my company repository manager does not
> proxy
> > staging repos.
> >
> > Can build from tag, generate the wrapper files, and run mvnw on some
> other
> > host, it will fail if I use the staging RC, but I can pull
> > maven-wrapper.jar from snapshot
> >
> > Thanks
> >
> > -D
> >
> > On Mon, Dec 13, 2021 at 1:12 PM Manfred Moser 
> >
> > wrote:
> > > Awesome. Thank you Herve.
> > >
> > > + 100
> > >
> > > Hervé BOUTEMY wrote on 2021-12-13 13:09 (GMT -08:00):
> > > > Hi,
> > >
> > > > We solved 18 issues:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721;
> > > version=12350068=Text>
> > > > Staging repo:
> > > > https://repository.apache.org/content/repositories/maven-1679/
> > >
> > >
> https://repository.apache.org/content/repositories/maven-1679/org/apache/m
> > >
> aven/wrapper/maven-wrapper-parent/3.1.0/maven-wrapper-parent-3.1.0-source-
> > > release.zip>
> > > > Source release checksum(s):
> > >
> > > > maven-wrapper-parent-3.1.0-source-release.zip sha512:
> > >
> 9b7362c956cd24e21b46b290e154893ae35fd38431b6fe80f035cd17a97806e9221c71ac14
> > > 975692f2a948ad25489f5b9d9bbb72441f9ab5eb541da0a86bdef9>
> > > > Staging site:
> > > > https://maven.apache.org/wrapper-archives/wrapper-LATEST/
> > > >
> > > > Guide to testing staged releases:
> > > >
> https://maven.apache.org/guides/development/guide-testing-releases.html
> > > >
> > > > Vote open for at least 72 hours.
> > > >
> > > > [ ] +1
> > > > [ ] +0
> > > > [ ] -1
> > > >
> > > >
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Welcome Sławomir Jaranowski as Maven Committer

[Enrico Olivelli]

Congrats !

Enrico

Il giorno mar 14 dic 2021 alle ore 11:55 Sylwester Lachiewicz <
slachiew...@gmail.com> ha scritto:

> Congratulations Sławek
>
> wt., 14 gru 2021, 11:10 użytkownik Robert Scholte 
> napisał:
>
> > The Maven PMC invited Sławomir to become a committer and he has accepted
> > it.
> >
> > Enjoy improving Apache Maven!
> >
> > thanks,
> > Robert
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] Release Apache Maven version 3.8.4

[Enrico Olivelli]

+1
- tested the binaries on a few projects, on JDK11
- checked out/reviewed a couple of changes in the change log

Thank you Micheal !

Enrico

Il giorno lun 15 nov 2021 alle ore 13:19 Arnaud Héritier <
aherit...@gmail.com> ha scritto:

> No regression found
> +1
>
> On Sun, Nov 14, 2021 at 2:28 PM Michael Osipov 
> wrote:
>
> > Hi,
> >
> > We solved 5 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350685
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1669/
> >
> > Dev dist directory:
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.4/
> >
> > Source release checksums:
> > apache-maven-3.8.4-src.zip sha512:
> >
> >
> 2f57dd7476ee1831867930dbe33ebe669b8fc0a9863586093a4eb2188745c5ddc2710beea1bf076263923ce38a487ef92d570bc752c77d0e0f1e3416b65bc785
> > apache-maven-3.8.4-src.tar.gz sha512:
> >
> >
> ea4b5f2b29be45d22e716099d0ef87367c78766aade094e8d7f295fe3b2c98cba2bf0f214d3ed55e2c17d2f74c82352cf9dc83fa47ddc97a8d2b847315500431
> >
> > Binary release checksums:
> > apache-maven-3.8.4-bin.zip sha512:
> >
> >
> bcd1e99548ac8a5b9ec159ee16c23d29d6799696c92140d583d25eb323433aadcc0b47c45b0b6bd9dbcf344bbba38b56dd056a9c49ae714cfc22dc06bb4a4230
> > apache-maven-3.8.4-bin.tar.gz sha512:
> >
> >
> a9b2d825eacf2e771ed5d6b0e01398589ac1bfa4171f36154d1b5787879605507802f699da6f7cfc80732a5282fd31b28e4cd6052338cbef0fa1358b48a5e3c8
> >
> > Draft for release notes:
> > https://github.com/apache/maven-site/pull/274
> >
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open until 2021-11-19T18:00Z
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Arnaud Héritier
> Twitter/GitHub/... : aheritier
>

Re: [VOTE] Release Apache Maven Shared Resources version 4

[Enrico Olivelli]

Can you give more context about why we should cut this release with only
one issue?
Probably I missed some discussion

BTW +1 (non binding)


Enrico

Il Sab 2 Ott 2021, 17:15 Sylwester Lachiewicz  ha
scritto:

> Hi,
>
> We solved 1 issue:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12349555=Text=12317922
>
> Dependency upgrade
>  [MSHARED-990] - Swap scope and exclude scope to access modifier in
> the check JavadocMethodCheck.
>
> There are no issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-resources
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1668/
>
> https://repository.apache.org/content/repositories/maven-1668/org/apache/maven/shared/maven-shared-resources/4/maven-shared-resources-4-source-release.zip
>
> Source release checksum(s):
> maven-shared-resources-4-source-release.zip sha512:
>
> 5792cecf4a644dfb050d03f32ad4b5718422cd51b10ccb4056c0b0fe9618c8fec615115dc932d75a5470888c16c02cb7987f61b18611f6119fc2d2d3cb679bf7
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-shared-resources-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven version 3.8.3

[Enrico Olivelli]

+1

Enrico

Il Sab 2 Ott 2021, 10:14 Sylwester Lachiewicz  ha
scritto:

> also +1 from me
> Sylwester
>
> czw., 30 wrz 2021 o 21:04 Hervé BOUTEMY 
> napisał(a):
> >
> > +1
> >
> > build reproduced successfully: reference was done on Windows with JDK 8
> >
> > Regards,
> >
> > Hervé
> >
> > Le lundi 27 septembre 2021, 21:17:59 CEST Michael Osipov a écrit :
> > > Hi,
> > >
> > > We solved 18 issues:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922
> > > rsion=12350518
> > >
> > > There are still a couple of issues left in JIRA:
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resol
> > >
> ution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1667/
> > >
> > > Dev dist directory:
> > > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.3/
> > >
> > > Source release checksums:
> > > apache-maven-3.8.3-src.zip sha512:
> > >
> 165c7ce9fbc1b20a0e826950f2acc6638abffbbcd0b2dda869b9b2612984c421c985844ec68b
> > > 9d4f9d214df3d1531f3051bbe8edd29b22cf97ef4606f15761f7
> > > apache-maven-3.8.3-src.tar.gz sha512:
> > >
> 7d7b6abf8f0407f95e35ccf857412b59c8ebfa0b2eef8cf52badf20d47e4be1e79f2412965d5
> > > 14314240184847b5bf5c20e63c7f4b8d6cce5d2f3bc5bd31d2f2
> > >
> > > Binary release checksums:
> > > apache-maven-3.8.3-bin.zip sha512:
> > >
> 959de0db3e342ecf1c183b321799a836c3c10738126f3302b623376efa45c6769ccb5cd32a17
> > > f9a9a8eb64bb30f13a6a0e4170bf03a7707cfba6d41392107e93
> > > apache-maven-3.8.3-bin.tar.gz sha512:
> > >
> 1c12a5df43421795054874fd54bb8b37d242949133b5bf6052a063a13a93f13a20e6e9dae2b3
> > > d85b9c7034ec977bbc2b6e7f66832182b9c863711d78bfe60faa
> > >
> > > Draft for release notes:
> > > https://github.com/apache/maven-site/pull/264
> > >
> > >
> > > Guide to testing staged releases:
> > > http://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open until Sunday.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven WAR Plugin version 3.3.2

[Enrico Olivelli]

+1

Enrico

Il giorno lun 6 set 2021 alle ore 19:55 Arnaud Héritier 
ha scritto:

> +1
>
> On Sun, Sep 5, 2021 at 11:38 AM Hervé BOUTEMY 
> wrote:
>
> > Hi,
> >
> > We solved 2 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121=12348574=Text
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1661/
> >
> >
> https://repository.apache.org/content/repositories/maven-1661/org/apache/maven/plugins/maven-war-plugin/3.3.2/maven-war-plugin-3.3.2-source-release.zip
> >
> > Source release checksum(s):
> > maven-war-plugin-3.3.2-source-release.zip sha512:
> >
> 368d1066d3aa429b3dc26b1e3a502fe56c4232fae13727c74d44015b160eec3753f28ff72e3a0f33f9dfa9d25e9912efb559d45cf41952151ecc88337203fc95
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Arnaud Héritier
> Twitter/GitHub/... : aheritier
>

Re: [VOTE] Release Apache Maven version 3.8.2

[Enrico Olivelli]

+1 (non binding)

Enrico

Il Dom 8 Ago 2021, 10:07 Michael Osipov  ha scritto:

> Am 2021-08-04 um 22:02 schrieb Michael Osipov:
> > Hi,
> >
> > We solved 68 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12349965
> >
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> >
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1657/
> >
> > Dev dist directory:
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.2/
> >
> > Source release checksums:
> > apache-maven-3.8.2-src.zip sha512:
> >
> 228ae07dfd89f73cc7d0b10b60708db2730465dbe6022968bde6c5d7f0df9bcd7f460fe1d8012726a29f136486bdb63d1e1ba932e307380fe4c1f4db440407dd
>
> >
> > apache-maven-3.8.2-src.tar.gz sha512:
> >
> 617377ad85ced7961f972610ed88535fd3f1ab18e104556d8a3adee7769515ee67ee3cbaff50afcffd74a443b471b806acb1ae92f91a259bc8ccaab56795baf6
>
> >
> >
> > Binary release checksums:
> > apache-maven-3.8.2-bin.zip sha512:
> >
> 59ad2cbd6b7abde34ebedda94ce5631256373718e71b55202035bd1190d0144f071433f78b99e16f1204413b3eb888659e5039009e1ad0106f16332e3c62bced
>
> >
> > apache-maven-3.8.2-bin.tar.gz sha512:
> >
> b0bf39460348b2d8eae1c861ced6c3e8a077b6e761fb3d4669be5de09490521a74db294cf031b0775b2dfcd57bd82246e42ce10904063ef8e3806222e686f222
>
> >
> >
> > Draft for release notes:
> > https://github.com/apache/maven-site/pull/251
> >
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
>
> +1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Shade Plugin version 3.3.0

[Enrico Olivelli]

Tibor

Il Dom 18 Lug 2021, 17:06 Tibor Digana  ha scritto:

> -1, the reason is that the contributors and committers are waiting for PR
> #90 and #95, and pls restart the Vote which is faster right now.
> T
>

In my humble opinion this is not a good motivation for a binding -1.

If the code is in good shape and there are no blockers there is no need to
block the release.
It is up to the RM to decide whether to cut a new RC.

That said, everybody is free to cast his/her VOTE the way he/she likes

Enrico


> On Sun, Jul 18, 2021 at 12:34 PM Michael Osipov 
> wrote:
>
> > I need one more binding vote...
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] Release Apache Parent POM version 24

[Enrico Olivelli]

+1 (non binding)

I have run thru the diff on github.
There are plenty of good improvements.

Thanks for driving the release

Enrico

Il Sab 10 Lug 2021, 13:33 Sylwester Lachiewicz  ha
scritto:

> +1
>
> sob., 10 lip 2021, 11:56 użytkownik Michael Osipov 
> napisał:
>
> > Am 2021-07-10 um 03:39 schrieb Hervé BOUTEMY:
> > > Hi,
> > >
> > > We solved 17 issues:
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12346845=Text
> > >
> > >
> >
> https://github.com/apache/maven-apache-parent/compare/apache-23...apache-24
> > >
> > > Staging repo:
> > >
> https://repository.apache.org/content/repositories/orgapacheapache-1021/
> > >
> >
> https://repository.apache.org/content/repositories/orgapacheapache-1021/org/apache/apache/24/apache-24-source-release.zip
> > >
> > > Source release checksum(s):
> > > apache-24-source-release.zip sha512:
> >
> 3c0667eee535523ba16309c991e5aed4ef59f48bae623eea6757762ff03ec3ef3ab51d11958a75c032efb95be491c2c8a367b46c7ca0104e6203a5003c878ad8
> > >
> > > Staging site:
> > > https://maven.apache.org/pom-archives/asf-LATEST/
> > >
> > > Guide to testing staged releases:
> > >
> https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for at least 72 hours.
> >
> > +1
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [JENKINS] - New Maven Controller for the project

[Enrico Olivelli]

Il giorno gio 8 lug 2021 alle ore 20:06 Gavin McDonald 
ha scritto:

> Hi All,
>
> With no more interest in this subject, and no willing testers, I'll be
> going ahead tomorrow and move all Maven jobs to ci-maven.apache.org.
>

I have tested that I am able to login to ci-maven with my LDAP credentials

Thanks
Enrico


>
> Feel free to check after the move and create INFRA jira ticket(s) for
> anything that breaks as a result.
>
> Gav...
>
> On 2021/06/30 18:23:54, Gavin McDonald  wrote:
> > Hi Michael,
> >
> > On 2021/06/30 18:12:12, Michael Osipov  wrote:
> > > Am 2021-06-30 um 20:03 schrieb Gavin McDonald:
> > > > Hi Maven folks.
> > > >
> > > > Infra has decided to separate off the Maven build jobs from
> > > > ci-builds.apache.org over to its very own Jenkins Controller and
> Agents.
> > > >
> > > > This means that Maven now has a dedicated Jenkins environment for
> itself.
> > > > It
> > > > also means that no other projects build jobs can build on the Maven
> nodes;
> > > > and
> > > > then Maven jobs will no longer  be able to build on the ci-builds
> jobs.
> > > >
> > > > Your new Controller is set up as https://ci-maven.apache.org and
> all Maven
> > > > Committers
> > > > can login via LDAP and create jobs.
> > > >
> > > > At the time of writing, there is one node/agent attached but I am
> building
> > > > 4 more  - all
> > > > Ubuntu 20.04 and based in our Azure account.
> > >
> > > Well, just Ubuntu? We actually need at least three different operating
> > > systems to detect subtile bugs which I have found over time.
> > > Since this is on an Azure can you rather add at least one Windows and
> > > FreeBSD node to it? 4x Ubuntu won't really help.
> >
> > You are getting exactly as you have been using on ci-builds.a.o (and
> builds.a.o) before that.
> > There is no FreeBSD on any of our CI nor has there been for many years,
> we do not support
> > it.
> >
> > As for Windows nodes, you still have access to the same Windows nodes as
> you always have, they are what are called floating agents available for
> lease by all Jenkins Controllers, so your access and availability to the
> Windows nodes will not change. We have 6 Windoes nodes currently and plan
> to add some more soon.
> >
> > If anyone were to donate any nodes to attach to ci-maven then we'd be
> happy to help add them on, including FreeBSD donated nodes, only difference
> being that Infra would not manage them nor install any software on them,
> which would be up to the donator(s).
> >
> > HTH
> >
> > >
> > > Michael
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 4 performances problems

[Enrico Olivelli]

Il giorno gio 1 lug 2021 alle ore 12:27 Robert Scholte 
ha scritto:

> Should we postpone the alpha-1 release because of this?
> For me the most important reason for alpha-1 is to get confirmation that
> builds won't be broken due to build/consumer.
>

100% agreed
it is an ALPHA and there are many cool features, it is worth to give it to
the users and get feedback

my two cents
Enrico


> But if users simply look at buildtime and due to some slower result don't
> care for the other changes, then we shouldn't do this release now.


> Robert
>
>
>
> On 1-7-2021 11:20:17, Guillaume Nodet  wrote:
> I've been running a few tests to measure performances.
> This simplistic test looks like running the following command in a loop and
> measure the execution time. This is done on a quite big project so that a
> bunch of pom files are actually read.
>
> for i in 1 2 3 4 5 6 7 8 9 10 ; do time $MAVEN_HOME/bin/mvn -DskipTests
> -Dmaven.experimental.buildconsumer=true help:evaluate
> -Dexpression=java.io.tmpdir -DforceStdout -q ; done
>
> The average results are the following:
> Maven 4 with build/consumer: 28,40s
> Maven 4 w/out build/consumer: 23,43s
> Maven 3: 21,54s
>
> I find the 20% performance loss of the build/consumer feature quite
> problematic. I hinted about those possible performance problems when
> reviewing the original PR, so I'd like to see if I can investigate a
> different way of achieving the transformation. I think the main
> performance cost comes from using the following pattern:
> read file -> parse using JAXP -> transform using TRAX -> write to stream
> read stream -> parse using XPP3
> The first step is performed in a separate thread and the output written to
> a pipe stream which is used as the input of the usual pom parser. This
> double parsing step, in addition to using the JAXP / TRAX api, which is not
> the fastest one, comes at a heavy cost.
>
> I see two ways to solve the problem:
> * refactor the build/consumer feature to use a different API so that the
> parsing can be done in a single step (this would mean defining an XmlFilter
> interface to do the filtering and wrapping it inside an XmlPullParser)
> * get rid of the Xpp3 implementation and use the more common Stax api
> which already defines filters
>
> The second option has some drawbacks though: all the plugin configuration
> done using Xpp3Dom would not work anymore, so this is a very big and
> incompatible change.
>
> I'm thus willing to investigate the first option and see what can be done.
> If there's a consensus, I'll start working on a POC about the api / filters
> and will get back to this list with some more information.
>
> --
> 
> Guillaume Nodet
>

Re: [VOTE] Import mvndaemon/mvnd project @ Apache

[Enrico Olivelli]

+1

Enrico

Il giorno mer 16 giu 2021 alle ore 09:42 Arnaud Héritier
 ha scritto:
>
> +1
>
> On Wed, Jun 16, 2021 at 8:50 AM Olivier Lamy  wrote:
>
> > Hi
> > As already proposed by Guillaume, it looks to be a good idea to
> > import mvndaemon/mvnd here at Apache.
> >
> > I'd like to propose a vote for this.
> > +1: import the project here
> > 0  : no real idea
> > -1 : no (please explain why)
> >
> > cheers
> > --
> > Olivier
> > PS: Actually I have no idea how binding works in such vote.
> >
>
>
> --
> Arnaud Héritier
> Twitter/Skype : aheritier

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

Re: Welcome Guillaume Nodet as new Maven Committer

[Enrico Olivelli]

Congrats!


Enrico

Il giorno mer 26 mag 2021 alle ore 13:04 Grzegorz Grzybek
 ha scritto:
>
> Congratulations Guillaume! Maven Force be with you!
>
> regards
> Grzegorz Grzybek
>
> śr., 26 maj 2021 o 09:44 Arnaud Héritier  napisał(a):
>
> > Welcome Guillaume !!
> > Happy to see you here.
> >
> > Cheers
> >
> > On Tue, May 25, 2021 at 7:19 PM Robert Scholte 
> > wrote:
> >
> > > Hi,
> > >
> > > On behalf of the Apache Maven PMC I am pleased to announce that
> > > Guillaume Nodet has been voted in as new Apache Maven committer
> > > and he has accepted this invitation.
> > >
> > > Welcome on board and have a lot of fun!
> > >
> > > Thanks,
> > > Robert Scholte
> > >
> >
> >
> > --
> > Arnaud Héritier
> > Twitter/Skype : aheritier
> >

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

Re: [RESULT] [VOTE] Release Apache Maven Javadoc Plugin version 3.3.0

[Enrico Olivelli]

(too late)
+1
run tests on MacOs, JDK 1.8.0

Enrico

Il giorno sab 22 mag 2021 alle ore 11:52 Robert Scholte
 ha scritto:
>
> Hi,
>
> The vote has passed with the following result:
>
> +1 : Robert Scholte, Hervé BOUTEMY, Frederik Boster, Arnaud Héritier, Michael 
> Osipov
>
> PMC quorum: reached
>
> I will promote the artifacts to the central repo.
>
> On 18-5-2021 20:43:37, Robert Scholte  wrote:
> Hi,
>
> We solved 28 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12346637=Text
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317529%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1649
> https://repository.apache.org/content/repositories/maven-1649/org/apache/maven/plugins/maven-javadoc-plugin/3.3.0/maven-javadoc-plugin-3.3.0-source-release.zip
>
> Source release checksum(s):
> maven-javadoc-plugin-3.3.0-source-release.zip sha512: 
> 780e485ea5bb05a074089f243f6442ad43d9627e7a3805e5985dbda67751fcf140504e48b1e74596dc10d187cb6bb3d9a153f74dda3b733e2d8d3a42062d4794
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-javadoc-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1

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

Re: [surefire] Invert trimStackTrace default

[Enrico Olivelli]

Il giorno lun 17 mag 2021 alle ore 13:15 Romain Manni-Bucau
 ha scritto:
>
> Up,
>
> any hope we get this finally fixed (disabled)?
> This is pretty bothering to have to configure it in all projects because
> default always swallow what is interesting when a test failure occurs.

I am still +1

if the tests on CI pass I suggest to merge the patch

Enrico

>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le mar. 9 juin 2020 à 08:31, Romain Manni-Bucau  a
> écrit :
>
> > Pushed https://issues.apache.org/jira/browse/SUREFIRE-1798
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github
> >  | LinkedIn
> >  | Book
> > 
> >
> >
> > Le mer. 3 juin 2020 à 11:36, Olivier Lamy  a écrit :
> >
> >> definitely +1
> >>
> >> On Wed, 3 Jun 2020 at 18:08, Romain Manni-Bucau 
> >> wrote:
> >>
> >> > Hi everyone,
> >> >
> >> > Shouldn't we set trimStackTrace=false by default?
> >> > Current state makes the log quite useless since there is never the data
> >> you
> >> > need to understand why it failed so it just mess up the output without
> >> > added value IMO.
> >> >
> >> > Wdyt?
> >> >
> >> > Romain Manni-Bucau
> >> > @rmannibucau  |  Blog
> >> >  | Old Blog
> >> >  | Github <
> >> > https://github.com/rmannibucau> |
> >> > LinkedIn  | Book
> >> > <
> >> >
> >> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >> > >
> >> >
> >>
> >>
> >> --
> >> Olivier Lamy
> >> http://twitter.com/olamy | http://linkedin.com/in/olamy
> >>
> >

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

Re: [VOTE] Release Apache Maven GPG Plugin version 3.0.1

[Enrico Olivelli]

+1
built and run ITs on MacOs + jdk8

Enrico

Il giorno gio 6 mag 2021 alle ore 10:58 Karl Heinz Marbaise
 ha scritto:
>
> Hi,
>
> +1 from me.
>
> Kind regards
> Karl Heinz Marbaise
> On 05.05.21 18:46, Hervé BOUTEMY wrote:
> > Hi,
> >
> > We solved 5 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521=12348086=Text
> >
> > in addition to the cancelled 3.0.0 release candidate that solved 13 other 
> > issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317521=12330781=Text
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1645/
> > https://repository.apache.org/content/repositories/maven-1645/org/apache/maven/plugins/maven-gpg-plugin/3.0.1/maven-gpg-plugin-3.0.1-source-release.zip
> >
> > Source release checksum(s):
> > maven-gpg-plugin-3.0.1-source-release.zip sha512: 
> > 10eef9c1f3e71724b328e0f8d76303d251922a4e7a05ffbbe44191e2293c097e976b0f6b7ec3b8783b04da13c74bbe5b34f4dabc5e0dd3a7cb5fe7aa92122af0
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: Cutting a release for Surefire?

[Enrico Olivelli]

Tibor

Il Sab 3 Apr 2021, 12:32 Tibor Digana  ha scritto:

> It is only a milestone version which means a work in progress. The fixes
> made so far are really minor, no need to make any release.
>

Got it thanks.

Latest release 3.0.0-M5 has some weird behaviour that makes it impossible
to upgrade from 3.0.0-M4 but I saw that current master works well.

I am sorry I don't have time to contribute code patches to surefire during
this period (no need to explain) but I am actively following the project
and I see that all of the patches that went in since 3.0.0-M5 only enhance
surefire and did not introduce instability.

I can help with bureaucratic stuff and I can take care of ensuring that
what we release to the public is in good shape with responsibility.

That said, upgrading to 3.0.0M5 is not important to me.

I can wait.

Thanks for sharing your opinion

Cheers
Enrico


If you take a look at the road map, you will see that I do not need to fix
> tiny issues, I need to rework the additional attributes which will transfer
> events about tests. There are testId and RunOrder. Without them the BIGGER
> fixes, than the ones you are aiming for, would not be possible, e.g. better
> xml marshaller, logs from parallel tests and re-run which is currently
> unstable due to it relies on the order of test run. The next thing which
> seems to be easier and also necessary is the execution of UUID and Script
> which is needed by Cucumber and junit5.
> The sad thing is that mostly common users participate and they become
> committers. Our official committers do not. So Enrico, pls participate in
> coding because many of us like performing releases but there are only few
> hard workers. Making a release is easy but taking the responsibility for
> the binaries in the world is much harder. So, pls participate in
> Stackoverflow like Karl does and me, participate in coding and then we can
> talk about taking a benefit from a release.
>
> Yeah, one more very important thing. We introduced TCP connector for making
> the above plan possible. The user found that the TCP feature hangs somehow,
> see https://issues.apache.org/jira/browse/SUREFIRE-1881. It took me
> several
> months to understand the rootcase. It has nothing to do with TCP itself,
> nothing but process pipes which are full of bytes before the tcp makes
> handshaking. Releasing the work in the middle and unstable is silly. You
> know when I found the root cause? It was at 1:30 early in the morning.
> Again pls come to work and spend less time in discussions, let;s work in
> PRs on GitHub and we will have a chance to make releases earlier.
> I am sorry that I am a bad guy, but I asked Enrico several times to work in
> this OSS as well. I know Enrico that you participate in another OSSes too
> but you have to decide, since the day has only 24 hours, how much you will
> do and what you will do, but sorry making a release without working on it
> is not adequate.
>
> T
>
> On Sat, Apr 3, 2021 at 11:08 AM Enrico Olivelli 
> wrote:
>
> > What about cutting a release for Surefire plugin?
> > We already fixed important problems that are on 3.0.0-M5 and I saw that
> > current master branch works well.
> >
> > Thoughts?
> > Volunteers?
> >
> > Enrico
> >
>

Cutting a release for Surefire?

[Enrico Olivelli]

What about cutting a release for Surefire plugin?
We already fixed important problems that are on 3.0.0-M5 and I saw that
current master branch works well.

Thoughts?
Volunteers?

Enrico

Re: [VOTE] Release Apache Maven version 3.8.1

[Enrico Olivelli]

+1 (non binding)
I have tested the staged binaries againsts a few projects

I have observed these logs, IIUC this is expected.

[INFO] Reading assembly descriptor: assembly.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/joda-time/joda-time/maven-metadata.xml
[WARNING] Could not transfer metadata
joda-time:joda-time/maven-metadata.xml from/to
maven-default-http-blocker (http://0.0.0.0/): transfer failed for
http://0.0.0.0/joda-time/joda-time/maven-metadata.xml

Enrico


Il giorno mer 31 mar 2021 alle ore 08:46 Maarten Mulders
 ha scritto:
>
> Retried the test that I did on 3.8.0, this time I observe the desired /
> correct behaviour.
>
>
> +1
>
>
> Maarten
>
>
> On March 31, 2021, at 01:46, Mark Derricutt wrote:
> > +1 non-binding
> >
> > - bistro zips are in the /dev/ tree
> > - my multi-repo osgi maven tiles weirdo build works fine.
> >
> >
> >
> >
> > From: Robert Scholte  
> > Reply: Maven Developers List  
> > Date: 31 March 2021 at 9:58:56 AM
> > To: dev@maven.apache.org  
> > Subject:  [VOTE] Release Apache Maven version 3.8.1
> >
> > Hi,
> >
> > For the details about this release, please read
> > https://maven.apache.org/docs/3.8.1/release-notes.html
> > Also please provide feedback on the release notes. (as you know, these are
> > published separately from the release, so it doesn't have to block the
> > release itself)
> >
> > We solved 6 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350032=Text
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1634/
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.zip
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/source/apache-maven-3.8.1-src.zip
> >
> > Source release checksum(s):
> > apache-maven-3.8.1-bin.zip sha512:
> > c585847bfbcf8647aeabfd3e8bf0ac3f67a037bd345545e274766f144c2b978b3457cbc3e31545e62c21ad69e732695de01ec96ea2580e5da67bd85df095c0f4
> >
> > apache-maven-3.8.1-src.zip
> > sha512: 
> > 893988635349985074c88ce5ef27ac5ccb62fcdf58846209eee8a7ea5515238288b91c202347ca42e201ab336c14d83f3f5fd8194070e57b9366bcce2414614d
> >
> >
> > Knows issues:
> > When building with the sources with JDK-16 and above, the unittest
> > MavenCliTest#testStyleColors will fail. This will be fix with MNG-7127[1],
> > but is left out to keep focus on the real purpose of this release.
> >
> > Staging site:
> > https://maven.apache.org/ref/3-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > ---
> > [1] https://issues.apache.org/jira/browse/MNG-7127
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: [VOTE] Release Apache Maven version 3.8.0

[Enrico Olivelli]

The problem is that Robert uploaded the binaries to the "dist/release" directory

this is to be done only after the vote completes

IIRC we have dist/dev for staging releasing

Enrico

Il giorno ven 26 mar 2021 alle ore 08:17 Maxim Solodovnik
 ha scritto:
>
> Hello,
>
> Moving might not do what is expected
> the binaries are already in 
> http://archive.apache.org/dist/maven/maven-3/3.8.0/
>
> On Fri, 26 Mar 2021 at 11:25, Olivier Lamy  wrote:
> >
> > Yes you're right that shouldn't be there as this has been mirrored in all
> > Apache mirrors as a real release...
> >
> > The procedure
> > http://maven.apache.org/developers/release/maven-core-release.html says:
> > "
> >
> > For non-alpha/beta releases, release candidates are produced before the
> > actual release.
> >
> > Checkout https://dist.apache.org/repos/dist/dev/maven/maven-3 then create
> > the necessary directory tree.
> >
> > "
> >
> > @Robert I moved the binaries. As the vote is not finished they shouldn;t be
> > in the official Apache release download area
> >
> > svn mv https://dist.apache.org/repos/dist/release/maven/maven-3/3.8.0
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/
> >
> > Committing transaction...
> >
> > Committed revision 46741.
> >
> > On Fri, 26 Mar 2021 at 13:18, Mark Derricutt  wrote:
> >
> > > I notice in the vote email we have mentioned:
> > >
> > >
> > > dist.apache.org/repos/dist/release/maven/maven–3/3.8.0/binaries/apache-maven–3.8.0-bin.zip
> > > 
> > > <
> > > http://dist.apache.org/repos/dist/release/maven/maven%E2%80%933/3.8.0/binaries/apache-maven%E2%80%933.8.0-bin.zip
> > > >
> > >
> > > which doesn’t really highlight anywhere that this is a staging/unreleased
> > > version.
> > >
> > > Tho changing that probably won’t change too much here.
> > >
> > > *ponders*
> > >
> > >
> > >
> > >
> > > From: Gary Gregory  
> > > Reply: Maven Developers List  
> > > Date: 26 March 2021 at 2:13:05 PM
> > > To: Maven Developers List  
> > > Subject:  Re: [VOTE] Release Apache Maven version 3.8.0
> > >
> > > It's pretty clear to me that the Maven release process is broken when
> > > people are getting new versions they think are real and valid when in fact
> > > it is a release candidate vote in in progress. Gary
> > >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>
> --
> Best regards,
> Maxim
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: [VOTE] Release Maven Resolver version 1.6.2

[Enrico Olivelli]

+1 (non binding)
- run tests on jdk11
- I have followed the discussions about the patches

Enrico

side note:
I am not able to build on JDK15
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce
(enforce-minimum-java-version) on project maven-resolver: Execution
enforce-minimum-java-version of goal
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce failed:
An API incompatibility was encountered while executing
org.apache.maven.plugins:maven-enforcer-plugin:1.4.1:enforce:
java.lang.ExceptionInInitializerError: null
[ERROR] -
[ERROR] realm =plugin>org.apache.maven.plugins:maven-enforcer-plugin:1.4.1
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/home/eolivelli/.m2/repository/org/apache/maven/plugins/maven-enforcer-plugin/1.4.1/maven-enforcer-plugin-1.4.1.jar
[ERROR] urls[1] =
file:/home/eolivelli/.m2/repository/org/codehaus/mojo/extra-enforcer-rules/1.2/extra-enforcer-rules-1.2.jar

Il giorno lun 15 mar 2021 alle ore 23:53 Michael Osipov
 ha scritto:
>
> Hi,
>
> We solved 2 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=1235
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MRESOLVER/issues?filter=allopenissues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1632/
> https://repository.apache.org/content/repositories/maven-1632/org/apache/maven/resolver/maven-resolver/1.6.2/maven-resolver-1.6.2-source-release.zip
>
> Source release checksum(s):
> maven-resolver-1.6.2-source-release.zip
> 521529465c4cc29390aa125e8b5495cc1e26e54eefb11298beb4c15aa5b1fef43e965171eb45933a95478d387dff3e37c978168c2bc5c08c9863140624a2
>
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: [VOTE] Release Maven Wagon version 3.4.3

[Enrico Olivelli]

+1 (non binding)
build and run tests on MacOs, OpenJDK8 and OpenJDK11

Thanks for driving the release Michael

Enrico

Il giorno gio 18 feb 2021 alle ore 23:32 Michael Osipov 
ha scritto:

> Hi,
>
> We solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122=12349719
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1630/
>
> https://repository.apache.org/content/repositories/maven-1630/org/apache/maven/wagon/wagon/3.4.3/wagon-3.4.3-source-release.zip
>
> Source release checksum(s):
> wagon-3.4.3-source-release.zip
> sha512:
>
> 377ad8690bab1a6698cbc45ab6c2c7fc09d36851ff6df8543857da8cee06d50e4daa73dda0b8daed9c46acd835b324245ca1dce67c1c7957cd75808f819938de
>
> Staging site:
> https://maven.apache.org/wagon-archives/wagon-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Releasing Wagon

[Enrico Olivelli]

Hello,
there are issues on GitHub Actions that could be mitigated/fixed with a new
release of Wagon Wheel.

There is only this fix, about upgrading Http Client dependencies
https://issues.apache.org/jira/projects/WAGON/versions/12349719

The problem is described here
https://github.com/apache/maven-wagon/pull/76

The problem is

   - fix for https://issues.apache.org/jira/browse/HTTPCORE-634
   which is causing artifact download failures with error messages such as
   "Could not transfer artifact groupId:artifact:1.2.3 from/to central (
   https://repo1.maven.org/maven2): Entry
   [id:1280][route:{s}->https://repo1.maven.org:443][state:null] has not
   been leased from this pool"


I know that it is not so much stuff for a release, but we will help users
on GitHub Actions (and many Apache projects that are migrating to GH
Actions)

I can make the release, but before starting the process I would like to see
the opinion for the community ?

It would be great to have a Maven Core release as well after releasing
Wagon (otherwise upgrading Wagon will be nasty), but this out of the scope
of this thread

Shall I proceed with the release ?

Enrico

Re: [VOTE] Release Apache Maven Checkstyle Plugin version 3.1.2

[Enrico Olivelli]

+1


Enrico

Il giorno mer 27 gen 2021 alle ore 00:51 Hervé BOUTEMY <
herve.bout...@free.fr> ha scritto:

> +1
>
> checked that the build is reproducible, built with JDK 11 on Windows
>
> Regards,
>
> Hervé
>
> Le dimanche 24 janvier 2021, 00:02:19 CET Sylwester Lachiewicz a écrit :
> > Hi,
> >
> > We solved 5 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223
> > rsion=12347024=Text
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MCHECKSTYLE%20AND
> >
> %20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated
> > %20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1624/
> >
> https://repository.apache.org/content/repositories/maven-1624/org/apache/mav
> >
> en/plugins/maven-checkstyle-plugin/3.1.2/maven-checkstyle-plugin-3.1.2-sourc
> > e-release.zip
> >
> > Source release checksum(s):
> > maven-checkstyle-plugin-3.1.2-source-release.zip sha512:
> >
> 4d90277a306390ec5a6434e01631295654fc4c45c1a4a0b5fae6c7c000a40e8357667fa943d0
> > 5ddb55d1d742eae7628f371e4aba637941c538791bdd9ef39d08
> >
> > Staging site:
> >
> https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven issue with JDK16 - javac and javadoc

[Enrico Olivelli]

I am testing latest build of openjdk16,
it seems to me that the problem has been resolved

Benjamin,
can you please try ?

probably there is no need for a fix on Maven

Enrico

Il giorno lun 14 dic 2020 alle ore 22:12 Benjamin Marwell <
bmarw...@apache.org> ha scritto:

> > I'm pretty sure this can be solved without touching the maven startup
> scripts.
> > And I don't like the idea to hack the script
>
> Agreed. I did not like the idea either, and even worse, I was unable to
> reproduce the results I had.
>
>
>
> Am Mo., 14. Dez. 2020 um 21:58 Uhr schrieb Robert Scholte <
> rfscho...@apache.org>:
>
> > I'm pretty sure this can be solved without touching the maven startup
> > scripts.
> > And I don't like the idea to hack the script because one plugin has
> issues.
> > I expect good help on your question on the jigsaw mailinglist.
> >
> > Robert
> > On 14-12-2020 15:21:04, Benjamin Marwell  wrote:
> > I was able to provide a test, but the only solution to the underlying I
> > found was to modify the mvn start script by adding the missing modules
> (or
> > maybe even better: all system modules).
> >
> > From what I could see from slack, plexus compiler would need to be a
> > module, requiring jdk.javadoc.
> >
> > Thus, we could solve it in a maven release 3.6.4 if you wished, or the
> next
> > compiler plugin as soon as the next plexus javac dependency is available.
> >
> > I wouldn't mind a 3.6.4 release and cherry picking the change to 4.0.0,
> as
> > that would be a quick solution.
> >
> >
> > On Sun, 13 Dec 2020, 17:12 Benjamin Marwell, wrote:
> >
> > > JIRA issue (please kindly review):
> > > https://issues.apache.org/jira/browse/MCOMPILER-445
> > >
> > >
> > > Am So., 13. Dez. 2020 um 14:07 Uhr schrieb Benjamin Marwell <
> > > bmarw...@apache.org>:
> > >
> > >> > If is has proven itself for jlink, then we know we can do the same
> for
> > >> all other tools.
> > >>
> > >> I tested my PR with a JavaFX app and it did work. But there's no
> release
> > >> yet, only the ITs and my test project. But adding a parameter to
> disable
> > >> the ToolProvider as a fallback should not be a problem.
> > >>
> > >> A test case should be ready by tomorrow morning, but I cannot make any
> > >> promises about the implementation, as I work on it only in my free
> time.
> > >> Possibly, there is quite a bit of code to refactor as we want to have
> as
> > >> few code duplication as possible.
> > >>
> > >> Please do ourselves a favour and vote for all MultiRelease (MR) issues
> > at
> > >> jetbrains. They currently do not support MR projects, and it is a PIT*
> > to
> > >> develop for MR jars (from an IDE perspective). Thanks. 
> > >>
> > >> Ben
> > >>
> > >>
> > >>
> > >> On Sun, 13 Dec 2020, 13:38 Robert Scholte, wrote:
> > >>
> > >>> Yes, that makes a lot of sense. If is has proven itself for jlink,
> then
> > >>> we know we can do the same for all other tools.
> > >>> If we have a good feeling about the implementation, we could use it
> at
> > >>> reference for other plugins as some kind of pattern.
> > >>>
> > >>> Robert
> > >>> On 13-12-2020 11:39:02, Benjamin Marwell wrote:
> > >>> Robert already suggested to use ToolProvider for the JDK9+ builds. I
> > >>> created such a patch for jlink and I could create s similar one for
> the
> > >>> compiler and javadoc plugin. This would solve the underlying problem
> > from
> > >>> my understanding.
> > >>>
> > >>> As fork mode and fork count would not apply, I would suggest that the
> > >>> ToolProvider is only used if fork mode is "no fork". This way,
> existing
> > >>> configurations are not affected. Does that make sense?
> > >>>
> > >>> Best regards,
> > >>> Ben
> > >>>
> > >>>
> > >>> On Sat, 12 Dec 2020, 20:49 Enrico Olivelli, wrote:
> > >>>
> > >>> > Is anyone interested in helping with this problem?
> > >>> >
> > >>> > Otherwise with the advent of jdk16 we will probably see people that
> > >>> need to
> > >>> > switch to fork mode for javac, with slower builds, and 

Re: Maven issue with JDK16 - javac and javadoc

[Enrico Olivelli]

Il giorno lun 14 dic 2020 alle ore 15:21 Benjamin Marwell <
bmarw...@apache.org> ha scritto:

> I was able to provide a test, but the only solution to the underlying I
> found was to modify the mvn start script by adding the missing modules (or
> maybe even better: all system modules).
>

I tried with .mvn/jvm.config
but it does not work
https://maven.apache.org/configure.html

what does your change look like ?

Enrico


> From what I could see from slack, plexus compiler would need to be a
> module, requiring jdk.javadoc.
>
> Thus, we could solve it in a maven release 3.6.4 if you wished, or the next
> compiler plugin as soon as the next plexus javac dependency is available.
>
> I wouldn't mind a 3.6.4 release and cherry picking the change to 4.0.0, as
> that would be a quick solution.
>
>
> On Sun, 13 Dec 2020, 17:12 Benjamin Marwell,  wrote:
>
> > JIRA issue (please kindly review):
> > https://issues.apache.org/jira/browse/MCOMPILER-445
> >
> >
> > Am So., 13. Dez. 2020 um 14:07 Uhr schrieb Benjamin Marwell <
> > bmarw...@apache.org>:
> >
> >> > If is has proven itself for jlink, then we know we can do the same for
> >> all other tools.
> >>
> >> I tested my PR with a JavaFX app and it did work. But there's no release
> >> yet, only the ITs and my test project. But adding a parameter to disable
> >> the ToolProvider as a fallback should not be a problem.
> >>
> >> A test case should be ready by tomorrow morning, but I cannot make any
> >> promises about the implementation, as I work on it only in my free time.
> >> Possibly, there is quite a bit of code to refactor as we want to have as
> >> few code duplication as possible.
> >>
> >> Please do ourselves a favour and vote for all MultiRelease (MR) issues
> at
> >> jetbrains. They currently do not support MR projects, and it is a PIT*
> to
> >> develop for MR jars (from an IDE perspective). Thanks. 
> >>
> >> Ben
> >>
> >>
> >>
> >> On Sun, 13 Dec 2020, 13:38 Robert Scholte, 
> wrote:
> >>
> >>> Yes, that makes a lot of sense. If is has proven itself for jlink, then
> >>> we know we can do the same for all other tools.
> >>> If we have a good feeling about the implementation, we could use it at
> >>> reference for other plugins as some kind of pattern.
> >>>
> >>> Robert
> >>> On 13-12-2020 11:39:02, Benjamin Marwell  wrote:
> >>> Robert already suggested to use ToolProvider for the JDK9+ builds. I
> >>> created such a patch for jlink and I could create s similar one for the
> >>> compiler and javadoc plugin. This would solve the underlying problem
> from
> >>> my understanding.
> >>>
> >>> As fork mode and fork count would not apply, I would suggest that the
> >>> ToolProvider is only used if fork mode is "no fork". This way, existing
> >>> configurations are not affected. Does that make sense?
> >>>
> >>> Best regards,
> >>> Ben
> >>>
> >>>
> >>> On Sat, 12 Dec 2020, 20:49 Enrico Olivelli, wrote:
> >>>
> >>> > Is anyone interested in helping with this problem?
> >>> >
> >>> > Otherwise with the advent of jdk16 we will probably see people that
> >>> need to
> >>> > switch to fork mode for javac, with slower builds, and we will see
> >>> > complaints from users
> >>> >
> >>> > The problem probably is is plexus compiler and the way we start
> javac,
> >>> we
> >>> > should enable jdk.javadoc module
> >>> >
> >>> > Unfortunately I don't have time
> >>> >
> >>> > Enrico
> >>> >
> >>> > Il Gio 12 Nov 2020, 13:59 Enrico Olivelli ha
> >>> > scritto:
> >>> >
> >>> > > Yes, the problem is about javac with "no-fork + -Xdoclint"
> >>> > >
> >>> > > using no-fork is not a good option because it slows down a lot big
> >>> multi
> >>> > > module projects
> >>> > >
> >>> > > Enrico
> >>> > >
> >>> > > Il giorno gio 12 nov 2020 alle ore 13:55 Romain Manni-Bucau
> >>> > > rmannibu...@gmail.com> ha scritto:
> >>> > >
> >>> > >> @Graham I guess you can force the compiler to fork and force
> >>> do

Re: Maven issue with JDK16 - javac and javadoc

[Enrico Olivelli]

Il Dom 13 Dic 2020, 11:38 Benjamin Marwell  ha scritto:

> Robert already suggested to use ToolProvider for the JDK9+ builds. I
> created such a patch for jlink and I could create s similar one for the
> compiler and javadoc plugin. This would solve the underlying problem from
> my understanding.
>

Makes sense to me.

Btw the problem here is only with javac, not javadoc.
The problem is that javac doesn't see jdk.javadoc module while running
inside Maven process.
This module is needed when using-Xdoclint that depends on javadoc

Thanks
Please ping me when you have a patch I will be happy to test it

Enrico


> As fork mode and fork count would not apply, I would suggest that the
> ToolProvider is only used if fork mode is "no fork". This way, existing
> configurations are not affected. Does that make sense?
>
> Best regards,
> Ben
>
>
> On Sat, 12 Dec 2020, 20:49 Enrico Olivelli,  wrote:
>
> > Is anyone interested in helping with this problem?
> >
> > Otherwise with the advent of jdk16 we will probably see people that need
> to
> > switch to fork mode for javac, with slower builds, and we will see
> > complaints from users
> >
> > The problem probably is is plexus compiler and the way we start javac, we
> > should enable jdk.javadoc module
> >
> > Unfortunately I don't have time
> >
> > Enrico
> >
> > Il Gio 12 Nov 2020, 13:59 Enrico Olivelli  ha
> > scritto:
> >
> > > Yes, the problem is about javac with "no-fork + -Xdoclint"
> > >
> > > using no-fork is not a good option because it slows down a lot big
> multi
> > > module projects
> > >
> > > Enrico
> > >
> > > Il giorno gio 12 nov 2020 alle ore 13:55 Romain Manni-Bucau <
> > > rmannibu...@gmail.com> ha scritto:
> > >
> > >> @Graham I guess you can force the compiler to fork and force doclint
> to
> > >> none in javadoc plugin config (ensure to use a recent version).
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > >> <https://rmannibucau.metawerx.net/> | Old Blog
> > >> <http://rmannibucau.wordpress.com> | Github <
> > >> https://github.com/rmannibucau> |
> > >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > >> <
> > >>
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >> >
> > >>
> > >>
> > >> Le jeu. 12 nov. 2020 à 13:51, Graham Leggett  >
> > a
> > >> écrit :
> > >>
> > >> > On 12 Nov 2020, at 14:03, Enrico Olivelli 
> > wrote:
> > >> >
> > >> > > I have fallen into this issue about Maven + Maven Compiler Plugin
> +
> > >> JDK16
> > >> > >
> > >> > > This is the issue on JDK issue tracking
> > >> > > https://bugs.openjdk.java.net/browse/JDK-8253996
> > >> > >
> > >> > > Basically -Xdoclint:missing does not work anymore when you run
> javac
> > >> > inside
> > >> > > the same JVM as Maven core, because the JVM lacks the jdk.javadoc
> > >> module.
> > >> > > If you run javac in "fork" mode the problem is not present because
> > the
> > >> > > external "javac" program loads correctly jdk.javadoc module and is
> > >> able
> > >> > to
> > >> > > execute "-Xdoclint"
> > >> > >
> > >> > > it looks like we have to fix it on Maven, I am not sure the
> problem
> > is
> > >> > > about maven-compiler-plugin or plexus compiler, as it is because
> the
> > >> JVM
> > >> > > that executes Maven core lacks the jdk.javadoc module.
> > >> > >
> > >> > > On the JDK side it looks like the issue is to be closed as "works
> > for
> > >> me"
> > >> > >
> > >> > >
> > >> > > Thoughts?
> > >> >
> > >> > I have been smashing my head against the javadoc plugin and
> > >> > maven-release-plugin, which keeps failing releases over and over
> again
> > >> on
> > >> > the basis that the docs can’t be built.
> > >> >
> > >> > In the absence of a way to fix this, if there is a way to switch
> this
> > >> off
> > >> > it would help a huge amount.
> > >> >
> > >> > Regards,
> > >> > Graham
> > >> > —
> > >> >
> > >> >
> > >> >
> -
> > >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >> > For additional commands, e-mail: dev-h...@maven.apache.org
> > >> >
> > >> >
> > >>
> > >
>

Re: Maven issue with JDK16 - javac and javadoc

[Enrico Olivelli]

Is anyone interested in helping with this problem?

Otherwise with the advent of jdk16 we will probably see people that need to
switch to fork mode for javac, with slower builds, and we will see
complaints from users

The problem probably is is plexus compiler and the way we start javac, we
should enable jdk.javadoc module

Unfortunately I don't have time

Enrico

Il Gio 12 Nov 2020, 13:59 Enrico Olivelli  ha scritto:

> Yes, the problem is about javac with "no-fork + -Xdoclint"
>
> using no-fork is not a good option because it slows down a lot big multi
> module projects
>
> Enrico
>
> Il giorno gio 12 nov 2020 alle ore 13:55 Romain Manni-Bucau <
> rmannibu...@gmail.com> ha scritto:
>
>> @Graham I guess you can force the compiler to fork and force doclint to
>> none in javadoc plugin config (ensure to use a recent version).
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> >
>>
>>
>> Le jeu. 12 nov. 2020 à 13:51, Graham Leggett  a
>> écrit :
>>
>> > On 12 Nov 2020, at 14:03, Enrico Olivelli  wrote:
>> >
>> > > I have fallen into this issue about Maven + Maven Compiler Plugin +
>> JDK16
>> > >
>> > > This is the issue on JDK issue tracking
>> > > https://bugs.openjdk.java.net/browse/JDK-8253996
>> > >
>> > > Basically -Xdoclint:missing does not work anymore when you run javac
>> > inside
>> > > the same JVM as Maven core, because the JVM lacks the jdk.javadoc
>> module.
>> > > If you run javac in "fork" mode the problem is not present because the
>> > > external "javac" program loads correctly jdk.javadoc module and is
>> able
>> > to
>> > > execute "-Xdoclint"
>> > >
>> > > it looks like we have to fix it on Maven, I am not sure the problem is
>> > > about maven-compiler-plugin or plexus compiler, as it is because the
>> JVM
>> > > that executes Maven core lacks the jdk.javadoc module.
>> > >
>> > > On the JDK side it looks like the issue is to be closed as "works for
>> me"
>> > >
>> > >
>> > > Thoughts?
>> >
>> > I have been smashing my head against the javadoc plugin and
>> > maven-release-plugin, which keeps failing releases over and over again
>> on
>> > the basis that the docs can’t be built.
>> >
>> > In the absence of a way to fix this, if there is a way to switch this
>> off
>> > it would help a huge amount.
>> >
>> > Regards,
>> > Graham
>> > —
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>> >
>>
>

Re: [MARCHETYPES-70] New release for maven archetypes

[Enrico Olivelli]

If no one objects I can try to create a release.
But I don't have time to add other commits, just to run the release
procedure.

Does it sound as a good plan?

Enrico

Il Gio 3 Dic 2020, 20:30 Jurrian Fahner  ha
scritto:

> Hi all,
>
> Please notice my gentle ping...
> It has been a while I send an email and I didn't got a response.
>
> Is there a way I can help to release the maven archetypes?
>
> Kind regards,
>
> Jurrian Fahner
>
> Op wo 18 nov. 2020 om 19:53 schreef Jurrian Fahner <
> jurrian.fah...@gmail.com>:
>
>> Hi,
>>
>> Recently I've worked on improving the quick start archetype in maven
>> archetypes.
>>
>> Since the build was successful
>> ,
>> the branch has been merged
>> .
>>
>> Since Enrico doesn't have the time now to create a release, I was
>> wondering whether there is somebody who can do it for us.
>>
>> Who can help us out with this?
>>
>> Kind regards,
>>
>> Jurrian Fahner
>>
>>

Re: Javac server?

[Enrico Olivelli]

Robert,

Il Lun 16 Nov 2020, 20:13 Robert Scholte  ha scritto:

> It is still on my wishlist to make use of javac via the ToolProvider, just
> like now is done with jlink.[1]
>

This approach would also probably fix the issue with JDK16 and -Xdoclink
that I pointed out recently

Enrico

But this one might be interesting too.
>
> Robert
>
> [1] https://github.com/apache/maven-jlink-plugin/pull/16
>
> On 15-11-2020 22:24:21, Enrico Olivelli  wrote:
> Hey folks,
> I had never heard about this javac server before
> https://openjdk.java.net/jeps/139
>
>
> Is there any way we can exploit it in order to speed up the build?
> Is it enough to execute javac tool inside the same JVM of Maven core to get
> the same results?
>
> Do anyone have experience with it?
>
> Enrico
>

Javac server?

[Enrico Olivelli]

Hey folks,
I had never heard about this javac server before
https://openjdk.java.net/jeps/139


Is there any way we can exploit it in order to speed up the build?
Is it enough to execute javac tool inside the same JVM of Maven core to get
the same results?

Do anyone have experience with it?

Enrico

Re: Maven issue with JDK16 - javac and javadoc

[Enrico Olivelli]

Yes, the problem is about javac with "no-fork + -Xdoclint"

using no-fork is not a good option because it slows down a lot big multi
module projects

Enrico

Il giorno gio 12 nov 2020 alle ore 13:55 Romain Manni-Bucau <
rmannibu...@gmail.com> ha scritto:

> @Graham I guess you can force the compiler to fork and force doclint to
> none in javadoc plugin config (ensure to use a recent version).
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le jeu. 12 nov. 2020 à 13:51, Graham Leggett  a
> écrit :
>
> > On 12 Nov 2020, at 14:03, Enrico Olivelli  wrote:
> >
> > > I have fallen into this issue about Maven + Maven Compiler Plugin +
> JDK16
> > >
> > > This is the issue on JDK issue tracking
> > > https://bugs.openjdk.java.net/browse/JDK-8253996
> > >
> > > Basically -Xdoclint:missing does not work anymore when you run javac
> > inside
> > > the same JVM as Maven core, because the JVM lacks the jdk.javadoc
> module.
> > > If you run javac in "fork" mode the problem is not present because the
> > > external "javac" program loads correctly jdk.javadoc module and is able
> > to
> > > execute "-Xdoclint"
> > >
> > > it looks like we have to fix it on Maven, I am not sure the problem is
> > > about maven-compiler-plugin or plexus compiler, as it is because the
> JVM
> > > that executes Maven core lacks the jdk.javadoc module.
> > >
> > > On the JDK side it looks like the issue is to be closed as "works for
> me"
> > >
> > >
> > > Thoughts?
> >
> > I have been smashing my head against the javadoc plugin and
> > maven-release-plugin, which keeps failing releases over and over again on
> > the basis that the docs can’t be built.
> >
> > In the absence of a way to fix this, if there is a way to switch this off
> > it would help a huge amount.
> >
> > Regards,
> > Graham
> > —
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Maven issue with JDK16 - javac and javadoc

[Enrico Olivelli]

Hi folks,
I have fallen into this issue about Maven + Maven Compiler Plugin + JDK16

This is the issue on JDK issue tracking
https://bugs.openjdk.java.net/browse/JDK-8253996

Basically -Xdoclint:missing does not work anymore when you run javac inside
the same JVM as Maven core, because the JVM lacks the jdk.javadoc module.
If you run javac in "fork" mode the problem is not present because the
external "javac" program loads correctly jdk.javadoc module and is able to
execute "-Xdoclint"

it looks like we have to fix it on Maven, I am not sure the problem is
about maven-compiler-plugin or plexus compiler, as it is because the JVM
that executes Maven core lacks the jdk.javadoc module.

On the JDK side it looks like the issue is to be closed as "works for me"


Thoughts?
Enrico

Surefire, multiple forks and id of the forked process

[Enrico Olivelli]

Hello,
I have recently started to move a few projects to use multiple forks to run
tests in order to speed up the build process. Nothing new.

I find it quite awkward to correlate the line that starts a test and the
line with the results (using -Dmaven.test.redirectTestOutputToFile).

Do you think it would be interesting to add a flag to surefire to print out
some id of the "forked process" in order to correlate visually and also on
CI logs what's happening?

If there is interest in this feature I will be happy to open a JIRA and
implement it

Regards
Enrico

Re: Second review for MNG-6118

[Enrico Olivelli]

I sent my review.

But I don't know very much that part of the codebase.
More expert eyes are needed

Thanks for contributing that useful fix

Enrico

Il Ven 16 Ott 2020, 08:51 Maarten Mulders  ha
scritto:

> Hi all,
>
> May I please remind you of this question? We'd appreciate if anyone
> could spend some time on these changes and provide us with feedback on
> the approach. Robert has already shared his 2 cents but since these
> changes happen in Core, we are still waiting for a second reviewer.
>
> Thanks,
>
> Maarten
>
> On Oct 1st, 2020 at 21:11, Maarten Mulders wrote:
> > Hi all,
> >
> > Over the last month, Martin Kanters and myself have been working to make
> > it possible to execute goals on a specific module while building a
> > multi-module project [1]. The pull request [2] enables resolving
> > inter-module dependencies of the whole multi-module project while
> > building a part of a multi-module project (by using -f or by navigating
> > to a subdirectory).
> >
> > These changes make the following scenarios behave in a consistent way:
> >
> > * mvn -pl module-a
> > * mvn -f module-a/pom.xml
> > * cd module-a && mvn
> >
> > There are also integration tests [3] that demonstrate and verify this
> > behaviour. The changes have run through Jenkins in an earlier stage, and
> > are running again now that I have merged master into our feature branch.
> > Robert has done a first round of review and we would appreciate if
> > somebody else could also take a look at the proposed changes.
> >
> > Thanks,
> >
> > Maarten
> >
> > [1] https://issues.apache.org/jira/browse/MNG-6118
> > [2] https://github.com/apache/maven/pull/373
> > [3] https://github.com/apache/maven-integration-testing/pull/68
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Resolver version 1.6.0

[Enrico Olivelli]

+1
checked checksum and run tests on JDK14 + Mac

 mvn -v

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)

Maven home: xx

Java version: 14, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-14.jdk/Contents/Home

Default locale: it_IT, platform encoding: UTF-8

OS name: "mac os x", version: "10.15.4", arch: "x86_64", family: "mac"

Il giorno lun 14 set 2020 alle ore 08:55 Hervé BOUTEMY <
herve.bout...@free.fr> ha scritto:

> +1
>
> sadly, the build is not reproducible: reference build done with JDK 8 on
> Windows, but Felix Maven Bundle Plugin is causing issues in generated META-
> INF/MANIFEST.MF (contains username, detailed JDK version, and order or
> Private
> Package not reproducible): I'll have a look to check if recent updates to
> this
> plugin can fix the issue...
>
> Regards,
>
> Hervé
>
> Le vendredi 11 septembre 2020, 20:19:56 CEST Michael Osipov a écrit :
> > Hi,
> >
> > We solved 19 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628
> > rsion=12348666
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/projects/MRESOLVER/issues?filter=allopenissue
> > s
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1605/
> >
> https://repository.apache.org/content/repositories/maven-1605/org/apache/mav
> > en/resolver/maven-resolver/1.6.0/maven-resolver-1.6.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-resolver-1.6.0-source-release.zip
> >
> fd419a3f0bbe3c0ea0b3d7b881c4892fcfc73ec6cf812e7ddb724febb8bc010c754d5845498c
> > 6c916a3bbdae2d90dd66787eb44fdbdd27310c745bdc1e8cc15b
> >
> > Staging site:
> > https://maven.apache.org/resolver-archives/resolver-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Note: This Resolver version offers salvation from a 13.5 years old
> > feature request: MNG-2802
> > Yes, you can have now concurrent-safe access to your local Maven
> > repository synchronized with Redis.
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Make Jira issues viewable.

[Enrico Olivelli]

I agree with Bindul

I have never seen such blocks

Enrico

Il Ven 11 Set 2020, 10:38 Bindul Bhowmik  ha
scritto:

> Hi,
>
> If I may chime in, the Maven (and most Apache) JIRA issues don't
> require a login to view. I believe the issue is that Amelia added a
> filter to the URL pasted in the tweet, and the filter requires a
> login.
> So: https://issues.apache.org/jira/browse/MNG-6928 is viewable without
> a login https://issues.apache.org/jira/browse/MNG-6928?filter=-2 is
> not.
>
> Bindul
>
> On Fri, Sep 11, 2020 at 12:54 AM Maarten Mulders 
> wrote:
> >
> > Agreed. If there's anything that is too deliberate to discuss in the
> > open, there's the mailing list, direct email or what not.
> >
> > Maarten
> >
> > On 11/09/2020 09:51, Robert Scholte wrote:
> > > Based on the
> https://twitter.com/ameliaeiras/status/1303815661307613184 and the
> responses of Marten Deinum I agree that it makes sense to make issues
> viewable for all.
> > >
> > > If there is no strong reason to keep it as it is, I'll ask our Jira
> administrator if our scheme can be updated.
> > > (looks like the Maven projects are missing an explicit Issue Security
> scheme)
> > >
> > > thanks,
> > > Robert
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [MCHECKSTYLE] Request for merging PRs #17 and #28 please

[Enrico Olivelli]

working on them now

sorry for so late reply

Enrico

Il giorno lun 17 ago 2020 alle ore 14:20 Benjamin Marwell <
bmarw...@gmail.com> ha scritto:

> Hi,
>
> PRs #17 and #28 seem to be ready to be merged. They are also approved
> by reviewers.
> If they still look good, could they be merged? They are open for a while
> now.
>
> * https://github.com/apache/maven-checkstyle-plugin/pull/17
> * https://github.com/apache/maven-checkstyle-plugin/pull/28
>
> Thanks!
> Ben
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Dependency Analyzer version 1.11.2

[Enrico Olivelli]

+1 (non binding)
build and run tests on Mac + JDK14

Enrico

Il giorno gio 23 lug 2020 alle ore 16:49 Karl Heinz Marbaise <
khmarba...@gmx.de> ha scritto:

> Hi,
>
> +1 from me
>
> Kind regards
> Karl Heinz Marbaise
> On 20.07.20 16:32, Elliotte Rusty Harold wrote:
> > Hi,
> >
> > We solved 2 issues:
> > ** Dependency upgrade
> >  * [MSHARED-868] - Upgrade plexus-component-metadata to 2.1.0
> >  * [MSHARED-870] - Upgrade asm to 8.0.1
> >
> >
> > There are still six issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20maven-dependency-analyzer
> >
> >
> > Staging repo:
> >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.2/
> >
> https://repository.apache.org/content/repositories/maven-staging-group/org/apache/maven/shared/maven-dependency-analyzer/1.11.2/maven-dependency-analyzer-1.11.2-source-release.zip
> >
> > Source release checksum(s):
> > maven-dependency-analyzer-1.11.2-source-release.zip sha512:
> >
> 290335fae258749da8fab43cc6d7557255ad68330abe5573cc6bc87c45c3e9d8982ddcd7c34b8b8d1e06e250a8db82a18173cc74fb889debe2fcbe23742d66b5
> >
> > Staging site:
> >
> https://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Gitbox passwords

[Enrico Olivelli]

You have to use your @apache.org credentials.

If you prefer you can use github auth and push/fetch only to/from github
mirrors.
In this case you have to enable 2FA and use a token

Enrico

Il Gio 16 Lug 2020, 18:02 Gary Gregory  ha scritto:

> I use my regular Apache creds.
>
> Gary
>
> On Thu, Jul 16, 2020, 11:41 Elliotte Rusty Harold 
> wrote:
>
> > Anyone happen to know what username and password I should use for
> > Gitbox? The credentials I use for logging into Jira and other Apache
> > sites don't seem to work for this.
> >
> > $ git push --set-upstream origin gb
> > Username for 'https://gitbox.apache.org': elharo
> > Password for 'https://elh...@gitbox.apache.org':
> > fatal: Authentication failed for
> > 'https://gitbox.apache.org/repos/asf/maven-pmd-plugin.git/'
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Short guide "Working with Github pull requests"

[Enrico Olivelli]

Il Mar 14 Lug 2020, 13:09 Elliotte Rusty Harold  ha
scritto:

> On Tue, Jul 14, 2020 at 2:25 AM Olivier Lamy  wrote:
> >
>
> > ***DO NOT CREATE PULL REQUEST FOR RIDICULOUS COMMIT WHICH DO NOT NEED
> REVIEW***
>
> IMHO all PRs need review for the same reason everything needs a test.
>

I see your pain. Having reviews by fellow committers and from the community
helps a lot.
I felt this way the first times I got write permission to Maven
repositories.

But we have many repositories and those simple pull requests really sound
as noise.

Every commit you push to a shared repository triggers an email and every
other committer (and anyone who is subscribe to the ml) sees your commit
and can chime in in case there is something wrong.

So feel free to commit simple stuff as far as you stay into our conventions
and integration tests pass.
We are all here and see the flow of commits.
Feel free to ask for review, in that case I prefer a PR.

I hope that helps
Enrico


>From experience I know I can't tell the difference between PRs that
> are too simple to fail and PRs that only look that way.
>
> > it's very noisy and useless notifications (especially because we get
> from both gitbox and github)
>
> Not sure why you're seeing all these notifications. I don't see them.
>

Probably because you are the author


However if both gitbox and github are sending notices for the same PR,
> there's a really easy fix. Simply disable one of the two from sending
> any notifications.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Short guide "Working with Github pull requests"

[Enrico Olivelli]

Il Lun 13 Lug 2020, 21:03 Maarten Mulders  ha
scritto:

> So, just to make sure: the sync is two-way?


Yes

What happens on Gitbox is
> synced to Github and vice versa? I thought it was only from Gitbox to
> Github, but never the other way around...
>

No. We should ask infra to know how this magic happens

>
> I do agree that Githubs UI is a bit more sophisticated for dealing with
> merge requests. I vaguely recall an earlier discussion on this list
> about the use of Githubs "Squash and merge" button. I thought the
> outcome of that discussion was that we shouldn't use it, because the
> author in the commit log would show as "Github", or something like that.
>
> So then the conclusion is, we can use Github for accepting & merging
> pull requests, but shouldn't use "Squash & merge"?
>

Yes, do not use the button

Enrico



> Maarten
>
> On July 13th, 2020 at 20:28, Elliotte Rusty Harold wrote:
> > Much work happens directly on Github and syncs the other direction to
> > Gitbox. That workflow is likely more familiar to most developers these
> > days, and the Github UI is significantly advanced beyond Gitbox.
> >
> > On Mon, Jul 13, 2020 at 2:20 PM Maarten Mulders 
> wrote:
> >>
> >> Hi all,
> >>
> >> The other day I was working on a pull request offered through Github. I
> >> couldn't find instructions on how to accept and incorporate it. Based on
> >> my own experiences with submitting patches to Maven through Github I
> >> came up with a short how-to.
> >>
> >> I have written it down in a short guide "Working with Github pull
> >> requests" [1] which I intent to publish on the Apache Maven site, under
> >> "Maven Developer Centre / Committers". I would appreciate if some of you
> >> could take a look and see if the guide makes sense.
> >>
> >> Thanks,
> >>
> >> Maarten
> >>
> >> [1]
> >>
> https://gitbox.apache.org/repos/asf?p=maven-site.git;a=shortlog;h=refs/heads/add-github-pull-request-guide
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Welcome the new Maven committers: Maarten Mulders en Martin Kanters

[Enrico Olivelli]

Welcome aboard!

Enrico

Il Ven 10 Lug 2020, 21:13 Robert Scholte  ha scritto:

> Hi,
>
> On behalf of the Apache Maven PMC I am pleased to announce that
> Maarten Mulders en Martin Kanters has been voted in as new Apache Maven
> committers
> and they've both accepted this invitation.
>
> Welcome on board and have a lot of fun!
>
> Thanks,
> Robert Scholte
>

Re: [VOTE] Release Apache Maven WAR Plugin version 3.3.1

[Enrico Olivelli]

+1 (non binding)
Built and run ITS on Mac + JDK14

Enrico

Il giorno ven 10 lug 2020 alle ore 12:39  ha scritto:

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121=12348374=Text
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1593/
>
> https://repository.apache.org/content/repositories/maven-1593/org/apache/maven/plugins/maven-war-plugin/3.3.1/maven-war-plugin-3.3.1-source-release.zip
>
> Source release checksum(s):
> maven-war-plugin-3.3.1-source-release.zip sha512:
> d59079cc8b8fbc48d624be97806db9f1f9a42945735e57197ee80197275208f591cfc0fe5ed6b0c0576c76ece85a4b5e0b94cf84ab3cf4b69fc278d6cbfecc32
>
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: surefire M6?

[Enrico Olivelli]

Olivier,
If it is only a matter of doing the release I can pack it today or tomorrow
(not Friday).

What's the status of master branch? I mean, are there any other blocker
issues waiting for fix or for review?

Enrico

Il Mer 8 Lug 2020, 01:40 Falko Modler  ha scritto:

> Hi Oliver,
>
> which performance issue do you mean?
>
> I was actually hoping to revive
> https://github.com/apache/maven-surefire/pull/169 for M6 but I haven't
> had time thus far.
>
> Cheers,
>
> Falko
>
> Am 08.07.2020 um 00:38 schrieb Olivier Lamy:
> > Hi,
> > I wonder if there is a plan to release M6 ASAP with the performance issue
> > fixed?
> > TBH M5 is definitely NOT usable but it contains some interesting fixes
> but
> > performance is awful.
> > I'm definitely happy to help.
> > let me know.
> >
> > cheers
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: second MNG-5760

[Enrico Olivelli]

+1 (already approved on github)


Enrico

Il Sab 20 Giu 2020, 12:19 Hervé BOUTEMY  ha scritto:

> +1
> really nice work!
>
> Regards,
>
> Hervé
>
> Le vendredi 19 juin 2020, 11:42:44 CEST Robert Scholte a écrit :
> > I've guided Maarten and Martin with their wok on solving MNG-5760
> > With it you can simply call mvn -r / --resume and it will start from the
> > failing module, respecting multiple failed modules in a multithreaded
> > build.
> >
> > To me these PRs are ready to be merged.
> >
> > thanks,
> > Robert
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M5

[Enrico Olivelli]

+1 (non binding)
- checksums ok
- built locally on Fedora + JDK14, all tests passed (mvn install -Prun-its)
- Tested with a few projects, even with the new TCP implementation

Thank you Tibor for putting this all together



Enrico

Il giorno dom 14 giu 2020 alle ore 23:46 Dan Tran  ha
scritto:

> +1 tested with our 300+ maven modules build
>
> Found the following new 'good' behaviors/fixes
>
>1. Junit 4 test class now have 'public' scope at both class and method
> level.
>2. Exception at test 'setup' ( ie @Before) now show up as failures, They
> are ignored at M4
>
> Great works
>
> Thanks
>
>
>
> On Sat, Jun 13, 2020 at 3:40 PM Tibor Digana 
> wrote:
>
> > Hi Herve,
> >
> > We can fork the discussion about this problem apart in the Slack.
> > Thx for finding this.
> >
> > T
> >
> >
> > On Sat, Jun 13, 2020 at 9:35 PM Hervé BOUTEMY 
> > wrote:
> >
> > > +1
> > >
> > > near full reproducibility of reference artifacts with JDK 8 on Windows:
> > 48
> > > artifacts are ok, just 2 still have issues:
> > > - surefire-3.0.0-M5-source-release.zip: I don't know why my local build
> > > added 3 dependency-reduced-pom.xml that do not exist in reference build
> > > - surefire-shadefire-3.0.0-M5.jar: some strange timestamp issues for
> some
> > > shaded content, probably a subtle maven-shade-plugin bug
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le samedi 13 juin 2020, 15:46:10 CEST Tibor Digana a écrit :
> > > > Hi,
> > > >
> > > > We solved 40 issues:
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927
> > > > rsion=12344612
> > > >
> > > > There are still a couple of issues left in JIRA:
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20
> > > > status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
> > > >
> > > > Staging repo:
> > > > https://repository.apache.org/content/repositories/maven-1590/
> > > >
> > >
> >
> https://repository.apache.org/content/repositories/maven-1590/org/apache/mav
> > > > en/surefire/surefire/3.0.0-M5/surefire-3.0.0-M5-source-release.zip
> > > >
> > > > Source release checksum(s):
> > > > surefire-3.0.0-M5-source-release.zip  sha1:
> > > > 687a89ceb4a1b2e5dd472deec8d3843f2a98b68f
> > > > surefire-3.0.0-M5-source-release.zip  sha512:
> > > >
> > >
> >
> e88ced058923b349acfe1948d4c4a7ff6f4bef08e5685f2f2ac73cfb26ad35fd6578f05309f0
> > > > 91081f01986b19bbca38a2fe6bf0fbd16980cd6f41228c529ee7
> > > >
> > > > Staging site:
> > > > http://maven.apache.org/surefire-archives/surefire-LATEST/
> > > >
> > > > Guide to testing staged releases:
> > > >
> http://maven.apache.org/guides/development/guide-testing-releases.html
> > > >
> > > > Vote open for 72 hours.
> > > >
> > > > [ ] +1
> > > > [ ] +0
> > > > [ ] -1
> > > >
> > > > Cheers
> > > > Tibor
> > >
> > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M5

[Enrico Olivelli]

John
This is the best forum but please start another email thread. This is the
official VOTE thread

Thanks for reporting your finding. It is very precious

Enrico

Il Dom 14 Giu 2020, 21:45 John Patrick  ha scritto:

> What is the best forum to discuss issues or configuration around
> compiler, surefire and jpms?
>
> Most of the issues I have, seam to be resolved with 3.0.0-M5, but;
> - already raising issue with IntelliJ now as they don't support 2
> module-info.java files in the same project, one under src/main/java
> and the other under src/test/java.
> - how can package private methods be tested? as compiler is now seeing
> the new test module-info.java but complaining about package exists in
> main and test module-info.
> - i might be making things more complex as i've using src/main/java
> and src/test/java for java 8 code, and src/main/java11 and
> src/test/java11 for java 11 code base. so creating multi version jars.
> java 8 builds an tests, then java 11 does verify, i then rebuild and
> test fully on java 11.
>
> John
>
>
> On Sat, 13 Jun 2020 at 23:40, Tibor Digana  wrote:
> >
> > Hi Herve,
> >
> > We can fork the discussion about this problem apart in the Slack.
> > Thx for finding this.
> >
> > T
> >
> >
> > On Sat, Jun 13, 2020 at 9:35 PM Hervé BOUTEMY 
> wrote:
> >
> > > +1
> > >
> > > near full reproducibility of reference artifacts with JDK 8 on
> Windows: 48
> > > artifacts are ok, just 2 still have issues:
> > > - surefire-3.0.0-M5-source-release.zip: I don't know why my local build
> > > added 3 dependency-reduced-pom.xml that do not exist in reference build
> > > - surefire-shadefire-3.0.0-M5.jar: some strange timestamp issues for
> some
> > > shaded content, probably a subtle maven-shade-plugin bug
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le samedi 13 juin 2020, 15:46:10 CEST Tibor Digana a écrit :
> > > > Hi,
> > > >
> > > > We solved 40 issues:
> > > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927
> > > > rsion=12344612
> > > >
> > > > There are still a couple of issues left in JIRA:
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20
> > > > status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
> > > >
> > > > Staging repo:
> > > > https://repository.apache.org/content/repositories/maven-1590/
> > > >
> > >
> https://repository.apache.org/content/repositories/maven-1590/org/apache/mav
> > > > en/surefire/surefire/3.0.0-M5/surefire-3.0.0-M5-source-release.zip
> > > >
> > > > Source release checksum(s):
> > > > surefire-3.0.0-M5-source-release.zip  sha1:
> > > > 687a89ceb4a1b2e5dd472deec8d3843f2a98b68f
> > > > surefire-3.0.0-M5-source-release.zip  sha512:
> > > >
> > >
> e88ced058923b349acfe1948d4c4a7ff6f4bef08e5685f2f2ac73cfb26ad35fd6578f05309f0
> > > > 91081f01986b19bbca38a2fe6bf0fbd16980cd6f41228c529ee7
> > > >
> > > > Staging site:
> > > > http://maven.apache.org/surefire-archives/surefire-LATEST/
> > > >
> > > > Guide to testing staged releases:
> > > >
> http://maven.apache.org/guides/development/guide-testing-releases.html
> > > >
> > > > Vote open for 72 hours.
> > > >
> > > > [ ] +1
> > > > [ ] +0
> > > > [ ] -1
> > > >
> > > > Cheers
> > > > Tibor
> > >
> > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Consumer pom and relative disk paths for parent pom

[Enrico Olivelli]

+1 from me (I have also approved on github)

We need more eyes on this patch.

Thanks Robert

Enrico

Il Dom 14 Giu 2020, 13:43 Robert Scholte  ha scritto:

> It looks like the branches[1][2] are ready for review, jenkins[3] is happy
> too.
>
> Robert
>
>
> [1] https://github.com/apache/maven/pull/286
>
> [2] https://github.com/apache/maven-integration-testing/pull/66
>
> [3] https://builds.apache.org/job/maven-box/job/maven/job/MNG-6656/
> On 25-5-2020 22:54:33, Robert Scholte  wrote:
> next on my list
>
> Robert
> On 25-5-2020 17:42:23, Enrico Olivelli  wrote:
> Robert,
> do we have news about this great feature ?
>
> Enrico
>
> Il giorno sab 30 nov 2019 alle ore 14:38 Enrico Olivelli
> eolive...@gmail.com> ha scritto:
>
> > Good news
> >
> > Il giorno sab 30 nov 2019 alle ore 14:27 Robert Scholte
> > rfscho...@apache.org> ha scritto:
> >
> >> Hi Enrico,
> >>
> >> current implementation says groupId+artifact are required, but you can
> >> either specify version or relativePath (or omit it, meaning ../pom.xml)
> >> I've decided to keep G+A so MAven can verify the pom is pointing to the
> >> right parent.
> >> MNG-6656 has a demo attached which shows you the new valid pom
> structure.
> >>
> >>
> > This is the link for reference
> >
> >
> https://github.com/apache/maven/pull/286/files#diff-367b1a6eb386aada5bd28a0aaebe645bR36
> >
> > I am totally ok for keeping G+A, it sounds very sensible to me.
> >
> > Thank you so much, I missed that part of the change, or at least I forgot
> > about it
> >
> > I am really sure I want this new feature in 3.7.0 !
> >
> > It looks like we are adding great stuff to Maven for this new major
> release
> >
> > Enrico
> >
> >
> >> thanks,
> >> Robert
> >>
> >> On 30-11-2019 13:39:12, Enrico Olivelli wrote:
> >> Hi,
> >> when we move to the consumer pom we can leverage the disk layout of
> >> projects inside the same repository while looking for the parent pom.
> >>
> >> Currently you can use the element to refer to the location
> >> of a parent pom, AFAIK this is only an hint for Maven and for tools: you
> >> must always copy all of the coordinates of the parent module because
> when
> >> you publish your pom the consumer must be able to find such parent
> module
> >> from remote repositories, without having the physical layout of the
> source
> >> code.
> >>
> >> With the consumer pom with can let the build pom have only the
> >> relativePath
> >> element and then we will fill the consumer (deployed) pom with the
> >> effective parent coordinates.
> >>
> >> This will simply a lot this part of Maven that is quite annoying for
> users
> >>
> >> Thoughts?
> >> Enrico
> >>
> >
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M5

[Enrico Olivelli]

(I will cast my final vote on Monday)
Tibor
It is worth to note that this release includes the new communication
protocol between Maven and the forked JVM.
Can you please share a bit of help about how to try it?

This is a great release of surefire, it is a big milestone for Maven and
Surefire


Enrico

Il Sab 13 Giu 2020, 20:50 Michael Osipov  ha scritto:

> Am 2020-06-13 um 15:46 schrieb Tibor Digana:
> > Hi,
> >
> > We solved 40 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12344612
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1590/
> >
> https://repository.apache.org/content/repositories/maven-1590/org/apache/maven/surefire/surefire/3.0.0-M5/surefire-3.0.0-M5-source-release.zip
> >
> > Source release checksum(s):
> > surefire-3.0.0-M5-source-release.zip  sha1:
> > 687a89ceb4a1b2e5dd472deec8d3843f2a98b68f
> > surefire-3.0.0-M5-source-release.zip  sha512:
> >
> e88ced058923b349acfe1948d4c4a7ff6f4bef08e5685f2f2ac73cfb26ad35fd6578f05309f091081f01986b19bbca38a2fe6bf0fbd16980cd6f41228c529ee7
> >
> > Staging site:
> > http://maven.apache.org/surefire-archives/surefire-LATEST/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
>
> Massive and impressive!
>
> +1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [surefire] Invert trimStackTrace default

[Enrico Olivelli]

Il giorno mer 3 giu 2020 alle ore 10:08 Romain Manni-Bucau <
rmannibu...@gmail.com> ha scritto:

> Hi everyone,
>
> Shouldn't we set trimStackTrace=false by default?
>

+1
It is very awkward current default (trimStackTrace=true)

Enrico


> Current state makes the log quite useless since there is never the data you
> need to understand why it failed so it just mess up the output without
> added value IMO.
>
> Wdyt?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>

Re: Maven Runtime Metrics System - MNG-6899

[Enrico Olivelli]

Il Lun 1 Giu 2020, 07:08 Romain Manni-Bucau  ha
scritto:

> Hi Enrico,
>
> As mentionned I think 5 would be an error, we should provide an in memory
> flavor with a dump at exist (-Dmaven.metrics.dumpOnExit=/tmp/metrics.csv or
> so?) otherwise it will be a noop for user so not sure it is worth having it
> at all.
>

Here it is the implementation
It is only a matter of pushing it to our ASF repository.
It is mostly a cut and paste of the same stuff we did in Zookeeper project.

No problem in pushing it to Maven repository from my side.


Enrico

In other words, if you want it as a vendor you put a javaagent on the JVM
> and you are done with the added value of getting metrics.
> I don't mean I think we must not have it, I strongly think we must, but I
> also think it is only worth if usable directly, even if limited to in
> memory case.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le dim. 31 mai 2020 à 22:31, Enrico Olivelli  a
> écrit :
>
> > Hey guys,
> > I feel this Metrics Runtime API will be very useful to Maven and Maven
> > plugins.
> > But I am not sure we are reaching consensus.
> >
> > Main points:
> > 1) We will introduce a Metrics Provider API, maintained by Maven project.
> > 2) Metrics are not "extension points", they are not "events",
> > implementations of the Provider API cannot alter the behaviour of Maven
> > 3) Metrics are just "values in time" (counters, gauges, summaries) ,
> > usually exposed as time series, they are useful to inspect the runtime
> > low-level performances of internals of Maven core, internal libraries and
> > plugins
> > 4) The implementation of the API (the code that publishes and/or analyse
> > data) is loaded using the Extensions mechanism, by default there will be
> a
> > noop implementation bundled with Maven distribution
> > 5) We (Maven project) won't provide initially any implementation other
> than
> > the NOOP, in order not to add burden to Maven project. I can maintain a
> few
> > implementations on a separate repository, no need to add a burden to main
> > Maven project.
> > 6) Plugins will be able to register metric values using the Metrics API,
> > the will look up the MetricSystem component with @Inject or with explicit
> > lookup.
> >
> > I am glad to move forward with this project if we agree on all of the
> > aspects.
> > I am open to discuss again about  all of the points.
> >
> > Thanks to everyone who already joined the discussion, I hope we could
> ship
> > v1 of the API in Maven 3.7 or Maven 3.8, the sooner the better
> >
> > Enrico
> >
> >
> >
> > Il giorno lun 11 mag 2020 alle ore 08:02 Romain Manni-Bucau <
> > rmannibu...@gmail.com> ha scritto:
> >
> > > Hmm, it shouldn't be:
> > >
> > > metricsSystem
> > > .getMetricsContext()
> > > .getSummary( "resolvePluginDependency", "Time to resolve dependencies
> of
> > a
> > > plugin (ms)" )
> > > .add( MetricsUtils.elapsedMillis( startResolve ) );
> > >
> > > but
> > >
> > > counter.add(duration).
> > >
> > > Resolution of the counter can be either (just in terms of inputs, then
> > api
> > > can be fluent or not, it is a detail for me):
> > >
> > > Counter counter = metricSystem.get(new CounterSpec("my counter",
> "ms"));
> > >
> > > or, since any operation in maven has a scope (mojo, artifact
> resolution,
> > > ...):
> > >
> > > @Inject @MetricSpec("my-counter", "ms") Counter counter;
> > >
> > > Concretely metrics system should enable to resolve a counter from a few
> > > meta (at least name, likely also the unit) and counter is just a long
> > (then
> > > in terms of impl it is a LongAdder to be concurrency friendly I guess
> but
> > > it is a detail).
> > > We likely don't want to pay any other overhead otherwise I fully agree
> > > events are almost 1-1 in terms of feature but totally opposed in terms
> of
> > > design:
> > >
> > > 1. A counter is a unified view of data where data are pushed from
> > >

Re: Maven Runtime Metrics System - MNG-6899

[Enrico Olivelli]

Hey guys,
I feel this Metrics Runtime API will be very useful to Maven and Maven
plugins.
But I am not sure we are reaching consensus.

Main points:
1) We will introduce a Metrics Provider API, maintained by Maven project.
2) Metrics are not "extension points", they are not "events",
implementations of the Provider API cannot alter the behaviour of Maven
3) Metrics are just "values in time" (counters, gauges, summaries) ,
usually exposed as time series, they are useful to inspect the runtime
low-level performances of internals of Maven core, internal libraries and
plugins
4) The implementation of the API (the code that publishes and/or analyse
data) is loaded using the Extensions mechanism, by default there will be a
noop implementation bundled with Maven distribution
5) We (Maven project) won't provide initially any implementation other than
the NOOP, in order not to add burden to Maven project. I can maintain a few
implementations on a separate repository, no need to add a burden to main
Maven project.
6) Plugins will be able to register metric values using the Metrics API,
the will look up the MetricSystem component with @Inject or with explicit
lookup.

I am glad to move forward with this project if we agree on all of the
aspects.
I am open to discuss again about  all of the points.

Thanks to everyone who already joined the discussion, I hope we could ship
v1 of the API in Maven 3.7 or Maven 3.8, the sooner the better

Enrico



Il giorno lun 11 mag 2020 alle ore 08:02 Romain Manni-Bucau <
rmannibu...@gmail.com> ha scritto:

> Hmm, it shouldn't be:
>
> metricsSystem
> .getMetricsContext()
> .getSummary( "resolvePluginDependency", "Time to resolve dependencies of a
> plugin (ms)" )
> .add( MetricsUtils.elapsedMillis( startResolve ) );
>
> but
>
> counter.add(duration).
>
> Resolution of the counter can be either (just in terms of inputs, then api
> can be fluent or not, it is a detail for me):
>
> Counter counter = metricSystem.get(new CounterSpec("my counter", "ms"));
>
> or, since any operation in maven has a scope (mojo, artifact resolution,
> ...):
>
> @Inject @MetricSpec("my-counter", "ms") Counter counter;
>
> Concretely metrics system should enable to resolve a counter from a few
> meta (at least name, likely also the unit) and counter is just a long (then
> in terms of impl it is a LongAdder to be concurrency friendly I guess but
> it is a detail).
> We likely don't want to pay any other overhead otherwise I fully agree
> events are almost 1-1 in terms of feature but totally opposed in terms of
> design:
>
> 1. A counter is a unified view of data where data are pushed from
> contributors
> 2. Event are an heterogeneous set of data where consumers are interpreting
> the value
>
> If you want to be iso you create a Counter event but then you have this
> overhead we should avoid IMO + you just recreated metric system with
> another API (likely slower due to the bus usage which requires a lot of
> caching and JIT to be iso in terms of perf but it is really after some
> dozen of thousands of executions).
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le dim. 10 mai 2020 à 22:23, Enrico Olivelli  a
> écrit :
>
> > Il giorno dom 10 mag 2020 alle ore 22:10 Robert Scholte <
> > rfscho...@apache.org> ha scritto:
> >
> > > This looks more like a bug, so this should be analyzed.
> > > It sounds to me, that if this information was accurate, there wouldn't
> be
> > > a need for the a separate MetricSystem.
> > >
> >
> > Sorry, I have added that metric just to have some data to retrieve and
> > monitor.
> > Maybe this is not interesting.
> >
> > The point is that if I want to track this duration, now I can do it just
> by
> > adding a bunch of lines locally.
> > There is no need to introduce a new formal "event", that would be part of
> > some public API.
> > If the information is not useful I can remove it in the next release,
> there
> > is no strong contract with the end user
> >
> > Enrico
> >
> >
> >
> >
> >
> >
> >
> >
> > >
> > > Robert
> > > On 10-5-2020 20:38:39, Romain Manni-Bucau 
> wrote:
> > > Le dim. 10 mai 2020 à 20:11, Karl Heinz Marbaise a
&

Re: PR spam

[Enrico Olivelli]

Il Dom 31 Mag 2020, 00:57 Olivier Lamy  ha scritto:

> Hi
> First I'm not against PR and people asking review.
> But for obvious changes, we can probably avoid PR (ie some spam especially
> when people tag you in the description of a PR).
> We have a long history about commit-then-review so let's keep this.
>
> Such change don't really need a PR
> https://github.com/apache/maven-site-plugin/pull/26/files
> I received around 15 emails for this from github and gitbox (as I was
> tagged in the description).
>
> So please create PR only for complicated change.

Yes
PR are useful for inline comments and code review
One liner changes are not worth, if they are from a committer


Enrico


Upgrade of a dependency is
> NOT a complicated change (except if it breaks backward compat and btw most
> of the time there is a Jira for this which generate even more emails).
>
> I'm just asking to reduce the level of emails we received as at the end the
> result is people don't really look at notifications...
>
> cheers
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: Dynamic phases proposal

[Enrico Olivelli]

Stephen,
do we have news about this great feature ?

Enrico

Il giorno sab 23 nov 2019 alle ore 11:51 Stephen Connolly <
stephen.alan.conno...@gmail.com> ha scritto:

> Ok I figured out dynamic lookup from plexus:
>
> $ mvn -version
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T19:33:14+01:00)
> Maven home: /usr/local/Cellar/maven/3.5.4/libexec
> Java version: 1.8.0_152, vendor: Oracle Corporation, runtime:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_152.jdk/Contents/Home/jre
> Default locale: en_IE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac"
> $ mvn validate
> [ERROR] The project uses experimental features that require exactly Maven
> 3.7.0-SNAPSHOT -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
>
> Much nicer!
>
>
>
> On Fri, 22 Nov 2019 at 16:12, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > I have advanced the PoC a bit more by adding an experiments mechanism.
> >
> > To use the dynamic phases PoC you now need to:
> >
> > 1. Build and install Maven on the branch
> > 2. Add the experiments extension in .mvn/extensions.xml, e.g.
> >
> > 
> > http://maven.apache.org/EXTENSIONS/1.0.0; xmlns:xsi="
> > http://www.w3.org/2001/XMLSchema-instance;
> > xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.0.0
> > http://maven.apache.org/xsd/core-extensions-1.0.0.xsd;>
> >
> >   
> > org.apache.maven
> > maven-experiments
> > 3.7.0-SNAPSHOT
> >   
> >
> > 
> >
> > 3. Update your pom to use the new dynamic phases.
> >
> > The reason for the experiments extension is to guard against assuming the
> > phases will work and prevent "normal" versions of Maven from producing a
> > bad build.
> >
> > Here's a build with the extension enabled:
> >
> > [INFO] Enabling experimental features of Maven 3.7.0-SNAPSHOT
> > [INFO] Experimental features enabled:
> > [INFO]   * dynamic-phases
> > [INFO] Scanning for projects...
> > [INFO]
> > 
> > [INFO] Reactor Build Order:
> > [INFO]
> > [INFO] foo
> >  [jar]
> > [INFO] bar
> >  [jar]
> > [INFO] test
> > [pom]
> > [INFO]
> > [INFO] --< localdomain:foo
> > >---
> > [INFO] Building foo 1.0-SNAPSHOT
> >  [1/3]
> > [INFO] [ jar
> > ]-
> > [INFO]
> > [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ foo
> > ---
> > [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> > resources, i.e. build is platform dependent!
> > [INFO] skip non existing resourceDirectory
> > /Users/stephenc/tmp/test/foo/src/main/resources
> > [INFO]
> > [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ foo ---
> > [INFO] No sources to compile
> > [INFO]
> > [INFO] --- maven-resources-plugin:2.6:testResources
> > (default-testResources) @ foo ---
> > [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> > resources, i.e. build is platform dependent!
> > [INFO] skip non existing resourceDirectory
> > /Users/stephenc/tmp/test/foo/src/test/resources
> > [INFO]
> > [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
> > foo ---
> > [INFO] No sources to compile
> > [INFO]
> > [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ foo ---
> > [INFO] No tests to run.
> > [INFO]
> > [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ foo ---
> > [WARNING] JAR will be empty - no content was marked for inclusion!
> > [INFO]
> > [INFO] --- maven-antrun-plugin:1.3:run (2) @ foo ---
> > [INFO] Executing tasks
> >  [echo] beat you
> > [INFO] Executed tasks
> > [INFO]
> > [INFO] --- maven-antrun-plugin:1.3:run (1) @ foo ---
> > [INFO] Executing tasks
> >  [echo] hi
> > [INFO] Executed tasks
> > [INFO]
> > [INFO] --- maven-antrun-plugin:1.3:run (4) @ foo ---
> > [INFO] Executing tasks
> > [INFO]
> > [INFO] --- maven-antrun-plugin:1.3:run (3) @ foo ---
> > [INFO] Executing tasks
> >  [echo] bye
> > [INFO] Executed tasks
> > [INFO]
> > 
> > [INFO] Reactor Summary for test 1.0-SNAPSHOT:
> > [INFO]
> > [INFO] foo  FAILURE [
> >  2.745 s]
> > [INFO] bar  SKIPPED
> > [INFO] test ... SKIPPED
> > [INFO]
> > 
> > [INFO] BUILD FAILURE
> > [INFO]
> > 

Re: Consumer pom and relative disk paths for parent pom

[Enrico Olivelli]

Robert,
do we have news about this great feature ?

Enrico

Il giorno sab 30 nov 2019 alle ore 14:38 Enrico Olivelli <
eolive...@gmail.com> ha scritto:

> Good news
>
> Il giorno sab 30 nov 2019 alle ore 14:27 Robert Scholte <
> rfscho...@apache.org> ha scritto:
>
>> Hi Enrico,
>>
>> current implementation says groupId+artifact are required, but you can
>> either specify version or relativePath (or omit it, meaning ../pom.xml)
>> I've decided to keep G+A so MAven can verify the pom is pointing to the
>> right parent.
>> MNG-6656 has a demo attached which shows you the new valid pom structure.
>>
>>
> This is the link for reference
>
> https://github.com/apache/maven/pull/286/files#diff-367b1a6eb386aada5bd28a0aaebe645bR36
>
> I am totally ok for keeping G+A, it sounds very sensible to me.
>
> Thank you so much, I missed that part of the change, or at least I forgot
> about it
>
> I am really sure I want this new feature in 3.7.0 !
>
> It looks like we are adding great stuff to Maven for this new major release
>
> Enrico
>
>
>> thanks,
>> Robert
>>
>> On 30-11-2019 13:39:12, Enrico Olivelli  wrote:
>> Hi,
>> when we move to the consumer pom we can leverage the disk layout of
>> projects inside the same repository while looking for the parent pom.
>>
>> Currently you can use the element to refer to the location
>> of a parent pom, AFAIK this is only an hint for Maven and for tools: you
>> must always copy all of the coordinates of the parent module because when
>> you publish your pom the consumer must be able to find such parent module
>> from remote repositories, without having the physical layout of the source
>> code.
>>
>> With the consumer pom with can let the build pom have only the
>> relativePath
>> element and then we will fill the consumer (deployed) pom with the
>> effective parent coordinates.
>>
>> This will simply a lot this part of Maven that is quite annoying for users
>>
>> Thoughts?
>> Enrico
>>
>

Re: [VOTE] Release Maven Wagon version 3.4.1

[Enrico Olivelli]

+1 (non binding)

Side note:
I see from the diff (good idea!) that we added a new comment with 'TODO'
We should create a JIRA and link to it.

Enrico


Il Sab 23 Mag 2020, 14:12 Robert Scholte  ha scritto:

> +1
>
>
> On 23-5-2020 13:03:20, Arnaud Héritier  wrote:
> LGTM +1
> I did only a code review using
> https://github.com/apache/maven-wagon/compare/wagon-3.4.0...wagon-3.4.1
>
> On Fri, May 22, 2020 at 9:45 PM Michael Osipov wrote:
>
> > Hi,
> >
> > We solved 6 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122=12348210
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1576/
> >
> >
> https://repository.apache.org/content/repositories/maven-1576/org/apache/maven/wagon/wagon/3.4.1/wagon-3.4.1-source-release.zip
> >
> > Source release checksum(s):
> > wagon-3.4.1-source-release.zip
> > sha512:
> >
> >
> 342d3ad88ba3535a0b6cafcfebd3f5b2e0fc6ac4022bebcea78a60703b0c611232e765ea87fb98ada0dc5daf1a9002e9bf7959571eebc4c974efda042246999c
> >
> > Staging site:
> > https://maven.apache.org/wagon-archives/wagon-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>

Re: second apache-maven-wrapper

[Enrico Olivelli]

Approved on github

+1
I have run thru the diff.
It looks very well

Longing for testing it on a real project

The fact that you won't have to commit mave wrapper jar to local sources is
great


Enrico

Il Ven 22 Mag 2020, 22:56 Manfred Moser  ha
scritto:

> Awesome! +1
>
> Robert Scholte wrote on 2020-05-22 13:36 (GMT -07:00):
>
> > I've reached the point where apache-maven-wrapper is ready to be merged
> into
> > master.
> > The code contains all original commits and a few from me to get them
> step by
> > step into core.
> >
> > Related tickets:
> > https://issues.apache.org/jira/browse/MNG-5937
> >
> > https://issues.apache.org/jira/browse/MNG-6914
> >
> >
> > https://github.com/apache/maven/pull/349
> >
> > https://github.com/apache/maven-integration-testing/pull/62
> >
> >
> > thanks,
> > Robert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: next level of compatibility (was Re: [maven-site] branch master updated: few precisions)

[Enrico Olivelli]

+1

Enrico

Il Sab 23 Mag 2020, 09:40 Sylwester Lachiewicz  ha
scritto:

> +1
>
> sob., 23 maj 2020, 09:22 użytkownik Hervé BOUTEMY 
> napisał:
>
> > Le vendredi 22 mai 2020, 02:13:16 CEST Olivier Lamy a écrit :
> > > > +  * discussions on Maven > 3.0.x (3.1 or 3.2 or 3.3? details still
> > TDB) +
> > > > Java 8 prerequisites
> > >
> > > Don't be shy Hervé we can definitely says >= 3.3.9 (at least you will
> not
> > > hear any objections from me :) )
> >
> > looking at our history https://maven.apache.org/docs/history.html, there
> > is 1
> > year between 3.1.max and 3.2.max then 1 year to 3.3.max: not so much
> > and AFAIK, many people went from 3.0 to 3.3+
> >
> > looks a good idea to me: +1
> >
> > any objection?
> >
> > Regards,
> >
> > Hervé
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Merging via GitHub

[Enrico Olivelli]

Olivier

Il giorno dom 17 mag 2020 alle ore 04:00 Olivier Lamy  ha
scritto:

> and yeah that's embarrassing
> someone mentioned using a script. where is this script?
>

I have a script that syncs the PR with a local branch. It is very raw so it
is not worth to share

btw in ZooKeeper community we have this wonderful script
https://github.com/apache/zookeeper/blob/master/zk-merge-pr.py

it performs these steps:
- downloads the PR
- squash all of the commits (preserving the author)
- pushes to the target branch
- add fixVersion to JIRA
- Resolves the issue on JIRA

The only tricky part for us in Maven is that we need to push the branch to
ASF repo in order to kick CI in

But if anyone is interested in improving the script...
I feel we will save lot of time and allow a better learning curve for new
committers

Enrico

Enrico



>
> On Sun, 17 May 2020 at 11:51, Olivier Lamy  wrote:
>
> >
> >
> > On Sun, 17 May 2020 at 11:40, David Jencks 
> > wrote:
> >
> >> As a side note, I’m personally in favor of the author squashing manually
> >> and the “merge” into master using rebase-and-commit.
> >>
> >> To your main issue, I’m pretty sure that GitHub doesn’t keep any secret
> >> information, instead you are using an insufficiently verbose log
> command.
> >> Try
> >>
> >> git log --pretty=fuller
> >>
> >> By default git log just shows the author, and you are looking for the
> >> committer (person who merged in the commit).
> >>
> >> See git-log 
> >>
> >
> > argghhh I haven;t down enough with git help log :)
> > Thanks for the tip
> >
> >
> >>
> >> david jencks
> >>
> >> > On May 16, 2020, at 4:53 PM, Olivier Lamy  wrote:
> >> >
> >> > I wonder what is exactly the problem here? (except a noisy commit but
> >> who
> >> > cares really compared to the useless noise email notifications when
> >> someone
> >> > rebase a branch)
> >> > But at least there are real person name.
> >> > That's weird because I just used the "Squash and merge' for this PR (
> >> > https://github.com/apache/maven-shared-utils/pull/30) and got nice
> >> commit
> >> >
> >>
> https://github.com/apache/maven-shared-utils/commit/32942621ff5df2f8779e0f55276c902a1fcb42b9
> >> > Elliotte  Maybe something with your GH configuration?
> >> >
> >> > I have definitely more concerns with this one
> >> >
> >>
> https://github.com/apache/maven-shared-utils/commit/bb2f85e98c3c651ae50b7f642500cb74f50abb0d
> >> >
> >> > some github UI features show it as `dependabot-preview authored and
> >> > slachiewicz committed`
> >> > But looking at log with a real git tool call 'git' :) I get
> >> >
> >> >
> >> > commit bb2f85e98c3c651ae50b7f642500cb74f50abb0d
> >> > Author: dependabot-preview[bot] <27856297+dependabot-preview[bot]@
> >> > users.noreply.github.com>
> >> > Date:   Mon Mar 9 04:19:41 2020 +
> >> >Bump hamcrest-core from 1.3 to 2.2
> >> > Bumps [hamcrest-core](https://github.com/hamcrest/JavaHamcrest) from
> >> 1.3 to
> >> > 2.2.
> >> > - [Release notes](https://github.com/hamcrest/JavaHamcrest/releases)
> >> > - [Changelog](
> >> > https://github.com/hamcrest/JavaHamcrest/blob/master/CHANGES.md)
> >> > - [Commits](
> >> >
> >>
> https://github.com/hamcrest/JavaHamcrest/compare/hamcrest-java-1.3...v2.2
> >> )
> >> >
> >> > Signed-off-by: dependabot-preview[bot] 
> >> >
> >> > And this is totally wrong! we must have a real person name in the
> commit
> >> > logs (and github UI is not the real commit logs).
> >> > not sure how to fix that
> >>
> >>
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: Maven Runtime Metrics System - MNG-6899

[Enrico Olivelli]

Il giorno dom 10 mag 2020 alle ore 22:10 Robert Scholte <
rfscho...@apache.org> ha scritto:

> This looks more like a bug, so this should be analyzed.
> It sounds to me, that if this information was accurate, there wouldn't be
> a need for the a separate MetricSystem.
>

Sorry, I have added that metric just to have some data to retrieve and
monitor.
Maybe this is not interesting.

The point is that if I want to track this duration, now I can do it just by
adding a bunch of lines locally.
There is no need to introduce a new formal "event", that would be part of
some public API.
If the information is not useful I can remove it in the next release, there
is no strong contract with the end user

Enrico








>
> Robert
> On 10-5-2020 20:38:39, Romain Manni-Bucau  wrote:
> Le dim. 10 mai 2020 à 20:11, Karl Heinz Marbaise a
> écrit :
>
> >
> > On 10.05.20 19:59, Romain Manni-Bucau wrote:
> > > Events vs metrics is an old topic.
> > > The choice between both is not only design but also about perf. In
> terms
> > of
> > > design it brings the ability to export data without exposing it in code
> > > (events are public). It also avoid to expose a stable api of events and
> > > create coupling between plugin/exts and only require a single stable
> api
> > > which is very minimal (lot of projects kept their metric abstraction
> > > stable).
> > >
> > > Typically wagon should export metrics but if you fire an event per
> > download
> > > progress it will be quite slow currently and you will allocate a lot of
> > > objects (or create contentions) just to increase a monotonic counter (a
> > > longadder concretely).
> > >
> > > So I think Enrico is right and we cant avoid metrics (I have to admit
> > > events are overcomplex to use for plugin/ext dev, see all profiling
> > > extensions,
> >
> > > not a single one works and report accurate data whereas metrics
> > > can miss some drilldown data but would be right).
> >
> > Interesting point cause can you give some more details on which the
> > testimony is based that none of them works?
> >
>
> They all measure bus events, mainly mojo_start, mojo_end but at the end
> several mojo have a duration of 0ms...even if they take minutes.
>
> What I saw last time I checked the two top rated by github (and google I
> think), some events were missing (one ex where metrics are easier to
> handle, you push your data, no computation on consumer side).
> Out of my head in the project i was working on, gmaven plugin was totally
> missed.
>
>
> > Can you explain a accurate implementation?
> >
>
> If my build take 5mn and i sum all not overlapping times of the report of a
> monothreaded (T1) build then i should be close to 5mn (+- some sec for the
> boot, ioc, logging, final report).
> If I cant extract where time is spent these tools are uselesd.
>
> For the story i used a javaagent (based on sirona) to instrument the build
> i was optimizing, was using in memory counters with dump at shutdown (in
> csv). Indeed bytecode instrumentation overhead was not low enough but i
> managed to explain the build duration properly with such a tool.
>
> If we put these basic metrics in maven core (executor for ex) I'm pretty
> confident results will be less random than events interpretation and
> required code is very low and trivial to maintain for any dev so guess it
> is worth it even if off by default (noop metrics system).
>
>
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
> >
> > >
> > > Now we can limit the surfacing api and start only by counters and
> gauges
> > > maybe and later add histogram, meters etc only if needed (not sure for
> > mvn).
> > >
> > > Le dim. 10 mai 2020 à 19:32, Enrico Olivelli a
> > écrit :
> > >
> > >> Il Dom 10 Mag 2020, 17:49 Robert Scholte ha
> > >> scritto:
> > >>
> > >>> Hi Enrico,
> > >>>
> > >>> These could all be solved by firing events.
> > >>>
> > >>
> > >> Yes
> > >> I see your point.
> > >> Unfortunately those are the first points that I have instrumented in
> > order
> > >> to see some data.
> > >>
> > >>
> > >>> And there's another benefit: since there won't be an API, we don't
> need
> > >> to
> > >>> maintain it,or be afraid of mistakes.
> > >>>
> > >>
> > >> Exposed metrics won't be an API, or at least something to be
> m

Re: Maven Runtime Metrics System - MNG-6899

[Enrico Olivelli]

Il Dom 10 Mag 2020, 17:49 Robert Scholte  ha scritto:

> Hi Enrico,
>
> These could all be solved by firing events.
>

Yes
I see your point.
Unfortunately those are the first points that I have instrumented in order
to see some data.


> And there's another benefit: since there won't be an API, we don't need to
> maintain it,or be afraid of mistakes.
>

Exposed metrics won't be an API, or at least something to be maintained.
Each Maven version, component version, plugin version may expose any metric
is valuable for the component developer or for the users.

Exposed metrics are not an extension point, it is not expected that a
MetricsProvider is able to alter the behaviour of Maven.
Events/Extension point must be maintained forever, but you can drop/add a
metric at each release. They are very low level tracking points in code.

This is because I say that metrics are like loggers: you add logs where you
think it is useful, you can change log point at every version, there is not
strong contract with the user, logging implementation is totally pluggable.

The Metrics API is mostly the contract with Metrics Provider developers.
It will be very stable, I don't think there will be many changes in the mid
term.
It is only about the ability to give a name to counters, summaries and
gauges.

Having a simple implementation that dumps the final values at the end is
not the full power of this mechanism.

You can attach Prometheus or any other time series based metrics database
and see the evolution of the build, this will be very useful for long
running builds and especially on CI or during component development.

I will finish the implementation with Prometheus and try to create a
Grafana dashboard.

It would be super useful that some Maven-internals experts could suggest
useful values to track during the execution of the build.

I hope that explains better the value of the Metrics system.

Thank you Robert for your feedback and help

Enrico


To me this is the wrong approach to embed metrics.
>
> thanks,
> Robert
> On 10-5-2020 16:58:59, Enrico Olivelli  wrote:
> Il giorno dom 10 mag 2020 alle ore 13:42 Robert Scholte <>
> rfscho...@apache.org> ha scritto:
>
> > sometimes code says more than a thousand words: can you share the changes
> > in Maven Core you had in mind?
> >
>
> Maven Metrics Extensions API:
>
> https://github.com/apache/maven-metric/blob/master/maven-metrics-api/src/main/java/org/apache/maven/metrics/MetricsSystem.java
> An Extension is expected to implement that Named component
>
> Example implementation:
>
> https://github.com/eolivelli/simplemavenmetrics/blob/master/src/main/java/org/apache/maven/metrics/SimpleMetricsSystem.java
> This is mostly what Romain said, if you add this extension to your project
> (and use Maven 3.7. from my branch on maven studies)
> mvn -Dmetrics.dumpAtEnd=true verify
> You will see the "final" values of every metric, it does not track any time
> series
>
> This is a sample instrumentation of Maven Core
> https://github.com/apache/maven/pull/344/files
>
> I am not sure that those are the most interesting points but it is enough
> to see interesting data on some project:
> - time to resolve the pom
> - time to resolve dependencies of plugins
> - time to "install" an artifact locally
> - time to perform the execution of each mojo
>
> I wanted to instrument more components but I have to tweak Wagon and other
> lower level external components
>
> Enrico
>
> On 10-5-2020 12:07:33, Enrico Olivelli wrote:
> > Il giorno dom 10 mag 2020 alle ore 11:53 Robert Scholte
> > rfscho...@apache.org> ha scritto:
> >
> > > Maybe I'm still missing a detail, but this is what I had in mind:
> > > Maven already fires events.
> > >
> >
> > Metrics are for a distinct use case.
> > Metrics are like Logs, the developer instruments its own code to have
> > important information available during the execution.
> > For instance you want to see the evolution of a cache, see how much it is
> > useful,
> > or you can instrument the HTTP client inside wagon to see how well the
> > network is performing.
> > Usually they are for fine grained instrumentation of hot points in code.
> > For instance you do not want to fire an event every time an entry of a
> > cache is evicted and expect some code to intercept that event.
> >
> > Metrics are not extension points like current "events" mechanism.
> > The MetricsProvider will be an extension, in a way that it is separate
> from
> > Maven Core, it only provides the way to gather the information,
> > usually in form of time series and make it available to the tools (like
> > Dashboards, reports...).
> 

Re: Maven Runtime Metrics System - MNG-6899

[Enrico Olivelli]

Il giorno dom 10 mag 2020 alle ore 13:42 Robert Scholte <
rfscho...@apache.org> ha scritto:

> sometimes code says more than a thousand words: can you share the changes
> in Maven Core you had in mind?
>

Maven Metrics Extensions API:
https://github.com/apache/maven-metric/blob/master/maven-metrics-api/src/main/java/org/apache/maven/metrics/MetricsSystem.java
An Extension is expected to implement that Named component

Example implementation:
https://github.com/eolivelli/simplemavenmetrics/blob/master/src/main/java/org/apache/maven/metrics/SimpleMetricsSystem.java
This is mostly what Romain said, if you add this extension to your project
(and use Maven 3.7. from my branch on maven studies)
mvn -Dmetrics.dumpAtEnd=true verify
You will see the "final" values of every metric, it does not track any time
series

This is a sample instrumentation of Maven Core
https://github.com/apache/maven/pull/344/files

I am not sure that those are the most interesting points but it is enough
to see interesting data on some project:
- time to resolve the pom
- time to resolve dependencies of plugins
- time to "install" an artifact locally
- time to perform the execution of each mojo

I wanted to instrument more components but I have to tweak Wagon and other
lower level external components

Enrico

On 10-5-2020 12:07:33, Enrico Olivelli  wrote:
> Il giorno dom 10 mag 2020 alle ore 11:53 Robert Scholte
> rfscho...@apache.org> ha scritto:
>
> > Maybe I'm still missing a detail, but this is what I had in mind:
> > Maven already fires events.
> >
>
> Metrics are for a distinct use case.
> Metrics are like Logs, the developer instruments its own code to have
> important information available during the execution.
> For instance you want to see the evolution of a cache, see how much it is
> useful,
> or you can instrument the HTTP client inside wagon to see how well the
> network is performing.
> Usually they are for fine grained instrumentation of hot points in code.
> For instance you do not want to fire an event every time an entry of a
> cache is evicted and expect some code to intercept that event.
>
> Metrics are not extension points like current "events" mechanism.
> The MetricsProvider will be an extension, in a way that it is separate from
> Maven Core, it only provides the way to gather the information,
> usually in form of time series and make it available to the tools (like
> Dashboards, reports...).
>
> Metrics will be useful for:
> - Maven developers (core and plugins): see how well code behaves and where
> it is better to put enhancements/optimizations
> - Maven users: some of the metrics could be useful for users, especially
> about the system in which Maven is executing (network, disk speed, usage of
> memory during peaks)
> - Automatics tools, like Jenkins, to display information about the
> execution of long running builds
>
>
> Enrico
>
>
>
>
>
> > The extension listens to these events and can do its metrics.
> > I see no need for a hard coupling between these two.
> >
> > Robert
> >
> > On 10-5-2020 10:28:42, Enrico Olivelli wrote:
> > Il Dom 10 Mag 2020, 09:21 Romain Manni-Bucau ha
> > scritto:
> >
> > > Le dim. 10 mai 2020 à 07:43, Enrico Olivelli a
> > > écrit :
> > >
> > > > Robert
> > > > Maybe I was misunderstood.
> > > > We need a new repo only for the Metrics API.
> > > >
> > > > Maven core (3.7?) provides the noop implementation.
> > > >
> > > > Implementations of MetricsProvider will be extensions. I feel it is
> > > better
> > > > that we don't deal with implementations as a first step.
> > > > I will leave a couple of implementations in my personal repo.
> > > >
> > >
> > > Think we need at least a trivial memory impl with maybe a "log at
> > > shutdown" feature otherwise it will not bring anything to end users
> > >
> >
> >
> > Yep
> >
> > I have already implemented it :)
> >
> >
> > Robert,
> > I saw the github notification about the new two repositories
> >
> > Thank you all
> >
> >
> > Enrico
> >
> >
> >
> > >
> > > >
> > > > Enrico
> > > >
> > > >
> > > > Il Sab 9 Mag 2020, 22:51 Robert Scholte ha
> > > scritto:
> > > >
> > > > >
> > > > > On 9-5-2020 17:58:47, Enrico Olivelli wrote:
> > > > > Robert
> > > > >
> > > > > Il Sab 9 Mag 2020, 10:54 Robert Scholte 

Re: Maven Runtime Metrics System - MNG-6899

[Enrico Olivelli]

Il giorno dom 10 mag 2020 alle ore 11:53 Robert Scholte <
rfscho...@apache.org> ha scritto:

> Maybe I'm still missing a detail, but this is what I had in mind:
> Maven already fires events.
>

Metrics are for a distinct use case.
Metrics are like Logs, the developer instruments its own code to have
important information available during the execution.
For instance you want to see the evolution of a cache, see how much it is
useful,
or you can instrument the HTTP client inside wagon to see how well the
network is performing.
Usually they are for fine grained instrumentation of hot points in code.
For instance you do not want to fire an event every time an entry of a
cache is evicted and expect some code to intercept that event.

Metrics are not extension points like current "events" mechanism.
The MetricsProvider will be an extension, in a way that it is separate from
Maven Core, it only provides the way to gather the information,
usually in form of time series and make it available to the tools (like
Dashboards, reports...).

Metrics will be useful for:
- Maven developers (core and plugins): see how well code behaves and where
it is better to put enhancements/optimizations
- Maven users: some of the metrics could be useful for users, especially
about the system in which Maven is executing (network, disk speed, usage of
memory during peaks)
- Automatics tools, like Jenkins, to display information about the
execution of long running builds


Enrico





> The extension listens to these events and can do its metrics.
> I see no need for a hard coupling between these two.
>
> Robert
>
> On 10-5-2020 10:28:42, Enrico Olivelli  wrote:
> Il Dom 10 Mag 2020, 09:21 Romain Manni-Bucau ha
> scritto:
>
> > Le dim. 10 mai 2020 à 07:43, Enrico Olivelli a
> > écrit :
> >
> > > Robert
> > > Maybe I was misunderstood.
> > > We need a new repo only for the Metrics API.
> > >
> > > Maven core (3.7?) provides the noop implementation.
> > >
> > > Implementations of MetricsProvider will be extensions. I feel it is
> > better
> > > that we don't deal with implementations as a first step.
> > > I will leave a couple of implementations in my personal repo.
> > >
> >
> > Think we need at least a trivial memory impl with maybe a "log at
> > shutdown" feature otherwise it will not bring anything to end users
> >
>
>
> Yep
>
> I have already implemented it :)
>
>
> Robert,
> I saw the github notification about the new two repositories
>
> Thank you all
>
>
> Enrico
>
>
>
> >
> > >
> > > Enrico
> > >
> > >
> > > Il Sab 9 Mag 2020, 22:51 Robert Scholte ha
> > scritto:
> > >
> > > >
> > > > On 9-5-2020 17:58:47, Enrico Olivelli wrote:
> > > > Robert
> > > >
> > > > Il Sab 9 Mag 2020, 10:54 Robert Scholte ha scritto:
> > > >
> > > > > Although I'm disappointed there's no spec group for this, having
> our
> > > own
> > > > > seems indeed the best choice, but here we will likely face similar
> > > issues
> > > > > where the API needs adjustments.
> > > > > So lets create the maven-metrics git repository
> > > > >
> > > >
> > > >
> > > > Shall I do it by myself or do I need help from a PMC?
> > > >
> > > > For JIRA I think we can keep using Maven core project
> > > > Robert Scholte:
> > > > No, I'll create a separate project for it too. This extension will
> have
> > > > its own lifecycle, unrelated to the Maven lifecycle (and it won't be
> > > > bundled)
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > There are a few things I want to address:
> > > > > - Consider returning Optional when methods might return null.
> > > > >
> > > > Okay
> > > >
> > > > > - Specify how to handle Collections and Maps, I think we should
> > assume
> > > > > these are never null
> > > > >
> > > > Okay
> > > >
> > > > > - Abstract classes versus default methods. Default methods were
> > > > introduced
> > > > > to extend existing interfaces without breaking the contract. I
> > already
> > > > > expected patterns to appear where default methods would replace
> > > abstract
> > > > > classes. I'm not saying it is a bad thing, but just to have
> consensus
> > > >

Re: Maven Runtime Metrics System - MNG-6899

[Enrico Olivelli]

Il Dom 10 Mag 2020, 09:21 Romain Manni-Bucau  ha
scritto:

> Le dim. 10 mai 2020 à 07:43, Enrico Olivelli  a
> écrit :
>
> > Robert
> > Maybe I was misunderstood.
> > We need a new repo only for the Metrics API.
> >
> > Maven core (3.7?) provides the noop implementation.
> >
> > Implementations of MetricsProvider will be extensions. I feel it is
> better
> > that we don't deal with implementations as a first step.
> > I will leave a couple of implementations in my personal repo.
> >
>
> Think we need at least  a trivial memory impl with maybe a "log at
> shutdown" feature otherwise it will not bring anything to end users
>


Yep

I have already implemented it :)


Robert,
I saw the github notification about the new two repositories

Thank you all


Enrico



>
> >
> > Enrico
> >
> >
> > Il Sab 9 Mag 2020, 22:51 Robert Scholte  ha
> scritto:
> >
> > >
> > > On 9-5-2020 17:58:47, Enrico Olivelli  wrote:
> > > Robert
> > >
> > > Il Sab 9 Mag 2020, 10:54 Robert Scholte ha scritto:
> > >
> > > > Although I'm disappointed there's no spec group for this, having our
> > own
> > > > seems indeed the best choice, but here we will likely face similar
> > issues
> > > > where the API needs adjustments.
> > > > So lets create the maven-metrics git repository
> > > >
> > >
> > >
> > > Shall I do it by myself or do I need help from a PMC?
> > >
> > > For JIRA I think we can keep using Maven core project
> > > Robert Scholte:
> > > No, I'll create a separate project for it too. This extension will have
> > > its own lifecycle, unrelated to the Maven lifecycle (and it won't be
> > > bundled)
> > >
> > >
> > >
> > > >
> > > >
> > > > There are a few things I want to address:
> > > > - Consider returning Optional when methods might return null.
> > > >
> > > Okay
> > >
> > > > - Specify how to handle Collections and Maps, I think we should
> assume
> > > > these are never null
> > > >
> > > Okay
> > >
> > > > - Abstract classes versus default methods. Default methods were
> > > introduced
> > > > to extend existing interfaces without breaking the contract. I
> already
> > > > expected patterns to appear where default methods would replace
> > abstract
> > > > classes. I'm not saying it is a bad thing, but just to have consensus
> > > that
> > > > we can do this.
> > > >
> > >
> > > I will think more about this
> > >
> > > Thanks
> > > Enrico
> > >
> > >
> > > > thanks,
> > > > Robert
> > > >
> > > > On 4-5-2020 17:00:39, Romain Manni-Bucau wrote:
> > > > Le lun. 4 mai 2020 à 16:55, Slawomir Jaranowski a
> > > > écrit :
> > > >
> > > > > Hi,
> > > > > In my humble opinion it is not the best way to implement own api
> when
> > > > > similar api is already ready and maintained.
> > > > >
> > > > > There is another project used for metrics: micrometer, as we can
> see
> > it
> > > > is
> > > > > a quite popular 2.3K stars, 500 forks on github
> > > > > https://github.com/micrometer-metrics/micrometer
> > > > >
> > > > > Please consider similar situation with logging api used in maven,
> we
> > > have
> > > > > different logging in plexus component, maven plugin api, maven
> core,
> > > ...
> > > > > and now slf4j is try to replace old
> > > > >
> > > > > Why it is so important to you to be independent in this case?
> > > > >
> > > >
> > > > Cause none is stable and it will be user facing (mojo dev) so it is
> key
> > > to
> > > > create an API we - maven - can assume in time and not depend on
> > vendors.
> > > > Microprofile just proved it would have been a bad choice cause they
> > broke
> > > > the API quite drastically (I'm not blaming them, it is the
> microprofile
> > > > contract for now but at maven stage it would have been a bad choice).
> > > > This is not a ton of API and impl can rely on anything you want while
> > > fully
> > > > isolated (proxy on API?) from the mojo/extensions classloader
>

Re: Maven Runtime Metrics System - MNG-6899

[Enrico Olivelli]

Robert
Maybe I was misunderstood.
We need a new repo only for the Metrics API.

Maven core (3.7?) provides the noop implementation.

Implementations of MetricsProvider will be extensions. I feel it is better
that we don't deal with implementations as a first step.
I will leave a couple of implementations in my personal repo.

Enrico


Il Sab 9 Mag 2020, 22:51 Robert Scholte  ha scritto:

>
> On 9-5-2020 17:58:47, Enrico Olivelli  wrote:
> Robert
>
> Il Sab 9 Mag 2020, 10:54 Robert Scholte ha scritto:
>
> > Although I'm disappointed there's no spec group for this, having our own
> > seems indeed the best choice, but here we will likely face similar issues
> > where the API needs adjustments.
> > So lets create the maven-metrics git repository
> >
>
>
> Shall I do it by myself or do I need help from a PMC?
>
> For JIRA I think we can keep using Maven core project
> Robert Scholte:
> No, I'll create a separate project for it too. This extension will have
> its own lifecycle, unrelated to the Maven lifecycle (and it won't be
> bundled)
>
>
>
> >
> >
> > There are a few things I want to address:
> > - Consider returning Optional when methods might return null.
> >
> Okay
>
> > - Specify how to handle Collections and Maps, I think we should assume
> > these are never null
> >
> Okay
>
> > - Abstract classes versus default methods. Default methods were
> introduced
> > to extend existing interfaces without breaking the contract. I already
> > expected patterns to appear where default methods would replace abstract
> > classes. I'm not saying it is a bad thing, but just to have consensus
> that
> > we can do this.
> >
>
> I will think more about this
>
> Thanks
> Enrico
>
>
> > thanks,
> > Robert
> >
> > On 4-5-2020 17:00:39, Romain Manni-Bucau wrote:
> > Le lun. 4 mai 2020 à 16:55, Slawomir Jaranowski a
> > écrit :
> >
> > > Hi,
> > > In my humble opinion it is not the best way to implement own api when
> > > similar api is already ready and maintained.
> > >
> > > There is another project used for metrics: micrometer, as we can see it
> > is
> > > a quite popular 2.3K stars, 500 forks on github
> > > https://github.com/micrometer-metrics/micrometer
> > >
> > > Please consider similar situation with logging api used in maven, we
> have
> > > different logging in plexus component, maven plugin api, maven core,
> ...
> > > and now slf4j is try to replace old
> > >
> > > Why it is so important to you to be independent in this case?
> > >
> >
> > Cause none is stable and it will be user facing (mojo dev) so it is key
> to
> > create an API we - maven - can assume in time and not depend on vendors.
> > Microprofile just proved it would have been a bad choice cause they broke
> > the API quite drastically (I'm not blaming them, it is the microprofile
> > contract for now but at maven stage it would have been a bad choice).
> > This is not a ton of API and impl can rely on anything you want while
> fully
> > isolated (proxy on API?) from the mojo/extensions classloader (otherwise
> it
> > will conflict for sure).
> >
> >
> > >
> > > sob., 2 maj 2020 o 15:20 Enrico Olivelli napisał(a):
> > >
> > > > Robert
> > > >
> > > > Il Sab 2 Mag 2020, 15:11 Robert Scholte ha
> > > scritto:
> > > >
> > > > > If I take a look at the pom of maven-metrics, I see no dependency
> on
> > > > Maven.
> > > > > And looking at
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> > > > > [
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> > > > > ]
> > > > > This looks a lot like
> > > > >
> > > >
> > >
> >
> https://github.com/eclipse/microprofile-metrics/tree/master/api/src/main/java/org/eclipse/microprofile/metrics
> > > > > [
> > > > >
> > > >
> > >
> >
> https://github.com/eclipse/microprofile-metrics/tree/master/api/src/main/java/org/eclipse/microprofile/metrics
> > > > > ]
> > > > >
> > > > > So do we need to maintain our own Metrics API?
> > > > >
> > > >
> &g

Re: JDK 8 Minimum Requirement for Maven Resolver 2.0

[Enrico Olivelli]

+1

Enrico

Il giorno sab 9 mag 2020 alle ore 22:19 Elliotte Rusty Harold <
elh...@ibiblio.org> ha scritto:

> It is not true that Java 7 updates are no longer available. Java 7
> updates are available from Oracle for paying customers and from other
> vendors such as Azul for everyone.
>
> My preference is not to move unless there's a clear reason to do so.
> Are there specific features in Java 8 that would be useful for Maven
> resolver? E.g. support for a new protocol that isn't available in Java
> 7 such as TLS 1.3?
>
>
> On Sat, May 9, 2020 at 4:13 PM Sylwester Lachiewicz
>  wrote:
> >
> > Hi to all,
> >
> > based on the previous vote to require Java 8 for Maven Core - I would
> like
> > to propose setting the same minimum for Maven Resolver 2.0
> >
> > Maven Resolver is a base component to solve dependencies for Maven. It
> can
> > also be used separately from Maven for other projects.
> > Because Java 7 updates are no longer available, the market is also moving
> > towards using the newer version of Java 8/11.
> > Practically the Core requirement means that Resolver has little chance of
> > being used in Java 7 (see tricks to connect to Central).
> >
> > Benefits - more programmers can practice coding while improving our
> > codebase.
> >
> > What's your opinion on the subject?
> >
> > https://maven.apache.org/resolver/
> >
> > Kind regards
> > Sylwester
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven Runtime Metrics System - MNG-6899

[Enrico Olivelli]

Robert

Il Sab 9 Mag 2020, 10:54 Robert Scholte  ha scritto:

> Although I'm disappointed there's no spec group for this, having our own
> seems indeed the best choice, but here we will likely face similar issues
> where the API needs adjustments.
> So lets create the maven-metrics git repository
>


Shall I do it by myself or do I need help from a PMC?

For JIRA I think we can keep using Maven core project

>
>
> There are a few things I want to address:
> - Consider returning Optional when methods might return null.
>
Okay

> - Specify how to handle Collections and Maps, I think we should assume
> these are never null
>
Okay

> - Abstract classes versus default methods. Default methods were introduced
> to extend existing interfaces without breaking the contract. I already
> expected patterns to appear where default methods would replace abstract
> classes. I'm not saying it is a bad thing, but just to have consensus that
> we can do this.
>

I will think more about this

Thanks
Enrico


> thanks,
> Robert
>
> On 4-5-2020 17:00:39, Romain Manni-Bucau  wrote:
> Le lun. 4 mai 2020 à 16:55, Slawomir Jaranowski a
> écrit :
>
> > Hi,
> > In my humble opinion it is not the best way to implement own api when
> > similar api is already ready and maintained.
> >
> > There is another project used for metrics: micrometer, as we can see it
> is
> > a quite popular 2.3K stars, 500 forks on github
> > https://github.com/micrometer-metrics/micrometer
> >
> > Please consider similar situation with logging api used in maven, we have
> > different logging in plexus component, maven plugin api, maven core, ...
> > and now slf4j is try to replace old
> >
> > Why it is so important to you to be independent in this case?
> >
>
> Cause none is stable and it will be user facing (mojo dev) so it is key to
> create an API we - maven - can assume in time and not depend on vendors.
> Microprofile just proved it would have been a bad choice cause they broke
> the API quite drastically (I'm not blaming them, it is the microprofile
> contract for now but at maven stage it would have been a bad choice).
> This is not a ton of API and impl can rely on anything you want while fully
> isolated (proxy on API?) from the mojo/extensions classloader (otherwise it
> will conflict for sure).
>
>
> >
> > sob., 2 maj 2020 o 15:20 Enrico Olivelli napisał(a):
> >
> > > Robert
> > >
> > > Il Sab 2 Mag 2020, 15:11 Robert Scholte ha
> > scritto:
> > >
> > > > If I take a look at the pom of maven-metrics, I see no dependency on
> > > Maven.
> > > > And looking at
> > > >
> > >
> >
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> > > > [
> > > >
> > >
> >
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> > > > ]
> > > > This looks a lot like
> > > >
> > >
> >
> https://github.com/eclipse/microprofile-metrics/tree/master/api/src/main/java/org/eclipse/microprofile/metrics
> > > > [
> > > >
> > >
> >
> https://github.com/eclipse/microprofile-metrics/tree/master/api/src/main/java/org/eclipse/microprofile/metrics
> > > > ]
> > > >
> > > > So do we need to maintain our own Metrics API?
> > > >
> > >
> > > Yes it is really better.
> > >
> > > We will be in charge for this API, it will be a new API on which we
> will
> > > depend in many part of Maven core and in plugins.
> > > It is better to not depend on third party.
> > >
> > > There are other initiatives like microprofile metrics.
> > >
> > > The API itself is very small and we could add an implementation that
> uses
> > > micro profile. But we must be independent.
> > >
> > > Enrico
> > >
> > >
> > >
> > > > thanks,
> > > > Robert
> > > > On 2-5-2020 10:26:19, Enrico Olivelli wrote:
> > > > Hello community,
> > > > I am now ready to move forward with concrete steps for the
> > implementation
> > > > of Maven Runtime Metrics.
> > > >
> > > > This is the JIRA
> > > > https://issues.apache.org/jira/browse/MNG-6899
> > > >
> > > > It links to my proof-of-concept branch on maven studies.
> > > > https://github.com/apache/maven-studies/tree/maven-metrics
> > > >
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.22.3

[Enrico Olivelli]

I would go with option 'release surefire 3.0.0'


Enrico

Il Mar 5 Mag 2020, 07:59 Romain Manni-Bucau  ha
scritto:

> Hmm, this particular one is quite hard cause (from my window which is not
> 100% of users indeed) I see more users willing 1.6 (actually I should
> phrase it "upgrade to last junit5 when upgrading surefire") than other
> cases.
> Concretely, older versions will not upgrade surefire generally.
> I think we are "just" in a case where you encounter a bug with a release
> policy preventing to go to 3.x and this is why you want this particular
> case.
> Anyone has another view of users? (point being: if we downgrade and break
> all users not using spring boot parent we are exactly at the same point so
> let's try to avoid that).
>
> So question for me is:
>
> 1. Do we stick to that strategy and if so which version do we pick for
> 2.22.x and do we freeze this version?
> 1.a. junit 5.6
> 1.b. junit 5.3
> 1.c junit 5.5 (aka spring-boot current one AFAIK)
> 2. Do we backport 3.x strategy (or an enhanced flavor we do in 3.x and
> 2.22.x)?
> 3. Do we (just) document junit-platform* must be explicitly set in project
> dependencies for 2.22? (side note there: doc/website of 2.22 seems no more
> directly accessible online, is it intended since here the config is
> different?)
> 4. Do we just do a 3.0.0? (M4 is proven quite stable now so we could
> mitigate coming changes which are not testing provider related I think)
>
> I'd be for 1 (whatever version works) or 3 since it is the least investment
> very short term and enables to go with 4 as soon as ready.
>
> Hope it makes sense.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 4 mai 2020 à 20:42, Stephane Nicoll  a
> écrit :
>
> > OK. With that in mind, I think the surefire plugin shouldn't require a
> > newer version of JUnit in a maintenance release that way. I understand
> it's
> > fixed and can lead to problem anyway but there will be less problems if
> you
> > rely on an older version and backward compatiblity if a newer version is
> > around. I think we need to weigh what that change brings vs. the impact
> on
> > existing users upgrading to 2.22.3
> >
> > On Mon, May 4, 2020 at 7:36 PM Romain Manni-Bucau  >
> > wrote:
> >
> > > Yes but with transitive game it is not well positionned in the
> classpath
> > > (once again not saying it is "right", just the way it was done
> > originally)
> > > and surefire provider dependencies win so it must be redefined to be
> used
> > > in 2.x.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 4 mai 2020 à 18:52, Christian Stein  a
> > écrit :
> > >
> > > > On Mon, May 4, 2020 at 6:45 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Le lun. 4 mai 2020 à 18:30, Stephane Nicoll <
> > stephane.nic...@gmail.com
> > > >
> > > > a
> > > > > écrit :
> > > > >
> > > > > ...
> > > >
> > > > > OK. Why is our build failing with that error if we're importing the
> > > JUnit
> > > > > > 5.5.2 bom and it does not fail if we're importing the JUnit 5.6.2
> > > bom?
> > > > > Our
> > > > > > test dependencies have "junit-jupiter" in test scope which brings
> > the
> > > > > > engine.
> > > > > >
> > > > > > That looks like Surefire is using the user version to me. Anyway,
> > if
> > > it
> > > > > > wasn't we wouldn't have the error above, wouldn't we?
> > > > > >
> > > > >
> > > > > AFAIK you don't import junit-platform-launcher in 1.5.2 so it
> fails.
> > > > > So surefire uses user version but misses one dep which takes in its
> > own
> > > > > pom.
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> https://repo.maven.apache.org/maven2/org/junit/junit-bom/5.5.2/junit-bom-5.5.2.pom
> > > >
> > > >
> > > > contains
> > > >
> > > > 
> > > > org.junit.platform
> > > > junit-platform-launcher
> > > > 1.5.2
> > > > 
> > > >
> > >
> >
>

Re: Maven Runtime Metrics System - MNG-6899

[Enrico Olivelli]

Robert

Il Sab 2 Mag 2020, 15:11 Robert Scholte  ha scritto:

> If I take a look at the pom of maven-metrics, I see no dependency on Maven.
> And looking at
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> [
> https://github.com/apache/maven-studies/tree/maven-metrics/maven-metrics/src/main/java/org/apache/maven/metrics
> ]
> This looks a lot like
> https://github.com/eclipse/microprofile-metrics/tree/master/api/src/main/java/org/eclipse/microprofile/metrics
> [
> https://github.com/eclipse/microprofile-metrics/tree/master/api/src/main/java/org/eclipse/microprofile/metrics
> ]
>
> So do we need to maintain our own Metrics API?
>

Yes it is really better.

We will be in charge for this API, it will be a new API on which we will
depend in many part of Maven core and in plugins.
It is better to not depend on third party.

There are other initiatives like microprofile metrics.

The API itself is very small and we could add an implementation that uses
micro profile. But we must be independent.

Enrico



> thanks,
> Robert
> On 2-5-2020 10:26:19, Enrico Olivelli  wrote:
> Hello community,
> I am now ready to move forward with concrete steps for the implementation
> of Maven Runtime Metrics.
>
> This is the JIRA
> https://issues.apache.org/jira/browse/MNG-6899
>
> It links to my proof-of-concept branch on maven studies.
> https://github.com/apache/maven-studies/tree/maven-metrics
>
> In order to move forward I have to create an independent module/git
> repository for the Maven Metrics Runtime API.
> Currently I have it on maven-studies inside Maven Core but this is not
> good, because I would like to use it in Plugins independently from the
> version of Maven Core.
> When you run the plugin on an old version of Maven all of the data will be
> simply ignored.
>
> My plan:
> - create a git repository
> - put there the first version of the API (maybe we can put there a simple
> implementation of the API, but I could leave it off for the first release)
> - release it to the public
> - use it in Maven 3.7
> - use it in Wagon and in Resolver and in other "interesting" modules/core
> plugins
>
> Best regards
> Enrico
>

Maven Runtime Metrics System - MNG-6899

[Enrico Olivelli]

Hello community,
I am now ready to move forward with concrete steps for the implementation
of Maven Runtime Metrics.

This is the JIRA
https://issues.apache.org/jira/browse/MNG-6899

It links to my proof-of-concept branch on maven studies.
https://github.com/apache/maven-studies/tree/maven-metrics

In order to move forward I have to create an independent module/git
repository for the Maven Metrics Runtime API.
Currently I have it on maven-studies inside Maven Core but this is not
good, because I would like to use it in Plugins independently from the
version of Maven Core.
When you run the plugin on an old version of Maven all of the data will be
simply ignored.

My plan:
- create a git repository
- put there the first version of the API (maybe we can put there a simple
implementation of the API, but I could leave it off for the first release)
- release it to the public
- use it in Maven 3.7
- use it in Wagon and in Resolver and in other "interesting" modules/core
plugins

Best regards
Enrico

Re: overwriting a read-only attribute in Checkstyle config

[Enrico Olivelli]

Javier,
In upcoming Maven release 3.7
0  it won't be allowed to overwrite readonly attributes.

I am sorry, I don't know how to fix your issue.

Question for the community: can we drop the 'readonly' flag from the
'resources' field of checkstyle plugin?

I mean, it has always been writable up to now, so if we don't want to break
existing poms we should make it explicitly non readonly.
Is there any problem with this approach?

I image that we will do this way for other falsely readonly property

Enrico

Il Gio 23 Apr 2020, 20:06 Javier Gómez  ha scritto:

> Hi,
>
> we are testing a config, that overwrites a readonly attribute, in Maven
> Checkstyle plugin config, to be able to analyze a set of resource
> folders in project root folder.
>
> We don't want to define this spefic folders config in POM build
>  block, to avoid inherit that in child POMs, so we are
> forcing that at the plugin level, specifying the  block
> attribute.
>
> That this is a read-only attribute, and we define it in the plugin
> configuration, does not imply that the compilation fails, as I would
> expect. Is that correct?
>
> Any side effect that we could expect of this configuration?
>
> Thanks in advance.
>
>
> ===
>
> # Directory structure layout:
>
> /module1
> src/main/java
> src/main/resources
> pom.xml
> /module2
> ...
> /src
> /dir1
> /dir2
> pom.xml
>
> #
> # Parent POM build config
> #
>
> 
>
> 
>
> [Checkstyle config]
>
> 
>
> 
>
>   # config to analyze the specific resources folders, in project
> root folder
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
>   false
>   
>   
>   
>   dir1
>   
>   
>   dir2
>   
>   
>   
>   
>
>
>

Re: Proposal to deprecate Maven 3.0.x

[Enrico Olivelli]

+1

Enrico

Il Gio 16 Apr 2020, 07:39 Romain Manni-Bucau  ha
scritto:

> +1
>
> Le jeu. 16 avr. 2020 à 03:31, Olivier Lamy  a écrit :
>
> > +1
> > Good idea Manfred!
> >
> > On Thu, 16 Apr 2020 at 08:22, Manfred Moser 
> > wrote:
> >
> > > +100
> > >
> > > I would deprecate everything before the maven-resolver import back to
> the
> > > project while you are at it. Not sure exact version but 3.1x would
> > > definitely on that list as well. Maybe also 3.2x
> > >
> > > Manfred
> > >
> > > Tibor Digana wrote on 2020-04-15 13:39 (GMT -07:00):
> > >
> > > > Some users still use Maven 3.0.5 and they require a support for
> > > > compatibility reasons between nowadays Maven plugins and the Maven
> > > > 3.0.x.
> > > >
> > > > We have a couple of reasons to deprecate this version (JSR-330,
> > > > Components injection, Logger) and we have discussed this issue in
> > > > https://github.com/apache/maven-surefire/pull/274
> > > >
> > > > Let's discuss it.
> > > >
> > > > Cheers
> > > > Tibor17
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>