Re: [VOTE] Require Java 17 for Maven 4

[Xeno Amess]

+1 as a user

Frederik Boster  于2024年2月28日周三 16:15写道：

> +1
>
> On Wed, Feb 28, 2024, 08:31 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
> >
> >
>

Re: [DISCUSS] Java version for Maven

[Xeno Amess]

> people will be able to work on solutions after anyway.
Agreed as they can maintain a fork anyway if they really need.

From: Romain Manni-Bucau 
Sent: Wednesday, February 28, 2024 3:50:31 AM
To: Maven Developers List 
Subject: Re: [DISCUSS] Java version for Maven

Plain standard asf votes - or under the vote manager rules as allowed by
asf if it is agreed but means another discussion.

I dont care much the details but keeping energy for this thread starts to
be more negative on the community than anything positive IMHO so hope we
close it with a decision then move on.
Not everybody will be happy but we'll stop cycles hopefully and unhappy
people will be able to work on solutions after anyway.

Le mar. 27 févr. 2024 à 20:02, Aleksandar Kurtakov  a
écrit :

> On Tue, Feb 27, 2024 at 8:16 PM Xeno Amess  wrote:
>
> > whose vote would count and what be the majority:)
> > for example should my vote count? or not?
> > or just some committers? but why just committers(or not)(as some of them
> > might have less contributions even than non-committers)?
> > or just pmc?
> > or everyone share 1 vote(wow I don't think it shall work this way)
> >
>
> This is something that should be defined by Apache Foundation and/or Maven
> PMC. I don't plan to neither dive into the discussion more nor to try
> imposing our rules on another project.
> If the project believes that continuing such discussion in circles brings
> anything good - so be it.
>
>
>
> >
> >
> > Aleksandar Kurtakov  于2024年2月28日周三 01:15写道：
> >
> > > On Tue, Feb 27, 2024 at 6:13 PM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > wrote:
> > >
> > > > Not sure we'll converge guys but shouldnt we make a vote? Seems we
> all
> > > > understand the impacts technically so maybe time to decide else we'll
> > > still
> > > > be there in a year.
> > > >
> > >
> > > This is exactly what I try in the Eclipse community - vote, majority
> wins
> > > and move on.
> > > If there is one thing I'm 100% sure now is that no one from one camp
> will
> > > convince someone from the other camp so all the endless discussions
> bring
> > > only extra stress.
> > >
> > >
> > > >
> > > > Le mar. 27 févr. 2024 à 16:41, John Neffenger  a
> > > écrit :
> > > >
> > > > > On 2/26/24 11:42 AM, Basil Crow wrote:
> > > > > > We had a similar conversation in the Jenkins community, and I
> wrote
> > > up
> > > > > > our conclusions here:
> > > > >
> > > > > We also had a similar conversation in the NetBeans community, with
> > the
> > > > > final vote to drop JDK 8 (vote result: 20 to 1.5). See here:
> > > > >
> > > > > [VOTE][RESULT] Minimum JDK build and run policy (dropping JDK 8)
> > > > > https://lists.apache.org/thread/oq8bof3owctq0ot6xwk03n3w45d09zcc
> > > > >
> > > > > In particular, see the comments from James Gosling:
> > > > >
> > > > > Re: Lets talk about JDK 8 (new year edition)
> > > > > https://lists.apache.org/thread/sspm6fy1xq0jn2k8lfprn47v69g88jvh
> > > > >
> > > > >"So….  In my opinion, JDK8 must die."
> > > > >"Stop the unholy contortions to coexist.  Kill it.  Nail its
> > coffin
> > > > > closed.  Do not look back."
> > > > >
> > > > > I couldn't agree more. :-)
> > > > >
> > > > > John
> > > > >
> > > > >
> -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Aleksandar Kurtakov
> > > Red Hat Eclipse Team
> > >
> >
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>

Re: [DISCUSS] Java version for Maven

[Xeno Amess]

whose vote would count and what be the majority:)
for example should my vote count? or not?
or just some committers? but why just committers(or not)(as some of them
might have less contributions even than non-committers)?
or just pmc?
or everyone share 1 vote(wow I don't think it shall work this way)


Aleksandar Kurtakov  于2024年2月28日周三 01:15写道：

> On Tue, Feb 27, 2024 at 6:13 PM Romain Manni-Bucau 
> wrote:
>
> > Not sure we'll converge guys but shouldnt we make a vote? Seems we all
> > understand the impacts technically so maybe time to decide else we'll
> still
> > be there in a year.
> >
>
> This is exactly what I try in the Eclipse community - vote, majority wins
> and move on.
> If there is one thing I'm 100% sure now is that no one from one camp will
> convince someone from the other camp so all the endless discussions bring
> only extra stress.
>
>
> >
> > Le mar. 27 févr. 2024 à 16:41, John Neffenger  a
> écrit :
> >
> > > On 2/26/24 11:42 AM, Basil Crow wrote:
> > > > We had a similar conversation in the Jenkins community, and I wrote
> up
> > > > our conclusions here:
> > >
> > > We also had a similar conversation in the NetBeans community, with the
> > > final vote to drop JDK 8 (vote result: 20 to 1.5). See here:
> > >
> > > [VOTE][RESULT] Minimum JDK build and run policy (dropping JDK 8)
> > > https://lists.apache.org/thread/oq8bof3owctq0ot6xwk03n3w45d09zcc
> > >
> > > In particular, see the comments from James Gosling:
> > >
> > > Re: Lets talk about JDK 8 (new year edition)
> > > https://lists.apache.org/thread/sspm6fy1xq0jn2k8lfprn47v69g88jvh
> > >
> > >"So….  In my opinion, JDK8 must die."
> > >"Stop the unholy contortions to coexist.  Kill it.  Nail its coffin
> > > closed.  Do not look back."
> > >
> > > I couldn't agree more. :-)
> > >
> > > John
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>

Re: [DISCUSS] Java version for Maven

[Xeno Amess]

Yep you got a point, I hate streams either.(especially when using streams
be not necessary.)

Romain Manni-Bucau  于2024年2月23日周五 22:43写道：

> From my experience people hating var will also hate completionstage and at
> some point streams (or they willfully embrace them just using forEach which
> is a counter usage IMHO).
> Every time I digged it was 100% a knowledge+(IT) culture thing.
> But once again, I'm not sure it is about us - if so I would say I don't
> care much - but how attracting we can be since our community is not crazy
> active outside.
>
> This is for an an opportunity we should take IMHO.
>
> Now if we just want to speak about style and lib usage I guess we have
> enough threads showing we all diverge so not sure there is a way to
> converge anytime - nor the need to be honest.
>
> 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 ven. 23 févr. 2024 à 15:10, Tamás Cservenák  a
> écrit :
>
> > Make love not var!
> >
> > T
> >
> > On Fri, Feb 23, 2024 at 3:09 PM Xeno Amess  wrote:
> >
> > > I hate var.
> > > 
> > > From: Tamás Cservenák 
> > > Sent: Friday, February 23, 2024 9:52:08 PM
> > > To: Maven Developers List 
> > > Subject: Re: [DISCUSS] Java version for Maven
> > >
> > > Howdy,
> > >
> > > Some more stats based on 2nd package from Brian
> > >
> > > https://gist.github.com/cstamas/8207f8d70882090a1c63cdedc256ec56
> > >
> > > On Fri, Feb 23, 2024 at 2:08 PM Elliotte Rusty Harold <
> > elh...@ibiblio.org>
> > > wrote:
> > >
> > > > Yes, with var you still get type checks, unlike in Python. But I have
> > > > wasted so much time debugging Python code simply because the type of
> a
> > > > local variable wasn't right there in the declaration that I remain
> > > > unconvinced var was ever a good idea. I have been convinced by
> > > > experience that implicitly typed local variables dramatically reduce
> > > > debugging speed. This isn't something I believed two years ago. Back
> > > > then I mostly didn't think about it. But since then I have worked a
> > > > lot with implicit typing, and it is painful.
> > > >
> > > > IDEs are not a full solution. They're better in Java than Python, I
> > > > admit, but I spend more time reading code in tools like Github and
> > > > Critique than in IDEs.
> > > >
> > > > I don't think banning var goes against the community in any way. It's
> > > > simply another style choice for improved readability and
> > > > maintainability, like everything spotless and checkstyle currently
> do.
> > > >
> > > >
> > > > On Fri, Feb 23, 2024 at 12:58 PM Romain Manni-Bucau
> > > >  wrote:
> > > > >
> > > > > Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold <
> > > elh...@ibiblio.org>
> > > > a
> > > > > écrit :
> > > > >
> > > > > > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
> > > > > >  wrote:
> > > > > > >
> > > > > > > @Elliotte while you are pretty right in terms of *compile*
> > features
> > > > but
> > > > > > it
> > > > > > > ignores the biggest criteria for any ASF project : the
> community.
> > > > Even if
> > > > > > > silly, attracting people with Java 8 is born dead today (to
> > > > illustrate it
> > > > > > > just ask somebody to no more use "var" to do a PR for ex, he
> will
> > > > start
> > > > > > to
> > > > > > > "pf" ;)).
> > > > > >
> > > > > > Going off on a tangent but I would reject any PR that showed up
> in
> > my
> > > > > > code review queue that used "var", regardless of JDK version.
> It's
> > an
> > > > > > abomination that should never have been added to Java. It
> > prioritizes
> > > > > > a trivial speed up in writing code at the cost of a signifi

Re: [DISCUSS] Java version for Maven

[Xeno Amess]

I hate var.

From: Tamás Cservenák 
Sent: Friday, February 23, 2024 9:52:08 PM
To: Maven Developers List 
Subject: Re: [DISCUSS] Java version for Maven

Howdy,

Some more stats based on 2nd package from Brian

https://gist.github.com/cstamas/8207f8d70882090a1c63cdedc256ec56

On Fri, Feb 23, 2024 at 2:08 PM Elliotte Rusty Harold 
wrote:

