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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



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 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!
> > > >
> > > >
> > >
> > > --
> > > 

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



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 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]

 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

[Gary Gregory]

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

[Guillaume Nodet]

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: [VOTE} Maven Build Cache Extension 1.0.1

[Olivier Lamy]

On Tue, 6 Jun 2023 at 22:53, Sylwester Lachiewicz  wrote:
>
> 0 - on list we have also improvement and new features but we Release bugfix
> only version.

if this help,  the issues which were marked minor are now classified
as improvements...
looking at recent releases of core and plugins they are only 0.0.1
increment even with improvements so this is following a similar
pattern.


>
> Sylwester
>
> wt., 6 cze 2023, 13:51 użytkownik Olivier Lamy  napisał:
>
> > Hi,
> > I'd like to release Maven Build Cache Extension 1.0.1
> > We fixed 13 issues
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352469=Text=12324820=Create
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1953/
> > source zip:
> > https://repository.apache.org/content/repositories/maven-1953/org/apache/maven/extensions/maven-build-cache-extension/1.0.1/maven-build-cache-extension-1.0.1-source-release.zip
> >
> > stages site:
> > https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/
> >
> > Vote open 72h
> >
> > +1
> > 0
> > -1
> >
> > cheers
> > Olivier
> >
> > -
> > 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: 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: Regarding timestamp in _remote.repositories

[Michael Osipov]

Am 2023-06-06 um 20:40 schrieb Eric Lilja:

I didn't know that the datetime string in _remote.repositories was an
artifact of the behavior of a JDK class (or Properties.store(), more
specifically). Interesting. That also implies it is not processed by
anything. Thanks.


It has been a pain in the ass for decades. There is an JBS issue for 
this, actually. In Maven Archiver I filter this line out.



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

Re: Regarding timestamp in _remote.repositories

[Eric Lilja]

I didn't know that the datetime string in _remote.repositories was an
artifact of the behavior of a JDK class (or Properties.store(), more
specifically). Interesting. That also implies it is not processed by
anything. Thanks.

- Eric L

On Tue, Jun 6, 2023 at 6:30 PM Michael Osipov  wrote:

> Am 2023-06-06 um 14:14 schrieb Eric Lilja:
> > Hello everyone, the timestamp (e.g., #Tue Jun 06 01:59:04 CEST 2023) in
> the
> > _remote.repositories file, is that just for human consumption or is it
> > processed? If only as a courtesy for humans, can its generation be
> disabled
> > somehow?
>
> 5 seconds of Google: https://stackoverflow.com/q/6184335/696632
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[ANN] Maven Surefire 3.1.2 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Surefire version 3.1.2.


https://maven.apache.org/surefire/


Release Notes - Maven Surefire - Version 3.1.2

** Bug
* [SUREFIRE-2163] - customBundle properly not subject to basedir 
alignment
* [SUREFIRE-2165] - TestSuiteXmlParser does not capture text per 
element causing concatenated text produced
* [SUREFIRE-2169] - Potential NPE in WrappedReportEntry when 
#getElapsed() is called

* [SUREFIRE-2176] - Invalid formatting of time attribute

** Improvement
* [SUREFIRE-1533] - surefire-test-report.xsd has too narrow a 
definition for testcase time attribute
* [SUREFIRE-2164] - Simplify serialization of elapsed time in 
StatelessXmlReporter
* [SUREFIRE-2166] - Use ChoiceFormat to selectively render 
percentage and elapsed time in SurefireReportRenderer
* [SUREFIRE-2167] - Simplify deserialization of elapsed time in 
TestSuiteXmlParser
* [SUREFIRE-2168] - Use proper en dash approximation for console 
report output
* [SUREFIRE-2170] - Use ChoiceFormat to selectively render elapsed 
time in WrappedReportEntry
* [SUREFIRE-2173] - Update compiler source/target in integration 
tests to version 8


** Task
* [SUREFIRE-2174] - Remove legacy Surefire test report schema file 
and make 3.0 default
* [SUREFIRE-2175] - Turn time attribute to xs:float in Surefire 
test report schema


** Dependency upgrade
* [SUREFIRE-2157] - Upgrade JUnit 5 to 5.9.3 (or 5.10.x..)
* [SUREFIRE-2171] - Upgrade to Maven Surefire 3.1.0


Enjoy,

-The Apache Maven team

-
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

[Guillaume Nodet]

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

[RESULT] [VOTE] Release Maven Surefire version 3.1.2

[Michael Osipov]

Hi,

The vote has passed with the following result:

+1: Michael Osipov, Tamás Cservenák, Karl Heinz Marbaise, Olivier Lamy, 
Slawomir Jaranowski, Romain Manni-Bucau, Sylwester Lachiewicz, 
Jean-Baptiste Onofré


PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Gary Gregory]

Note that Apache Commons Compress supports pack200.

Gary

On Tue, Jun 6, 2023, 09:52 Delany  wrote:

> Hi Jeremy. We're talking about the possibility of a drop-in replacement.
> But what you're suggesting requires alterations to the code, and having
> struggled with JAXB and its many unofficial plugins I can vouch for the
> difficulty in doing that.
> Perhaps it would have been easier if OpenJDK took responsibility for
> providing the packages and the plugin and setup a nice document somewhere
> to explain, but that's not what I found.
>
> Anyway, today I'm sitting with a version of izpack that depends on the
> Pack200 compression class removed from JDK17. Ok, so just add
> https://github.com/pack200/pack200 right? Oh, but izpack expects
> java.util.jar.Pack200 not io.pack200.Pack200. Should I update izpack? Yeah,
> and I've tried twice already, and will try again. Also tried rebuilding the
> izpack version from source, but it doesn't match with what was released.
> Next I'll try shading, etc, etc.
> Suffice to say there are issues.
> Delany
>
> On Tue, 6 Jun 2023 at 14:34, Jeremy Landis 
> wrote:
>
> > Delany,
> >
> > "You need toolchains if your code needs the JAXB classes removed in
> JDK11.
> > Delany"
> >
> > That isn't accurate.  You do not need toolchains for jaxb.  You need to
> > add the correct libraries.  I can understand that statement from a dev
> that
> > doesn't quite understand the history of EE inside java but its 100% easy
> to
> > do without adding toolchains.
> >
> > Jeremy
> >
> > -Original Message-
> > From: Delany 
> > Sent: Tuesday, June 6, 2023 1:33 AM
> > To: Maven Developers List 
> > Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
> >
> > You need toolchains if your code needs the JAXB classes removed in JDK11.
> > Delany
> >
> >
> > On Tue, 6 Jun 2023 at 01:54, Henning Schmiedehausen <
> > henn...@schmiedehausen.org> wrote:
> >
> > > To get this discussion a bit more back to actual substance:
> > >
> > > Do you still need toolchains with JDK 11/17? I set the release version
> > > to "8" (or anything else) in my builds, ripped out all the toolchains
> > > and it "just works". We have done this for Jdbi for ages (require Java
> > > 11+ as the build JDK; we even enforce "latest LTS" for releases) and
> > > compile to Java 8 bytecode. So far, we had zero complaints from users
> > > that the resulting releases do not work / cause problems on JDK 8.
> > >
> > > It seems to me that toolchains are only relevant if you need to
> > > compile to Java 1.6 or lower (shudder). The current LTS supports any
> > > version post-7 as release target.
> > >
> > > Am I missing something?
> > >
> > > Oh, I am totally cool with Maven 4 requiring Java 17 to run. In fact,
> > > this will give us an opportunity to actually use java 17 code to
> > > *write* maven, which in turn will collapse all of those thousand
> > > little domain objects into single line records. Can't wait for that.
> > > :-)
> > >
> > > The challenge for plugin writers will be to support Maven 3.x (mostly
> > > 3.8,
> > > 3.9) and 4 evenly. The current set of available modules and libraries
> > > makes that hard. A page with "use this to be compatible with that"
> > > would be helpful.
> > >
> > > -h
> > >
> > >
> > >
> > >
> > > On Mon, Jun 5, 2023 at 2:23 PM 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.  

[ANN] Maven Project Info Reports Plugin 3.4.5 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Project Info Reports Plugin version 3.4.5.


https://maven.apache.org/plugins/maven-project-info-reports-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-project-info-reports-plugin
  3.4.5



Release Notes - Maven Project Info Reports Plugin - Version 3.4.5

** Bug
* [MPIR-441] - Fix DependenciesReportTest
* [MPIR-448] - [REGRESSION] DependenciesRenderer chokes on invalid 
scope with a NPE


** Improvement
* [MPIR-447] - Gradle deprecates compile in favor of implementation
* [MPIR-449] - Don't count and display debug information if 
dependency does not contain class files



Enjoy,

-The Apache Maven team

-
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

[Romain Manni-Bucau]

So are we in "I see it as somebody forcing me to move forward" vs "I see it
as the project attraction decreasing and the community misbehaving"?

Any way we find a compromise or should we just vote and be it?

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



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!
>
>

[RESULT] [VOTE] Release Maven Project Info Reports Plugin version 3.4.5

[Michael Osipov]

Hi,

The vote has passed with the following result:

+1: Sylwester Lachiewicz, Olivier Lamy, Michael Osipov, Karl Heinz 
Marbaise, Gabriel Belingueres, Slawomir Jaranowski


PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

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

priv...@maven.apache.org

[Michael Osipov]

Subject: [RESULT] [VOTE] Release Maven Project Info Reports Plugin 
version 3.4.5


Hi,

The vote has passed with the following result:

+1: Sylwester Lachiewicz, Olivier Lamy, Michael Osipov, Karl Heinz 
Marbaise, Gabriel Belingueres, Slawomir Jaranowski


PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Michael Osipov]

Am 2023-06-06 um 11:26 schrieb Jean-Baptiste Onofré:

Hi,

I agree with Guillaume here. It's actually an easy update path.


For who? For you? Do you speak for others as well?


-
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

[Michael Osipov]

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!

Re: Regarding timestamp in _remote.repositories

[Michael Osipov]

Am 2023-06-06 um 14:14 schrieb Eric Lilja:

Hello everyone, the timestamp (e.g., #Tue Jun 06 01:59:04 CEST 2023) in the
_remote.repositories file, is that just for human consumption or is it
processed? If only as a courtesy for humans, can its generation be disabled
somehow?


5 seconds of Google: https://stackoverflow.com/q/6184335/696632


-
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

[Delany]

Hi Jeremy. We're talking about the possibility of a drop-in replacement.
But what you're suggesting requires alterations to the code, and having
struggled with JAXB and its many unofficial plugins I can vouch for the
difficulty in doing that.
Perhaps it would have been easier if OpenJDK took responsibility for
providing the packages and the plugin and setup a nice document somewhere
to explain, but that's not what I found.

Anyway, today I'm sitting with a version of izpack that depends on the
Pack200 compression class removed from JDK17. Ok, so just add
https://github.com/pack200/pack200 right? Oh, but izpack expects
java.util.jar.Pack200 not io.pack200.Pack200. Should I update izpack? Yeah,
and I've tried twice already, and will try again. Also tried rebuilding the
izpack version from source, but it doesn't match with what was released.
Next I'll try shading, etc, etc.
Suffice to say there are issues.
Delany

On Tue, 6 Jun 2023 at 14:34, Jeremy Landis  wrote:

> Delany,
>
> "You need toolchains if your code needs the JAXB classes removed in JDK11.
> Delany"
>
> That isn't accurate.  You do not need toolchains for jaxb.  You need to
> add the correct libraries.  I can understand that statement from a dev that
> doesn't quite understand the history of EE inside java but its 100% easy to
> do without adding toolchains.
>
> Jeremy
>
> -Original Message-
> From: Delany 
> Sent: Tuesday, June 6, 2023 1:33 AM
> To: Maven Developers List 
> Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
>
> You need toolchains if your code needs the JAXB classes removed in JDK11.
> Delany
>
>
> On Tue, 6 Jun 2023 at 01:54, Henning Schmiedehausen <
> henn...@schmiedehausen.org> wrote:
>
> > To get this discussion a bit more back to actual substance:
> >
> > Do you still need toolchains with JDK 11/17? I set the release version
> > to "8" (or anything else) in my builds, ripped out all the toolchains
> > and it "just works". We have done this for Jdbi for ages (require Java
> > 11+ as the build JDK; we even enforce "latest LTS" for releases) and
> > compile to Java 8 bytecode. So far, we had zero complaints from users
> > that the resulting releases do not work / cause problems on JDK 8.
> >
> > It seems to me that toolchains are only relevant if you need to
> > compile to Java 1.6 or lower (shudder). The current LTS supports any
> > version post-7 as release target.
> >
> > Am I missing something?
> >
> > Oh, I am totally cool with Maven 4 requiring Java 17 to run. In fact,
> > this will give us an opportunity to actually use java 17 code to
> > *write* maven, which in turn will collapse all of those thousand
> > little domain objects into single line records. Can't wait for that.
> > :-)
> >
> > The challenge for plugin writers will be to support Maven 3.x (mostly
> > 3.8,
> > 3.9) and 4 evenly. The current set of available modules and libraries
> > makes that hard. A page with "use this to be compatible with that"
> > would be helpful.
> >
> > -h
> >
> >
> >
> >
> > On Mon, Jun 5, 2023 at 2:23 PM 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 

Re: [VOTE} Maven Build Cache Extension 1.0.1

[Sylwester Lachiewicz]

0 - on list we have also improvement and new features but we Release bugfix
only version.

Sylwester

wt., 6 cze 2023, 13:51 użytkownik Olivier Lamy  napisał:

> Hi,
> I'd like to release Maven Build Cache Extension 1.0.1
> We fixed 13 issues
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352469=Text=12324820=Create
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1953/
> source zip:
> https://repository.apache.org/content/repositories/maven-1953/org/apache/maven/extensions/maven-build-cache-extension/1.0.1/maven-build-cache-extension-1.0.1-source-release.zip
>
> stages site:
> https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/
>
> Vote open 72h
>
> +1
> 0
> -1
>
> cheers
> Olivier
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE} Maven Build Cache Extension 1.0.1

[Elliotte Rusty Harold]

The dependencies could use a little work. The Guava problem is a true
positive. I haven't checked the others yet, but Guava could almost
certainly be removed from the build. Only one class that is no longer
needed in Java 8+ seems to be used.

Also, seeing two variants of plexus-utils in the list is a tad
concerning. I'm not sure what's up with that. I haven't noticed that
issue before so I'll have to dig in to see what's happening there.

Also, JUnit and SLF4J versions seem to be mixed up.

