Re: [DISCUSS] Java version for Maven

[Hunter C Payne]

 Is a JDK 17 capable of building JDK 8 jars from JDK 17 source?  If so, what 
are we discussing/arguing/debating about?  Seems to me that that configuration 
gets you everything you want without forcing Maven 4 to not work with JVM/JRE 8.
Hunter

On Saturday, February 24, 2024 at 03:09:07 PM PST, Jorge Solórzano 
 wrote:  
 
 On Sat, Feb 24, 2024, 16:55 Tamás Cservenák  wrote:

> Jorge,
>
> Allow me one question: why would we need 3.10 for this? Could not we set
> same thing for existing 3.9.x?
>

Yes, but 3.10 can be used to better signal that is an LTS since the
beginning and will only contain critical bug fixes, breaking change should
not happen, in other words, that's not actively worked on and will be the
last version of the 3.x line.

Other than that, if it's agreed to just use 3.9 as LTS, then simply
s/3.10/3.9/ on the previous mail. :)





> T
>
>
>
>
> On Sat, Feb 24, 2024, 23:43 Jorge Solórzano  wrote:
>
> > Hi Maven Developers,
> >
> > A lot has been told already from both sides, but please, please, let's
> > focus on how to improve the current status and define how and what Java
> > version will be required for Maven, not on trivial discussions about
> using
> > var or virtual threads.
> >
> > Most developers would love to use the latest and greatest JDK, while
> > Enterprises want stability for deployments, here, we need to change the
> > mindset as the OpenJDK release cadence is not going to slow down.
> >
> > The Java ecosystem is moving forward and Maven should not get stuck with
> a
> > 10 years old JDK version.
> >
> > There are many trade-offs from both sides, many complaints, and (sorry to
> > be harsh) many absurd arguments for being stuck until 2030 with Java 8.
> >
> > I don't want to fall into the trap of "since I use it this way, I'm
> correct
> > and you don't ", so I will try to be as impartial as possible, I do agree
> > there is a need to support a Maven compatible with Java 8, I also do
> agree
> > that developers would like to use latest JDK features on Maven
> > core/plugins, so there needs to be a middle ground.
> >
> > First, we need to distinguish the difference between the required Java
> > version used at RUNTIME vs the Java version used at BUILD TIME, anyone
> can
> > compile a Java project at build time using Java 21 and target Java 8, so
> > here the issue is not about using Java 9+ (11, 17, 21) to compile code
> that
> > will be used at runtime in Java 8, and if every project makes uses of the
> > --release option of java compiler, there will be no issues as we are
> simply
> > targeting to Java 8, it doesn't matter if you compile with Java 11/17/21
> > if, in the end, the produced bytecode is Java 8 compatible. What we are
> > talking about here is the Java version required at RUNTIME, meaning that
> if
> > we raise the Java version to something like Java 17, it will not work
> with
> > Java 11 or 8, with that point being clear, let's continue.
> >
> > Before my proposal, a little disclaimer: I'm just an occasional
> > contributor, not a committer or Maven PMC, and while would be great to
> have
> > a full-time job to work on Maven, is currently not my case.
> >
> > So, the proposal that could make everyone happy is this:
> >
> > This proposal suggests the introduction of a *Long-Term Support (LTS)*
> > version of *Maven 3.10.x *targeting *Java 8* and *Maven 4.0* targeting*
> > Java 17.*
> >
> > In other words, let's require Java 17 in Maven 4.0 at RUNTIME, and the
> same
> > day that Maven 4.0 is released, cut and release a version of Maven
> 3.10.0,
> > this version (3.10.x) will be marked as LTS, and "supported" for up to 3
> or
> > 5 years (depending on needs) with only security or critical bug fixes,
> this
> > means that any new feature won't be backported to the 3.10.x branch,
> > something like supporting a new JDK version (like Java 25) will be added
> to
> > Maven 4.
> >
> > Why Java 17 and not Java 21? To be conservative and have a wider
> audience,
> > this should not be taken as a set-in-stone version, and if in 2 or 3
> years
> > the Java ecosystem has moved fast enough, then a Maven version that
> targets
> > Java 21 or Java 25 should be possible in something like Maven 4.2 (or
> > whatever version is released to that date), and when the current 3.10.x
> > version "expires" in 3 or 5 years, mark a new LTS version rinse, and
> > repeat.
> >
> > *Advantages of Maven 3.10.x (Targeting Java 8):*
> >
> >    1.
> >
> >    *Stability and Compatibility:* Maven 3.10.x will provide stability and
> >    compatibility for projects still reliant on Java 8. Many enterprises
> and
> >    legacy projects continue to utilize Java 8 due to its stability and
> >    extensive support. By maintaining a Maven version specifically for
> Java
> > 8,
> >    these projects can benefit from ongoing support without being forced
> to
> >    migrate to newer Java versions prematurely.
> >    2.
> >
> >    *Extended Support Period:* As an LTS version, Maven 3.10.x will
> rece

Re: [DISCUSS] Java version for Maven

[Hunter C Payne]

 Personally, given that Maven that still requires XML and that the language 
innovation happens these days outside of the Java language itself, the 
technical debt cleanup argument doesn't carry as much weight for me.  And 
requiring 21 seems like a really big jump from 7-8.  The performance benefits 
aren't provided by the compiler, they come from hotspot and that's the JVM 
version at runtime that matters there.  So the provided arguments about the 
benefits of a later JDK aren't really limited by what language Maven uses in 
its built pipeline nor the source version it is compiled with.  Instead it is 
the version of the JVM that the end user uses that matters for the performance 
benefits.

Hunter
On Thursday, February 22, 2024 at 04:20:49 PM PST, Robert Dean 
 wrote:  
 
 As an end user, having a single version of Maven that could build all
my projects (Java 8 - 21) would be preferred, even if it requires Java
21 to run.  That would allow for build pipeline standardization on a
single version of Maven and simplify things for developers.

That being said, if retiring Java 8 and lower output support allows
Maven to shed technical debt and deliver improvements faster, I'd get
over my disappointment. :)

Regards,
Robert Dean



On Thu, Feb 22, 2024 at 3:49 PM Tamás Cservenák  wrote:
>
> I think this starts to make reasonable picture:
>
> If you are on Java 8, use Maven 3
> If you are on Java 9+ use Maven 4 (once out).
>
> For start, Maven3 has no idea (notion) about "classpaths" vs "modulepaths"
> (is not quite true stated like this, it has SOME heuristics, that is mostly
> shoot-and-miss).
>
> So, I think it makes sense to have Maven 4 as Java 17, as folks in "big
> tech" with strict processes, policies and what not will not migrate anyway
> to Maven4. They have Maven3.
>
> T
>
>
> On Thu, Feb 22, 2024 at 9:23 PM Benjamin Marwell 
> wrote:
>
> > Brian, any Chance you could make a stacked 100% graph for every *week*
> > of the past two years?
> > We could then see where we are heading…
> > (or the raw numbers per week, so we could work with that).
> >
> > That's probably a lot to ask, but I think it will show us how "fast"
> > the progression was (and will be).
> >
> > @Tamas please consider the support times are different by vendor.
> > I have seen Java 8 support well beyond 2030 *shudder*.
> >
> > Seeing all those numbers, I now feel a lot more confident that Maven 4
> > should be 17 (runtime), 21 (build)
> > and Java 8 users should stay with 3.x.x.
> > Elliotte gave a good reason for this: There are two camps now (read:
> > ALREADY).
> > There is no reason to not go with either of them.
> >
> > Am Do., 22. Feb. 2024 um 19:56 Uhr schrieb Brian Fox :
> > >
> > > We dumped 30 days because that gives a good snapshot of what's happening
> > > right now. If we dumped for example the whole year, then it really blurs
> > > the lines all over the place and things newer will be less prominent just
> > > because they didn't have as much time. 30 days is how we typically bucket
> > > things when we want a form of relative popularity.
> > >
> > > As far as toy projects skewing, Tamas is right, the scale of central data
> > > is so large that it's insignificant. Also remember we only counted each
> > IP
> > > once per entry so even projects downloading over and over won't skew the
> > > results.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >

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

  

Re: [DISCUSS] Java version for Maven

[Hunter C Payne]

 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
> perhaps that has changed since the Oracle v Google/Alphabet trial.
> Hunter
>
>    On Wednesday, February 21, 2024 at 12:00:54 PM PST, Benjamin Marwell <
> bmarw...@apache.org> wrote:
>
>  FWIW, bazel changed its runtime requirement to Java 21.
> But they are shipping their own Java Runtime, so their users won't notice.
> [1]
>
> I think they are the first build tool to do that.
>
> I say this as a FYI fact only, not implying anything.
> Make of it what you want.
>
> - Ben
>
> Am Di., 20. Feb. 2024 um 21:50 Uhr schrieb Tamás Cservenák
> :
> >
> > 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 19, 2023, 5:17 PM
> > [VOTE] Release Maven Resolver 1.9.17
> > Reproducible Build ok: reference build done with JDK 21 on *nix with
> umask
> > 022
> >
> > Sat, Oct 21, 2023, 4:34 PM
> > VOTE] Apache Maven 4.0.0-alpha-8 release
> > Reproducible Build ok: reference build done with JDK 21 on *nix with
> umask
> > 022
> >
> > Mon, Oct 2, 2023, 9:11 AM
> > [VOTE] Release Apache Maven 3.9.5
> > Reproducible not fully ok: reference build done with JDK 17 on *nix and
> > umask 022
> >
> > 
> >
> > This CLEARLY shows the tendency:
> > - Michael does releases on Java 8 (on windows!), he is a known "aligner"
> > and windows person :)
> > - Olivier used the "minimum" required Java version (for build cache).
> > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
> > use 21 but also 8, but he shot for 11 that was EOL at the moment of
> release.
> > - The rest is 21.
> >
> > 
> >
> > So, the question for those refusing anything other than Java 8 to _run_
> > Maven (or to revert: for those refusing to run Maven on "latest LTS",
> that
> > is currently 21):
> > WHY?
> >
> >
> > Thanks
> > T
>
> -
> 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

[Hunter C Payne]

 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 perhaps that 
has changed since the Oracle v Google/Alphabet trial.
Hunter

On Wednesday, February 21, 2024 at 12:00:54 PM PST, Benjamin Marwell 
 wrote:  
 
 FWIW, bazel changed its runtime requirement to Java 21.
But they are shipping their own Java Runtime, so their users won't notice. [1]

I think they are the first build tool to do that.

I say this as a FYI fact only, not implying anything.
Make of it what you want.

- Ben

Am Di., 20. Feb. 2024 um 21:50 Uhr schrieb Tamás Cservenák
:
>
> 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 19, 2023, 5:17 PM
> [VOTE] Release Maven Resolver 1.9.17
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
>
> Sat, Oct 21, 2023, 4:34 PM
> VOTE] Apache Maven 4.0.0-alpha-8 release
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
>
> Mon, Oct 2, 2023, 9:11 AM
> [VOTE] Release Apache Maven 3.9.5
> Reproducible not fully ok: reference build done with JDK 17 on *nix and
> umask 022
>
> 
>
> This CLEARLY shows the tendency:
> - Michael does releases on Java 8 (on windows!), he is a known "aligner"
> and windows person :)
> - Olivier used the "minimum" required Java version (for build cache).
> - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
> use 21 but also 8, but he shot for 11 that was EOL at the moment of release.
> - The rest is 21.
>
> 
>
> So, the question for those refusing anything other than Java 8 to _run_
> Maven (or to revert: for those refusing to run Maven on "latest LTS", that
> is currently 21):
> WHY?
>
>
> Thanks
> T

-
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

[Hunter C Payne]

 Its more about supporting an ancient JVM/JDK than compiling Maven on an 