> Yes, with var you still get type checks, unlike in Python. But I have
> wasted so much time debugging Python code simply because the type of a
> local variable wasn't right there in the declaration that I remain
> unconvinced var was ever a good idea. I have been convinced by
> experience that implicitly typed local variables dramatically reduce
> debugging speed. This isn't something I believed two years ago. Back
> then I mostly didn't think about it. But since then I have worked a
> lot with implicit typing, and it is painful.
>
> IDEs are not a full solution. They're better in Java than Python, I
> admit, but I spend more time reading code in tools like Github and
> Critique than in IDEs.
>
> I don't think banning var goes against the community in any way. It's
> simply another style choice for improved readability and
> maintainability, like everything spotless and checkstyle currently do.
>
>
> On Fri, Feb 23, 2024 at 12:58 PM Romain Manni-Bucau
>  wrote:
> >
> > Le ven. 23 févr. 2024 à 13:44, Elliotte Rusty Harold 
> a
> > écrit :
> >
> > > On Fri, Feb 23, 2024 at 12:23 PM Romain Manni-Bucau
> > >  wrote:
> > > >
> > > > @Elliotte while you are pretty right in terms of *compile* features
> but
> > > it
> > > > ignores the biggest criteria for any ASF project : the community.
> Even if
> > > > silly, attracting people with Java 8 is born dead today (to
> illustrate it
> > > > just ask somebody to no more use "var" to do a PR for ex, he will
> start
> > > to
> > > > "pf" ;)).
> > >
> > > Going off on a tangent but I would reject any PR that showed up in my
> > > code review queue that used "var", regardless of JDK version. It's an
> > > abomination that should never have been added to Java. It prioritizes
> > > a trivial speed up in writing code at the cost of a significant slow
> > > down in reading and debugging code. Working in Python for the last
> > > couple of years has thoroughly convinced me that strong, explicit
> > > compile time types are the right way to go. I've seen what happens
> > > when you don't have them, and it's not fun.
> > >
> >
> > I assume you never used it to write that cause you don't loose compile
> > checks, you are not slower to read nor debug but generally faster cause
> > readability is increased and if you miss the 35 char long type your
> > preferred IDE will compensate that easily.
> > It is literally similar to streams or even plain old java, it depends the
> > habit of the coder but if we consider that we would also prevent foreach
> > usage.
> > You can also reverse it and write the exact same sentence on "not using
> > var", how slow it is to read such a code where half of the chars don't
> > bring any useful data or encourage palantir formatting to break on
> multiple
> > lines a single statement.
> > So IMHO this is not something right to think nor even consider.
> >
> > Ultimately the point is not "do we think it is good or not", it is
> > literally that if we go against the move then we go against the
> community -
> > keep in mind we should probably not be the primary citizens there - and
> > therefore I'm not sure the point to be at Apache if we don't care about
> our
> > community.
> > I'm clearly to stay there and enable people to join rather than staying
> > alone 10 years ago (happy anniversary java 8 ;)).
> >
> >
> > >
> > > --
> > > 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
> > >
> > >
>
>
>
> --
> 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: [DISCUSS] Java version for Maven

[Xeno Amess]

> The raw numbers are a more reasonable picture.
Elliotte, this is just the begin of maven 4, and maven 4.x is not just for
current projects, but for projects in the next several years.(and I guess
nobody here wanna increasing jdk major version during a same maven major
version?)
So if we agree that projects in future be more likely for higher jdk
versions, I think the normalization somehow reasonable...Just IMO

Elliotte Rusty Harold  于2024年2月22日周四 21:23写道：

> This is all very interesting data for reasons that go well beyond Maven.
> Thanks!
>
> My personal takeaway is that JDK 8 is a much bigger part of the market
> than I would have guessed and Java 11 and Java 7 are both much less.
> It looks to me like the Java world is dividing into two camps: The
> "risk averse, stay with what works and what we know" camp on Java 8
> and the Bleeding Edge camp on the latest LTS release.
>
> It's possible that's not what's really happening. Java 9 really broke
> compatibility and caused a lot of pain for folks, so it might just be
> a split between devs who were burned by Java 9+ and devs who weren't.
>
> Either way, we started with only the last 30 days of data so I don't
> think the normalization is reasonable. The lifespan of Java 8, 11, and
> 17 are all years before this data was taken so it's not like those
> clients couldn't have moved to Java 17 for some part of the period.
> The raw numbers are a more reasonable picture. I do not agree that the
> weighted pie shows what's dead and what's sliding out.
>
> On Thu, Feb 22, 2024 at 4:17 AM Tamás Cservenák 
> wrote:
> >
> > For start I "normalized" the Java strings to a form like "Java 8" or
> "Java
> > 17". This resulted in pretty much similar results as Romain PDF (Azul
> > report).
> >
> > But then realized, we should consider this: Not every LTS existed at the
> > same time span (and we discuss the future here, not the past). Here is
> some
> > history I collected:
> >
> > - Java 8: Covers strings like "Java 1.8.0-25" (2014) to "Java 1.8.0-401"
> > (2024), that is 10 year span.
> > - Java 11: Covers strings like "Java 11-ea" (2018) to "Java 11.0.22"
> > (2024), that is a 6 year span.
> > - Java 17: Covers strings like "Java 17-ea" (2021) to "Java 17.0.10"
> > (2024), that is a 3 year span.
> > - Java 21: Covers strings like "Java 21-ea" (2023) to "Java 21.0.2"
> (2024),
> > that is 1 year span.
> >
> > So, "normalized" and "weighted" (by lifespan) results are these:
> > https://gist.github.com/cstamas/d2e5560f24ebe6a667834aa1f44d6fc1
> >
> > Weighted pie immediately shows which Java versions are "dead" (are
> present,
> > but are "sliding out") and which ones are "alive and kicking" (and
> adoption
> > is quite high).
> >
> > ---
> >
> > Refs:
> > - https://www.java.com/releases/
> > - https://openjdk.org/projects/jdk/11/
> > - https://openjdk.org/projects/jdk/17/
> > - https://openjdk.org/projects/jdk/21/
> >
> > On Thu, Feb 22, 2024 at 8:50 AM Tamás Cservenák 
> wrote:
> >
> > > Howdy,
> > >
> > > Maven UA is created like this:
> > >
> > >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L555
> > >
> > > I was hoping also for a list of "Apache Maven ..." lines with
> occurrence
> > > count.
> > >
> > > Now am unsure, for example if any other tool would use "Java X" string
> in
> > > its own UA, is that collected here?
> > >
> > > But let's cook with what we have :)
> > >
> > > T
> > >
> > >
> > > On Thu, Feb 22, 2024, 08:03 Mateusz Gajewski <
> > > mateusz.gajew...@starburstdata.com> wrote:
> > >
> > >> Do you have maven version and java version at the same time report? I
> > >> wonder if old maven is used with old JDK :)
> > >>
> > >> On Wed, Feb 21, 2024 at 23:23 Brian Fox  wrote:
> > >>
> > >> > Hi everyone. I haven't caught up on this thread but Tamas pinged me
> to
> > >> get
> > >> > some usage data from Central. Attached are the Maven versions and
> JDK
> > >> > Version counts as reported by User Agent by distinct IP for the
> last 30
> > >> > days:
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Feb 21, 2024 at 4:15 PM Hunter C Payne
> > >> >  wrote:
> > >> >
> > >> >>  I also want to stress that we care about what maven supports far
> more
> > >> >> than what it requires to build.  If it needs JDK 17 to build but
> the
> > >> jars
> > >> >> are compliant with Java 8, that's fine with me.
> > >> >>
> > >> >> Hunter
> > >> >>
> > >> >> On Wednesday, February 21, 2024 at 12:47:33 PM PST, Romain
> > >> >> Manni-Bucau  wrote:
> > >> >>
> > >> >>  Hmm, not sure im ready for a 200M vanilla build tool even if it
> would
> > >> >> have
> > >> >> been ok legally...
> > >> >>
> > >> >> Le mer. 21 févr. 2024 à 21:41, Hunter C Payne
> > >> >>  a écrit :
> > >> >>
> > >> >> >  I might be wrong but I understood that shipping the JRE/JVM
> > >> required a
> > >> >> > license and this is why most people don't ship with a JVM
> bundled.
> > >> But
> > 

Re: [DISCUSS] Java version for Maven

[Xeno Amess]

Hi.
I use toolchain for multi-release-jars
please don't drop it or provide another way for building multi release jars

From: Romain Manni-Bucau 
Sent: Wednesday, February 21, 2024 3:48:43 PM
To: Maven Developers List 
Subject: Re: [DISCUSS] Java version for Maven

Hi Hervé,

+1000 on the philosophy!

On the toolchain support I still fail to see why maven has toolchain
anywhere in its code.
Look it how it is used:
* Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME,
JAVAEA_HOME or alike)
* Most plugins able to switch the JDK can switch the executable in their
config and use by default ${env.JAVAxx_HOME} or whatever is desired which
is the same indirection than toolchain but without the downside to setup a
toolchain.xml. Then plugins can just use the binary (optionally PathExt on
windows to get the extension) and be it, works really well.

So overall I think we could drop toolchain which ultimately still misses a
few parts to be complete in terms of env setup and make a shared-executable
stronger - likely the future base of exec plugin even if not required.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mer. 21 févr. 2024 à 08:39, Hervé Boutemy  a
écrit :

> for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have
> to update our plans
> https://maven.apache.org/developers/compatibility-plan.html
>
> the approach I'd love to promote is "what do we require to not hurt our
> diversity of users when upgrading minimum prerequisites" (and I'm doing it
> on my free time because I do care about the diversity of our community)
> => let's work on the enablers
>
> Java prerequisite for Maven core is something, but everything will start
> from plugins: that's why we started the plugins "requirement history"
> see for example
> https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html
>
> for a summary on our own plugins, see last column of
>
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html
>
> As you can see, not many plugins are not covered yet: who wants to work on
> this?
>
>
> Another good item cited is improving decoupling JDK of Maven from JDK to
> compile and run tests.
> IIRC, Guillaume prepared something about auto-importing available JDKs
> from sdkman, which is a great idea: I don't know if this was closed done,
> but I suppose other JDK switcher tools should be supported, I'm
> particularly interested on knowing what Windows users need
> One aspect that I know is not well done is that the MANIFEST in jar
> describes JDK release from Maven core, not target: we should probably do
> something
> Another aspect is that toolchains support has to be enabled in pom.xml: it
> would be useful for it to work from just CLI also.
>
> I'm sure there are other features that would be useful on this: who wants
> to work on this?
>
>
> The 2 previous enablers look sufficient to me: any other enabler someone
> thinks about?
>
> And more importantly: who wants to work on it? plan, track progress,
> document, explain?
> we need community's help to prepare a smooth change: updating our plans
> will be a consequence of this preparation
>
> Regards,
>
> Hervé
>
> Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a écrit :
> > Howdy,
> >
> > I intentionally used "Maven" here, and not "Maven 4" as I am sure the
> > majority of Maven users do not run Maven on the same Java version they
> > target with their build. We do not do that either.
> >
> > Some snippets from Herve (who is the ONLY one doing reproducible checks,
> > kudos for that) votes:
> >
> > Sun, Feb 18, 2024, 9:38 AM
> > [VOTE] Release Apache Maven Shade Plugin version 3.5.2
> > Reproducible Build ok: reference build done with JDK 11 on *nix
> >
> > Wed, Jan 31, 2024, 5:06 AM
> > [VOTE] Release Apache Maven JLink Plugin version 3.2.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Mon, Jan 8, 2024, 8:29 AM
> > [VOTE] Release Maven Plugin Tools version 3.11.0
> > Reproducible Builds ok: reference build done with JDK 8 on Windows with
> > umask
> >
> > Mon, Dec 18, 2023, 8:59 AM
> > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Mon, Dec 18, 2023, 8:59 AM
> > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> > Reproducible Builds ok: reference build done on *nix with JDK 21 and
> umask
> > 022
> >
> > Wed, Nov 29, 2023, 8:16 AM
> > [VOTE] Apache Maven Build Cache Extension 1.1.0
> > Reproducible Build ok: reference build done on *nix with JDK 11
> >
> > Sun, Nov 