[WARNING] Used undeclared dependencies found:
[WARNING]org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.3.5:provided
[WARNING]org.apache.maven:maven-plugin-api:jar:4.0.0-alpha-5:provided
[WARNING]javax.inject:javax.inject:jar:1:provided
[WARNING]org.apache.maven:maven-model:jar:4.0.0-alpha-5:provided
[WARNING]org.junit.jupiter:junit-jupiter-api:jar:5.9.3:test
[WARNING]junit:junit:jar:4.13.2:test
[WARNING]org.jetbrains:annotations:jar:17.0.0:test
[WARNING]org.slf4j:slf4j-api:jar:1.7.36:compile
[WARNING]org.apache.maven:maven-artifact:jar:4.0.0-alpha-5:provided
[WARNING]org.apache.maven.resolver:maven-resolver-spi:jar:1.9.7:provided
[WARNING]com.google.guava:guava:jar:30.1-jre:provided
[WARNING]org.apache.maven.resolver:maven-resolver-api:jar:1.9.7:provided
[WARNING]org.apache.maven:plexus-utils:jar:4.0.0-alpha-5:provided
[WARNING] Unused declared dependencies found:
[WARNING]
org.apache.maven.resolver:maven-resolver-transport-http:jar:1.9.7:provided
[WARNING]org.codehaus.plexus:plexus-utils:jar:3.5.1:compile
[WARNING]org.apache.maven.wagon:wagon-webdav-jackrabbit:jar:3.5.3:compile
[WARNING]org.junit.jupiter:junit-jupiter-engine:jar:5.9.3:test
[WARNING]org.apache.maven:maven-embedder:jar:4.0.0-alpha-5:test
[WARNING]ch.qos.logback:logback-classic:jar:1.3.7:test
[WARNING]org.slf4j:log4j-over-slf4j:jar:1.7.36:test
[WARNING]org.slf4j:jcl-over-slf4j:jar:1.7.35:test
[WARNING]org.slf4j:jul-to-slf4j:jar:1.7.35:test




On Tue, Jun 6, 2023 at 7:51 AM Olivier Lamy  wrote:
>
> Hi,
> I'd like to release Maven Build Cache Extension 1.0.1
> We fixed 13 issues
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352469=Text=12324820=Create
>
> Staging repo: https://repository.apache.org/content/repositories/maven-1953/
> source zip: 
> https://repository.apache.org/content/repositories/maven-1953/org/apache/maven/extensions/maven-build-cache-extension/1.0.1/maven-build-cache-extension-1.0.1-source-release.zip
>
> stages site: 
> https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/
>
> Vote open 72h
>
> +1
> 0
> -1
>
> cheers
> Olivier
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: [VOTE} Maven Build Cache Extension 1.0.1

[Karl Heinz Marbaise]

Hi,

+1 from me.

Kind regards
Karl Heinz Marbaise
On 06.06.23 13:51, Olivier Lamy wrote:

Hi,
I'd like to release Maven Build Cache Extension 1.0.1
We fixed 13 issues
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352469=Text=12324820=Create

Staging repo: https://repository.apache.org/content/repositories/maven-1953/
source zip: 
https://repository.apache.org/content/repositories/maven-1953/org/apache/maven/extensions/maven-build-cache-extension/1.0.1/maven-build-cache-extension-1.0.1-source-release.zip

stages site: 
https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/

Vote open 72h

+1
0
-1

cheers
Olivier



-
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

[Jeremy Landis]

Delany,

"You need toolchains if your code needs the JAXB classes removed in JDK11.
Delany"

That isn't accurate.  You do not need toolchains for jaxb.  You need to add the 
correct libraries.  I can understand that statement from a dev that doesn't 
quite understand the history of EE inside java but its 100% easy to do without 
adding toolchains.

Jeremy

-Original Message-
From: Delany 
Sent: Tuesday, June 6, 2023 1:33 AM
To: Maven Developers List 
Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0

You need toolchains if your code needs the JAXB classes removed in JDK11.
Delany


On Tue, 6 Jun 2023 at 01:54, Henning Schmiedehausen < 
henn...@schmiedehausen.org> wrote:

> To get this discussion a bit more back to actual substance:
>
> Do you still need toolchains with JDK 11/17? I set the release version
> to "8" (or anything else) in my builds, ripped out all the toolchains
> and it "just works". We have done this for Jdbi for ages (require Java
> 11+ as the build JDK; we even enforce "latest LTS" for releases) and
> compile to Java 8 bytecode. So far, we had zero complaints from users
> that the resulting releases do not work / cause problems on JDK 8.
>
> It seems to me that toolchains are only relevant if you need to
> compile to Java 1.6 or lower (shudder). The current LTS supports any
> version post-7 as release target.
>
> Am I missing something?
>
> Oh, I am totally cool with Maven 4 requiring Java 17 to run. In fact,
> this will give us an opportunity to actually use java 17 code to
> *write* maven, which in turn will collapse all of those thousand
> little domain objects into single line records. Can't wait for that.
> :-)
>
> The challenge for plugin writers will be to support Maven 3.x (mostly
> 3.8,
> 3.9) and 4 evenly. The current set of available modules and libraries
> makes that hard. A page with "use this to be compatible with that"
> would be helpful.
>
> -h
>
>
>
>
> On Mon, Jun 5, 2023 at 2:23 PM 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 

Re: [VOTE} Maven Build Cache Extension 1.0.1

[Olivier Lamy]

Ping have been done here and on the PRs with a reasonable amount of time to
let people answer if they don’t I can’t do much….
There is no need to have 0 PRs in the queue before a release