ancient version.  So as long as Maven targets 8 or less in its build, I don't 
think anyone cares (at least I don't) what the actual version of the JDK you 
use in the build pipeline.  Go ahead and have a source setting of 17 and a 
target setting of 8 and as long as it works, I'm fine with it.

Other possible reasons are licensing changes after Java 8 can be a concern for 
some companies (I don't know enough about the law to know if that is a good 
reason or not).  There are some poor souls out there that have really ancient 
setups from 20 years ago and trying to get those working on Java 9+ can be 
challenging.  That's really the big reason people have an opinion on this.  
Also, Java 8 is the last Sun version of Java.  Some old folks still have strong 
opinions on Oracle's ownership of Java.  I'm not one of those folks.

Hunter

On Tuesday, February 20, 2024 at 08:52:20 PM PST, David Jencks 
 wrote:  
 
 From your first paragraph I’d guess you would be on the “maven built on a 
recent LTS java” side.  I was wondering, given these omnipresent IDES,  and 
possibly from a philosophical perspective, what the arguments for “maven built 
on an antique JVM” would be.

Thanks
David Jencks

> On Feb 20, 2024, at 8:10 PM, Hunter C Payne 
>  wrote:
> 
> IDEs, including the 2 you named, have a configuration system for multiple 
> JDKs.  This allows devs to build for multiple versions of the JVM.  Likewise, 
> Maven has multiple ways to configure multiple JDKs for use by different 
> phases or plugins used in a given compilation setup and to target different 
> versions of the JVM.  Javac can target any older version than itself when 
> compiling to classfiles.  So my JDK 17 can compile for Java 8-17 but not 18 
> or higher.
> 
> On the JVM, packaging is just a jar and inside that jar's classfiles will be 
> a specific minimum version of the JVM required for it to run.  Generally 
> speaking, for a variety of reasons, most Java code is backwards compatible to 
> Java 8 which was released about 15 years ago.  No specific code is that 
> backwards compatible but most of it is.  That's why you don't realize that 
> these things exist.  Because unless you are a professional developer, why 
> would you ever care in a language with 15 years of backwards compatibility 
> baked into the culture and large base of 3rd party code.  Hope this answers 
> your question.
> 
> Hunter
> 
>    On Tuesday, February 20, 2024 at 08:01:27 PM PST, David Jencks 
> wrote:  
> 
> I’ve been wondering for some time… My uninformed impression is that most 
> corporate development uses Eclipse or IntilliJ, which I believe run only on 
> the java version they come packaged with, which presumably is not usually the 
> target java version for the code being developed.  Aside from packaging 
> questions (IIUC there’s no way for the maven project to ship a java 
> implementation), why should Maven be different?
> 
> Thanks
> David Jencks
> 
>> On Feb 20, 2024, at 1:30 PM, Tamás Cservenák  wrote:
>> 
>> Romain,
>> 
>> you immediately revealed your WHY:
>> Take off your "paid dev" hat, and please try again.
>> 
>> We ARE an open source project.
>> So it IS about us, the volunteers.
>> Is not about THEM, downstream users.
>> 
>> As it was told a million times:
>> if they are stuck (due whatever policy or who knows what), they can just
>> stay with 3.9, 3.8 or whatever suits them.
>> Why align with the "stuck" ones?
>> 
>> T
>> 
>> PS: and no, I just collected the last release VOTEs w/ Herve responses on
>> ML. If you consider that biased, then you have a problem ;)
>> 
>> 
>> 
>> On Tue, Feb 20, 2024 at 10:18 PM Romain Manni-Bucau 
>> wrote:
>> 
>>>> I am sure the majority of Maven users do not run Maven on the same Java
>>> version they target with their build.
>>> 
>>> Do you use that and the following figures to do a biased conclusion?
>>> 
>>> "If people don't use the same version then we can higher the version"?
>>> 
>>> I think we need to consider two things:
>>> 
>>> * We are OSS dev so not representative of the majority - in a company you
>>> most of the time use the same version you target and want to run that, just
>>> either laziness, policy or quality (building with different versions can
>>> lead to surprises and falsy passing tests = broken prod), sadly it is hard
>>> to find data there but I'm pretty sure it is a common experience
>>> * Guess there is a "use the first match

Re: [DISCUSS] Java version for Maven

[Hunter C Payne]

 IDEs, including the 2 you named, have a configuration system for multiple 
JDKs.  This allows devs to build for multiple versions of the JVM.  Likewise, 
Maven has multiple ways to configure multiple JDKs for use by different phases 
or plugins used in a given compilation setup and to target different versions 
of the JVM.  Javac can target any older version than itself when compiling to 
classfiles.  So my JDK 17 can compile for Java 8-17 but not 18 or higher.

On the JVM, packaging is just a jar and inside that jar's classfiles will be a 
specific minimum version of the JVM required for it to run.  Generally 
speaking, for a variety of reasons, most Java code is backwards compatible to 
Java 8 which was released about 15 years ago.  No specific code is that 
backwards compatible but most of it is.  That's why you don't realize that 
these things exist.  Because unless you are a professional developer, why would 
you ever care in a language with 15 years of backwards compatibility baked into 
the culture and large base of 3rd party code.  Hope this answers your question.

Hunter

On Tuesday, February 20, 2024 at 08:01:27 PM PST, David Jencks 
 wrote:  
 
 I’ve been wondering for some time… My uninformed impression is that most 
corporate development uses Eclipse or IntilliJ, which I believe run only on the 
java version they come packaged with, which presumably is not usually the 
target java version for the code being developed.  Aside from packaging 
questions (IIUC there’s no way for the maven project to ship a java 
implementation), why should Maven be different?

Thanks
David Jencks

> On Feb 20, 2024, at 1:30 PM, Tamás Cservenák  wrote:
> 
> Romain,
> 
> you immediately revealed your WHY:
> Take off your "paid dev" hat, and please try again.
> 
> We ARE an open source project.
> So it IS about us, the volunteers.
> Is not about THEM, downstream users.
> 
> As it was told a million times:
> if they are stuck (due whatever policy or who knows what), they can just
> stay with 3.9, 3.8 or whatever suits them.
> Why align with the "stuck" ones?
> 
> T
> 
> PS: and no, I just collected the last release VOTEs w/ Herve responses on
> ML. If you consider that biased, then you have a problem ;)
> 
> 
> 
> On Tue, Feb 20, 2024 at 10:18 PM Romain Manni-Bucau 
> wrote:
> 
>>> I am sure the majority of Maven users do not run Maven on the same Java
>> version they target with their build.
>> 
>> Do you use that and the following figures to do a biased conclusion?
>> 
>> "If people don't use the same version then we can higher the version"?
>> 
>> I think we need to consider two things:
>> 
>> * We are OSS dev so not representative of the majority - in a company you
>> most of the time use the same version you target and want to run that, just
>> either laziness, policy or quality (building with different versions can
>> lead to surprises and falsy passing tests = broken prod), sadly it is hard
>> to find data there but I'm pretty sure it is a common experience
>> * Guess there is a "use the first matching version I have" in the stats you
>> mention, so if you target 11 and have 17 you would use 17 but does not mean
>> you are ok to run 21 (random numbers, move them a bit to be a counter
>> example on whatever digit you want for maven 4)
>> * Guess very few people want to have >= 1 JDK
>> 
>> So clearly the question is not the latest LTS which would be for me just a
>> moving version we can't support and would be bad for our end users IMHO but
>> only the version we pick to start at 4.0.0.
>> Choices stay:
>> 
>> * Latest LTS at that moment to start fresh and not inherit from a legacy at
>> day 0
>> * Latest LTS - 1 - which would enable to cover more projects and get more
>> adoptions
>> * Something older but I don't find any valid reason since people skipping 2
>> LTS will likely never reach maven 4 before we discuss to move our baseline
>> again.
>> 
>> The other question we should probably anticipate is when do we move our
>> support version range.
>> Since java is not more predictable in terms of releases I think it can make
>> sense to target for "new" releases only 2 (maybe 3 but really unsure?) LTS
>> - indeed with best effort on later versions but no guarantee upfront.
>> With such a policy calendar can be communicated and people can follow or
>> not without surprises.
>> 
>> So today, since we don't have yet a final I think 21 can make sense but not
>> cause it is the current latest, cause it will likely be the ~N-1 at 4.0.0
>> time.
>> 
>> 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 mar. 20 févr. 2024 à 21:50, Tamás Cservenák  a
>> écrit :
>> 
>>> Howdy,
>>> 
>>> I intentio

Re: Java version for Maven 4?

[Hunter C Payne]

 Scala has lousy support and the language is dying mainly because Scala3 seems 
like a Kotlin clone (with poor support).  The folks that run Scala are 
academics and it shows in their marketing and mismanagement of the language.  
However, Kotlin is growing and it would be very surprising for me to meet a 
Java dev under 25 that doesn't do most of their work in Kotlin or Scala.

For you is it more that the new features are really that good or is it that the 
new languages aren't innovating ATM?  For instance, perhaps Kotlin focuses on 
Android too much for a general purpose language?  The really sad part is that 
Kotlin (and Scala) would be a far better language for ML/analytics folks than 
Python but nobody uses it that way so the language's features are all focused 
on Android dev.

Hunter

On Tuesday, February 6, 2024 at 07:18:07 AM PST, Romain Manni-Bucau 
 wrote:  
 
 Le mar. 6 févr. 2024 à 16:12, Hunter C Payne
 a écrit :

>  There are also license differences between Java 8 and Java 9+.  And the
> improvements beyond 8 are not things the market seems to want.  Nobody
> wants Jigsaw and the API improvements aren't enough to get people to
> upgrade.  Those that really want new language features use Scala or Kotlin
> and those both run best on Java 8.  Just to add some other reasons why Java
> 9+ isn't really something the market wants.
>


While I agree with the JPMS - and I was agreeing until 3-4 years ago on the
rest - I kind of disagree with the rest which is no more true since java
17+ IMO. Also Scala is slowly dying while Kotlin does not get much more
traction every year now so world changed and our old habits must probably
too IMHO ;).


> Hunter
>
>    On Tuesday, February 6, 2024 at 06:01:07 AM PST, Elliotte Rusty Harold
>  wrote:
>
>  On Mon, Feb 5, 2024 at 8:46 PM Benjamin Marwell 
> wrote:
> >
>
> > Besides that, most big (tech) companies do not allow unmaintained or
> > unsupported software.
>
> How I wish that were true. Unmaintained and unsupported software is
> all over the place, in big tech, little tech, enterprise, and my
> mother's MacBook. I doubt you can install a Linux distro that doesn't
> depend critically on some unmaintained library no one is paying
> attention to.
>
> What big tech mono-repo companies do differently that most other
> companies don't is build everything from source themselves, kernel and
> build tools included, so that when some critical bug surfaces they can
> dig into the code and fix it. They are mostly not dependent on
> binaries shipped by third parties. It's a feasible option for
> companies in the hundreds of billions of dollars range. For the rest
> of us, not so much.
>
> --
> 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?

[Hunter C Payne]

 There are also license differences between Java 8 and Java 9+.  And the 
improvements beyond 8 are not things the market seems to want.  Nobody wants 
Jigsaw and the API improvements aren't enough to get people to upgrade.  Those 
that really want new language features use Scala or Kotlin and those both run 
best on Java 8.  Just to add some other reasons why Java 9+ isn't really 
something the market wants.
Hunter

On Tuesday, February 6, 2024 at 06:01:07 AM PST, Elliotte Rusty Harold 
 wrote:  
 
 On Mon, Feb 5, 2024 at 8:46 PM Benjamin Marwell  wrote:
>

> Besides that, most big (tech) companies do not allow unmaintained or
> unsupported software.

How I wish that were true. Unmaintained and unsupported software is
all over the place, in big tech, little tech, enterprise, and my
mother's MacBook. I doubt you can install a Linux distro that doesn't
depend critically on some unmaintained library no one is paying
attention to.

What big tech mono-repo companies do differently that most other
companies don't is build everything from source themselves, kernel and
build tools included, so that when some critical bug surfaces they can
dig into the code and fix it. They are mostly not dependent on
binaries shipped by third parties. It's a feasible option for
companies in the hundreds of billions of dollars range. For the rest
of us, not so much.

-- 
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] POM model version

[Hunter C Payne]

 Sorry for chiming in again but perhaps I might have an idea.  The XSD schema 
that a POM uses is actually referenced from the POM.  So in essence each POM 
carries with it what is needed to know to parse it.  Perhaps in Maven 5 (or 
whichever version) we can require POM parsers to read and use the specific XSD 
schema referenced in the POM.  That way you can have more room to try changes 
to the POM format.  But there really should be a mechanism for pushing POM 
changes downstream and XSD seems like a good option for that.  Sorry if this is 
already the plan and I'm repeating what is already known.

Hunter

On Tuesday, June 13, 2023 at 11:12:39 PM PDT, Hervé Boutemy 
 wrote:  
 
 Le lundi 12 juin 2023, 01:50:56 CEST Guillaume Nodet a écrit :