Re: Java version for Maven 4?

[Xeno Amess]

actually if it can, just upgrading to 17 seems a good idea...
as spring's latest is for 17, maybe we can join forces to make the market
to 17...
(however I somehow love fiber so if people wanna 21 I just well be
happy)
I always think toolchains shall not be somehow public slaves for every
repo, and fulfil every of their requirements...
instead should become somehow master to force some outdated repo move on.
And as for the repos who wanna stay at 8, just let them use old toolchain
versions, and die out slowly, why should we even care for them and must
make sure they be able to use the latest maven version to build? We are not
slaves nor babysitters for kids after all.
If they want third party maintenance they can just pay for that, or hire
some group, I just don't think it that hard. like just what azul or
jetbrains jbm do...


Xeno Amess  于2024年2月21日周三 13:41写道：

> You are not the only one who hates jigsaw.
>
> As a real joke, about 4-6 years ago in a jackson mailing list, an [oracle
> employee] ask for them to delete module-info in the jars to make it
> runnable at lower jdk version, so yes even people in oracle (at least one)
> seems don't really agree with jigsaw...
>
> Gary Gregory  于2024年2月7日周三 07:38写道：
>
>> I have no use for JPMS today, I just don't want it to get in the way,
>> which
>> is impossible since there is no --dont-bother-me-jpms flag...
>>
>> Gary
>>
>> On Tue, Feb 6, 2024, 6:34 PM Martin Desruisseaux <
>> martin.desruisse...@geomatys.com> wrote:
>>
>> > Hello
>> >
>> > Le 2024-02-06 à 16 h 11, Hunter C Payne a écrit :
>> >
>> > > Nobody wants Jigsaw and the API improvements aren't enough to get
>> > > people to upgrade.
>> > >
>> > I cannot debate on whether a small minority, or a big minority, or a
>> > majority of developers want JPMS (a.k.a. Jigsaw), because I have no data
>> > for backing my claims. However, I have not see someone else providing
>> > reliable data (e.g. a serious study) for backing opposite claims
>> > neither. But one thing sure is that it is not "nobody wants Jigsaw",
>> > since at least two persons have expressed interest on this mailing list.
>> >
>> > Opinions based on personal experience are indicative of a market segment
>> > at best. Some peoples may base their opinions on their experience with
>> > Google or Amazon. My own personal experience is with space agencies,
>> > meteorological/oceanographical agencies, international standardization
>> > organizations, etc. They have different consumers, different
>> > constraints, different priorities. No consumer said directly "I want
>> > JPMS". But they do said "I want faster / more secure / more reliable
>> > software", and JPMS is one tool among others for achieving those goals.
>> > Not a panacea, but a significant help. For example, JPMS improves
>> > security by blocking at the JVM level all unauthorized accesses to
>> > internal packages. I'm not aware of any other non-deprecated solution
>> > providing this security at the JVM level. The few times that I spoke to
>> > peoples working in defence, they were very receptive to that kind of
>> > argument.
>> >
>> > My opinion is that as long as JPMS is so difficult to use in a
>> > non-trivial Maven or Gradle project, we cannot know if a relatively low
>> > adoption is really because of a lack of interest. Even if some
>> > communities are still not interested by JPMS no matter how easy, no
>> > personal experience can be generalized to the whole market. If a tool
>> > improving software security exists, I think it is a responsibility to
>> > make that tool accessible to developers who want to use it (again, I
>> > know that JPMS is not a panacea. But it helps).
>> >
>> > On the larger topic of API improvements in newer Java versions, Panama
>> > (coming final in Java 22) is a big feature given the important native
>> > libraries out there (e.g. for Artificial Intelligence). It may be of
>> > interest to Maven itself, e.g. for accessing C/C++ or Python build
>> tools.
>> >
>> >  Martin
>> >
>> >
>>
>

Re: Java version for Maven 4?

[Xeno Amess]

You are not the only one who hates jigsaw.

As a real joke, about 4-6 years ago in a jackson mailing list, an [oracle
employee] ask for them to delete module-info in the jars to make it
runnable at lower jdk version, so yes even people in oracle (at least one)
seems don't really agree with jigsaw...

Gary Gregory  于2024年2月7日周三 07:38写道：

> I have no use for JPMS today, I just don't want it to get in the way, which
> is impossible since there is no --dont-bother-me-jpms flag...
>
> Gary
>
> On Tue, Feb 6, 2024, 6:34 PM Martin Desruisseaux <
> martin.desruisse...@geomatys.com> wrote:
>
> > Hello
> >
> > Le 2024-02-06 à 16 h 11, Hunter C Payne a écrit :
> >
> > > Nobody wants Jigsaw and the API improvements aren't enough to get
> > > people to upgrade.
> > >
> > I cannot debate on whether a small minority, or a big minority, or a
> > majority of developers want JPMS (a.k.a. Jigsaw), because I have no data
> > for backing my claims. However, I have not see someone else providing
> > reliable data (e.g. a serious study) for backing opposite claims
> > neither. But one thing sure is that it is not "nobody wants Jigsaw",
> > since at least two persons have expressed interest on this mailing list.
> >
> > Opinions based on personal experience are indicative of a market segment
> > at best. Some peoples may base their opinions on their experience with
> > Google or Amazon. My own personal experience is with space agencies,
> > meteorological/oceanographical agencies, international standardization
> > organizations, etc. They have different consumers, different
> > constraints, different priorities. No consumer said directly "I want
> > JPMS". But they do said "I want faster / more secure / more reliable
> > software", and JPMS is one tool among others for achieving those goals.
> > Not a panacea, but a significant help. For example, JPMS improves
> > security by blocking at the JVM level all unauthorized accesses to
> > internal packages. I'm not aware of any other non-deprecated solution
> > providing this security at the JVM level. The few times that I spoke to
> > peoples working in defence, they were very receptive to that kind of
> > argument.
> >
> > My opinion is that as long as JPMS is so difficult to use in a
> > non-trivial Maven or Gradle project, we cannot know if a relatively low
> > adoption is really because of a lack of interest. Even if some
> > communities are still not interested by JPMS no matter how easy, no
> > personal experience can be generalized to the whole market. If a tool
> > improving software security exists, I think it is a responsibility to
> > make that tool accessible to developers who want to use it (again, I
> > know that JPMS is not a panacea. But it helps).
> >
> > On the larger topic of API improvements in newer Java versions, Panama
> > (coming final in Java 22) is a big feature given the important native
> > libraries out there (e.g. for Artificial Intelligence). It may be of
> > interest to Maven itself, e.g. for accessing C/C++ or Python build tools.
> >
> >  Martin
> >
> >
>

Re: Java version for Maven 4?

[Xeno Amess]

well I just doubt.

From: Xeno Amess 
Sent: Tuesday, February 6, 2024 12:18:42 PM
To: Maven Developers List 
Subject: Re: Java version for Maven 4?

well nothing affensive but do any guys got any payments from those still-java-6 
companies for maintaining maven for them？

From: Gary Gregory 
Sent: Tuesday, February 6, 2024 6:14:32 AM
To: Maven Developers List 
Subject: Re: Java version for Maven 4?

An interesting question for me is whether we need to think about companies
that pay for old JDK support and how that affects our support for these old
JDKs.

Gary

On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold 
wrote:

> On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau 
> wrote:
> >
> > Hi Elliotte,
>
> > Java 11 support is already EOL for most vendor until you go "premium"
> > flavor which will likely be very few people and most of them will be able
> > to pay somebody to backport the needed stuff in custom distro of their
> work
> > if needed anyday so not sure we should consider it.
>
> At least three big tech companies I know of build their own JDKs. At
> least one, possibly two, ship and support older JDKs for their
> customers. None of them are tied to Oracle and what Oracle is willing
> to support. If Oracle and all its data went to the great bit bucket in
> the sky tomorrow, they'd keep right on rolling. It would not even be a
> speed bump. They don't pay for premium support. They compete to
> provide premium support.*
>
> * There are some caveats here I won't go into for confidentiality
> reasons, but I can say that Azul's business model works.
>
> > On the other side most libraries tend to move forward faster and if you
> > like big ones, i'll take Spring or JakartaEE as an example - big user
> base
> > rather than big company$ ;) - and they don't even support Java 11
> anymore.
>
> Used by big tech customers. Not so much used by big tech companies
> themselves, that tend to run on stacks developed in house over more
> than a decade.
>
> --
> 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: Java version for Maven 4?

[Xeno Amess]

well nothing affensive but do any guys got any payments from those still-java-6 
companies for maintaining maven for them？

From: Gary Gregory 
Sent: Tuesday, February 6, 2024 6:14:32 AM
To: Maven Developers List 
Subject: Re: Java version for Maven 4?

An interesting question for me is whether we need to think about companies
that pay for old JDK support and how that affects our support for these old
JDKs.

Gary

On Mon, Feb 5, 2024, 4:28 PM Elliotte Rusty Harold 
wrote:

> On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau 
> wrote:
> >
> > Hi Elliotte,
>
> > Java 11 support is already EOL for most vendor until you go "premium"
> > flavor which will likely be very few people and most of them will be able
> > to pay somebody to backport the needed stuff in custom distro of their
> work
> > if needed anyday so not sure we should consider it.
>
> At least three big tech companies I know of build their own JDKs. At
> least one, possibly two, ship and support older JDKs for their
> customers. None of them are tied to Oracle and what Oracle is willing
> to support. If Oracle and all its data went to the great bit bucket in
> the sky tomorrow, they'd keep right on rolling. It would not even be a
> speed bump. They don't pay for premium support. They compete to
> provide premium support.*
>
> * There are some caveats here I won't go into for confidentiality
> reasons, but I can say that Azul's business model works.
>
> > On the other side most libraries tend to move forward faster and if you
> > like big ones, i'll take Spring or JakartaEE as an example - big user
> base
> > rather than big company$ ;) - and they don't even support Java 11
> anymore.
>
> Used by big tech customers. Not so much used by big tech companies
> themselves, that tend to run on stacks developed in house over more
> than a decade.
>
> --
> 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: Java version for Maven 4?

[Xeno Amess]

I vote for kill jdk8 out as to force them upgrade to 11+

From: Tamás Cservenák 
Sent: Sunday, February 4, 2024 10:35:55 PM
To: Maven Developers List 
Subject: Re: Java version for Maven 4?

Howdy,

See Inline.

On Sun, Feb 4, 2024 at 3:01 PM Elliotte Rusty Harold 
wrote:

> I can live with Java 11 if I have to, though I really don't see the
> point. Anything past Java 11 ranges from a major hassle to blocker for
> corporate developers, including those at big tech companies like Meta
> and Google, who are stuck on older versions as a matter of policy and
> internal support.
>
>
I see no problem here, those who are stuck with Java 8, can stick (sorry
for the pun) with Maven 3.9.x forever as well.

This thread is about Maven4, and its GA is still far away, so I see no need
for it to adapt somewhere in the unknown-how-far future (once it becomes
GA) for the sake of those who are stuck in the past.



Thanks
T



> On Sat, Feb 3, 2024 at 2:17 PM Martin Desruisseaux
>  wrote:
> >
> > Hello
> >
> >  From the replies in this thread, it seems to me that there is a
> > consensus for moving Maven 4 to some Java version after 8. I see:
> >
> >   * 0 in favour of Java 11
> >   * 1.5 in favour of Java 17 (the .5 is because I split a vote between
> > Java 17 and 21)
> >   * 2.5 in favour of Java 21
> >   * 4 seem neutral (including myself)
> >
> > Do we take that as an agreement to require Java 21 for building Maven 4?
> >
> > On a related question, what should be the minimal Java version for
> > *running* Maven 4? Keeping in mind that if Java 21 (for example) was
> > required, users would still be able to compile for an older Java version
> > using the --release option.
> >
> >  Martin
> >
>
>
> --
> 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: Why some of the files are not with ASF headers?

[Xeno Amess]

I'm not meaning about tecniqually(how to exclude some files from detection)
but just, if we should do so.

Xeno Amess  于2024年1月31日周三 11:08写道：

> Is there any rules to allow some files not adding asf headers? Or actually
> we shall add ASF headers to all files?
>

Why some of the files are not with ASF headers?

[Xeno Amess]

Is there any rules to allow some files not adding asf headers? Or actually
we shall add ASF headers to all files?

Re: [HEADS UP] Maven Release 3.9.1 coming soon

[Xeno Amess]

well can we release a RC version instead？
have a feeling it would become another months long waiting...

From: Elliotte Rusty Harold 
Sent: Thursday, March 2, 2023 2:09:21 AM
To: Maven Developers List 
Subject: Re: [HEADS UP] Maven Release 3.9.1 coming soon

https://issues.apache.org/jira/browse/MNG-7714 might be worth waiting
for as well if it can be reproduced. It's the most serious allegation
of a problem in version ordering yet.

On Wed, Mar 1, 2023 at 12:22 PM Tamás Cservenák  wrote:
>
> Just a short info:
>
> The "soon" is delayed a bit. While we had "all set" to do 3.9.1, two
> notable things happened:
>
> Resolver 1.9.6 is almost done:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.6
> (PRs are done, there is some verification ongoing still)
>
> Hence, the decision proposed is to let Maven 3.9.1 "wait" for the resolver
> 1.9.6 release. That will fix all reported and known issues in 3.9.0.
> Moreover, thanks to Guillaume Nodet, the plexus-utils XML related issues
> (MNG-7706, MNG-7709) are being addressed, so a new plexus-utils release
> will be another thing to "wait for".
>
> Thanks
> ~t~
>
> On Sat, Feb 25, 2023 at 4:52 PM Tamás Cservenák  wrote:
>
> > Howdy,
> >
> > I may be late, sorry about that, but few days ago pulled this page from
> > archive org (was hosted and lost on codehaus confluence):
> > https://cwiki.apache.org/confluence/display/MAVEN/Versioning
> >
> > As based on this page was Maven3 versioning implemented, at least
> > according to this page:
> >
> > https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes
> >
> > That was written at dawn of Maven3.
> >
> > Hth
> > T
> >
> > On Sat, Feb 25, 2023, 15:26 Elliotte Rusty Harold 
> > wrote:
> >
> >> After further investigation I'm willing to state that MNG-7701 is
> >> invalid, and I closed it.
> >>
> >> MNG-7700 is mostly invalid. There's a bit of a glitch around the
> >> "canonical representation" of version strings of the form 0.x that
> >> does not affect comparisons. However, nowhere do we define or promise
> >> anything about the canonical representation so it's hard to call it a
> >> bug.
> >>
> >> In all cases I've looked at, the comparison of two versions behaves
> >> according to spec. INHO, neither of these issues should block the
> >> release.
> >>
> >> On Fri, Feb 24, 2023 at 9:03 AM Tamás Cservenák 
> >> wrote:
> >> >
> >> > Howdy,
> >> >
> >> > just an update of Maven status (links will assume you are logged in to
> >> > JIRA):
> >> >
> >> > * 3.9.1 all done
> >> >
> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.1
> >> > * 3.9.1 candidates
> >> >
> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.1-candidate
> >> > (Elliotte plans to fix for weekend MNG-7700 and MNG-7701 if it is not
> >> > grabbed by anyone else until then)
> >> >
> >> > This means 3.9.1 is shaping really nicely
> >> >
> >> > Furthermore, for resolver:
> >> >
> >> > * 1.9.6 (will not make into 3.9.1 but probably 3.9.2):
> >> >
> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.6
> >> > (topic: bugfixes and improvements, would include
> >> > https://issues.apache.org/jira/browse/MNG-7705 that does not yet has
> >> > corresponding MRESOLVER issue)
> >> > * planned 1.10.0
> >> >
> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.10.0
> >> > (topic: HTTP/2 and other improvements, probably makes file-lock default)
> >> >
> >> > Thanks
> >> > T
> >> >
> >> >
> >> > On Fri, Feb 24, 2023 at 4:58 AM Jeremy Landis  >> >
> >> > wrote:
> >> >
> >> > > Update on issue I'm facing.
> >> > >
> >> > > The issue is using the site:jar during the release process.  Rather
> >> than
> >> > > deploy site to any location, we jar it and deploy it with normal
> >> artifacts
> >> > > to Artifactory.  Since that plugin goal wants the full build
> >> (aggregate),
> >> > > it fails against numerous plugins such as javadoc, jxr, etc.  I
> >> presume
> >> > > rather than that running during package phase, it needs to be moved
> >> and run
> >> > > separately like how the site-deploy works with the release plugin.
> >> Any
> >> > > ideas on best way to deal with this?  Right now it feels like its
> >> done in
> >> > > the right place, we even skip the 'site-deploy' entirely.  But
> >> clearly that
> >> > > isn't exactly good enough in this case.
> >> > >
> >> > > I don't think now that this is a maven 3.9.0 issue itself.  I think
> >> its
> >> > > more of something that is a big change in this specific use case that
> >> just
> >> > > needs some direction to resolve.  The more and more I've looked at
> >> this the
> >> > > more I've found little things that have changed over the years that
> >> had
> >> > > resulted in multiple site runs and some plugins from running 

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

[Xeno Amess]

+1 for -e default

From: Romain Manni-Bucau 
Sent: Friday, February 24, 2023 9:15:15 PM
To: Maven Developers List 
Subject: Re: And while I'm on the subject of logging

Hi Elliotte,

I agree -e should be the default, I don't see the point to not have the
error cause when it fails.
Your point 2 is only relevant if you never built the project nor a project
with the same dependencies so I guess we can assume it is a corner case - I
was also often checkouting projects and having to download their deps but
it never had been an issue and actually was good to see what it uses
without opening all the project build files IMHO so really a taste/corner
case point.
So at the end the aggregation report Guillaume proposed and switch -e by
default on mvn 4 sounds like good options, no?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 24 févr. 2023 à 13:33, Kemal Soysal 
a écrit :

> Hi Elliot,
>
> did you try to use mvnDebug?
>
> > Am 24.02.2023 um 13:26 schrieb Elliotte Rusty Harold  >:
> >
> > Real world example from the non-Apache project built with Maven I'm
> > working on this morning.
> >
> > 1. Build fails
> > 2. 591 lines of log output in my console, almost all of which are
> > artifacts being downloaded.
> > 3. Relevant lines: 1
> > 4. Percentage useful content: .17%
> >
> > That's bad. But wait. It gets worse.
> >
> > The only useful output is
> >
> > [ERROR] Failed to execute goal XXX (default) on project XXX: Execution
> > default of goal XXX failed.: NullPointerException -> [Help 1]
> >
> > So somewhere in my code (I'm writing the plugin that failed) there's a
> > NullPointerException. Where? The logs don't tell me! There's no stack
> > trace. There's no line number. The most critical information I need to
> > debug this isn't included by default. Of course,
> >
> > [ERROR] To see the full stack trace of the errors, re-run Maven with
> > the -e switch.
> >
> > So I rerun with -e and there's the info I need. But
> >
> > 1. I shouldn't have had to rerun. The information I actually needed
> > should have been shown to me up front.
> > 2. I shouldn't have been bombarded with 590 lines of irrelevant log junk.
> >
> > Is anyone really willing to argue that the list of artifacts Maven
> > downloaded and the amount of time each took are somehow more likely to
> > be relevant than an exception arising in the developer's own code? And
> > yet that is exactly what we're doing.
> >
> > On Mon, Feb 20, 2023 at 9:33 AM 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
> >
> >
> >
> > --
> > 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: And while I'm on the subject of logging

[Xeno Amess]

you can add a config or parameter to do this.
BUT I need that log, please don't remove it

From: Kemal Soysal 
Sent: Thursday, February 23, 2023 5:39:08 PM
To: Maven Developers List 
Subject: Re: And while I'm on the subject of logging

+1 logback

> Am 23.02.2023 um 06:39 schrieb Guillaume Nodet :
>
> Maven Daemon uses logback instead of the simple logger.  This definitely
> allows more configuration freedom.
> Should we switch maven 4 to logback or log4j too ?
>
> Le mer. 22 févr. 2023 à 18:45, Ralph Goers  a
> écrit :
>
>> Might I suggest that you are never going to make everyone happy.  That is
>> why Logging frameworks such as Log4j support using Logger names, Log
>> Levels, and Markers as basic ways of categorizing log events. With those
>> you can continue to log events but filter them down to just what the user
>> wants.
>>
>> Unfortunately, doing this will tie you to a logging implementation if you
>> try to do it programmatically.  If you let the user supply (or override)
>> the logging configuration then this wouldn’t be an issue.
>>
>> Ralph
>>
>>> On Feb 22, 2023, at 5:54 AM, Romain Manni-Bucau 
>> wrote:
>>>
>>> +1 to Guillaume proposal for default behavior while -X still logs
>>> everything (in logs ;))
>>>
>>> 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 mer. 22 févr. 2023 à 13:33, Gary Gregory  a
>>> écrit :
>>>
 This echoes IMO what a higher level app (Maven in this case) should do,
 tell me when something unusual happens, like when something is taking a
 long time. For us Windows users, the Explorer UI only pops up its
>> progress
 dialog when you are copying "a lot" or its taking "a long time",