On Tue, 6 Jun 2023 at 10:02 pm, Elliotte Rusty Harold 
wrote:

> There are three open PRs in the repo. At a quick glance, one looks
> like it perhaps should be closed unmerged, and the other needs to
> rebase onto master and be merged.
>
> On Tue, Jun 6, 2023 at 7:51 AM Olivier Lamy  wrote:
> >
> > Hi,
> > I'd like to release Maven Build Cache Extension 1.0.1
> > We fixed 13 issues
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352469=Text=12324820=Create
> >
> > Staging repo:
> https://repository.apache.org/content/repositories/maven-1953/
> > source zip:
> https://repository.apache.org/content/repositories/maven-1953/org/apache/maven/extensions/maven-build-cache-extension/1.0.1/maven-build-cache-extension-1.0.1-source-release.zip
> >
> > stages site:
> https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/
> >
> > Vote open 72h
> >
> > +1
> > 0
> > -1
> >
> > cheers
> > Olivier
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Regarding timestamp in _remote.repositories

[Eric Lilja]

Hello everyone, the timestamp (e.g., #Tue Jun 06 01:59:04 CEST 2023) in the
_remote.repositories file, is that just for human consumption or is it
processed? If only as a courtesy for humans, can its generation be disabled
somehow?

Best regards,
Eric Lilja

Re: [VOTE} Maven Build Cache Extension 1.0.1

[Elliotte Rusty Harold]

There are three open PRs in the repo. At a quick glance, one looks
like it perhaps should be closed unmerged, and the other needs to
rebase onto master and be merged.

On Tue, Jun 6, 2023 at 7:51 AM Olivier Lamy  wrote:
>
> Hi,
> I'd like to release Maven Build Cache Extension 1.0.1
> We fixed 13 issues
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352469=Text=12324820=Create
>
> Staging repo: https://repository.apache.org/content/repositories/maven-1953/
> source zip: 
> https://repository.apache.org/content/repositories/maven-1953/org/apache/maven/extensions/maven-build-cache-extension/1.0.1/maven-build-cache-extension-1.0.1-source-release.zip
>
> stages site: 
> https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/
>
> Vote open 72h
>
> +1
> 0
> -1
>
> cheers
> Olivier
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

[VOTE} Maven Build Cache Extension 1.0.1

[Olivier Lamy]

Hi,
I'd like to release Maven Build Cache Extension 1.0.1
We fixed 13 issues
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352469=Text=12324820=Create

Staging repo: https://repository.apache.org/content/repositories/maven-1953/
source zip: 
https://repository.apache.org/content/repositories/maven-1953/org/apache/maven/extensions/maven-build-cache-extension/1.0.1/maven-build-cache-extension-1.0.1-source-release.zip

stages site: 
https://maven.apache.org/extensions-archives/maven-build-cache-extension-LATEST/

Vote open 72h

+1
0
-1

cheers
Olivier

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

Re: [VOTE] Release Maven Surefire version 3.1.2

[Jean-Baptiste Onofré]

+1 (non binding)

Regards
JB

On Sat, Jun 3, 2023 at 9:32 PM Michael Osipov  wrote:
>
> Hi,
>
> we solved 15 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12353294
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1952/
> https://repository.apache.org/content/repositories/maven-1952/org/apache/maven/surefire/surefire/3.1.2/surefire-3.1.2-source-release.zip
>
> Source release checksum(s):
> surefire-3.1.2-source-release.zip
> sha512:
> 18be516e0d43673fa9c6754f34a90138d9fac58b81267b81cf9ce0401389c63570dec5b4eea350c939ea9ed599ccc14a7be60fd7517b897ce983c2ac3ca6207d
>
> Staging site:
> https://maven.apache.org/surefire-archives/surefire-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Jean-Baptiste Onofré]

Hi,

I agree with Guillaume here. It's actually an easy update path.

Regards
JB

On Wed, May 31, 2023 at 12:03 PM Guillaume Nodet  wrote:
>
> Le mer. 31 mai 2023 à 11:21, Michael Osipov  a écrit :
>
> > > I think with those improvements, requiring JDK 17 for master should be
> > > doable.  Any concerns of suggestions ?
> >
> > I am against this. There are enough people who cannot move to Java 17 for
> > a plethora of reasons regardless of Toolchains support. We provide a low
> > level tool and it should have a low barrier to use. Maven 4 should be used
> > as a transitional version to 5 to cut old ties and solve many issues --
> > even if we are in alpha phase now.
> > I bet many people will stick for 3.9.x or even 3.8.x for the years to come.
> >
>
> I don't get the argument here.  If people can stick with old versions of
> maven, this is actually an argument for moving the next releases forward,
> because that won't be a problem for them.
>
>
> >
> > M
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> 
> Guillaume Nodet

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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Romain Manni-Bucau]

@Hervé: was not really my point, more than forcing the maven version as
plugins do also forces the java version so as soon as we decide for maven
plugins are good. They can be compiled with java 8 and run on maven 3+4
while API is stable or just maven 4 if not. For external plugins some are
already compiled with java 11 only so will not run on java 8 builds even if
3.9 supports it so think this part is really good technically - agree with
you in terms of doc we can be better but requires a lot of time and effort
as you mentionned.

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