> > Don't look at Maven code to judge: the whole logic is based on "known
> > unknown"
> > = we don't know who parses POMs published to Maven Central, but there are
> > many
> > (it's easy to cite many, but not all).
> 
> I can't buy that argument.  You're saying that we should not assume the way
> the POM is parsed, but we assume they don't parse arguments.  That's
> clearly dodgy, and false for our own parser (both are parsed and rejected
> in strict mode and silently ignored in lenient mode).

I can understand that it does not match the precision of your logic based on 
todays code: did you look at Maven 2 code? did you look at every other 
consumer of Maven Central content?

whatever you feel about it today, that's what has been defined and done for now 
more than 15 years, and proven working, and AFAIK checked when publishing to 
Maven Central

If we change that, we are changing the Maven Central contract for everybody 
from the past and future

Maven 5 is not only about Maven: it's also about Maven Central, which is the 
hardest piece to make sure we don't break usage

Regards,

Hervé



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

  

Re: Build POM and consumer POM (was Re: [DISCUSS] POM model version

[Hunter C Payne]

 Isn't the schema named in the POM document itself?  Can't we just allow use of 
"extended" (read backwards compatible) schemas as the POM is versioned?  Then 
if/once a specific schema for a use case becomes popular it can be added to 
parsers as the required version if needed.  Or perhaps that's too complex...IDK.

Hunter

On Sunday, June 11, 2023 at 04:36:52 PM PDT, Guillaume Nodet 
 wrote:  
 
 Le dim. 11 juin 2023 à 23:12, Romain Manni-Bucau  a
écrit :

>
>
> Le dim. 11 juin 2023 à 22:28, Guillaume Nodet  a
> écrit :
>
>> Those are actually two different questions, but I'd like to raise those
>> together, since they do affect the same feature.
>>
>> 1/ We currently don't have an XML schema for the build POM.  One
>> possibility would be to relax a bit the constraints on the main POM
>> schema (
>> http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are
>> not
>> mandatory in the xml.  By not modifying the validation rules, those
>> elements will have to be present in the object model, so that should be
>> safe.  Another option would be to have a separate schema, but given the
>> small set of changes on the build pom on the current constraints, i
>> think the first solution would be better.  As a reminder, the build pom
>> supports: inferring version for artifacts that are part of the reactor
>> (that's usually done using managedVersion), inferring the relativePath
>> element, ci friendly interpolation for the version.
>>
>
> +1 to relax
>
>>
>> 2/ the consumer POM could be streamlined much more using the same
>> techniques than used in the flatten-maven-plugin. Currently, we're only
>> removing the  element, but we could remove the full build
>> section,
>> flatten dependencies, etc...  Packaged artifacts (i.e. with a non pom
>> packaging), can only be used as dependencies, so I think the whole
>> flattening process could make sense.  Is there any drawback in doing so ?
>> Any particular reason the consumer POM support is limited to removing
>> modules and does not go further ?  I can see some discussion in
>> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
>> but
>> those do not seem to be settled.
>>
>
> Doesnt flattening break transitive dep resolution since depth changes?
>
> Also drops some build meta which cant be resoled anymore portably like
> compiler setup, which graalvm version was used and lastly would need to
> drop or not props not used elsewhere.
> Think staying as close as possible of the source is overall good to
> consume as intended (build control) until the transformer is fully
> configurable (never hopefully since it sounds overcomplicated).
>

All those properties, plugin config, etc... are completely irrelevant for
jars or any other packaged artifact.  The only way those can actually have
an impact is when you use the pom as a parent.  That's because when you
inherit from a project, it has to have the "pom" packaging.  Dependency
management is used when importing BOMs, but all other usages are afaik
limited to declaring dependencies or plugins, and in those cases, the only
interesting bits are dependencies, dependencyManagement, parents and
properties (+ repositories).  The flatten-m-p does merge those 4 pieces
into a single list of dependencies (which has the benefit of simplifying
the consumption of the artifact).  We may not want to do that, but still
the build section is completely irrelevant.

To recap, we have 3 different usages of the POM:
  * the build pom on the file system read by maven when running
  * the consumer pom on a repository which is used when consuming a
dependency/plugin jar or any other kind of packaging
  * the build pom with a pom packaging which can be uploaded to central and
used as a parent by another project

I do somewhat understand the will to keep the pom schema for artifacts
uploaded in central.  When consuming those jars (as dependencies or
plugins), there's definitely very little need to actually make any change
to the POM schema that they are using (even though I'm not really buying
the fact that it has to be set in "amber").  Maven already supports any new
element/attribute and other tools could adapt as well.
However, there are clear needs to improve the build side POM.  The
build/pom consumer has done some improvement here, but it's not finished,
and the pain point has not been addressed in any doc/wiki page I've read so
far: if we ever introduce a new element in the build POM, but we want to
consume that POM as a parent: this is the third usage above, and it's
conflicting with two set of goals:
 * introduce new stuff in the build pom
 * keep 4.0.0 model in "amber"
I think the only way is to create a new schema called POM5 if you want and
to use it for build POM *and* for pom packaged POM uploaded to central,
while packaged artifacts would be stuck with POM4.  The POM5 could then be
free to evolve as desired.

So to sum-up, I can see two solutions:
  * allow the 4.0.0 model to evolve with 4.2.0 or

Re: Build POM and consumer POM (was Re: [DISCUSS] POM model version

[Hunter C Payne]

 Strange question but maybe it will inspire someone else.  Why does the POM the 
user uses to control the build the exact same format as the POMs created to 
express the results of the build?  Is that necessary?  It seems to me the 
discussion is about the drawbacks of that approach.  Perhaps its needed for 
reproducible builds or something but it seems to me those two use cases are 
different and the difficulty comes from trying to make one stable format serve 
both use cases.
Hunter

On Sunday, June 11, 2023 at 02:12:49 PM PDT, Romain Manni-Bucau 
 wrote:  
 
 Le dim. 11 juin 2023 à 22:28, Guillaume Nodet  a écrit :

> Those are actually two different questions, but I'd like to raise those
> together, since they do affect the same feature.
>
> 1/ We currently don't have an XML schema for the build POM.  One
> possibility would be to relax a bit the constraints on the main POM schema
> (
> http://maven.apache.org/xsd/maven-4.0.0.xsd) so that some elements are not
> mandatory in the xml.  By not modifying the validation rules, those
> elements will have to be present in the object model, so that should be
> safe.  Another option would be to have a separate schema, but given the
> small set of changes on the build pom on the current constraints, i
> think the first solution would be better.  As a reminder, the build pom
> supports: inferring version for artifacts that are part of the reactor
> (that's usually done using managedVersion), inferring the relativePath
> element, ci friendly interpolation for the version.
>

+1 to relax

>
> 2/ the consumer POM could be streamlined much more using the same
> techniques than used in the flatten-maven-plugin. Currently, we're only
> removing the  element, but we could remove the full build section,
> flatten dependencies, etc...  Packaged artifacts (i.e. with a non pom
> packaging), can only be used as dependencies, so I think the whole
> flattening process could make sense.  Is there any drawback in doing so ?
> Any particular reason the consumer POM support is limited to removing
> modules and does not go further ?  I can see some discussion in
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> but
> those do not seem to be settled.
>

Doesnt flattening break transitive dep resolution since depth changes?

Also drops some build meta which cant be resoled anymore portably like
compiler setup, which graalvm version was used and lastly would need to
drop or not props not used elsewhere.
Think staying as close as possible of the source is overall good to consume
as intended (build control) until the transformer is fully configurable
(never hopefully since it sounds overcomplicated).



> Le ven. 9 juin 2023 à 11:22, Guillaume Nodet  a écrit :
>
> >
> >
> > Le ven. 9 juin 2023 à 08:59, Hervé Boutemy  a
> > écrit :
> >
> >> adding a new POM element in build POM was supposed to be something for
> >> Maven 5
> >> and to trigger a POM 5 version, to make clear that we are leaving the
> >> Maven 3
> >> space (that uses POM version 4, hence the need for version clarification
> >> between Maven and it POM model version)
> >>
> >> if we enter that space before having released Maven 4, we're adding more
> >> complexity: do you really want to work on Maven 5 now?
> >>
> >>
> >> another aspect:
> >> do we want to have this new improvement only for Maven 4/5 or also have
> >> it for
> >> Maven 3.9?
> >> in Maven 3.9, such little enhancement were implemented as XML attributes
> >>
> >
> > Fwiw, if I reduce the diff between the XSD generated with 3.0 and with
> > 3.9.x, I end up with the following diff
> > https://gist.github.com/gnodet/f8dfd3206ebf55d6e4610a25e683120b
> > So, you're right, no new elements have been introduced. A few attributes
> > added, one element removed.
> >
> > However I really don't understand how adding an attribute vs an element
> > makes the POM more compatible. Our own generated parser will reject any
> > unknown new attribute the same way as an unknown element (that's for any
> > maven 3.x version). Here's what happen if I use a maven 3.2.5 to read a
> POM
> > with an element that has been introduced later:
> > https://gist.github.com/gnodet/35a3ad4d449e586dc282c08eacc82ed0
> > So I'm not really buying the argument about attribute / element at this
> > point.  If that could be clarified, it would be nice !
> >
> > So I think the question comes down to: do we prefer modifying/overwriting
> > the schema as we did in the past or do we prefer cleanly versioning it.
> In
> > both cases, I think we need to keep it compatible, i.e. only add
> > elements/attributes.  The first option is much easier to implement: just
> do
> > nothing as we did in the past, but this has the drawback of not giving
> > people/tools much warning or information about possible changes.  We
> simply
> > overwrite the schema from the web site with the latest one at each
> release,
> > hoping that tools will not see the change and that they don't really
> cac

Re: [DISCUSS] POM model version

[Hunter C Payne]

 Isn't this the type of change that XML Schema is supposed to enable?  Perhaps 
the problem is that we need to provide a downstream way to access generic 
plugin specific model elements that is divorced from the POM itself?  Then we 
don't have to live in fear of POM changes.  Just a thought...perhaps I am wrong.

Hunter

On Thursday, June 8, 2023 at 02:48:05 PM PDT, Romain Manni-Bucau 
 wrote:  
 
 +1 to enable it, +1000 to try to write a 4.0.0 version when possible else
fail until enabled/forced in install/deploy plugins maybe?

Le jeu. 8 juin 2023 à 22:56, Guillaume Nodet  a écrit :

> While working on an issue [1], I've raised a PR [2] which is adding an xml
> element to the POM.  So I raised the model version to 4.2.0.  My
> understanding is that the build/consumer POM feature [3] was created so
> that we could keep compatibility.  This is clearly indicated in the wiki
> page:  "Maven is stuck on POM v4 for a long time now, because changing the
> POM version and publishing artifacts on Maven Central with this new model
> would break consumers using either older Maven versions or other build
> tools (that use POM v4 as a compatibility format)."
>
> However, I think this axiom is false.  What happens, is that all maven
> versions are perfectly capable of consuming any model when used as a BOM /
> dependency / plugin, as the parser simply ignores any unknown attribute or
> element.  I can install a jar with the 4.2.0 model and consume it with any
> 3.x version without any problem.  The only issue is when using that project
> as a parent, in which case, the validation is strict and fails with the
> 4.2.0 model.
>
> So, saying that "new model would break consumers using [...] older Maven
> versions" is just wrong, as they work perfectly when consuming the POM as
> dependencies.  I can create a small git repo if you want to experiment, but
> that has been first checked by @cstamas, then double checked by myself.
>
> Now, the discussion is whether we want to allow modifications to the POM
> model and support new versions of it.  I think this would be quite safe,
> provided that there's no incompatible changes, i.e. it's only adding new
> elements/attributes.
> I don't think this goes against the build/consumer feature, as I think the
> main benefit of this feature is to allow default values using sane
> conventions (mainly the project layout on the file system, which is not
> available anymore in the remote repository, so this data has to be present
> for consumers).
>
> So, the question: should we go ahead and allow introducing newer POM models
> to bring in a few features that have been delayed for a long time because
> the assumption was that the model could never change ?  One possibility to
> minimize the disruption would be to have a smart POM writer : i.e. it could
> transform the POM to a 4.0.0 model if no new features are actually used, so
> that only projects actually using the newly introduced features would
> actually use the 4.x pom version.
>
> Guillaume
>
> [1] https://issues.apache.org/jira/browse/MNG-7804
> [2] https://github.com/apache/maven/pull/1147
> [3]
> https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM
> --
> 
> Guillaume Nodet
>
  

Re: HOCON support (was Re: Question - JDK Minimum of future Apache Maven 4.0.0)

[Hunter C Payne]

> >
> > Le mer. 7 juin 2023 à 18:02, Guillaume Nodet  a
> écrit :
> >
> >> A very rough cut at supporting HOCON is available at
> >> https://github.com/gnodet/maven-hocon-extension. It currently requires
> >> https://github.com/gnodet/maven/tree/polyglot (mainly to add the maven
> >> model as an attached artifact during the build so that it can be
> consumed
> >> by the hocon parser generator).  The generated parser does not handle
> the
> >> whole model yet, so it's very experimental (and an important part of it
> is
> >> the plugin configuration which is... xml).  A very simple parseable POM
> is
> >> available at
> >>
> >>
> https://github.com/gnodet/maven-hocon-extension/blob/main/src/it/simple/pom.conf
> >> .  If people are actually interested in that, we may be able to move it
> as
> >> an official maven extension.
> >>
> >> Note that takari-polyglot is broken with maven 4 and the above parser is
> >> only for maven 4...
> >>
> >> Anyway, I'm all for moving maven forward !
> >>
> >> Guillaume
> >>
> >> Le mer. 7 juin 2023 à 02:31, Hunter C Payne
> >>  a écrit :
> >>
> >>>  I completely agree that JSON is just reinventing the wheel.  But that
> >>> seems irrelevant from a marketing perspective.  And HOCON is actually
> >>> better than either JSON or XML.  If your potential customers first
> >> reaction
> >>> to Maven is 'ick XML' then it doesn't really matter if XML is better.
> >> Just
> >>> my experience and opinion.
> >>>
> >>> Hunter
> >>>      On Tuesday, June 6, 2023 at 05:24:59 PM PDT, Gary Gregory <
> >>> garydgreg...@gmail.com> wrote:
> >>>
> >>>  Playing a bit of devil's advocate here: while I've not used it, there
> >> is a
> >>> maven polyglot plugin that IIRC let's you author your POM in other
> >> formats.
> >>> But yeah, XML can be a pain but XML Schema is super handy in tooling
> and
> >>> editors. In the meantime, JSON is just reinventing the wheel...
> >>>
> >>> Gary
> >>>
> >>> On Tue, Jun 6, 2023, 20:02 Hunter C Payne  >>> .invalid>
> >>> wrote:
> >>>
> >>>>  Sorry to be glib.  I apologize.  But I did have a point.  The
> attitude
> >>>> that Guillaume has about my emacs (which has been updated more
> recently
> >>>> than either the JVM or your IDE) is exactly the same attitude I face
> >>> when I
> >>>> try to get new users to use Maven.  In the case of Maven, it is use of
> >>> XML
> >>>> for the pom, in the case of emacs its all the weird key bindings
> (which
> >>> you
> >>>> actually already know because of bash).  I hope this actually helps.
> >>>>
> >>>> Hunter
> >>>>
> >>>>    On Tuesday, June 6, 2023 at 04:42:10 PM PDT, Hunter C Payne <
> >>>> hunterpayne2...@yahoo.com.invalid> wrote:
> >>>>
> >>>>  Ok, sonny...go back to using software I wrote to do your
> development.
> >>>> Hunter
> >>>>
> >>>>    On Tuesday, June 6, 2023 at 03:47:56 PM PDT, Guillaume Nodet <
> >>>> gno...@apache.org> wrote:
> >>>>
> >>>>  Sounds like the only really plausible answer !  So if they can stay
> >> on a
> >>>> runtime which is 10 years old, an editor which has been released
> nearly
> >>> 38
> >>>> years ago (well, not the latest version of course, but still...), why
> >>> can't
> >>>> they stay on maven 3.9 which is a few months old ?
> >>>>
> >>>> My proposal was to support critical bug fixes (i.e. security or no
> >>>> work-around, but that can always be discussed) on the latest branches
> >>>> supporting LTS JDK for some time..., so 3.x for JDK 8, 4.x for JDK 17
> >> and
> >>>> maybe 5.x for JDK 21 or 24 or whatever the LTS jdk would be at that
> >> time.
> >>>> That would be a change from what has been done for the past 15 years,
> >> as
> >>>> looking at history, I think 2.0.11 was the only micro version ever
> >>> released
> >>>> after the next minor version.
> >>>>
> >>>> Guillaume
> >>&g

Re: HOCON support (was Re: Question - JDK Minimum of future Apache Maven 4.0.0)

[Hunter C Payne]

 So perhaps it is easier to translate other formats to XML instead of adding 
support directly to the main code.  My idea wasn't so much to replace XML, 
rather it was to translate other formats to XML and then use the existing XML 
implementations.  I think that makes the work easier without impacting 
downstream plugins.
Hunter

On Wednesday, June 7, 2023 at 09:05:57 AM PDT, Romain Manni-Bucau 
 wrote:  
 
 Maybe let's stabilize XML and ensure we can make it evolving properly in
time before supporting any other format which will impact negatively the
ecosystem IMHO since a lot of descriptor parsers are not org.apache.maven
(which is a very good thing IMHO, means we have a portable enough format to
be adopted).
Once we will tackle that support question I think the main point is which
formats do we want to maintain (support is not a big deal, maintaining is).
While I can envision xml and maybe json are no drama, any other one will
probably end as polyglot, kind of abandonned they restarted then
re-abandonned so from my window I don't see it as great for the community
("good bad idea" we sometimes say).

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 mer. 7 juin 2023 à 18:02, Guillaume Nodet  a écrit :

> A very rough cut at supporting HOCON is available at
> https://github.com/gnodet/maven-hocon-extension. It currently requires
> https://github.com/gnodet/maven/tree/polyglot (mainly to add the maven
> model as an attached artifact during the build so that it can be consumed
> by the hocon parser generator).  The generated parser does not handle the
> whole model yet, so it's very experimental (and an important part of it is
> the plugin configuration which is... xml).  A very simple parseable POM is
> available at
>
> https://github.com/gnodet/maven-hocon-extension/blob/main/src/it/simple/pom.conf
> .  If people are actually interested in that, we may be able to move it as
> an official maven extension.
>
> Note that takari-polyglot is broken with maven 4 and the above parser is
> only for maven 4...
>
> Anyway, I'm all for moving maven forward !
>
> Guillaume
>
> Le mer. 7 juin 2023 à 02:31, Hunter C Payne
>  a écrit :
>
> >  I completely agree that JSON is just reinventing the wheel.  But that
> > seems irrelevant from a marketing perspective.  And HOCON is actually
> > better than either JSON or XML.  If your potential customers first
> reaction
> > to Maven is 'ick XML' then it doesn't really matter if XML is better.
> Just
> > my experience and opinion.
> >
> > Hunter
> >    On Tuesday, June 6, 2023 at 05:24:59 PM PDT, Gary Gregory <
> > garydgreg...@gmail.com> wrote:
> >
> >  Playing a bit of devil's advocate here: while I've not used it, there
> is a
> > maven polyglot plugin that IIRC let's you author your POM in other
> formats.
> > But yeah, XML can be a pain but XML Schema is super handy in tooling and
> > editors. In the meantime, JSON is just reinventing the wheel...
> >
> > Gary
> >
> > On Tue, Jun 6, 2023, 20:02 Hunter C Payne  > .invalid>
> > wrote:
> >
> > >  Sorry to be glib.  I apologize.  But I did have a point.  The attitude
> > > that Guillaume has about my emacs (which has been updated more recently
> > > than either the JVM or your IDE) is exactly the same attitude I face
> > when I
> > > try to get new users to use Maven.  In the case of Maven, it is use of
> > XML
> > > for the pom, in the case of emacs its all the weird key bindings (which
> > you
> > > actually already know because of bash).  I hope this actually helps.
> > >
> > > Hunter
> > >
> > >    On Tuesday, June 6, 2023 at 04:42:10 PM PDT, Hunter C Payne <
> > > hunterpayne2...@yahoo.com.invalid> wrote:
> > >
> > >  Ok, sonny...go back to using software I wrote to do your development.
> > > Hunter
> > >
> > >    On Tuesday, June 6, 2023 at 03:47:56 PM PDT, Guillaume Nodet <
> > > gno...@apache.org> wrote:
> > >
> > >  Sounds like the only really plausible answer !  So if they can stay
> on a
> > > runtime which is 10 years old, an editor which has been released nearly
> > 38
> > > years ago (well, not the latest version of course, but still...), why
> > can't
> > > they stay

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

 Completely agree.  Maven's strength is that it is declarative.  Anyone old 
enough to remember autoconf, autoreconf, etc never wants to go back to that 
world.
Hunter

On Tuesday, June 6, 2023 at 10:35:07 PM PDT, Romain Manni-Bucau 
 wrote:  
 
 Polyglot was a good idea but a key feature of maven is to NOT rely on
scripting to init the context (deps typically) to let IDE load it quickly
in their format.
Typically opening a gradle script in idea is often a pain and as soon as
you get any error you can't even open it to fix it (yes, ridiculous but by
design).
So while we stay with a loadable statically script I'm fine, verbosity is
not only xml but the model, using inline coordinates could already help in
the user pom (vs produced pom for repos which will not change).
Not sure it is a great fight nor relevant regarding the jdk to use since we
can support both without much effort anyway, even if it needs one more
class - we use a ton of libs so one more class (not even lib) is ok ;).

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 mer. 7 juin 2023 à 02:31, Hunter C Payne
 a écrit :

>  I completely agree that JSON is just reinventing the wheel.  But that
> seems irrelevant from a marketing perspective.  And HOCON is actually
> better than either JSON or XML.  If your potential customers first reaction
> to Maven is 'ick XML' then it doesn't really matter if XML is better.  Just
> my experience and opinion.
>
> Hunter
>    On Tuesday, June 6, 2023 at 05:24:59 PM PDT, Gary Gregory <
> garydgreg...@gmail.com> wrote:
>
>  Playing a bit of devil's advocate here: while I've not used it, there is a
> maven polyglot plugin that IIRC let's you author your POM in other formats.
> But yeah, XML can be a pain but XML Schema is super handy in tooling and
> editors. In the meantime, JSON is just reinventing the wheel...
>
> Gary
>
> On Tue, Jun 6, 2023, 20:02 Hunter C Payne  .invalid>
> wrote:
>
> >  Sorry to be glib.  I apologize.  But I did have a point.  The attitude
> > that Guillaume has about my emacs (which has been updated more recently
> > than either the JVM or your IDE) is exactly the same attitude I face
> when I
> > try to get new users to use Maven.  In the case of Maven, it is use of
> XML
> > for the pom, in the case of emacs its all the weird key bindings (which
> you
> > actually already know because of bash).  I hope this actually helps.
> >
> > Hunter
> >
> >    On Tuesday, June 6, 2023 at 04:42:10 PM PDT, Hunter C Payne <
> > hunterpayne2...@yahoo.com.invalid> wrote:
> >
> >  Ok, sonny...go back to using software I wrote to do your development.
> > Hunter
> >
> >    On Tuesday, June 6, 2023 at 03:47:56 PM PDT, Guillaume Nodet <
> > gno...@apache.org> wrote:
> >
> >  Sounds like the only really plausible answer !  So if they can stay on a
> > runtime which is 10 years old, an editor which has been released nearly
> 38
> > years ago (well, not the latest version of course, but still...), why
> can't
> > they stay on maven 3.9 which is a few months old ?
> >
> > My proposal was to support critical bug fixes (i.e. security or no
> > work-around, but that can always be discussed) on the latest branches
> > supporting LTS JDK for some time..., so 3.x for JDK 8, 4.x for JDK 17 and
> > maybe 5.x for JDK 21 or 24 or whatever the LTS jdk would be at that time.
> > That would be a change from what has been done for the past 15 years, as
> > looking at history, I think 2.0.11 was the only micro version ever
> released
> > after the next minor version.
> >
> > Guillaume
> >
> > Le mar. 6 juin 2023 à 23:05, Hunter C Payne
> >  a écrit :
> >
> > >  emacs
> > > Hunter
> > >
> > >    On Tuesday, June 6, 2023 at 11:19:43 AM PDT, Guillaume Nodet <
> > > gno...@apache.org> wrote:
> > >
> > >  One question for people that want JDK 8 support.  What IDE do they use
> > to
> > > develop ? Because none of the actual IDE is running JDK 8, though they
> > can
> > > be used by JDK 8, just like maven with toolchains.
> > > So really, the argument does not really stand, but for the very
> minority
> > of
> > > devs still using emacs/vim.
> > > It re

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

 I completely agree that JSON is just reinventing the wheel.  But that seems 
irrelevant from a marketing perspective.  And HOCON is actually better than 
either JSON or XML.  If your potential customers first reaction to Maven is 
'ick XML' then it doesn't really matter if XML is better.  Just my experience 
and opinion.

Hunter
On Tuesday, June 6, 2023 at 05:24:59 PM PDT, Gary Gregory 
 wrote:  
 
 Playing a bit of devil's advocate here: while I've not used it, there is a
maven polyglot plugin that IIRC let's you author your POM in other formats.
But yeah, XML can be a pain but XML Schema is super handy in tooling and
editors. In the meantime, JSON is just reinventing the wheel...

Gary

On Tue, Jun 6, 2023, 20:02 Hunter C Payne 
wrote:

>  Sorry to be glib.  I apologize.  But I did have a point.  The attitude
> that Guillaume has about my emacs (which has been updated more recently
> than either the JVM or your IDE) is exactly the same attitude I face when I
> try to get new users to use Maven.  In the case of Maven, it is use of XML
> for the pom, in the case of emacs its all the weird key bindings (which you
> actually already know because of bash).  I hope this actually helps.
>
> Hunter
>
>    On Tuesday, June 6, 2023 at 04:42:10 PM PDT, Hunter C Payne <
> hunterpayne2...@yahoo.com.invalid> wrote:
>
>  Ok, sonny...go back to using software I wrote to do your development.
> Hunter
>
>    On Tuesday, June 6, 2023 at 03:47:56 PM PDT, Guillaume Nodet <
> gno...@apache.org> wrote:
>
>  Sounds like the only really plausible answer !  So if they can stay on a
> runtime which is 10 years old, an editor which has been released nearly 38
> years ago (well, not the latest version of course, but still...), why can't
> they stay on maven 3.9 which is a few months old ?
>
> My proposal was to support critical bug fixes (i.e. security or no
> work-around, but that can always be discussed) on the latest branches
> supporting LTS JDK for some time..., so 3.x for JDK 8, 4.x for JDK 17 and
> maybe 5.x for JDK 21 or 24 or whatever the LTS jdk would be at that time.
> That would be a change from what has been done for the past 15 years, as
> looking at history, I think 2.0.11 was the only micro version ever released
> after the next minor version.
>
> Guillaume
>
> Le mar. 6 juin 2023 à 23:05, Hunter C Payne
>  a écrit :
>
> >  emacs
> > Hunter
> >
> >    On Tuesday, June 6, 2023 at 11:19:43 AM PDT, Guillaume Nodet <
> > gno...@apache.org> wrote:
> >
> >  One question for people that want JDK 8 support.  What IDE do they use
> to
> > develop ? Because none of the actual IDE is running JDK 8, though they
> can
> > be used by JDK 8, just like maven with toolchains.
> > So really, the argument does not really stand, but for the very minority
> of
> > devs still using emacs/vim.
> > It really comes down to ease of use (i.e. not having to use --release
> flag
> > or to setup a toolchain) vs staying on JDK for 10 more years.
> >
> > Le mar. 6 juin 2023 à 18:32, Michael Osipov  a
> écrit
> > :
> >
> > > Am 2023-06-06 um 07:42 schrieb Hervé Boutemy:
> > > > it's not about *one not wanting* to upgrade (anybody can use JDK 17
> if
> > > they want currently)
> > > >
> > > > it's about *one forcing everybody else* to upgrade (and enter the
> > > toolchain setup question)
> > >
> > > EXACTLY!
> > >
> > >
> >
> > --
> > 
> > Guillaume Nodet
> >
>
>
>
> --
> 
> Guillaume Nodet
>
  

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

 Sorry to be glib.  I apologize.  But I did have a point.  The attitude that 