>> otherwise
 it is quiet.

 Question: when I ask mvn for -U behavior, I do like to see the download
 logging, because I am asking for non-default behavior, I expect the
>> extra
 output.

 As previously mentioned, there won't be change that makes everyone
>> happy,
 but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
 folks happy.

 Gary

 On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:

> I do agree that logging all downloads is unneeded, and I do agree that
 the
> hanging case can happen quite often and one needs to be informed.
> However, both goals are not conflicting, we just need to enhance the
> logger/downloader to:
> * print a single statement that it starts downloading things
> * if a download is too slow (for example, nothing has been received
 since
> a few seconds), log a warning message
> * log a summary when the download finished (like "Downloaded 5
 artifacts
> from central and yyy repositories")
> It should not be very difficult to detect stalled downloads.
>
> Le mer. 22 févr. 2023 à 12:51, Romain Manni-Bucau <
>> rmannibu...@gmail.com
>
> a
> écrit :
>
>> Eliotte I kind of fail to follow your reasoning because it literally
> means
>> don't log any info and just set default log level to ERROR which I
 don't
>> think will make anyone happy.
>> You also tend to think everything works all the time but network
>> issues
> are
>> not work/fail kind of issue, the hanging case is really bothering and
>> downloading logs really help there when you can keep them.
>> Lastly downloads are not expected by maven after one build so being a
 bit
>> more verbose is not an issue and going outside the machine should
 likely
>> always be logged at the beginning these days.
>>
>> 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 mer. 22 févr. 2023 à 12:40, Elliotte Rusty Harold <
 elh...@ibiblio.org
>>
>> a
>> écrit :
>>
>>> On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
>>>  wrote:


 except there is no issue, the download is just slow so why
 would
>> you
 fail?
 Hapoy to discuss a better solution but logging is a very satisfying
>> one.
>>>
>>> If there is no issue, don't log it. If being slow is an issue
>>> (arguably it isn't) report it when it's slow enough to be an issue,
>>> and only then. Too many developer tools 

Re: We need to lay down strategy

[Xeno Amess]

So..If I wanna make some refinements, I shall put them onto 4.0, means
master, right?

Slawomir Jaranowski  于2022年4月11日周一 03:20写道：

> our CI has running build for branches:
>  - master
>  - 3.9.x
>  - 3.8.x
>
> It is only versions for which we can do changes, for others we simply don't
> have running infrastructure, so the rest of the versions should be
> officially mentioned as EOL.
>
> To be clear we also should add information what kind of change will be
> accepted for specific version, like: 3.8.x, 3.9.x only critical regression
> bugs as Tamás mentions
>
> niedz., 10 kwi 2022 o 19:59 Hervé BOUTEMY 
> napisał(a):
>
> > Le dimanche 10 avril 2022, 09:56:46 CEST Michael Osipov a écrit :
> > > Am 2022-04-10 um 09:10 schrieb Hervé BOUTEMY:
> > >
> > > >> I think that the truth is that versions less than 3.8.x are also
> EOL.
> > > >
> > > > no
> > > > please read the EOL message we took a lot of discussion to define for
> > > > Maven
> >  3.0.x:
> > > > "Maven 3.0 has now reached its end of life. New plugin releases will
> > > > require
> >  Maven 3.1 or later."
> > > >
> > > > yes, the definition of what "EOL" and "supported" mean for a project
> > like
> > > > ours
> >  is not so easy: finding the right message is not easy
> > >
> > >
> > > But I don't think that this is the full truth.
> > > What we actually do is to compile against a specific Maven version, but
> > > only test latest. I don't expect that everyone tests with 3.1.x, 3.2.x
> > > and so it -- I don't and will not.
> > 1. our CI tests quite a good number of situations: we don't expect manual
> > test
> > from every committer
> > 2. even if we don't fully test every detailed situation, we defined our
> > minimum
> > required Maven version to show that we support these situation
> > 3. if you go that route, please define what support means given our OSS
> > nature
> >
> > let's be reasonable at every level
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Sławomir Jaranowski
>

Re: Review of used reports for Maven project sites.

[Xeno Amess]

strongly suggest move maven-javadoc-plugin from *site *to *build*

It is better to let the committer handle this when they get these codes,
than letting the release manager handle this.


Olivier Lamy  于2022年2月27日周日 08:46写道：

> Thanks for the PRs.
> I'd like to start a discussion rather than some comments in PRs lost in the
> middle of gh notification flood.
> I have started some POC including more "live" reporting in Jenkins (by live
> I mean this could be at least for every commit to master).
> Perso, I'm not reading some reports from the site produced at release time
> because it's simply too late as nothing can be done to improve anything.
> Who is really reading those reports after a release has been made?
> Code analysis is interesting when we develop/change the code to improve it
> (i.e monitoring change of master branch) but once release is done do we
> really care?
> Well this can be a long discussion :)
> Anyway the POC now includes reports such jacoco somes static analysis (pmd,
> checkstyle, spotbugs, errorprone) and some logs parsing (maven warning,
> compiler warnings)
> See here
>
> https://ci-maven.apache.org/job/Maven/job/maven-compiler-plugin-test-olamy/job/ci-reporting/15/linux-jdk11/
>
> such reports do not fail the build and can show improvement of the master
> branch.
> It's a POC only available now in a maven-compiler-plugin
> branch ci-reporting and the common jenkins build with this PR (
> https://github.com/apache/maven-jenkins-lib/pull/3)
> if someone need some more reports more formats are available here
>
> https://github.com/jenkinsci/analysis-model/blob/master/SUPPORTED-FORMATS.md
>
>
> comments welcome.
>
>
>
> On Sat, 26 Feb 2022 at 03:41, Slawomir Jaranowski 
> wrote:
>
> > Hi,
> >
> > I've created a few PRs for removing some reports from Maven site. [1]
> >
> > I think that such reports do not bring any useful information for project
> > documentations, but have influence to site build time.
> >
> > [1] https://github.com/apache/maven-parent/pulls
> >
> >
> > pt., 25 lut 2022 o 03:11 Olivier Lamy  napisał(a):
> >
> > > Hi,
> > >
> > > On Fri, 25 Feb 2022 at 07:57, Slawomir Jaranowski <
> > s.jaranow...@gmail.com>
> > > wrote:
> > >
> > > > Hi
> > > > In next version of Maven parent
> > > >  - detectLinks from javadoc configurations was removed, so javadoc
> will
> > > not
> > > > download remote resource, it was fails many times in this case
> > > >  - findbugs was removed - it also took a lot of time
> > > >
> > > > My proposition is to remove from reports:
> > > >   - surefire
> > > >   - checkstyle
> > > >   - pmd
> > > >   - taglist
> > > >   - invoker
> > > >   and finally - jxr
> > > >
> > > > chekstyle is used during build,
> > > > if we want to use pmd should be included in build
> > > > any other tests result are reported on jenkins for each build, I
> don't
> > > see
> > > > benefit of such in documentations
> > > >
> > >
> > > I tend to agree to remove reports which are already part of the build
> and
> > > fail the build in case of issues (such checkstyle, surefire, invoker).
> > > Because at the end reports are just empty and finally do not provide
> much
> > > more interesting information.
> > > What about having those reports in Jenkins (for at least only one
> > > combination).
> > > But which one? Jenkins reporting can support a lot of tools
> > >
> > >
> >
> https://github.com/jenkinsci/analysis-model/blob/master/SUPPORTED-FORMATS.md
> > > I feel sometimes some reports are generating some false negative
> > warnings,
> > > But at least it will be here if someone wants to have a look but would
> > not
> > > fail a normal build and not make extra noise
> > > Not sure which tools could be interesting? spotbugs, compiler warnings,
> > > what else?
> > >
> > >
> > >
> > > >
> > > > and of course I can change GH action to build site only on one node
> > > >
> > >
> > > agree on that maybe for only 1 combination such linux/jdk 1.8/maven
> last
> > > version?
> > >
> > >
> > > >
> > > > czw., 24 lut 2022 o 22:49 Tamás Cservenák 
> > > > napisał(a):
> > > >
> > > > > Olivier,
> > > > >
> > > > > please remove all the Jenkins checks from all of the Maven builds
> you
> > > > added
> > > > > without asking anyone about adding it.
> > > > > The release manager should ensure beforehand it is all ok, if not,
> > try
> > > to
> > > > > fix it, if the issue is bigger, still can decide to rollback the
> > > change.
> > > > >
> > > > > Thanks
> > > > > T
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Feb 24, 2022 at 10:14 PM Tamás Cservenák <
> > ta...@cservenak.net>
> > > > > wrote:
> > > > >
> > > > > > Building javadoc is slow and very fragile (fetches remote
> > resources,
> > > > > chews
> > > > > > on stuff etc).
> > > > > > Why not have a savvy release manager ensuring it is building, and
> > > > calling
> > > > > > out PR authors to fix it?
> > > > > > The Worst can happen is rel mgr rollback the chnge if the PR
> author
> > > is
> > > > > > unresponsive.
> > > 

Re: Commit Review Policy

[Xeno Amess]

things in openjdk is if a pr cannot gain interest from any already-in
members, although it might be a great pr, it is automatically-closed.

> There cannot be a rule "No review" -> "wait 3 days" -> "accept" because
this is the thing everybody would utilize to involve a trojan horse.

yep, at least one apache-committer's review is needed I think.

And apache-committer is hard to become, as I myself even not being one.

Tibor Digana  于2022年2月4日周五 19:46写道：

> Slawomir, we have a fundamental problem.
> You want to accept PR. But I say that the purpose of PR is not to accept it
> because the ASFshould be always critical and therefore I think the rules
> cannot be written in terms "When to accept the PR".
> There should be rules "When not to accept the PR" because we should be
> critical to the PRs - that's the purpose of the existence of pull-requests.
> If there is no review, no comment, most probably the ASF developers should
> be announced, and/or it means that the business feature presented in the PR
> is not needed.
>
> The ASF is responsible for the changes, not the contributor.
> It is no real situation to search the contributor on the plant and ask
> her/him to repair the fix which will cause a new bug in the future - we are
> responsible, the contributor is not.
> So we should not wait for at least one approval.
> We should be critical to the PRs, and if there is one -1 it means that the
> PR should be open as a work in progress or it should be closed.
>
> There cannot be a rule "No review" -> "wait 3 days" -> "accept" because
> this is the thing everybody would utilize to involve a trojan horse.
>
> T
>
>
>
> On Fri, Feb 4, 2022 at 12:12 PM Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> wrote:
>
> > Hi,
> > Example value as 3 days or other values are to discuss and can be an
> agreed
> > value. Now such values are not important ... it will be the last item to
> > confirm.
> >
> > I only want to show how the process can look.
> >
> > Currently we only have sentence that we use "Commit then Review" policy
> > without more details
> >
> > pt., 4 lut 2022 o 11:58 Xeno Amess  napisał(a):
> >
> > > Yes, reviewing prs is time consuming, though usually worth it.
> > > 3 days does not seem enough for normal pr reviews I think.
> > > If a maintainer disagrees with this and they do think they can review
> > every
> > > prs inside the 3 days limit, then I will be glad to show him why he
> > can't,
> > > just tell me what repos he maintains.
> > > I do have the ability (and experience) in creating 100+ positively
> > > meaningful prs per day.
> > >
> > >
> > > Tibor Digana  于2022年2月4日周五 18:00写道：
> > >
> > > > IMHO the reactions against PRs should be technically critical.
> > > > IMHO the PRs from contributors should not be accepted unless there
> are
> > > > objections or pending objections.
> > > > Example, would you move your hand up and accept long commit in a PR
> > even
> > > if
> > > > you do not see the following statements?
> > > > *if ( cha[] == char[] )*
> > > > Sometimes, you need to open the PR in your IDE because GH view is
> pure
> > > for
> > > > complex changes. You should do everything in order to understand the
> PR
> > > and
> > > > you must be convinced about the proposals almost like you were the
> > author
> > > > of the PR even if you are not the author.
> > > >
> > > >
> > > > On Thu, Feb 3, 2022 at 12:23 PM Xeno Amess 
> > wrote:
> > > >
> > > > > 3 days?
> > > > > according to my experience, usually you need 30 - 180 days.
> > > > >
> > > > > Tibor Digana  于2022年1月28日周五 06:40写道：
> > > > >
> > > > > > It's nice to write some rules but still the developers are not
> > > > machines.
> > > > > > You can, for instance, get some vote for totally crazy things
> like
> > > > > removing
> > > > > > public method in a library which is widely used in ASF or in the
> > > world.
> > > > > > Yes, your right against the rules but was this according to the
> > best
> > > > > > practices, those best practices which must be learned by the
> > > developers
> > > > > for
> > > > > > years?
> > > > > > Was the public method @Deprecated

Re: Commit Review Policy

[Xeno Amess]

Yes, reviewing prs is time consuming, though usually worth it.
3 days does not seem enough for normal pr reviews I think.
If a maintainer disagrees with this and they do think they can review every
prs inside the 3 days limit, then I will be glad to show him why he can't,
just tell me what repos he maintains.
I do have the ability (and experience) in creating 100+ positively
meaningful prs per day.


Tibor Digana  于2022年2月4日周五 18:00写道：

> IMHO the reactions against PRs should be technically critical.
> IMHO the PRs from contributors should not be accepted unless there are
> objections or pending objections.
> Example, would you move your hand up and accept long commit in a PR even if
> you do not see the following statements?
> *if ( cha[] == char[] )*
> Sometimes, you need to open the PR in your IDE because GH view is pure for
> complex changes. You should do everything in order to understand the PR and
> you must be convinced about the proposals almost like you were the author
> of the PR even if you are not the author.
>
>
> On Thu, Feb 3, 2022 at 12:23 PM Xeno Amess  wrote:
>
> > 3 days?
> > according to my experience, usually you need 30 - 180 days.
> >
> > Tibor Digana  于2022年1月28日周五 06:40写道：
> >
> > > It's nice to write some rules but still the developers are not
> machines.
> > > You can, for instance, get some vote for totally crazy things like
> > removing
> > > public method in a library which is widely used in ASF or in the world.
> > > Yes, your right against the rules but was this according to the best
> > > practices, those best practices which must be learned by the developers
> > for
> > > years?
> > > Was the public method @Deprecated before removal?
> > > Did you check the consumers of this artifact in the Maven repository
> and
> > > checked or asked the projects if it can be removed?
> > > Did you announce the community on the site?
> > > What if there are other deprecated methods and they have survived
> several
> > > releases but still not removed, and this method is going to be removed
> > > without deprecation? Is it consistent in project which is used by
> others?
> > > These are all the things which cannot be written in the rules but we
> have
> > > it somewhere in our mind.
> > > Do you obey your internal rules?
> > > Which have higher priority?
> > >
> > > I don't need to have an answer for my questions, since they are not
> > > questions...
> > >
> > > T
> > >
> > > On Tue, Jan 25, 2022 at 8:46 PM Slawomir Jaranowski <
> > > s.jaranow...@gmail.com>
> > > wrote:
> > >
> > > > 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
> > > >
> > >
> >
>

Re: Commit Review Policy

[Xeno Amess]

3 days?
according to my experience, usually you need 30 - 180 days.

Tibor Digana  于2022年1月28日周五 06:40写道：

> It's nice to write some rules but still the developers are not machines.
> You can, for instance, get some vote for totally crazy things like removing
> public method in a library which is widely used in ASF or in the world.
> Yes, your right against the rules but was this according to the best
> practices, those best practices which must be learned by the developers for
> years?
> Was the public method @Deprecated before removal?
> Did you check the consumers of this artifact in the Maven repository and
> checked or asked the projects if it can be removed?
> Did you announce the community on the site?
> What if there are other deprecated methods and they have survived several
> releases but still not removed, and this method is going to be removed
> without deprecation? Is it consistent in project which is used by others?
> These are all the things which cannot be written in the rules but we have
> it somewhere in our mind.
> Do you obey your internal rules?
> Which have higher priority?
>
> I don't need to have an answer for my questions, since they are not
> questions...
>
> T
>
> On Tue, Jan 25, 2022 at 8:46 PM Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> wrote:
>
> > 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
> >
>

Re: Using of Travis

[Xeno Amess]

travis is too slow comparing to github actions.
so as github actions be free...
+1 for move to actions.

XenoAmess

From: Gary Gregory 
Sent: Tuesday, December 21, 2021 12:23:46 AM
To: Maven Developers List 
Subject: Re: Using of Travis

FWIW, I plan on doing the same for most Apache Commons components.

Gary

On Mon, Dec 20, 2021, 11:22 Elliotte Rusty Harold 
wrote:

> +1 to drop Travis, for multiple reasons
>
> On Fri, Dec 17, 2021 at 7:52 AM Slawomir Jaranowski
>  wrote:
> >
> > Hi,
> >
> > As the primary CI environment we use Jenkins.
> > Now also using GH Actions  ...
> > I think that those both are enough.
> >
> > Some projects contain scripts for Travis, like surefire.
> >
> > Do we want to still use Travis?
> >
> > --
> > Sławomir Jaranowski
>
>
>
> --
> 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: reviewing Maven Wrapper before releasing

[Xeno Amess]

+1 for forcing more people quit java 5,6,7， as even 17 is out.
8 is the minimum version normal people can accept，others be zombies who do not 
need to be maintained IMO. They can use original wrapper plugin anyway.
If we do not force them when beginning，it is harder to add the liminition later.

XenoAmess

From: Slawomir Jaranowski 
Sent: Thursday, December 9, 2021 3:11:42 AM
To: Maven Developers List 
Subject: Re: reviewing Maven Wrapper before releasing

I created issues with the proposition of improvement:

https://issues.apache.org/jira/browse/MWRAPPER-31
https://issues.apache.org/jira/browse/MWRAPPER-32
https://issues.apache.org/jira/browse/MWRAPPER-33

please assign a version to fix ... if it is applicable.

śr., 8 gru 2021 o 19:47 Hervé BOUTEMY  napisał(a):

> because it's as it was imported:
> https://github.com/takari/maven-wrapper/blob/master/pom.xml#L21
> I refactored but kept everything as equivalent as possible
>
> we can update the value if it has an interest, with associated Jira issue
>
> Regards,
>
> Hervé
>
> Le mercredi 8 décembre 2021, 19:14:55 CET Slawomir Jaranowski a écrit :
> > Next question:
> >
> >  - why use java 5 in maven-wrapper module .. it is not possible build
> with
> > java > 8 [1]
> >
> > [1]
> >
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-wrapper/job/ma
> > ster/
> > śr., 8 gru 2021 o 19:05 Hervé BOUTEMY 
> napisał(a):
> > > Le mercredi 8 décembre 2021, 15:52:46 CET Robert Scholte a écrit :
> > > > With mvn verify -Prun-its all ITs fail on my system. This should work
> > > > out-of-the-box, so I'll need to investigate the issue.
> > > >
> > > > And I'm pretty sure we can remove the cli package: you can't pass
> System
> > > > properties to Maven, only arguments. And they should be passed as is
> to
> > > > mvn.
> > >
> > > I must admit I don't know: I suppose that if the code is here from the
> > > beginning, it's for some use, it's just me who did not imagine the use
> > > case
> > >
> > > if everybody is confident that it's never used, no problem to remove it
> > >
> > > > IT's should confirm that.
> > > >
> > > > Robert
> > > >
> > > > -- Origineel bericht --
> > > > Van: "Jason van Zyl" 
> > > > Aan: "Maven Developers List" 
> > > > Verzonden: 7-12-2021 14:55:32
> > > > Onderwerp: Re: reviewing Maven Wrapper before releasing
> > > >
> > > > >Everything builds and it generates the wrapper for a project in a
> way
> > >
> > > will
> > >
> > > > >be familiar to existing users. The switch for current users should,
> > > > >hopefully, be painless and transparent.
> > > > >
> > > > >Nice work Robert and Hervé. I put a notice on the GitHub page for
> the
> > > > >Takari version about the impending release at Apache, and provided
> > > > >pointers to the new Git repository and JIRA project.
> > > > >
> > > > >jvz
> > > > >
> > > > >>  On Dec 6, 2021, at 6:07 PM, Hervé BOUTEMY  >
> > >
> > > wrote:
> > > > >>  Hi,
> > > > >>
> > > > >>  Maven Wrapper has been donated to Apache Maven, imported to
> > > > >>
> > > > >>https://github.com/apache/maven-wrapper
> > > > >>
> > > > >>  Documentation published to https://maven.apache.org/wrapper/
> > >
> > > > >>  Here is the list of fixes from previous 0.5.6 release:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721;
> > >
> > > > >>version=12350068>>
> > > > >>
> > > > >>  Please test and review so we can do a release soon
> > > > >>
> > > > >>  Regards,
> > > > >>
> > > > >>  Hervé
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> 
> > > > >>  -
> > > > >>  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
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

--
Sławomir Jaranowski

Re: Maven Code Style and imports layouts

[Xeno Amess]

...if there be a style restriction, adding it to CI is necessary.

Benjamin Marwell  于2021年10月18日周一 下午2:28写道：

> +1!
>
>  Sandra and I tried similar Suggestions a while back.
> This will help new contributors a lot.
>
> Thanks for your efforts!
>
> On Mon, 18 Oct 2021, 07:10 Slawomir Jaranowski, 
> wrote:
>
> > Hi,
> >
> > In order to help make decisions, I prepared PR [1] with the most used
> order
> > layout in Maven Core.
> >
> > Please look and vote / approve / choose another proposition.
> >
> > [1] https://github.com/apache/maven-site/pull/269
> >
> >
> > czw., 23 wrz 2021 o 23:47 Slawomir Jaranowski 
> > napisał(a):
> >
> > > Hi
> > >
> > > I checked the maven core project to see how many files don't meet the
> > > proposed layout.
> > >
> > > All imports in each group are alphabetically sorted.
> > >
> > >
> > > 1,
> > > - import javax.*
> > > - import java.*
> > > - blank line
> > > - all other imports
> > > - blank line
> > > - import static all other imports
> > >
> > > -> 285 files to change
> > >
> > > 2.
> > > - static imports
> > > - blank line
> > > - all other imports alphabetically
> > >
> > > -> 673 files to change
> > >
> > > 3.
> > > - import javax.*
> > > - blank line
> > > - import java.*
> > > - blank line
> > > - all other imports
> > > - blank line
> > > - import static all other imports
> > >
> > > -> 196 files to change
> > >
> > > 3.
> > > - import static all other imports
> > > - blank line
> > > - import javax.*
> > > - blank line
> > > - import java.*
> > > - blank line
> > > - all other imports
> > >
> > > -> 302 files to change
> > >
> > >
> > > So option 3 seems the most popular in maven , but it is easy to change
> > for
> > > all files, or only looks in changed files.
> > > In the first step, preparing documentation is most important - may be
> > > enough.
> > >
> > > I've created issue for it [1]
> > >
> > > Please vote for a proposition or give another one.
> > >
> > >
> > > [1] https://issues.apache.org/jira/browse/MNGSITE-465
> > >
> > >
> > >
> > > sob., 18 wrz 2021 o 20:38 Elliotte Rusty Harold 
> > > napisał(a):
> > >
> > >> simpler is better, though perhaps the fundamental rule should be don't
> > >> reporter what's already there. That is, avoid needless churn.
> > >>
> > >> My preferred style is:
> > >>
> > >> static imports
> > >> blank line
> > >> all other imports alphabetically
> > >>
> > >>
> > >> On Fri, Sep 17, 2021 at 9:19 PM Slawomir Jaranowski
> > >>  wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > We have described many rules about code style on Maven Code Style
> And
> > >> Code
> > >> > Conventions [1].
> > >> >
> > >> > One item missing for me is how java imports should be ordered and
> > >> groped.
> > >> > I can setup it in IDE and it is very useful to use code formatting
> > with
> > >> > tools.
> > >> > I think that all propositions in this case will be ok - the most
> > >> important
> > >> > is to have one standard.
> > >> > At the end we can even use checkstyle to verify it ... [2]
> > >> >
> > >> > So first proposition:
> > >> >
> > >> > - import javax.*
> > >> > - import java.*
> > >> >
> > >> > - blank line
> > >> >
> > >> > - all other imports
> > >> >
> > >> > - blank line
> > >> >
> > >> > - import static all other imports
> > >> >
> > >> >
> > >> > [1] https://maven.apache.org/developers/conventions/code.html
> > >> > [2]
> https://checkstyle.sourceforge.io/config_imports.html#ImportOrder
> > >> >
> > >> > --
> > >> > Sławomir Jaranowski
> > >> >
> > >> > https://twitter.com/SlawekJaran
> > >> > https://github.com/slawekjaranowski
> > >> > https://linkedin.com/in/slawomirjaranowski
> > >>
> > >>
> > >>
> > >> --
> > >> 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
> > >>
> > >>
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>

Re: Forcing "provided" for some dependencies

[Xeno Amess]

Hi.
Sounds like what you need is exclusion?


org.apache.commons
commons-vfs2
${commons-vfs2.version}


org.slf4j
slf4j-log4j12


log4j
log4j


org.slf4j
slf4j-jdk14


org.slf4j
slf4j-nop






Romain Manni-Bucau  于2020年9月2日周三 下午2:01写道：

> Hi,
>
> I think it is risky because some dependencies are really provided so you
> should write an extension which does it for specific artifacts but then
> question will be: what about parent provided deps?
>
> Therefore my proposal would be to ask upstream projects to fix their pom or
> add a pom in their own build to provide you that feature.
>
> Le mer. 2 sept. 2020 à 07:47,  a
> écrit :
>
> > Hello,
> >
> >
> >
> > I have Maven project using spring-boot that is composed of base project
> and
> > components. This is mainly runtime dependency: Base (B) provides some
> > services, and components (C1, C2, C3.) are "installed" by dropping them
> > into
> > specific directory. This works fine, but as I expected I have some
> problems
> > with dependency management in specific cases. These specific cases are as
> > follows: there are two components, lets say C1 and C2, which pack
> activemq
> > and hawtio. Components are built using very simple mechanism - I have
> > separate projects that include component's artifacts (basically my
> compiled
> > code), and specify . Most of dependencies are provided
> > indirectly by specifying Base (B) or other Components (C1, C2.) with
> scope
> > . They are built using maven shade plugin (so
> > "jar-with-dependencies" aka "fat jar"). The only problem I have is with
> > aforementioned "activemq" and "hawtio". They are built not from compiled
> > code but by including artifacts by dependency. That means that AFAIU
> maven
> > reads their poms and includes specified dependencies - but their scope is
> > set to "compile" (probably some are transitive and are included from
> other
> > artifacts, but it doesn't matter), so shade plugin includes quite a lot
> of
> > dependencies into created fat jar - it results in multiple instances of
> > same
> > artifacts. I can work around it by specifying in e.g. hawtio's pom.xml
> > these
> > dependencies by hand with scope "provided", but I don't think this is
> > manageable in the long run - I have 20 dependencies right now and I
> suppose
> > any new version will only require more. And now, when the situation is
> > (hopefully) clear, here goes my question:
> >
> >
> >
> > I'd like to create a plugin, that would somehow intercept dependency
> > resolution and change scope to provided if given artifact is provided by
> > (so
> > provided) any other provided artifacts. So if Base (B)
> > provides e.g. artifact A1 and hawtio requires A1 (explicitly in pom, so
> > with
> > "compile" scope), plugin would check that A1 is already provided, so it
> > would change A1's scope to "provided> - this can be also done as a
> separate
> > step, it is just that I don't know how to get my hands on full dependency
> > graph.
> >
> >
> >
> > Or maybe there is already such plugin and I just couldn't find it? Or
> maybe
> > this approach was tried and failed and I should do everything some other
> > way
> > (which means asking on other group)?
> >
> >
> >
> > Thanks in advance,
> >
> > Jędrzej Dudkiewicz
> >
> >
> >
> >
> >
> >
>

Re: Why is old IO API used in maven resolver?

[Xeno Amess]

Hi.
I wanna know how much it improve.
could you please also run a corresponding jmh bencark for the old codes?

Olivier Lamy  于 2020年8月16日周日 下午4:36写道：

> On Sun, 16 Aug 2020 at 16:07, STEFAN REICH  wrote:
>
> > Hi there!
> >
> > I am working on a very large code base, and build performance issues made
> > me look at the maven-resolver source code. In terms of File usages, there
> > are a lot of InputStreams being copied around using ByteBuffer, instead
> of
> > using FileChannel.transferTo. Affected classes are DefaultFileProcessor,
> > ChecksumCalculator, WagonTransporter, AbstractTransporter and potentially
> > more. Was it a conscious decision to use this pattern over the more
> > efficient transferTo? Would you accept a PR with more modern NIO API that
> > still works with JDK 7?
> >
>
> yes please.
>
>
> > Here are the throughput results from a JMH benchmark, copying a 22MB file
> > around using the pattern currently used in maven, and transferTo, as
> > measured on macOS with JDK 11 on an SSD.
> >
> > Result "MyBenchmark.resolverCopy":
> >   291.362 ±(99.9%) 5.443 ops/s [Average]
> >   (min, avg, max) = (276.923, 291.362, 302.911), stdev = 7.266
> >   CI (99.9%): [285.919, 296.804] (assumes normal distribution)
> >
> > Result "MyBenchmark.transferTo":
> >   325.188 ±(99.9%) 8.838 ops/s [Average]
> >   (min, avg, max) = (306.978, 325.188, 355.784), stdev = 11.799
> >   CI (99.9%): [316.350, 334.026] (assumes normal distribution)
> >
> >
> sounds like a good result.
> Will it be the same for all OS? (windows, linux. osx)
>
>
>
> >
> > Thanks!
> > Stefan
>
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: JDK 15 is in Rampdown Phase One

[Xeno Amess]

@Dalibor Topic 
Hi.
I submitted the bug(or issue) on bugs.java.com as you requested.
And it said internal review ID : 9065633. on the wabpage.
If there anything else I should do please let me know.

Gary Gregory  于2020年6月25日周四 下午8:11写道：

> Thanks for bringing this up Xeno.
>
> Gary
>
> On Thu, Jun 25, 2020, 06:08 Dalibor Topic 
> wrote:
>
>> Hi Xeno,
>>
>> JDK 15 added support for CLDR 37 per
>> https://bugs.openjdk.java.net/browse/JDK-8239480 , which adds support
>> for the Fulah [0] language with the Adlam script per
>> http://cldr.unicode.org/index/downloads/cldr-37 , among others.
>>
>> A parse error in a newly added locale sounds like something we should
>> investigate. Please file a bug report on bugs.java.com and let us know
>> the incident id.
>>
>> cheers,
>> dalibor topic
>>
>> [0] https://en.wikipedia.org/wiki/Fula_language
>> [1] https://en.wikipedia.org/wiki/Adlam_script
>>
>> An account of the script's development can be found at
>> https://news.microsoft.com/stories/people/adlam.html .
>>
>>
>> On 25.06.2020 01:39, Xeno Amess wrote:
>> > Hi.
>> > In your latest jdk15 versions, we found something not quite right.
>> > a related pr is at https://github.com/apache/commons-lang/pull/558
>> > In short, some codes like this cannot pass tests for some Locale like
>> > "ff_LR_#Adlm"
>> > *@Test
>> >  public void java15BuggyLocaleTest() throws ParseException {
>> >  final String buggyLocaleName = "ff_LR_#Adlm";
>> >  Locale buggyLocale = null;
>> >
>> >  for (final Locale locale : Locale.getAvailableLocales()) {
>> >  if (buggyLocaleName.equals(locale.toString())) {
>> >  buggyLocale = locale;
>> >  break;
>> >  }
>> >  }
>> >
>> >  if (buggyLocale == null) {
>> >  return;
>> >  }
>> >
>> >  final Calendar cal = Calendar.getInstance(GMT);
>> >  cal.clear();
>> >  cal.set(2003, Calendar.FEBRUARY, 10);
>> >  final SimpleDateFormat sdf = new SimpleDateFormat(LONG_FORMAT,
>> > buggyLocale);
>> >  final String formattedDate = sdf.format(cal.getTime());
>> >  sdf.parse(formattedDate);
>> >  sdf.parse(formattedDate.toUpperCase(buggyLocale));
>> >  sdf.parse(formattedDate.toLowerCase(buggyLocale));
>> >  }*
>> > BUT in jdk 8-14's all locales can pass the tests, only ones newlly
>> added
>> > in jdk15 fails.
>> > I wanna know whether it be by design or just a bug.
>> >
>> >
>> > Rory O'Donnell > > <mailto:rory.odonn...@oracle.com>> 于2020年6月23日周二 上午12:19写道：
>> >
>> >
>> > Hi Robert ,
>> >
>> > *Per the JDK 15 schedule , we are in Rampdown Phase One* *[1] *
>> >
>> > *Please advise if you find any issues while testing the latest Early
>> > Access builds.
>> > *
>> >
>> >* Schedule for JDK 15
>> >o *2020/06/11 Rampdown Phase One*
>> >o 2020/07/16 Rampdown Phase Two
>> >o 2020/08/06 Initial Release Candidate
>> >o 2020/08/20 Final Release Candidate
>> >o 2020/09/15 General Availability
>> >
>> >* Features included in JDK 15:
>> >o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
>> >  <http://openjdk.java.net/jeps/339>
>> >o JEP 360: Sealed Classes (Preview)
>> > <http://openjdk.java.net/jeps/360>
>> >o JEP 371: Hidden Classes <http://openjdk.java.net/jeps/371>
>> >o JEP 372: Remove the Nashorn JavaScript Engine
>> >  <http://openjdk.java.net/jeps/372>
>> >o JEP 373: Reimplement the Legacy DatagramSocket API
>> >  <https://openjdk.java.net/jeps/373>
>> >o JEP 374: Disable and Deprecate Biased Locking
>> >  <http://openjdk.java.net/jeps/374>
>> >o JEP 375: Pattern Matching for instanceof (Second Preview)
>> >  <https://openjdk.java.net/jeps/375>
>> >o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
>> >  <http://openjdk.java.net/jeps/377>
>> >o JEP 378: Text 

Re: JDK 15 is in Rampdown Phase One

[Xeno Amess]

Hi.
In your latest jdk15 versions, we found something not quite right.
a related pr is at https://github.com/apache/commons-lang/pull/558
In short, some codes like this cannot pass tests for some Locale like
"ff_LR_#Adlm"
























*@Testpublic void java15BuggyLocaleTest() throws ParseException {
  final String buggyLocaleName = "ff_LR_#Adlm";Locale
buggyLocale = null;for (final Locale locale :
Locale.getAvailableLocales()) {if
(buggyLocaleName.equals(locale.toString())) {buggyLocale =
locale;break;}}if (buggyLocale
== null) {return;}final Calendar cal =
Calendar.getInstance(GMT);cal.clear();cal.set(2003,
Calendar.FEBRUARY, 10);final SimpleDateFormat sdf = new
SimpleDateFormat(LONG_FORMAT, buggyLocale);final String
formattedDate = sdf.format(cal.getTime());
sdf.parse(formattedDate);
sdf.parse(formattedDate.toUpperCase(buggyLocale));
sdf.parse(formattedDate.toLowerCase(buggyLocale));}*
BUT in jdk 8-14's all locales can pass the tests, only ones newlly added in
jdk15 fails.
I wanna know whether it be by design or just a bug.


Rory O'Donnell  于2020年6月23日周二 上午12:19写道：

>
> Hi Robert ,
>
> *Per the JDK 15 schedule , we are in Rampdown Phase One* *[1] *
>
> *Please advise if you find any issues while testing the latest Early
> Access builds.
> *
>
>   * Schedule for JDK 15
>   o *2020/06/11 Rampdown Phase One*
>   o 2020/07/16 Rampdown Phase Two
>   o 2020/08/06 Initial Release Candidate
>   o 2020/08/20 Final Release Candidate
>   o 2020/09/15 General Availability
>
>   * Features included in JDK 15:
>   o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
> 
>   o JEP 360: Sealed Classes (Preview) <
> http://openjdk.java.net/jeps/360>
>   o JEP 371: Hidden Classes 
>   o JEP 372: Remove the Nashorn JavaScript Engine
> 
>   o JEP 373: Reimplement the Legacy DatagramSocket API
> 
>   o JEP 374: Disable and Deprecate Biased Locking
> 
>   o JEP 375: Pattern Matching for instanceof (Second Preview)
> 
>   o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
> 
>   o JEP 378: Text Blocks 
>   o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
> 
>   o JEP 381: Remove the Solaris and SPARC Ports
> 
>   o JEP 383: Foreign-Memory Access API (Second Incubator)
> 
>   o JEP 384: Records (Second Preview)
> 
>   o JEP 385: Deprecate RMI Activation for Removal
> 
>
> *JDK 15 **Early Access build 28 **is available**at : - jdk.java.net/15/*
>
> These early-access, open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception**Release
> notes
>
>   * Release notes
>   o http://jdk.java.net/15/release-notes
>   * Recent fixes that might be of interest
>   o Build 27
>   + JDK-8233215: jpackage doesn't allow enough flexibility for
> file type binding
>   + JDK-8244582: Remove terminally deprecated Solaris-specific
> SO_FLOW_SLA socket option
>   + JDK-8245068: Implement Deprecation of RMI Activation
>   + JDK-8246770: Atomic::add() with 64 bit value fails to link
> on 32-bit platforms
>   # Reported by JaCoCo
>   o Build 26
>   + JDK-8240871: SSLEngine handshake status immediately after
> the handshake can be NOT_HANDSHAKING rather than FINISHED
> with TLSv1.3
>   # Reported by Apache Tomcat
>   o Build 25
>   + JDK-8206925: Support the certificate_authorities extension
>   + JDK-8239480: Support for CLDR version 37
>   + JDK-8243925: Toolkit#getScreenInsets() returns wrong value
> on HiDPI screens (Windows)
>
> *JDK 16 Early Access build 2 is available**at : - jdk.java.net/16/*
>
> These early-access, open-source builds are provided under the GNU
> General Public License, version 2, with the Classpath Exception.*
> *
>
> *_Survey on _**_jinfo, jmap, jstack serviceability tools in JDK:_ *
>
>   * Oracle is considering deprecation and (eventual) removal of 3 JDK
> tools - jinfo, jmap, jstack.
>   * The Survey Link
>  will
> remain open through July 15 2020.
>
>
> Rgds, Rory
>
> [1] 

any reviewer for [MJAVADOC-653]?

[Xeno Amess]

Hi.
I created a pr 8 days ago.
Is there anyone who interested in giving some suggestions?
jira  [MJAVADOC-653], github
https://github.com/apache/maven-javadoc-plugin/pull/48

Re: Plexus Logging API

[Xeno Amess]

I like slf4j.
But slf4j can cause dependency hell as it really lack something
named backward compatibility.
I met that thing in one of my repo.
Really bad experience for me.

Romain Manni-Bucau  于2020年6月1日周一 上午2:35写道：

> Hmm,we are already bound to slf4j simple logger by conf and we dont want to
> break it so less costly is slf4j, will avoid to reimpl the binding (needed
> with jul and log4j)...but does not solve all issues with plugins and
> conflicts (jul would). That said not sure we can do better without a huge
> investment not worth it so let's clean things a bit if we can or just keep
> it as it since it does not hurt at all IMHO.
>
> Le dim. 31 mai 2020 à 20:24, Gary Gregory  a
> écrit :
>
> > I'm sure you all know that Apache's own Log4j 2 has it's own API facade
> > with a backing implementation and bridges to other logging systems like
> > SLF4 and Logback, and Java Logging. Not only that but it is actively
> > maintained by more than a single  BDFL (like yours truly) I won't debate
> > the pros vs slf4j...
> >
> > ;-)
> >
> > Gary
> >
> > On Sun, May 31, 2020, 13:41 Robert Scholte  wrote:
> >
> > > Some pro's and cons:
> > >
> > > There have always been concerns about SLF4J, especially because it is
> > > maintained by only one person.
> > > Although Ceki did help us to make Maven work well with SLF4J, it still
> is
> > > a risk.
> > > Depending on third party libraries always comes with a risk.
> > > Having our own logging interfaces (I don't consider plexus as a third
> > > party library, as it is maintained by Maven developers) means could
> > switch
> > > to another framework at any time.
> > > That said, we might even switch to the Java Logging Framework, as
> > > available since Java 1.4
> > >
> > > On the other hand, SLF4J has become the leading standard, so even in
> the
> > > worst case scenario I expect there will a way to keep using the current
> > > SLF4J API.
> > >
> > > One of the benefits of dropping Plexus Logging is getting rid of
> > > the AbstractLogEnabled and LogEnabled classes, which bind the
> components
> > > very strict to the Plexus logging framework.
> > >
> > > thanks,
> > > Robert
> > > On 31-5-2020 19:21:51, Elliotte Rusty Harold 
> wrote:
> > > To be clear, my proposal is not to do anything to the plexus logging
> > > API or the code in the plexus project. I simply would like to chamge
> > > some Maven code to call SLF4J instead of Plexus logging.
> > >
> > > On Sun, May 31, 2020 at 12:43 PM Romain Manni-Bucau
> > > wrote:
> > > >
> > > > If it does not break mojos (thinking to getLog API) +1 from me,
> > > otherwise I
> > > > would be -1 until a compatibility module is properly added to the
> > distro.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau | Blog
> > > > | Old Blog
> > > > | Github |
> > > > LinkedIn | Book
> > > >
> > > >
> > > >
> > > > Le dim. 31 mai 2020 à 18:38, Tamás Cservenák a écrit :
> > > >
> > > > > +1 to rip out plexus logging
> > > > >
> > > > > On Sun, May 31, 2020, 17:58 Elliotte Rusty Harold
> > > > > wrote:
> > > > >
> > > > > > Moved from slack per suggestion:
> > > > > >
> > > > > > The documentation on logging for Maven seems of two minds:
> > > > > >
> > > > > > "Maven uses [Plexus logging API][6] with basic Maven
> implementation
> > > > > > writing to stdout.
> > > > > > We have reached the decision that SLF4J is the best option for a
> > > > > > logging API: SLF4J has reached a certain level of ubiquity and
> > while
> > > > > > SLF4J may not be perfect, it's the de facto standard and it's
> > > > > > pointless to try and remake another one. There are many
> > > > > > implementations to choose from, including Logback and Log4j2. All
> > the
> > > > > > hard work has been done. All the bridges and funnels for other
> > > systems
> > > > > > function well, which allows others to use whatever logging
> > > > > > implementation they like in their components, while still being
> > able
> > > > > > to have integrated logging."
> > > > > >
> > > > > > Does this mean we can rip out the Plexus logging API and replace
> it
> > > > > > with SLF4J? In at least one plugin, the plexus logging API pulls
> > in a
> > > > > > lot of plexus code we wouldn't otherwise need.
> > > > > >
> > > > > > --
> > > > > > 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
> > > > > >
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > 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
> > >
> > >
> >
>