Le mar. 6 juin 2023 à 09:11, Hervé Boutemy  a écrit :

> you're right that we're currently talking about core, not plugins
>
> but this question will inevitably extend from core to plugins, and there
> are
> much more plugin developers than core developers
>
> then I think that getting a large view is useful
>
> and honestly, now that I had the opportunity to do the summary and find
> dist-
> tool + DOCCK-38 improvements, I know how to continue to prepare the future
> of
> this JDK prerequisite question on plugins
>
> I'll just need that people interested in upgrading JDK prerequisite help
> doing
> the hard documentation work required to make that move in a smooth way =
> avoid
> the "I only care about users who can use latest JDK" effect
>
> Regards,
>
> Hervé
>
> Le mardi 6 juin 2023, 08:29:16 CEST Romain Manni-Bucau a écrit :
> > Do we really care about plugins Hervé? They are compatible with some
> maven
> > versions so cover the underlying prerequisites, no?
> >
> > 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. 6 juin 2023 à 08:27, Hervé Boutemy  a
> écrit :
> > > > > 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
> > > >
> > > > Can you detail it please? While we keep plugin-api java 8 compat -
> which
> > >
> > > is
> > >
> > > > not under discussion there - there is no more impact than today
> > > > normally.
> > >
> > > currently, if you are still using JDK 7 or even earlier (not a shame,
> just
> > > a necessity), it's easy to select latest compatible Maven release:
> > > https://maven.apache.org/docs/history.html
> > >
> > > What about using latest compatible plugins?
> > > It's where finding documentation starts to become hard:
> > >
> > > - each plugin has it public documentation showing only the latest JDK
> > > prerequisite
> > >
> > > - our consolidated view itself is just known from experts only:
> > >
> > >
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/jo
> > > b/master/site/dist-tool-prerequisites.html
> > >
> > >
> > > we added some time ago "System Requirements History" for that purpose =
> > > https://issues.apache.org/jira/browse/MPLUGIN-400
> > > for example, once a plugin has documented its history, you get:
> > >
> > >
> https://maven.apache.org/maven-release/maven-release-plugin/plugin-info.ht
> > > ml#system-requirements
> > >
> > > Every plugin should document its system requirements history
> > > = we need to organise the work to make sure it's done in our own
> plugins:
> > > I did the job on a few ones, but it has to be generalised and I don't
> see
> > > anybody interested in doing the work (and I'm tired of doing myself the
> > > documentation cleanup on many aspects...)
> > >
> > > notice: now that I wrote that summary, I see we can:
> > > 1. add a check in dist-tool prerequisites report, to have a clear
> global
> > > view
> > > 2. add a check in DOCCK Maven Documentation Checker Plugin: it did not
> > > have any release for years, this will be a good reason to update it
> > > https://maven.apache.org/plugins/maven-docck-plugin/index.html
> > > https://issues.apache.org/jira/browse/MDOCCK-38 created
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, 

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

you're right that we're currently talking about core, not plugins

but this question will inevitably extend from core to plugins, and there are 
much more plugin developers than core developers

then I think that getting a large view is useful

and honestly, now that I had the opportunity to do the summary and find dist-
tool + DOCCK-38 improvements, I know how to continue to prepare the future of 
this JDK prerequisite question on plugins

I'll just need that people interested in upgrading JDK prerequisite help doing 
the hard documentation work required to make that move in a smooth way = avoid 
the "I only care about users who can use latest JDK" effect

Regards,

Hervé

Le mardi 6 juin 2023, 08:29:16 CEST Romain Manni-Bucau a écrit :
> Do we really care about plugins Hervé? They are compatible with some maven
> versions so cover the underlying prerequisites, no?
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github 
> | LinkedIn  | Book
>  >
> Le mar. 6 juin 2023 à 08:27, Hervé Boutemy  a écrit :
> > > > 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
> > > 
> > > Can you detail it please? While we keep plugin-api java 8 compat - which
> > 
> > is
> > 
> > > not under discussion there - there is no more impact than today
> > > normally.
> > 
> > currently, if you are still using JDK 7 or even earlier (not a shame, just
> > a necessity), it's easy to select latest compatible Maven release:
> > https://maven.apache.org/docs/history.html
> > 
> > What about using latest compatible plugins?
> > It's where finding documentation starts to become hard:
> > 
> > - each plugin has it public documentation showing only the latest JDK
> > prerequisite
> > 
> > - our consolidated view itself is just known from experts only:
> > 
> > https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/jo
> > b/master/site/dist-tool-prerequisites.html
> > 
> > 
> > we added some time ago "System Requirements History" for that purpose =
> > https://issues.apache.org/jira/browse/MPLUGIN-400
> > for example, once a plugin has documented its history, you get:
> > 
> > https://maven.apache.org/maven-release/maven-release-plugin/plugin-info.ht
> > ml#system-requirements
> > 
> > Every plugin should document its system requirements history
> > = we need to organise the work to make sure it's done in our own plugins:
> > I did the job on a few ones, but it has to be generalised and I don't see
> > anybody interested in doing the work (and I'm tired of doing myself the
> > documentation cleanup on many aspects...)
> > 
> > notice: now that I wrote that summary, I see we can:
> > 1. add a check in dist-tool prerequisites report, to have a clear global
> > view
> > 2. add a check in DOCCK Maven Documentation Checker Plugin: it did not
> > have any release for years, this will be a good reason to update it
> > https://maven.apache.org/plugins/maven-docck-plugin/index.html
> > https://issues.apache.org/jira/browse/MDOCCK-38 created
> > 
> > Regards,
> > 
> > Hervé
> > 
> > 
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org





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

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
> 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