Guillaume has about my emacs (which has been updated more recently than either 
the JVM or your IDE) is exactly the same attitude I face when I try to get new 
users to use Maven.  In the case of Maven, it is use of XML for the pom, in the 
case of emacs its all the weird key bindings (which you actually already know 
because of bash).  I hope this actually helps.

Hunter

On Tuesday, June 6, 2023 at 04:42:10 PM PDT, Hunter C Payne 
 wrote:  
 
  Ok, sonny...go back to using software I wrote to do your development.
Hunter

    On Tuesday, June 6, 2023 at 03:47:56 PM PDT, Guillaume Nodet 
 wrote:  
 
 Sounds like the only really plausible answer !  So if they can stay on a
runtime which is 10 years old, an editor which has been released nearly 38
years ago (well, not the latest version of course, but still...), why can't
they stay on maven 3.9 which is a few months old ?

My proposal was to support critical bug fixes (i.e. security or no
work-around, but that can always be discussed) on the latest branches
supporting LTS JDK for some time..., so 3.x for JDK 8, 4.x for JDK 17 and
maybe 5.x for JDK 21 or 24 or whatever the LTS jdk would be at that time.
That would be a change from what has been done for the past 15 years, as
looking at history, I think 2.0.11 was the only micro version ever released
after the next minor version.

Guillaume

Le mar. 6 juin 2023 à 23:05, Hunter C Payne
 a écrit :

>  emacs
> Hunter
>
>    On Tuesday, June 6, 2023 at 11:19:43 AM PDT, Guillaume Nodet <
> gno...@apache.org> wrote:
>
>  One question for people that want JDK 8 support.  What IDE do they use to
> develop ? Because none of the actual IDE is running JDK 8, though they can
> be used by JDK 8, just like maven with toolchains.
> So really, the argument does not really stand, but for the very minority of
> devs still using emacs/vim.
> It really comes down to ease of use (i.e. not having to use --release flag
> or to setup a toolchain) vs staying on JDK for 10 more years.
>
> Le mar. 6 juin 2023 à 18:32, Michael Osipov  a écrit
> :
>
> > Am 2023-06-06 um 07:42 schrieb Hervé Boutemy:
> > > it's not about *one not wanting* to upgrade (anybody can use JDK 17 if
> > they want currently)
> > >
> > > it's about *one forcing everybody else* to upgrade (and enter the
> > toolchain setup question)
> >
> > EXACTLY!
> >
> >
>
> --
> 
> Guillaume Nodet
>



-- 

Guillaume Nodet
    

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

 Ok, sonny...go back to using software I wrote to do your development.
Hunter

On Tuesday, June 6, 2023 at 03:47:56 PM PDT, Guillaume Nodet 
 wrote:  
 
 Sounds like the only really plausible answer !  So if they can stay on a
runtime which is 10 years old, an editor which has been released nearly 38
years ago (well, not the latest version of course, but still...), why can't
they stay on maven 3.9 which is a few months old ?

My proposal was to support critical bug fixes (i.e. security or no
work-around, but that can always be discussed) on the latest branches
supporting LTS JDK for some time..., so 3.x for JDK 8, 4.x for JDK 17 and
maybe 5.x for JDK 21 or 24 or whatever the LTS jdk would be at that time.
That would be a change from what has been done for the past 15 years, as
looking at history, I think 2.0.11 was the only micro version ever released
after the next minor version.

Guillaume

Le mar. 6 juin 2023 à 23:05, Hunter C Payne
 a écrit :

>  emacs
> Hunter
>
>    On Tuesday, June 6, 2023 at 11:19:43 AM PDT, Guillaume Nodet <
> gno...@apache.org> wrote:
>
>  One question for people that want JDK 8 support.  What IDE do they use to
> develop ? Because none of the actual IDE is running JDK 8, though they can
> be used by JDK 8, just like maven with toolchains.
> So really, the argument does not really stand, but for the very minority of
> devs still using emacs/vim.
> It really comes down to ease of use (i.e. not having to use --release flag
> or to setup a toolchain) vs staying on JDK for 10 more years.
>
> Le mar. 6 juin 2023 à 18:32, Michael Osipov  a écrit
> :
>
> > Am 2023-06-06 um 07:42 schrieb Hervé Boutemy:
> > > it's not about *one not wanting* to upgrade (anybody can use JDK 17 if
> > they want currently)
> > >
> > > it's about *one forcing everybody else* to upgrade (and enter the
> > toolchain setup question)
> >
> > EXACTLY!
> >
> >
>
> --
> 
> Guillaume Nodet
>



-- 

Guillaume Nodet
  

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

 emacs
Hunter

On Tuesday, June 6, 2023 at 11:19:43 AM PDT, Guillaume Nodet 
 wrote:  
 
 One question for people that want JDK 8 support.  What IDE do they use to
develop ? Because none of the actual IDE is running JDK 8, though they can
be used by JDK 8, just like maven with toolchains.
So really, the argument does not really stand, but for the very minority of
devs still using emacs/vim.
It really comes down to ease of use (i.e. not having to use --release flag
or to setup a toolchain) vs staying on JDK for 10 more years.

Le mar. 6 juin 2023 à 18:32, Michael Osipov  a écrit :

> Am 2023-06-06 um 07:42 schrieb Hervé Boutemy:
> > it's not about *one not wanting* to upgrade (anybody can use JDK 17 if
> they want currently)
> >
> > it's about *one forcing everybody else* to upgrade (and enter the
> toolchain setup question)
>
> EXACTLY!
>
>

-- 

Guillaume Nodet
  

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

 So one dev said he specifically was dealing with an issue that someone else 
said wouldn't happen.  That's a binary decision which someone can't control, it 
is just true or not true (i'm assuming that the person who posted knew what 
they were talking about).  That isn't the same as a matter of taste which 
doesn't materially impact someones ability to work with the source base.  
Functionality trumps taste in my opinion.  That's why I treated those two 
matters differently.

As for Java lambdas, they don't really save you any keystrokes compared to a 
Java for comprehension so I just don't see the point.  Once you have real 
functions as first class objects with all the typing, currying and composition 
that comes with a real FP language, then you can do a lot more with less.  In 
the case of Java, you get so little for so much upgrade headache.  In the case 
of other FP languages, you get a huge number of new design patterns that fit a 
lot of use cases better than you can do with pure-OO.  So its a matter of 
degree to me.  You would really have to spend sometime coding in one of those 
languages to understand exactly what I mean but I hope this illustrates why 
some of us really don't care about upgrading JVM versions.  The language and 
its features that you use doesn't necessarily depend on later JVMs anymore.

All that being said, I have said my peace and I don't think continuing to reply 
will help anything.  I appreciate you listening.
Hunter

On Monday, June 5, 2023 at 11:53:28 PM PDT, Benjamin Marwell 
 wrote:  
 
 Hunter,

please keep to facts and do not get on a personal level:
> It isn't OK to just ignore their input
But then you say:
> Your personal taste shouldn't [...]

I think you just ignored some other dev's input yourself, as some already
voted for JDK11+.

> If you leave Java8, you leave behind everyone who can't upgrade their
source base.

That is not true, and the opposite has been said a few times now.
Yes, Java 8 users get behind regarding new features, which are Java17-only,
but that's not something new.
And then, I bet most Java 8 projects are not even on Maven 3.8. A lot are
not even on 3.6 yet.
They are already behind anyway. A new Maven JDK/JRE runtime version would
NOT change that,
nor would a Maven 4 release on Java 8.

Even then, you still were able to use toolchains and the --release switch
to use Maven 4 on your Java 8 project.
I did this for three years now, and never had issues.
Instead of just saying "you're leaving them behind" please state WHY this
would be true.
We have given you  facts that this is untrue (users CAN migrate), but
there's nothing
but an empty argument from your side. Please state why this would not be an
option in your view/opinion.

Some newer posts on this thread already stated that "attracting devs" would
be working,
because Maven should go with a recent LTS release, not with the oldest one.
So your assumption that I am the only one demanding this is wrong.

> PS Lambdas are only useful if there is function composition and
currying.  Java lacks both.
> So the debate over lambdas is pretty amusing to me.  It is just syntactic
sugar.

Some devs already voted in favour of syntactic sugar.
Most people here seem to doubt that they are not useful, and this is the
first time I heard of it.
Yes, Scala and Kotlin can do more -- but that doesn't make the status quo
for Java less valuable.

See posts from Romain, Delaney and Manfred for reference.

- Ben


Am Mo., 5. Juni 2023 um 21:41 Uhr schrieb Hunter C Payne
:

> Ok, so let's take these points one at a time:* Reduce build matrix, save
> energySo, less builds which is good but pretty minimal value.
> * Attract devsAbsolutely not.  If you want to attract devs, switch to a
> language that is actually growing (no I'm advocating for this).  That isn't
> Java.  If anything, this will lose you devs.  The company I work for will
> be leaving Maven if you stop supporting Java8.  That's 300 users you lose
> right there.  That's just 1 company.  You will lose users in droves if you
> stop Java8 support.  Many companies don't have/put enough resources into
> this type of upgrade.  Its hard to justify to the business and it makes
> lots of work for devs (expensive).  If it is cheaper to switch build
> systems that to upgrade the JVM, that's exactly what folks will do.  My
> company certainly will (not my decision so don't try to convince me, I'm
> not the one you have to convince).
>
> * CDS for non-OpenJ9-usersI'm not sure this is something that is really
> taken advantage of by Maven.  Perhaps I am wrong.
>
> * Better clarity of code (yes, I mean that)That you say that you actually
> mean this says it all.  Clearly this is something that isn't agreed upon
> uni

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

 Other projects have tried to do that (given they are different types of 
projects) and it turned out that keeping JVM8 support going when not compiling 
on JDK8 proved difficult and when push came to shove, it was JVM 8 support that 
was dropped.  I know that's not you or this project, but human nature is what 
it is and patterns tend to repeat.  So while I understand what you are saying, 
I have my doubts based upon past projects I have seen do this.

On the other hand, the reasons for the upgrade are always a bit weak and the 
upgrade really only created lots of support work for the devs and users (the 
security model is especially an issue) and yes they thought it would be 
seem-less too.  Writing code in any other JVM language would accomplish what 
you want far more effectively.  Instead you want to put lipstick on the pig and 
act like Java 21 is somehow like more modern languages (it isn't, it never will 
be).   Just because you can pass a function in Java, doesn't make it a FP 
language.  It has no currying, no function composition, it lacks a self-type, 
there are no concepts of co or contra variance in the types and that's just a 
short list off the top of my head.  That's the direction you are pushing with 
what you are asking about but Java 21 isn't the answer there as it has none of 
these things, while almost all of them would be useful in Maven itself.
So from my perspective, you are proposing a solution to a problem that doesn't 
exist while at the same time the solution you propose doesn't truly give you 
what you want.  Nobody wanting to a new language on their CV is going to need 
that language to be Java.  If they are joining the Maven project, it is likely 
because they want to contribute to Maven, not because Maven uses JDK 21.  And 
your users just don't want to be bothered and want their build system to work.  
It is hardly ideal and I have sympathy but it doesn't make dropping building of 
Maven by javac8 the right call.

Hunter
On Monday, June 5, 2023 at 02:22:59 PM PDT, Delany 
 wrote:  
 
 Your inclination to ignore points of the debate doesn't do your own
arguments any justice.
Multiple times it's been explained that raising the required runtime JDK in
Maven 4 will not prevent you from
- building with a lower JDK (via toolchains)
- targeting a lower JDK (via the release property)
- building with Maven 3

This is the main point of the debate, not the language.

On Mon, 5 Jun 2023 at 21:42, Hunter C Payne
 wrote:

> * Attract devsAbsolutely not.  If you want to attract devs, switch to a
> language that is actually growing (no I'm advocating for this).  That isn't
> Java.  If anything, this will lose you devs.  The company I work for will
> be leaving Maven if you stop supporting Java8.  That's 300 users you lose
> right there.  That's just 1 company.  You will lose users in droves if you
> stop Java8 support.  Many companies don't have/put enough resources into
> this type of upgrade.  Its hard to justify to the business and it makes
> lots of work for devs (expensive).  If it is cheaper to switch build
> systems that to upgrade the JVM, that's exactly what folks will do.  My
> company certainly will (not my decision so don't try to convince me, I'm
> not the one you have to convince).
>
> * CDS for non-OpenJ9-usersI'm not sure this is something that is really
> taken advantage of by Maven.  Perhaps I am wrong.
>
> * Better clarity of code (yes, I mean that)That you say that you actually
> mean this says it all.  Clearly this is something that isn't agreed upon
> universally.  Your personal taste shouldn't decide the future of a project
> used by so many others.
> * No additional work (we don't need to migrate, just use the features when
> modifying a line for a bug/feature anyway)This is simply not true.  There
> have been comments by devs on this very list, in this very discussion that
> disprove this point.  It isn't OK to just ignore their input because you
> really want to use lambdas.
>
> * We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have
> that backwards.  If you leave Java8, you leave behind everyone who can't
> upgrade their source base.  It seems to me that the size of the group of
> Java8 folks you will leave behind is quite large.  So your argument about
> no drawbacks isn't credible.  There are no drawbacks for you, that isn't
> the same as there being no drawbacks for the entire user base.
> * By the time Maven 4 final is out, your views might have changed!I write
> most of my code in Scala so I doubt it seriously.
>
> Your points are not nearly as strong as you imply with your tone.  Some of
> them indicate a lack of understanding of some more advanced parts of FP
> which is understandable

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

Ok, so let's take these points one at a time:* Reduce build matrix, save 
energySo, less builds which is good but pretty minimal value.
* Attract devsAbsolutely not.  If you want to attract devs, switch to a 
language that is actually growing (no I'm advocating for this).  That isn't 
Java.  If anything, this will lose you devs.  The company I work for will be 
leaving Maven if you stop supporting Java8.  That's 300 users you lose right 
there.  That's just 1 company.  You will lose users in droves if you stop Java8 
support.  Many companies don't have/put enough resources into this type of 
upgrade.  Its hard to justify to the business and it makes lots of work for 
devs (expensive).  If it is cheaper to switch build systems that to upgrade the 
JVM, that's exactly what folks will do.  My company certainly will (not my 
decision so don't try to convince me, I'm not the one you have to convince).

* CDS for non-OpenJ9-usersI'm not sure this is something that is really taken 
advantage of by Maven.  Perhaps I am wrong.

* Better clarity of code (yes, I mean that)That you say that you actually mean 
this says it all.  Clearly this is something that isn't agreed upon 
universally.  Your personal taste shouldn't decide the future of a project used 
by so many others.
* No additional work (we don't need to migrate, just use the features when
modifying a line for a bug/feature anyway)This is simply not true.  There have 
been comments by devs on this very list, in this very discussion that disprove 
this point.  It isn't OK to just ignore their input because you really want to 
use lambdas.

* We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have that 
backwards.   If you leave Java8, you leave behind everyone who can't upgrade 
their source base.  It seems to me that the size of the group of Java8 folks 
you will leave behind is quite large.  So your argument about no drawbacks 
isn't credible.  There are no drawbacks for you, that isn't the same as there 
being no drawbacks for the entire user base.
* By the time Maven 4 final is out, your views might have changed!I write most 
of my code in Scala so I doubt it seriously.

Your points are not nearly as strong as you imply with your tone.  Some of them 
indicate a lack of understanding of some more advanced parts of FP which is 
understandable for Java devs but doesn't make your points correct.  And your 
analysis of the impact on the userbase is just plain wrong.  If you want people 
to bomb this list with complains, drop Java 8 support and enjoy the rage 
postings you get from 100s to 1000s of devs who work for companies and projects 
that don't have to resources to upgrade.

Hunter
PS Lambdas are only useful if there is function composition and currying.  Java 
lacks both.  So the debate over lambdas is pretty amusing to me.  It is just 
syntactic sugar.  It doesn't actually give you the ability to do other things 
like in Scala or Kotlin.  So I don't really understand why you want to use them 
so much.  Are for loops really that hard to write?  I mean there is already so 
much ceremony in Java that saving 3 or 4 keystrokes per loop doesn't really 
make any difference.


   On Monday, June 5, 2023 at 11:52:16 AM PDT, Tamás Cservenák 
 wrote:  
 
 Seems people missed this (somewhat related) thread:

https://lists.apache.org/thread/kpsrb28nst84vtohwngy3140g1r0ydd4

Thanks


On Mon, Jun 5, 2023, 20:40 Hunter C Payne 
wrote:

>  Hi,  Karl, I'm not sure I agree you have "stated a benefit" so far.
> There have been plenty of hand-wavy arguments but nothing really solid.
> That's why you are getting so much push back.  Point to a specific feature
> you need or some other thing that would help the project in some
> significant way.  At the moment, the argument is basically, "its newer so
> its better", I'm sorry but that simply is not true.  Make a better case and
> you will get less pushback.
> Hunter
>
>    On Monday, June 5, 2023 at 06:03:26 AM PDT, Karl Heinz Marbaise <
> khmarba...@gmx.de> wrote:
>
>  Hi,
>
> On 03.06.23 11:46, Hervé Boutemy wrote:
> > +1
> >
> > I really don't what benefit we get from going to Java 17
>
> which was already part of the email:
>
>
>  > Based on the argument we don't need  features of JDK17+ I see a number
>  > of things which could make our handling/maintenance easier for example
>  > using sealed classes to prevent exposing internal things to public which
>  > could be used etc. also some other small features (`var` for example;
>  > Text-Blocks in Tests etc) or using records in some situation (really
> immutability)..
>  >
>  >
>
>
> Kind regards
> Karl Heinz Marbaise
>
> >
> > I perfectly see the impact 

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

 Hi,  Karl, I'm not sure I agree you have "stated a benefit" so far.  There 
have been plenty of hand-wavy arguments but nothing really solid.  That's why 
you are getting so much push back.  Point to a specific feature you need or 
some other thing that would help the project in some significant way.  At the 
moment, the argument is basically, "its newer so its better", I'm sorry but 
that simply is not true.  Make a better case and you will get less pushback.
Hunter

On Monday, June 5, 2023 at 06:03:26 AM PDT, Karl Heinz Marbaise 
 wrote:  
 
 Hi,

On 03.06.23 11:46, Hervé Boutemy wrote:
> +1
>
> I really don't what benefit we get from going to Java 17

which was already part of the email:


 > Based on the argument we don't need  features of JDK17+ I see a number
 > of things which could make our handling/maintenance easier for example
 > using sealed classes to prevent exposing internal things to public which
 > could be used etc. also some other small features (`var` for example;
 > Text-Blocks in Tests etc) or using records in some situation (really
immutability)..
 >
 >


Kind regards
Karl Heinz Marbaise

>
> I perfectly see the impact we'll have on our users: for what benefit?
>
> notice that this will also impact all plugins: and given the few work done on
> plugins to clearly show what plugin version remains compatible with a JDK
> release, I feel we're not taking the topic the right way
>
> Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit :
>>  I'm not sure I would worry too much about that David.  I think most devs
>> who want better syntax moved from Java sometime ago.  They might still be
>> on the JVM just not writing Java.  Also, Maven is a mature project.  I
>> don't think devs considering contributing to it are thinking about using
>> the latest and greatest version of Java.  Compatibility is probably a
>> bigger concern for the user base.  Just my opinion.
>>
>> Hunter
>>      On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks
>>  wrote:
>>
>>  I wonder if having maven require java 8 syntax discourages any potential
>> contributors who are used to coding using more recent developments. I have
>> no idea how to tell, but maybe someone else does.
>>
>> David Jencks
>>
>>> On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise  wrote:
>>>
>>> Hi,
>>>
>>> my clear opinion is to go  with most recent JDK LTS version for the
>>> release point of Maven 4.0.0 which I assume will be JDK 21...
>>>
>>> That means clear the build time requirement which is completely
>>> different from runtime of an application.
>>>
>>>
>>> Older JDK's are supported by some vendors by having particular special
>>> support which most of the time requires special contracts (means also
>>> paying money for it)..some of them offering builds without paying money
>>> yes..
>>>
>>> Older runtime target are supported with different approaches like
>>> Toolchain or via `--release XX` which exists since JDK9+.
>>>
>>>
>>> Furthermore if someone is not capable of upgrading the build environment
>>> to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X...
>>>
>>> If it would be requirement to port things back to 3.8.X or 3.9.X it
>>> could be handled by someone who has the time etc. to do that ... if not,
>>> those people might think of paying someone to do that work...
>>>
>>>
>>> The given argument about JPMS for migration causes issues is from my
>>> point of view false-positive because migration to newer JDK versions
>>> does not require JPMS usage...
>>>
>>> Even platforms like AWS support JDK17 in the meantime which is the
>>> runtime...
>>>
>>>
>>> Based on the maintenance part it would mean in consequence to downgrade
>>> to even JDK7... (or even lower) because you can get support for older
>>> JDK version in some ways... (JDK7 from azul for example)
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html


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

  

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

 Folks who think like that have been using Scala or Kotlin for at least 5 years 
by now.  If you are still writing Java, it isn't for new features.
Hunter

PS If you want to use "new features" use Scala or Kotlin.  If you want 
stability, use Java8.  Using Java17 is a middle ground that gets nobody 
anything they way.  That's why are having a hard time naming a new feature you 
want/need.
On Saturday, June 3, 2023 at 06:16:11 AM PDT, Delany 
 wrote:  
 
 There may not be a killer feature, but the cumulative changes are
appreciated, especially when you're used to them. Having closed the door on
whatever came before List.of its like a miniature thorn in my side every
time its not available.

What motivated the change to JDK8? Were there any negative repercussions
from that? All I'm reading is guesses about the impact. Is there an actual
example of when the required JDK was raised and a tool was dropped or lost
out to another because of it?

Anyway, if there's nothing substantial to gain from the change from 8 to
17, then I don't see what is so disruptive about requiring it. Given that
there's no single killer feature, and no obviously drawback, the argument
should probably center on principles and even on determining a rule for
Maven to follow (this isn't the first time this chestnut of an argument has
come up).

The vendor(s) and the source of the language are two different entities, so
who is Maven beholden to? Since vendor interests are monetized in a way
that Maven is not its more reasonable to expect Maven to follow Java's lead
(rather than a vendor's support lifecycle).

Despite the core principle of backward compatibility in the Java ecosystem,
not adopting the latest LTS for a major Maven release is clearly going
against Java's efforts to promote more regular update cycles and all the
many automation and security benefits that comes with that. When
people/businesses push back against updates I immediately think they must
have some sub-standard DevOps workflow. Given that DevOps/JS cynics will
probably gravitate to Java ecosystem this is unsurprising. Java is full of
conservative sentiment.

On the other hand there's the integrity of the language. Other languages
make a hard fork, while Java risks being multiple languages - fun for those
with decades of experience, but not encouraging to new faces who must
choose between 5 different ways to solve a problem. One of my colleagues
regularly portrays tech envy in sexual terms. Well guess what, we're human
not robots and yes its "sexier" and more "satisfying" to work with JDK17.
Ignoring that fact is itself irrational.

Delany

On Sat, 3 Jun 2023 at 11:46, Hervé Boutemy  wrote:

> +1
>
> I really don't what benefit we get from going to Java 17
>
> I perfectly see the impact we'll have on our users: for what benefit?
>
> notice that this will also impact all plugins: and given the few work done
> on
> plugins to clearly show what plugin version remains compatible with a JDK
> release, I feel we're not taking the topic the right way
>
> Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit :
> >  I'm not sure I would worry too much about that David.  I think most devs
> > who want better syntax moved from Java sometime ago.  They might still be
> > on the JVM just not writing Java.  Also, Maven is a mature project.  I
> > don't think devs considering contributing to it are thinking about using
> > the latest and greatest version of Java.  Compatibility is probably a
> > bigger concern for the user base.  Just my opinion.
> >
> > Hunter
> >    On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks
> >  wrote:
> >
> >  I wonder if having maven require java 8 syntax discourages any potential
> > contributors who are used to coding using more recent developments. I
> have
> > no idea how to tell, but maybe someone else does.
> >
> > David Jencks
> >
> > > On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise 
> wrote:
> > >
> > > Hi,
> > >
> > > my clear opinion is to go  with most recent JDK LTS version for the
> > > release point of Maven 4.0.0 which I assume will be JDK 21...
> > >
> > > That means clear the build time requirement which is completely
> > > different from runtime of an application.
> > >
> > >
> > > Older JDK's are supported by some vendors by having particular special
> > > support which most of the time requires special contracts (means also
> > > paying money for it)..some of them offering builds without paying money
> > > yes..
> > >
> > > Older runtime target are supported with different approaches like
> &

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hunter C Payne]

 I'm not sure I would worry too much about that David.  I think most devs who 
want better syntax moved from Java sometime ago.  They might still be on the 
JVM just not writing Java.  Also, Maven is a mature project.  I don't think 
devs considering contributing to it are thinking about using the latest and 
greatest version of Java.  Compatibility is probably a bigger concern for the 
user base.  Just my opinion.

Hunter
On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks 
 wrote:  
 
 I wonder if having maven require java 8 syntax discourages any potential 
contributors who are used to coding using more recent developments. I have no 
idea how to tell, but maybe someone else does.

David Jencks

> On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise  wrote:
> 
> Hi,
> 
> my clear opinion is to go  with most recent JDK LTS version for the
> release point of Maven 4.0.0 which I assume will be JDK 21...
> 
> That means clear the build time requirement which is completely
> different from runtime of an application.
> 
> 
> Older JDK's are supported by some vendors by having particular special
> support which most of the time requires special contracts (means also
> paying money for it)..some of them offering builds without paying money
> yes..
> 
> Older runtime target are supported with different approaches like
> Toolchain or via `--release XX` which exists since JDK9+.
> 
> 
> Furthermore if someone is not capable of upgrading the build environment
> to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X...
> 
> If it would be requirement to port things back to 3.8.X or 3.9.X it
> could be handled by someone who has the time etc. to do that ... if not,
> those people might think of paying someone to do that work...
> 
> 
> The given argument about JPMS for migration causes issues is from my
> point of view false-positive because migration to newer JDK versions
> does not require JPMS usage...
> 
> Even platforms like AWS support JDK17 in the meantime which is the
> runtime...
> 
> 
> Based on the argument we don't need  features of JDK17+ I see a number
> of things which could make our handling/maintenance easier for example
> using sealed classes to prevent exposing internal things to public which
> could be used etc. also some other small features (`var` for example;
> Text-Blocks in Tests etc) or using records in some situation...
> 
> 
> Based on the maintenance part it would mean in consequence to downgrade
> to even JDK7... (or even lower) because you can get support for older
> JDK version in some ways... (JDK7 from azul for example)
> 
> Kind regards
> Karl Heinz Marbaise
> 
> [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


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

  

Re: [DISCUSS] Allow attributes shorthand in pom.xml

[Hunter C Payne]

 I'm very glad you get some use out of reproducible builds.  Especially given 
the amount of work it seems to take (seems like ~1 out of every 3 emails is 
about this).  And you are right about my co-workers (pity me).  But perhaps you 
are not appreciating the scale of the problem.  Maven is losing an entire 
generation of devs right now for a very silly reason.  Don't dismiss it as just 
a grumble when it is so commonly heard.  

The issues with XML are more than just attributes.  It is also how lists and 
maps work in XML.  And gaining a simpler abstraction mechanism is just a 
optional bonus (the includes in HOCON).

Who really cares what format the users/devs write the POM in?  It doesn't have 
to effect the Maven devs nearly as much as breaking the venerable POM XML 
format would.  Let the computers translate from one format to another.  If 
users want to write their POMs in HOCON or JSON (or even, ick YAML) does it 
really matter as long as Maven can translate the POM into XML or the Maven 
internal POM data structures?  Its not like the internals of Maven are 
dependent upon the POM being written in XML anyway (yea abstraction).  The 
IDEs/tools can still use the translated XML POMs.  

It is much better than breaking the POM format which is the current proposal.  
In my opinion the original proposal of using XML attributes is putting a 
band-aid on a broken leg.  Seems like supporting other POM formats is less work 
for more win to me.  Especially since working POM conversion implementations 
already exist.
> You mention that 12 line SBT build - that’s great, but the moment you need to 
> deviate from something normal - it can deviate quite quickly IMHO.
It doesn't have to.

Hunter
On Sunday, December 13, 2020, 5:01:33 PM PST, Mark Derricutt 
 wrote:  
 
 Spoken just like someone who deals with people from high school in 2005.

I certainly care about reproducible builds - maybe not to the level of
some, but when working on projects that span multiple years, have multiple
deployments in different data centres for different customers, with
different versions deployed - that all need to be able to be maintained.

Being able to check out the version of the project that would deployed 2
years ago, and rebuild it with the exact same packages and get the same
build back - makes patching so much easier.

With a project made up on around 90 repos/artifacts ( non multi module - so
different releasee cadences across the board ), being able to check out
that old version - build it, reproduce the problem, patch one, maybe two
modules, and rebuild the platform for distribution with the minimum of
surface area change possible - for that patch release - and being able to
do that without major issue, in a short period of time - is a god send.

Sure, it MAY incur some upfront and ongoing costs - but the pay off, when
needed - is wonderful.

the level of frustration people have with Maven and its enthrallment with
XML at this point

I see a lot of folk grumble about XML, or mostly - the over use of elements
vs attributes, however, knowing that *everything* is an element (config
aside in a few plugins) is also a godsend for both tooling, and consistency.

I see far more people grumble about Gradle’s blend of DSL and Groovy
programming, and the dark majick that obscures where one changes from the
other ( I believe this is mitigated largely with the Kotlin DSL ).

You won’t have to look far to find someone, even those on the dev team who
don’t agree that the POM needs to change - but adoption, and usage is now
far far *beyond* merely just “Apache Maven” itself - so it’s not the
easiest thing to change.

You mention that 12 line SBT build - that’s great, but the moment you need
to deviate from something normal - it can deviate quite quickly IMHO.




From: Hunter C Payne 

Reply: Maven Developers List  
Date: 14 December 2020 at 10:06:25 AM
To: Maven Developers List  
Subject:  Re: [DISCUSS] Allow attributes shorthand in pom.xml

Hunter PS I've never even heard someone want a repeatable build.  I have no
idea why that would even be that desirable.  

Re: [DISCUSS] Allow attributes shorthand in pom.xml

[Hunter C Payne]

 Sorry if my tone was too much.  I tried to edit that out but apparently 
failed.  But perhaps you can appreciate the level of frustration people have 
with Maven and its enthrallment with XML at this point.

Build systems should be declarative but the only real option for that is Maven 
(in the JVM world).  And Maven is stuck in 2005 (someone had to say it).  Makes 
it hard when you write in a language created in 2010 and work with people who 
were in HS or less in 2005.  If I let them use a build system with logic in it, 
they hang themselves in a few weeks.  Maven is how I keep them from breaking 
everything twice a week.  And that's getting harder and harder to do when a pom 
file is 250 lines and a SBT file is 12 lines to do the same things.  Where do 
you work where this isn't a problem for you?

Hunter
PS I've never even heard someone want a repeatable build.  I have no idea why 
that would even be that desirable.

On Sunday, December 13, 2020, 11:53:34 AM PST, Bernd Eckenfels 
 wrote:  
 
 Hello,

Having includes in a format might be handy, but it does not fit the philosophy 
of maven of having a repeatable declarative style. If you need such modularity 
and imperative style you might be better off using gradle or simple pipeline 
scripts.

(With derived published POMs and changes like profiles and plugins not fitting 
into this it might have eroded over time, but coming from ANT I still value 
convention/declaration over imperative style - so every time I wish maven would 
be more open I remeber those times and I am reconsider if the task I have is 
suited for a maven Pom (after all its project model not build script)

BTW i abstain from commenting on your tone since we are all passionate about 
our experiences, it does trigger me to add this footnote, however.

Gruss
Bernd
--
http://bernd.eckenfels.net
________
Von: Hunter C Payne 
Gesendet: Saturday, December 12, 2020 8:02:15 PM
An: Maven Developers List 
Betreff: Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml

So there have been a few comments so far (yea) so I'm going to try to address 
them here:
1) choice of formatAny format that specifies a POM should have validation 
(which JSON, HOCON and XML do). YAML should be a non-starter as it has no 
validation (or types and it depends on invisible characters for formatting).  
But Unbound only translates between formats and so you can still write your 
1000s of lines of XML if you want but it allows the rest of us to have 10 line 
POM files.
But I've noticed that none of you have mentioned HOCON (which has comments) so 
far which leads me to think that none of you know this format or understand 
what it enables.  Its an extension of JSON so it picks up all the validation 
functionality.  But it also has an include primitive which allows abstracting 
of POMs in a really useful way.  I can write a block of HOCON and host it on a 
server somewhere in my infrastructure and then every project in the org can add 
an include line to use that block of POM.  That's so much nicer than the way we 
abstract POMs currently.  Multi-project POMs are often a nightmare to do mainly 
because the inheritance of POMs is so complex.
HOCON spec: https://github.com/lightbend/config/blob/master/HOCON.md

2) why we are doing thisIf you don't have problems getting teammates to use 
Maven, then you are the lucky 1%.  The rest of us have to work with folks under 
the age of 35 and its pretty impossible to get them to use or learn Maven due 
to XML.  Also, my HOCON POMs are a small fraction as long as the XML ones but 
with the same functionality.

I'm just not understanding the resistance here.  I feel like those that are 
resisting don't really understand the current developer community.  SBT is a 
slow and very poor build tool but people use it because they dislike XML that 
much more.  Not sure why folks on this list don't understand that.  XML is 
pretty universally hated at this point.  Perhaps best to just accept that 
instead of talking about features (XSD) that almost nobody ever used.

3) ease of integrationI'm only asking to have Unbound included, not to change 
the POM format, or require significant changes in Maven itself.  I'm not sure 
why you would want this as the tooling should still use XML for reasons of 
legacy and practicality.  But forcing devs to write POMs in XML by hand is 
currently required and pretty undesirable.
 4) what is wrong with XMLFor one the way lists and maps are represented are 