Re: [VOTE] Release Maven Surefire version 3.1.2

[Slawomir Jaranowski]

+1

sob., 3 cze 2023 o 21:33 Michael Osipov  napisał(a):

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

-- 
Sławomir Jaranowski

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Benjamin Marwell]

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
> 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.  

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Romain Manni-Bucau]

Do we really care about plugins Hervé? They are compatible with some maven
versions so cover the underlying prerequisites, no?

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



Le mar. 6 juin 2023 à 08:27, Hervé Boutemy  a écrit :

> > > 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
> >
> > Can you detail it please? While we keep plugin-api java 8 compat - which
> is
> > not under discussion there - there is no more impact than today normally.
>
> currently, if you are still using JDK 7 or even earlier (not a shame, just
> a necessity), it's easy to select latest compatible Maven release:
> https://maven.apache.org/docs/history.html
>
> What about using latest compatible plugins?
> It's where finding documentation starts to become hard:
>
> - each plugin has it public documentation showing only the latest JDK
> prerequisite
>
> - our consolidated view itself is just known from experts only:
>
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html
>
>
> we added some time ago "System Requirements History" for that purpose =
> https://issues.apache.org/jira/browse/MPLUGIN-400
> for example, once a plugin has documented its history, you get:
>
> https://maven.apache.org/maven-release/maven-release-plugin/plugin-info.html#system-requirements
>
> Every plugin should document its system requirements history
> = we need to organise the work to make sure it's done in our own plugins:
> I did the job on a few ones, but it has to be generalised and I don't see
> anybody interested in doing the work (and I'm tired of doing myself the
> documentation cleanup on many aspects...)
>
> notice: now that I wrote that summary, I see we can:
> 1. add a check in dist-tool prerequisites report, to have a clear global
> view
> 2. add a check in DOCCK Maven Documentation Checker Plugin: it did not
> have any release for years, this will be a good reason to update it
> https://maven.apache.org/plugins/maven-docck-plugin/index.html
> https://issues.apache.org/jira/browse/MDOCCK-38 created
>
> Regards,
>
> Hervé
>
>
>
>
> -
> 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

[Hervé Boutemy]

> > 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
> 
> Can you detail it please? While we keep plugin-api java 8 compat - which is
> not under discussion there - there is no more impact than today normally.

currently, if you are still using JDK 7 or even earlier (not a shame, just a 
necessity), it's easy to select latest compatible Maven release:
https://maven.apache.org/docs/history.html

What about using latest compatible plugins?
It's where finding documentation starts to become hard:

- each plugin has it public documentation showing only the latest JDK 
prerequisite

- our consolidated view itself is just known from experts only:
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html


we added some time ago "System Requirements History" for that purpose = 
https://issues.apache.org/jira/browse/MPLUGIN-400
for example, once a plugin has documented its history, you get:
https://maven.apache.org/maven-release/maven-release-plugin/plugin-info.html#system-requirements

Every plugin should document its system requirements history
= we need to organise the work to make sure it's done in our own plugins: I did 
the job on a few ones, but it has to be generalised and I don't see anybody 
interested in doing the work (and I'm tired of doing myself the documentation 
cleanup on many aspects...)

notice: now that I wrote that summary, I see we can:
1. add a check in dist-tool prerequisites report, to have a clear global view
2. add a check in DOCCK Maven Documentation Checker Plugin: it did not have any 
release for years, this will be a good reason to update it
https://maven.apache.org/plugins/maven-docck-plugin/index.html
https://issues.apache.org/jira/browse/MDOCCK-38 created

Regards,

Hervé




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

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Sylwester Lachiewicz]

That's how we also our ci and local environment.
On prvarte laptops we use latest LTS and ea Java versions to build and
compile but use gha to check with other combinations.
Sometimes it's a bit huge
https://github.com/apache/maven-compiler-plugin/actions/runs/518201
- 3 latest Maven versions ("3.3.9", "3.8.8", "3.9.2")
- latest LTS Java "8", "11", "17" and non LTS "20"
- also people may use JDK from different vendors, previously not everything
was working in same way "temurin", "zulu", "microsoft", "adopt-openj9"

This results in around 120 runs donated by Azure/Microsoft resources (Thx!)

Then we do not run tests on Java 21-ea - to help with early bug detection
in Java or plugins - this would add around 6 more runs.
Believe me or not, but soon after Java 21 release someone will raise a bug
report if something isn't working (and that's good).