very verbose and unwieldy.  But the bigger thing for me is how inheritance is 
done in Maven.  Mutli-module projects are way too hard to make work.  A simpler 
block level inheritance that HOCON enables is far more preferable.  Consider 
this example:
https://github.com/hunterpayne/maven-unbound/blob/master/examples/rpm.conf
This block of code can be included by adding this to your HOCON POM:
 include file("ex

Re: AW: [DISCUSS] Allow attributes shorthand in pom.xml

[Hunter C Payne]

So there have been a few comments so far (yea) so I'm going to try to address 
them here:
1) choice of formatAny format that specifies a POM should have validation 
(which JSON, HOCON and XML do). YAML should be a non-starter as it has no 
validation (or types and it depends on invisible characters for formatting).  
But Unbound only translates between formats and so you can still write your 
1000s of lines of XML if you want but it allows the rest of us to have 10 line 
POM files.
But I've noticed that none of you have mentioned HOCON (which has comments) so 
far which leads me to think that none of you know this format or understand 
what it enables.  Its an extension of JSON so it picks up all the validation 
functionality.  But it also has an include primitive which allows abstracting 
of POMs in a really useful way.  I can write a block of HOCON and host it on a 
server somewhere in my infrastructure and then every project in the org can add 
an include line to use that block of POM.  That's so much nicer than the way we 
abstract POMs currently.  Multi-project POMs are often a nightmare to do mainly 
because the inheritance of POMs is so complex.
HOCON spec: https://github.com/lightbend/config/blob/master/HOCON.md

2) why we are doing thisIf you don't have problems getting teammates to use 
Maven, then you are the lucky 1%.  The rest of us have to work with folks under 
the age of 35 and its pretty impossible to get them to use or learn Maven due 
to XML.  Also, my HOCON POMs are a small fraction as long as the XML ones but 
with the same functionality.  

I'm just not understanding the resistance here.  I feel like those that are 
resisting don't really understand the current developer community.  SBT is a 
slow and very poor build tool but people use it because they dislike XML that 
much more.  Not sure why folks on this list don't understand that.  XML is 
pretty universally hated at this point.  Perhaps best to just accept that 
instead of talking about features (XSD) that almost nobody ever used.

3) ease of integrationI'm only asking to have Unbound included, not to change 
the POM format, or require significant changes in Maven itself.  I'm not sure 
why you would want this as the tooling should still use XML for reasons of 
legacy and practicality.  But forcing devs to write POMs in XML by hand is 
currently required and pretty undesirable.
 4) what is wrong with XMLFor one the way lists and maps are represented are 
very verbose and unwieldy.  But the bigger thing for me is how inheritance is 
done in Maven.  Mutli-module projects are way too hard to make work.  A simpler 
block level inheritance that HOCON enables is far more preferable.  Consider 
this example:
https://github.com/hunterpayne/maven-unbound/blob/master/examples/rpm.conf
This block of code can be included by adding this to your HOCON POM: 
 include file("examples/rpm.conf")

And now my pom can build RPMs in a single line.  Pretty nifty and so much 
better than repeating 80 or so lines of XML.
Hunter




   On Saturday, December 12, 2020, 8:20:08 AM PST, Gary Gregory 
 wrote:  
 
 On Sat, Dec 12, 2020 at 6:53 AM Robert Scholte  wrote:

> Here's my unpopular response: I'm not going to invest in attribute support
> for Maven.
> If the verbosity of the pom.xml is the first thing people complain about,
> well, then Maven is doing a pretty good job (if the build itself had
> issues, one would complain about that first, right?).
> By having elements only it is much easier to maintain Maven.
> It'll remove discussion as to: what would be an attribute and what should
> be an element? Can it be based on required versus optional? Allowing both
> for the same "fields" is probably a recipe for disaster.
>

That's simple IMO and what we usually do at my day job: XML elements and
attributes are like Types (Classes) and its attributes (instance
variables). It does not need to be more complicated than that. FWIW, I'm
baffled at the suggestion that optional vs. required has anything to do
with this.

Gary

I'll leave it up to tools like polyglot to do some the transformation from
> your favorite language to the XML as expected by Maven.
> This is a clear separation, and it will give the Maven team the
> opportunity to focus on the real issues.
>
> So please join your forces and spend your energy on improving polyglot!
>
> thanks,
> Robert
> On 12-12-2020 11:04:33, Markus KARG  wrote:
> Wouldn't it be a more modern and even more effective approach to add JSON
> support for POMs? We could keep POM.xml for legacy reasons but add support
> for POM.json files.
> -Markus
>
> -Ursprüngliche Nachricht-
> Von: Will Iverson [mailto:wiver...@gmail.com]
> Gesendet: Freitag, 11. Dezember 2020 23:40
> An: dev@maven.apache.org
> Betreff: [DISCUSS] Allow attributes shorthand in pom.xml
>
> One of the biggest complaints about Maven has long been the verbosity of
> the XML format. The verbosity is due in large part to the exclusive
> reliance on XML el

Re: [DISCUSS] Allow attributes shorthand in pom.xml

[Hunter C Payne]

I agree that the XML format is a bit long.  That's why a bit ago I wrote Maven 
Unbound.
Homepage: https://hunterpayne.github.io/maven-unbound-site/Source: 
https://github.com/hunterpayne/maven-unbound
Its a way to generate pom.xml files from Hocon/Json (and visa-versa).  This 
allows two things: 1) using the import functionality of Hocon to abstract my 
poms and 2) make very small and compact poms for each of my projects.  It makes 
using Maven look more like SBT but without the slowness of compiling Scala and 
with the declarative nature of Maven.  I think this is a better approach to 
making Maven less XML-like.  Also, this approach doesn't require the Maven devs 
to do anything other than merge my project into Maven proper.

thanx,
Hunter
   On Friday, December 11, 2020, 2:40:29 PM PST, Will Iverson 
 wrote:  
 
 One of the biggest complaints about Maven has long been the verbosity of
the XML format. The verbosity is due in large part to the exclusive
reliance on XML elements in Maven.

Proposal: Allow Maven pom.xml to treat attributes as a short-hand for
declaring configuration elements.

Example: One of the most verbose sections of the pom for most projects is
dependencies. A typical example:


commons-io
commons-io
2.8.0


Here is the same declaration expressed with attribute shortcuts:


That's an 80% reduction in LoC, and would make Maven comparable with other
popular build tools (e.g. compare and contrast with other build tools at
https://mvnrepository.com/artifact/commons-io/commons-io/2.8.0)

REQUEST: Feedback on if this is something to pursue. I've done some
research, happy to submit patches, but don't want to pursue if there is
either a) technical reason[s] not to proceed I'm not aware of or b) a lack
of enthusiasm for the entire idea from the community.

Basically, I'm looking for some feedback along the lines of a) love it -
please submit patches so we can check it out, b) huh, maybe, willing to
look at it, or c) this is a terrible idea, because X. Effectively, a
totally non-binding vote on if this is worth exploring.

I've discussed this with others online and done some research, so are a few
answers to objections/Qs as I currently understand. I may be
wrong/uninformed about certain aspects, which would be very helpful
feedback.

Q: Won't this require a new Maven XSD to be generated?
A: No. The current Maven XSD declares many elements, but is not actually
involved in validation. While the current XSD is valuable for tools and
documentation, it does not actually perform validation.

Q: Wait, so what actually does the validation?
A: It's all done in Java code generated by Modello. The maven-model project
(https://github.com/apache/maven/tree/maven-3.6.3/maven-model) relies on
the Modello Maven Plugin (
http://codehaus-plexus.github.io/modello/modello-maven-plugin/) which in
turn relies on Modello core (http://codehaus-plexus.github.io/modello/) to
generate the Java code that processes the pom.xml

The proposal is to submit a patch for Modello that would allow the
generated source to accept an attribute as an alias for input. If it's a
valid element per the Maven maven.mdo file (
https://github.com/apache/maven/blob/maven-3.6.3/maven-model/src/main/mdo/maven.mdo)
it will now accept an attribute as a shortcut.

Q: Wouldn't this break, like, everything?
A: It would only affect pom.xml files that are read at runtime. All emitted
pom.xml files would remain exactly the same.

Q: Does this involve changing or rewriting the user's pom.xml? Isn't that
the thing that's making it hard to support alternative formats for pom.xml
like polyglot poms, etc?
A: Nope, the pom.xml on disk is still the pom.xml. A
X.X.X would be the only flag
recommended to declare that a pom.xml uses attributes for shorthand.

Q: How much work is this to actually implement?
A: It starts with a few lines added to the Modello code generation to allow
for attribute aliasing with a feature flag. Testing those changes through
the rest of the dependency chain. Adding test cases throughout.
Documentation. although as "now you can use attributes" is conceptually
simple it's not too bad. Tools in the Maven ecosystem would be able to
indicate they have been updated to support this by referring to the simple
term, "attribute shortcuts". Because nothing else changes, the only real
documentation change would be "things that were elements can also be
declared as attributes." The trickiest part is probably sorting out how to
manage the feature flag across the various components. I'm sure there's
more with a huge ecosystem like this, but the actual changes to the Modello
code gen appear to be surprisingly minor.

Q: What about tooling, like IDEs, publishing to Maven Central & Maven
repositories, etc?
A: Many IDEs appear to have implemented validation logic on top of Maven
that currently will flag attributes as errors in a pom.xml. Those IDEs and
other tools would require updates to this validation logic. Because the
rendered pom.xml output rema

Re: Need a way to extend a plugin before build

[Hunter C Payne]

 I don't believe it is possible to change the POM during a single build.  
However, are you sure this is what you need.  Perhaps you instead need to the 
dependency scope of your dependency.  

Maven – Introduction to the Dependency Mechanism

| 
| 
|  | 
Maven – Introduction to the Dependency Mechanism

Brett Porter Trygve Laugstol Karl Heinz Marbaise


 |

 |

 |


Hunter

On Friday, April 17, 2020, 12:02:22 PM PDT, 雾月政变 <594403...@qq.com> wrote:  
 
 Hello:
       We have tried many ways to extend maven plugins, and 
we need a plugin that could process before build that we could change some 
dependency. Is there a way to do this with a maven plugin?  

Re: [DISCUSS] configuration for Reproducible Builds

[Hunter C Payne]

 What if that timestamp was based upon the scm's last commit timestamp instead 
of the time of the build?

Hunter
On Sunday, September 29, 2019, 10:25:41 AM PDT, Tibor Digana 
 wrote:  
 
 Can somebody explain a realistic USE CASE when you trigger two consequent
builds (with no changes in sources) and that you expect identical MD5 of
the build artifacts (JAR)?
This can be achieved only when the "timeStamp" in properties is fixed
unmodified in POM.
Does it make sense to call it timeStamp if it is not related to build time
nothing but some kind of , well I don't know what time because the time is
incremental and does not stop.
Even not very pragmatic to control it because you as USER have to correlate
MD5 with the algorith which produces the timeStamp and its changes.
If no MD5 has changed, the timeStamp would not change either. And here is
the problem: what if this rule is broken? And another problem: how you want
to ensure that the timeStamp is changed if and only if the changes have
been done. Somehow connected to the previous discussion with the
Incremental Build.

On Sun, Sep 29, 2019 at 5:55 PM Romain Manni-Bucau 
wrote:

> Hi all,
>
> Wonder if it can't "just" (this is not a small task but in terms of design
> it is small ;)) be a flag on higher level archiver plugins
> (maven-jar-plugin being the first one we'll all have in mind).
> I take as a reference jib here which takes into account a creation time for
> that case (
>
> https://github.com/GoogleContainerTools/jib/blob/master/jib-maven-plugin/src/main/java/com/google/cloud/tools/jib/maven/JibPluginConfiguration.java#L190
> ).
> Long story short, they have ~3 modes:
>
> 1. set epoch + 1s (there are issue setting epoch directly)
> 2. set a constant time configured by the user
> 3. respect file time (not reproducible but enable to disable it)
>
> At the end it means we don't need a project.build.* property but just to
> enrich plugins (maybe let's start with jar one) to handle that.
>
> I also wonder if I'm too biased on the topic but if I would have to work on
> it now with our current ecosystem, I would "just" (again ;)) use
> maven-shade-plugin and a set of transformers to handle all files which can
> have not deterministic changes.
> This enables to get the feature immediately without anything specific in
> maven core and handle even external plugin generated files through external
> transformers - a real reproducible build feature would need this extension
> anyway, think about frontend resources included in META-INF/resources for
> example.
> Only missing piece in shade plugin is the Jar reproducibility handling but
> this is likely very doable since we already have JarOutputStream impl at
> apache which can host it IMHO.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le dim. 29 sept. 2019 à 17:45, Hervé BOUTEMY  a
> écrit :
>
> > Le dimanche 29 septembre 2019, 12:29:47 CEST Karl Heinz Marbaise a écrit
> :
> > > Hi Hervé,
> > >
> > > On 29.09.19 11:19, Hervé BOUTEMY wrote:
> > > > regarding the property name, I had an idea:
> > > >
> > > > why not do like we already did for  ${project.build.sourceEncoding},
> > ie.
> > > > mimic a future element in pom.xml, in build?
> > > >
> > > > could be project.build.timestamp?
> > >
> > > This sounds like the best idea...
> > >
> > >
> > > This would mean to define something like this:
> > >
> > > 
> > >    ..
> > > 
> > >
> > > But now there are coming up some questions:
> > >
> > > * Is that the real value to be used?
> > > * Or should it activate the mechanism ? (boolean?)
> > we can define both a boolean and a timestamp
> > but the timestamp de-facto means also a boolean: defined means true,
> > undefined
> > means false
> >
> > >
> > > 
> > >    true
> > > 
> > >
> > >
> > > * Or should we use it by default and giving the user the opportunity
> > >    to overrite the current timestamp by fixed timestamp for building ?
> > >    This means we would define only the real time to be used during
> > >    building. No need for a kind of activation etc.
> > >    So you could call Maven via:
> > >
> > >    mvn -Dproject.build.timestamp=... package
> > >
> > >
> > > * Or do we need a combination of the above
> > >
> > >    First activate, define the format and the timestamp to be used.
> > >
> > >
> > > Furthermore do we need to define a format either which could look like
> > this:
> > >
> > > 
> > >    true
> > >    ..
> > >
> > ISO-8601
> > > 
> > letting the format as a third parameter is of course feasible, but adds
> > complexity: is it really necessary? Isn't ISO-8601 sufficient to you?
> >
> > >
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > > > Le samedi 28 septembre 201

Maven with Hocon and Json

[Hunter C Payne]

Hi Maven devs,
I emailed you about a month ago about an idea to allow Maven to use Hocon and 
Json formatted POMs which I called Unbound.
Just wanted to let you know that Unbound is beta now and ready to be used by 
others.

https://hunterpayne.github.io/maven-unbound-site/
Hunter

PS I'm interested in donating this project to Apache and integrating it 
directly into Maven.

Re: hocon and json formats for the Project Object Model

[Hunter C Payne]

Trying again in plain text.  Sorry for the resends.  Its Monday morning and I'm 
moving a bit slowly today...

https://github.com/hunterpayne/maven-unbound

Hunter





On Monday, June 10, 2019, 4:15:32 AM PDT, Enrico Olivelli  
wrote: 





Hi, Hunter,
I have received your email a bit corrupted.
Did you put some ASCII art ?
Did you add attachments ?

I find your idea interesting. thank you

Enrico

Il giorno lun 10 giu 2019 alle ore 11:33 Hunter C Payne
 ha scritto:


> Hello all,  I've used Maven for probably 15 years now.  I think its great
> and want to thank you all for all your hard work.
>    I've written a quick Scala library that converts pom.xml files to/from
> pom.json and pom.conf (Hocon) files.  This allows for a much less verbose
> way to specify pom files.  The code I've written should also be suitable to
> integrate into Maven proper (if you so choose) as it can construct the
> Maven bean classes that represent a POM in the Maven source base.
>
> Here is a link to that library which I call Unbound.  Hope everyone likes
> this little project and thinks it helps promote Maven.  Its not quite
> complete yet as a bit more testing and debugging is necessary before it can
> be used but I still wanted to broadcast the idea to see how everyone felt
> about it.
>
> hunterpayne/maven-unbound
>
> |
> |
> |
> |  |  |
>
>  |
>
>  |
> |
> |  |
> hunterpayne/maven-unbound
>
> Hocon and Json to Apache pom.xml. Contribute to hunterpayne/maven-unbound
> development by creating an account on ...
>  |
>
>  |
>
>  |
>
>
> thank you for your time,
> Hunter
>

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

hocon and json formats for the Project Object Model

[Hunter C Payne]

Hello all,   I've used Maven for probably 15 years now.  I think its great and 
want to thank you all for all your hard work.
   I've written a quick Scala library that converts pom.xml files to/from 
pom.json and pom.conf (Hocon) files.  This allows for a much less verbose way 
to specify pom files.  The code I've written should also be suitable to 
integrate into Maven proper (if you so choose) as it can construct the Maven 
bean classes that represent a POM in the Maven source base.  

Here is a link to that library which I call Unbound.  Hope everyone likes this 
little project and thinks it helps promote Maven.  Its not quite complete yet 
as a bit more testing and debugging is necessary before it can be used but I 
still wanted to broadcast the idea to see how everyone felt about it.

hunterpayne/maven-unbound

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
hunterpayne/maven-unbound

Hocon and Json to Apache pom.xml. Contribute to hunterpayne/maven-unbound 
development by creating an account on ...
 |

 |

 |


thank you for your time,
Hunter