Recent bugs like https://github.com/google/error-prone/issues/3895 affected
also our pipeline (spotless plugin) - we can learn and adjust our setup.
"We" means The Community - everyone who can open PR and help improve our
products so everyone can benefot from it.

Sylwester


wt., 6 cze 2023 o 02:05 Henning Schmiedehausen 
napisał(a):

> Agreed, that is one way to do that, but it seems to me that this is a
> CI/integration test issue, not a build issue per se.
>
> We do the same thing in Jdbi: Build with the LTS JDK, then test against 8,
> 11, 17, current Java release:
> https://github.com/jdbi/jdbi/blob/master/.github/workflows/ci.yml
>
> Personally, I have zero interest in installing many JDKs on my laptop
> (hah!) and am happy to let the CI manage those. It's its job after all. :-)
>
> -h
>
>
> On Thu, Jun 1, 2023 at 9:51 AM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > define 3 Java versions in my toolchains.xml, and then add 3 executions
> for
> > surefire like here?
> >
> >
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/toolchains.html
> >
> > Thanks
> > T
> >
> >
> > On Thu, Jun 1, 2023 at 6:39 PM Gary Gregory 
> > wrote:
> >
> > > I claim it is not wasteful to run unit tests on Java 8, 11, and 17,
> which
> > > usually is the longest and most resource intensive part of a build.
> > >
> > > How would you do that were it not for a GitHub matrix?
> > >
> > > Gary
> > >
> > > On Thu, Jun 1, 2023, 08:01 Tamás Cservenák 
> wrote:
> > >
> > > > Howdy,
> > > >
> > > > From recent discussions I see an interesting pattern: it seems that
> > > people
> > > > (even our PMCs) are using Maven in a way that is making sure that
> "same
> > > > Java version" (I guess vendor + version) is used from "beginning" to
> > > "end".
> > > >
> > > > And "beginning" here means BUILDING (think workstations and CI and so
> > > on),
> > > > while "end" means PRODUCTION (deploying the stuff into production).
> > > >
> > > > Why is that?
> > > >
> > > > We all know that even before this "speedup" of Java releases (so to
> > say,
> > > up
> > > > to Java 8) we did put extra effort into supporting this (running
> Maven
> > on
> > > > different Java versions and producing another bytecode output). One
> > can:
> > > > - use source/target compiler flags + animal sniffer (if on Java 8 or
> > > older)
> > > > - use release compiler flag (if Java9+ used)
> > > > - use toolchains
> > > >
> > > > Why does any of these above "does not work" for those "aligning Java
> > from
> > > > beginning to end"?
> > > >
> > > > With today's tools like sdkman, jenv, homebrew, jbang, mvnw (and who
> > > knows
> > > > what) it is REALLY HARD to miss the automation of getting JDKs and
> > tools
> > > > (and keeping them up to date!!!) on workstations and CIs (deployment
> > not
> > > > counted here, but hopefully it is automated as well).
> > > >
> > > > Another point is that upcoming Maven 4 has tremendous improvements
> > > > targeting toolchains.
> > > >
> > > > Finally, a bit of digression, but very much related thing: as Niels
> > > > showcased on other thread in
> > > > https://github.com/nielsbasjes/ToolChainsInCiBuilds
> > > >
> > > > The CI "matrix" build's Java version part can be moved into Maven
> > itself.
> > > > Personally, I always hated "matrix" as they explode very easily (size
> > > wise)
> > > > but in MOST cases they really just "warm the oceans" (from HB) and do
> > not
> > > > do anything useful. I do keep _matrix useful_ for OS variations, but
> to
> > > > rebuild the same commit over and over with Java8, Java11, Java17 only
> > to
> > > > "be sure" it will work, is really an overkill (and very wasteful).
> The
> > > > added beauty of applying this pattern is that one can perform the
> whole
> > > > build and testing (using different Javas) even on their own
> > workstations.
> > > >
> > > > Does Maven miss some features (aside from those above) to make it
> > > possible
> > > > for those "aligning" Java versions to move?
> > > >
> > > > Thanks
> > > > T
> > > >
> > >
> >
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Hervé Boutemy]

Le mardi 6 juin 2023, 01:54:27 CEST Henning Schmiedehausen a écrit :
> To get this discussion a bit more back to actual substance:
> 
> Do you still need toolchains with JDK 11/17? I set the release version to
> "8" (or anything else) in my builds, ripped out all the toolchains and it
> "just works". We have done this for Jdbi for ages (require Java 11+ as the
> build JDK; we even enforce "latest LTS" for releases) and compile to Java 8
> bytecode. So far, we had zero complaints from users that the resulting
> releases do not work / cause problems on JDK 8.
> 
> It seems to me that toolchains are only relevant if you need to compile to
> Java 1.6 or lower (shudder). The current LTS supports any version post-7 as
> release target.
> 
> Am I missing something?
Yes: you are perfectly describing compiling
the missed part is unit-tests and *-tests execution = when they target Java 8 
bytecode, people want to execute tests against JDK 8

Regards,

Hervé



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