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

[Olivier Lamy]

+1

On Wed, 31 May 2023 at 07:35, Slawomir Jaranowski
 wrote:
>
> Hi,
>
> We solved 8 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317824=12353136
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRELEASE%20AND%20resolution%20%3D%20Unresolved
>
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1950/
> https://repository.apache.org/content/repositories/maven-1950/org/apache/maven/release/maven-release/3.0.1/maven-release-3.0.1-source-release.zip
>
> Source release checksum(s):
> maven-release-3.0.1-source-release.zip - SHA-512:
> e59018a70e67f8af38f4d02bc28703f54ec01d032bd9d21972d087bb196ed8997040da0600a687d5604ebed794ab444d67b697ae17f793f0e8908a4ca0a37f69
>
>
> Staging site:
> https://maven.apache.org/components/maven-release-archives/maven-release-LATEST
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Sławomir Jaranowski

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

 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: Question - JDK Minimum of future Apache Maven 4.0.0

[Olivier Lamy]

Perso I do not have any issue using 17.
By curiosity, I wonder what sort of 17 (or 9+) features we really want/need?
Pattern matching for switch?
record (so we can get rid of Modello but record will be not compatible
with previous standard beans).


On Fri, 2 Jun 2023 at 09:17, 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
>

-
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

[David Jencks]

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: Question - JDK Minimum of future Apache Maven 4.0.0

[Karl Heinz Marbaise]

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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Martijn Verburg]

As an FYI - https://adoptium.net/en-GB/support/ can give a guide as to the
thinking around OSS support for Java 8 (Nov 2026 is the minimum timeline,
it may extend).

Cheers,
Martijn


On Thu, 1 Jun 2023 at 23:36, Elliotte Rusty Harold 
wrote:

> On Thu, Jun 1, 2023 at 10:47 AM Romain Manni-Bucau
>  wrote:
>
> > Yep but this is also something an OSS product don't want to rely on (ie
> > particular vendor specificities which can change), so we should probably
> > stick to the global dates and align on these ones consistently.
> >
>
> Yes, but that principle implies the opposite. We should not rely on
> the particular vendor specificities of Oracle's commercial release,
> including when they decide to stop supporting JDK 8.
>
> The open source release of JDK 8 is available and will continue to be
> so for years. It is supported and maintained by multiple companies,
> organizations, and individuals, not just Oracle. It is an active
> project with quarterly releases and many active committers:
>
> https://wiki.openjdk.org/display/jdk8u/Main
>
> --
> 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] Maven runtime vs artifact runtime?

[Tamás Cservenák]

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: Maven 3.9.x plugins verifications

[Tamás Cservenák]

Howdy,

did locally a change that any validation issues are always reported in
DEBUG (left remains as before).

Here is an example output:
https://gist.github.com/cstamas/277a5c8b400af917e784a8b0f3f3db26

Simply put, DEBUG is always logged (for any kind), and if you use commands
like in gist (or tweak logging properties) you get output as this.

This also reveals how validation is not invoked on same spot:
- per module (once) plugins are resolved, that's where dep scopes etc are
validated (and reported once, as results are reused)
- per mojo invocation happens parameter and config validation

Thanks
T

On Thu, Jun 1, 2023 at 6:28 PM Romain Manni-Bucau 
wrote:

> +1, guess it should be off by default and on in verbose/-X.
> If user always want to see it or see only a subpart tunning is fine 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 jeu. 1 juin 2023 à 18:19, Tamás Cservenák  a
> écrit :
>
> > Howdy,
> >
> > well, am starting to think we should just use different loggers for these
> > (by locality) and let users tweak logging as they wish?
> >
> > Or any other idea?
> >
> > Thanks
> > T
> >
> > On Thu, Jun 1, 2023 at 2:44 PM Slawomir Jaranowski <
> s.jaranow...@gmail.com
> > >
> > wrote:
> >
> > > We have some of discussion about this feature in 3.9.2
> > >
> > > I saw some negative opinions ... Maybe I am missing something
> > > I think that people's nature is that when they don't like something
> they
> > > will speak about it ... but when people like something don't speak
> about
> > > it.
> > >
> > > So I would like to say that I like it :-)
> > >
> > > Of course users can not fix problems in used plugins, but I see that
> when
> > > we show those problems users start putting pressure on authors of
> plugins
> > > to fix it.
> > >
> > > Now in 3.9.3 we will group internal - problems which users can fix and
> > > external problems in plugins.
> > >
> > > By default we will show only internal violations in inline mode so
> > external
> > > violations will never be visible.
> > >
> > > now we have:
> > > - NONE - no reports
> > > - INLINE - internal violation in place where exist (default)
> > > - SUMMARY - reports summary but only about internal 
> > > - VERBOSE - boths internal and external in verbose mode
> > >
> > > I would like to have an option to see internal as inline and external
> as
> > > briev at the and of build,
> > > Now I don't have possibility to display reports for external issues in
> > > summary/brief mode
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Gary Gregory]

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: Maven 3.9.x plugins verifications

[Romain Manni-Bucau]

+1, guess it should be off by default and on in verbose/-X.
If user always want to see it or see only a subpart tunning is fine IMHO.

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



Le jeu. 1 juin 2023 à 18:19, Tamás Cservenák  a écrit :

> Howdy,
>
> well, am starting to think we should just use different loggers for these
> (by locality) and let users tweak logging as they wish?
>
> Or any other idea?
>
> Thanks
> T
>
> On Thu, Jun 1, 2023 at 2:44 PM Slawomir Jaranowski  >
> wrote:
>
> > We have some of discussion about this feature in 3.9.2
> >
> > I saw some negative opinions ... Maybe I am missing something
> > I think that people's nature is that when they don't like something they
> > will speak about it ... but when people like something don't speak about
> > it.
> >
> > So I would like to say that I like it :-)
> >
> > Of course users can not fix problems in used plugins, but I see that when
> > we show those problems users start putting pressure on authors of plugins
> > to fix it.
> >
> > Now in 3.9.3 we will group internal - problems which users can fix and
> > external problems in plugins.
> >
> > By default we will show only internal violations in inline mode so
> external
> > violations will never be visible.
> >
> > now we have:
> > - NONE - no reports
> > - INLINE - internal violation in place where exist (default)
> > - SUMMARY - reports summary but only about internal 
> > - VERBOSE - boths internal and external in verbose mode
> >
> > I would like to have an option to see internal as inline and external as
> > briev at the and of build,
> > Now I don't have possibility to display reports for external issues in
> > summary/brief mode
> >
> > --
> > Sławomir Jaranowski
> >
>

Re: Maven 3.9.x plugins verifications

[Tamás Cservenák]

Howdy,

well, am starting to think we should just use different loggers for these
(by locality) and let users tweak logging as they wish?

Or any other idea?

Thanks
T

On Thu, Jun 1, 2023 at 2:44 PM Slawomir Jaranowski 
wrote:

> We have some of discussion about this feature in 3.9.2
>
> I saw some negative opinions ... Maybe I am missing something
> I think that people's nature is that when they don't like something they
> will speak about it ... but when people like something don't speak about
> it.
>
> So I would like to say that I like it :-)
>
> Of course users can not fix problems in used plugins, but I see that when
> we show those problems users start putting pressure on authors of plugins
> to fix it.
>
> Now in 3.9.3 we will group internal - problems which users can fix and
> external problems in plugins.
>
> By default we will show only internal violations in inline mode so external
> violations will never be visible.
>
> now we have:
> - NONE - no reports
> - INLINE - internal violation in place where exist (default)
> - SUMMARY - reports summary but only about internal 
> - VERBOSE - boths internal and external in verbose mode
>
> I would like to have an option to see internal as inline and external as
> briev at the and of build,
> Now I don't have possibility to display reports for external issues in
> summary/brief mode
>
> --
> Sławomir Jaranowski
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Jeremy Landis]

On github I use the matrix across nearly everything just to show to users it 
works on various versions.  It has nothing to do at all with what is used to 
release it.  I use only jdk 17 on windows currently to release items on github.

For my paying job. We don't have that level of resources available so jave 17 
is it to target 8 or 11 or 17.  We don't use toolchains as IMO it's 
unnecessary.  We use the release tag and enforcer.  Got rid of animal sniffer 
long ago.

And given many plugins now require java 8. We don't bother with 8 anymore on 
repos I work on github outside of one that have this insistence in proving 8 
works.  But again no toolchain there either.  Just make GHA build it then pull 
jdk and run integration tests proving 8 works.

Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android

From: Tamás Cservenák 
Sent: Thursday, June 1, 2023 8:20:13 AM
To: Maven Developers List 
Subject: Re: [DISCUSS] Maven runtime vs artifact runtime?

Howdy,

But AFAIK the toolchain is similar, all you need is to
setup maven-toolchains-plugin once and done, so is "central" as well, no?
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fguides%2Fmini%2Fguide-using-toolchains.html=05%7C01%7C%7C22d12e2342394f27ef8b08db629a9c34%7C84df9e7fe9f640afb435%7C1%7C0%7C638212188408929080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=1YbaEsP6uVSBxYMfpdG61loWoH3DfYrPl9G9jAF49Ok%3D=0

What do you mean by "no need to configure here and there"? You mean
toolchains.xml? Or POM changes?
As Romain said, Guillaume made a nice change related to that

On Thu, Jun 1, 2023 at 2:12 PM Christoph Läubrich 
wrote:

>  > Does Maven miss some features
>
> Just look at how gradle support toolchains:
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.gradle.org%2Fcurrent%2Fuserguide%2Ftoolchains.html=05%7C01%7C%7C22d12e2342394f27ef8b08db629a9c34%7C84df9e7fe9f640afb435%7C1%7C0%7C638212188408929080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=vOWuj2rurVip7qPHg3wm1jRs8VDB0a8hhTbLHCLyDE0%3D=0
>
> That's all shows what maven refuses to support and leaving people think
> its easier to use the same JVM "from beginning to end":
>
> 1) First class declarative central configuration (no need to configure
> it here and there)
> 2) automatic discovery of installed toolchains
> 3) Support for automatically download if a matching one if not found
>
> All this has nothing to do with that is is *possible* to do so in maven
> as well, it is just not *convenient* to do so and as its is not *easy*
> as well (you can just miss a thing) people are skeptical and try to "be
> sure" by using the same JVM from start-to-end...
>
>
> Am 01.06.23 um 14:00 schrieb Tamás Cservenák:
> > 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnielsbasjes%2FToolChainsInCiBuilds=05%7C01%7C%7C22d12e2342394f27ef8b08db629a9c34%7C84df9e7fe9f640afb435%7C1%7C0%7C638212188408929080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=zLjPt3pJ54BQYKfbzb4wBErMbNeG4AbHstto4Df4Smc%3D=0
> >
> > The CI "matrix" build's Java version part can 

Maven 3.9.x plugins verifications

[Slawomir Jaranowski]

We have some of discussion about this feature in 3.9.2

I saw some negative opinions ... Maybe I am missing something
I think that people's nature is that when they don't like something they
will speak about it ... but when people like something don't speak about it.

So I would like to say that I like it :-)

Of course users can not fix problems in used plugins, but I see that when
we show those problems users start putting pressure on authors of plugins
to fix it.

Now in 3.9.3 we will group internal - problems which users can fix and
external problems in plugins.

By default we will show only internal violations in inline mode so external
violations will never be visible.

now we have:
- NONE - no reports
- INLINE - internal violation in place where exist (default)
- SUMMARY - reports summary but only about internal 
- VERBOSE - boths internal and external in verbose mode

I would like to have an option to see internal as inline and external as
briev at the and of build,
Now I don't have possibility to display reports for external issues in
summary/brief mode

-- 
Sławomir Jaranowski

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Tamás Cservenák]

Howdy,

But AFAIK the toolchain is similar, all you need is to
setup maven-toolchains-plugin once and done, so is "central" as well, no?
https://maven.apache.org/guides/mini/guide-using-toolchains.html

What do you mean by "no need to configure here and there"? You mean
toolchains.xml? Or POM changes?
As Romain said, Guillaume made a nice change related to that

On Thu, Jun 1, 2023 at 2:12 PM Christoph Läubrich 
wrote:

>  > Does Maven miss some features
>
> Just look at how gradle support toolchains:
>
> https://docs.gradle.org/current/userguide/toolchains.html
>
> That's all shows what maven refuses to support and leaving people think
> its easier to use the same JVM "from beginning to end":
>
> 1) First class declarative central configuration (no need to configure
> it here and there)
> 2) automatic discovery of installed toolchains
> 3) Support for automatically download if a matching one if not found
>
> All this has nothing to do with that is is *possible* to do so in maven
> as well, it is just not *convenient* to do so and as its is not *easy*
> as well (you can just miss a thing) people are skeptical and try to "be
> sure" by using the same JVM from start-to-end...
>
>
> Am 01.06.23 um 14:00 schrieb Tamás Cservenák:
> > 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
> >
>
> -
> 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?

[Romain Manni-Bucau]

Well, Guillaume's work kind of solves that...but still, even with gradle,
toolchains are a nightmare for most users so it is quite common to end with
the same jdk to build and run.

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



Le jeu. 1 juin 2023 à 14:12, Christoph Läubrich  a
écrit :

>  > Does Maven miss some features
>
> Just look at how gradle support toolchains:
>
> https://docs.gradle.org/current/userguide/toolchains.html
>
> That's all shows what maven refuses to support and leaving people think
> its easier to use the same JVM "from beginning to end":
>
> 1) First class declarative central configuration (no need to configure
> it here and there)
> 2) automatic discovery of installed toolchains
> 3) Support for automatically download if a matching one if not found
>
> All this has nothing to do with that is is *possible* to do so in maven
> as well, it is just not *convenient* to do so and as its is not *easy*
> as well (you can just miss a thing) people are skeptical and try to "be
> sure" by using the same JVM from start-to-end...
>
>
> Am 01.06.23 um 14:00 schrieb Tamás Cservenák:
> > 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
> >
>
> -
> 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?

[Christoph Läubrich]

> Does Maven miss some features

Just look at how gradle support toolchains:

https://docs.gradle.org/current/userguide/toolchains.html

That's all shows what maven refuses to support and leaving people think 
its easier to use the same JVM "from beginning to end":


1) First class declarative central configuration (no need to configure 
it here and there)

2) automatic discovery of installed toolchains
3) Support for automatically download if a matching one if not found

All this has nothing to do with that is is *possible* to do so in maven 
as well, it is just not *convenient* to do so and as its is not *easy* 
as well (you can just miss a thing) people are skeptical and try to "be 
sure" by using the same JVM from start-to-end...



Am 01.06.23 um 14:00 schrieb Tamás Cservenák:

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



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

[Romain Manni-Bucau]

Hi Tamas,

Think we have two kind of users:

* toolchain ones (probably minority) -> most plugins are okish there
* contextual ones (use the build jdk to run maven and build apps)

So overall I think we are quite targetting that already.

In terms of compat matrix, I agree it is werid to not build on one OS with
one Java version and test against other OS and version since it is the only
case which will happen at release time + it implies some lost time but not
sure how easy it would be to have a downstream build to replay the tests
only on our CI.

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



Le jeu. 1 juin 2023 à 14:02, Tamás Cservenák  a écrit :

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

[DISCUSS] Maven runtime vs artifact runtime?

[Tamás Cservenák]

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

[Elliotte Rusty Harold]

On Thu, Jun 1, 2023 at 10:47 AM Romain Manni-Bucau
 wrote:

> Yep but this is also something an OSS product don't want to rely on (ie
> particular vendor specificities which can change), so we should probably
> stick to the global dates and align on these ones consistently.
>

Yes, but that principle implies the opposite. We should not rely on
the particular vendor specificities of Oracle's commercial release,
including when they decide to stop supporting JDK 8.

The open source release of JDK 8 is available and will continue to be
so for years. It is supported and maintained by multiple companies,
organizations, and individuals, not just Oracle. It is an active
project with quarterly releases and many active committers:

https://wiki.openjdk.org/display/jdk8u/Main

-- 
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: Question - JDK Minimum of future Apache Maven 4.0.0

[Tamás Cservenák]

On Thu, Jun 1, 2023 at 12:51 PM Michael Osipov  wrote:

> Neither nor. Many use OpenJDK in production even w/o any commercial plans
> because they are happy with that. So there is also C.
>

And that is fine, if they are happy with it, they should be happy with
other "same age" tech, so they probably don't want to migrate to Maven 4
anyway

But seemingly we are again back at Delany's question: what do customer
(app/lib runtime) requirements have to do with the build tool's required
JDK?

T

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Michael Osipov]

Neither nor. Many use OpenJDK in production even w/o any commercial plans 
because they are happy with that. So there is also C.

On 2023/06/01 10:48:28 Tamás Cservenák wrote:
> This is silly.
> So we need to support Java 8 in the future (not yet happened) Maven 4
> releases due:
> 
> A) hobbyist (personal/individual users or for non-production,
> development/testing purposes)
> 
> OR
> 
> B) commercial entities paying for licenses (commercial/business use of
> those public releases in production is restricted and requires a commercial
> license)
> 
> Which one, A or B?
> 
> For me, cas A hobbyists will happily use the latest Java LTS. And in case B
> support DID end in a sense Guillaume meant it.
> 
> Thanks
> T
> 
> On Thu, Jun 1, 2023 at 12:39 PM Elliotte Rusty Harold 
> wrote:
> 
> > On Thu, Jun 1, 2023 at 6:28 AM Guillaume Nodet  wrote:
> > >
> > > JDK 8 active support ended 15 months ago, so I think that's definitely
> > fine
> > > to require a newer version.
> >
> > This is a common misconception. JDK 8 is fully supported by multiple
> > companies including Azul. It also seems supported by Oracle:
> >
> > "For Java SE 8, Oracle will continue to release new updates on its
> > public websites for personal/individual users or for non-production,
> > development/testing purposes.  However, commercial/business use of
> > those public releases in production is restricted and requires a
> > commercial license."
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> 

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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Tamás Cservenák]

This is silly.
So we need to support Java 8 in the future (not yet happened) Maven 4
releases due:

A) hobbyist (personal/individual users or for non-production,
development/testing purposes)

OR

B) commercial entities paying for licenses (commercial/business use of
those public releases in production is restricted and requires a commercial
license)

Which one, A or B?

For me, cas A hobbyists will happily use the latest Java LTS. And in case B
support DID end in a sense Guillaume meant it.

Thanks
T

On Thu, Jun 1, 2023 at 12:39 PM Elliotte Rusty Harold 
wrote:

> On Thu, Jun 1, 2023 at 6:28 AM Guillaume Nodet  wrote:
> >
> > JDK 8 active support ended 15 months ago, so I think that's definitely
> fine
> > to require a newer version.
>
> This is a common misconception. JDK 8 is fully supported by multiple
> companies including Azul. It also seems supported by Oracle:
>
> "For Java SE 8, Oracle will continue to release new updates on its
> public websites for personal/individual users or for non-production,
> development/testing purposes.  However, commercial/business use of
> those public releases in production is restricted and requires a
> commercial license."
>
> --
> 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: Question - JDK Minimum of future Apache Maven 4.0.0

[Romain Manni-Bucau]

Le jeu. 1 juin 2023 à 12:39, Elliotte Rusty Harold  a
écrit :

> On Thu, Jun 1, 2023 at 6:28 AM Guillaume Nodet  wrote:
> >
> > JDK 8 active support ended 15 months ago, so I think that's definitely
> fine
> > to require a newer version.
>
> This is a common misconception. JDK 8 is fully supported by multiple
> companies including Azul. It also seems supported by Oracle:
>
> "For Java SE 8, Oracle will continue to release new updates on its
> public websites for personal/individual users or for non-production,
> development/testing purposes.  However, commercial/business use of
> those public releases in production is restricted and requires a
> commercial license."
>

Yep but this is also something an OSS product don't want to rely on (ie
particular vendor specificities which can change), so we should probably
stick to the global dates and align on these ones consistently.


>
> --
> 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: Question - JDK Minimum of future Apache Maven 4.0.0

[Elliotte Rusty Harold]

On Thu, Jun 1, 2023 at 6:28 AM Guillaume Nodet  wrote:
>
> JDK 8 active support ended 15 months ago, so I think that's definitely fine
> to require a newer version.

This is a common misconception. JDK 8 is fully supported by multiple
companies including Azul. It also seems supported by Oracle:

"For Java SE 8, Oracle will continue to release new updates on its
public websites for personal/individual users or for non-production,
development/testing purposes.  However, commercial/business use of
those public releases in production is restricted and requires a
commercial license."

-- 
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: Question - JDK Minimum of future Apache Maven 4.0.0

[Michael Osipov]

On 2023/06/01 06:28:18 Guillaume Nodet wrote:
> JDK 8 active support ended 15 months ago, so I think that's definitely fine
> to require a newer version. I don't think we should wait and support JDK 8
> until 2030 and then switch from JDK 8 to what, JDK 24 ? That's really not a
> good plan imho and that's what maintenance branches are used for.  The JDK
> release cycle has changed and the whole java ecosystem is adapting to this
> faster release cycle.

So what? All we need to make sure that Maven runs on it, not requires it.

> So I think we should:
>   * maintain a 3.x branch with JDK 8 and provide bug fixes
>   * set up 4.x branches to require at least the oldest actively supported
> JDK at the time the first micro version is released (so that would be 17 by
> the time 4.0.0 comes out) and 21 by the end of 2026 (maybe 4.2.0 ?)
> JDK 17 can still target JDK 8 for compilation, so that should cover most
> needs.

We do already actively support newer JDKs.

> If needed, we could even automatically download a JRE 17 at first usage
> (using [1] but we'd have to check for upgrades, etc...) and continue the
> work for discovering toolchains [2], etc... to help users. We could also
> make JDK toolchains much easier to use by modifying the project model and
> adding specific support for it.  That would allow selecting the toolchains
> very early in the build, thus allowing toolchain based jdk activation, and
> would make the configuration much simpler.  Though I have a feeling that
> all this is not really necessary...

This sounds like a total waste of time and yet another NIH syndrome. Someone 
else has invented package managers aleady.

I am still against, we gain very little compared to the junk we still have in 
the basement. It requires a massive cleanup: JIRA has > 2000 open issues and 
rising. Cases, important ones not resolved for years. I don't see a reason to 
do something new if the foundation isn't clean.

M

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

Re: Build cache extension release

[Guillaume Nodet]

I've resolved conflicts and merged
https://github.com/apache/maven-build-cache-extension/pull/34

Le jeu. 1 juin 2023 à 07:27, Olivier Lamy  a écrit :

> Hi,
> I'd like to release the build cache extension in the coming days.
> If someone has something to merge or fix please let me know/
>
> cheers
> Olivier
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 

Guillaume Nodet

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Romain Manni-Bucau]

Sounds like a plan to me we have to adopt the new JDK release schedule
somehow anyway, we cant stick on java 8 now it is EOL and java 11 soon so
today only java 17 is a fair option for users.

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



Le jeu. 1 juin 2023 à 08:28, Guillaume Nodet  a écrit :

> JDK 8 active support ended 15 months ago, so I think that's definitely fine
> to require a newer version. I don't think we should wait and support JDK 8
> until 2030 and then switch from JDK 8 to what, JDK 24 ? That's really not a
> good plan imho and that's what maintenance branches are used for.  The JDK
> release cycle has changed and the whole java ecosystem is adapting to this
> faster release cycle.
>
> So I think we should:
>   * maintain a 3.x branch with JDK 8 and provide bug fixes
>   * set up 4.x branches to require at least the oldest actively supported
> JDK at the time the first micro version is released (so that would be 17 by
> the time 4.0.0 comes out) and 21 by the end of 2026 (maybe 4.2.0 ?)
> JDK 17 can still target JDK 8 for compilation, so that should cover most
> needs.
>
> If needed, we could even automatically download a JRE 17 at first usage
> (using [1] but we'd have to check for upgrades, etc...) and continue the
> work for discovering toolchains [2], etc... to help users. We could also
> make JDK toolchains much easier to use by modifying the project model and
> adding specific support for it.  That would allow selecting the toolchains
> very early in the build, thus allowing toolchain based jdk activation, and
> would make the configuration much simpler.  Though I have a feeling that
> all this is not really necessary...
>
> Guillaume
>
> [1] https://foojay.io/
> [2] https://github.com/apache/maven-toolchains-plugin/pulls
>
> Le mer. 31 mai 2023 à 21:17, Michael Osipov  a écrit
> :
>
> > I also would like to point out that OpenJDK 8 support will surpass 11 by
> > 2030: https://endoflife.date/java
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> 
> Guillaume Nodet
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Guillaume Nodet]

JDK 8 active support ended 15 months ago, so I think that's definitely fine
to require a newer version. I don't think we should wait and support JDK 8
until 2030 and then switch from JDK 8 to what, JDK 24 ? That's really not a
good plan imho and that's what maintenance branches are used for.  The JDK
release cycle has changed and the whole java ecosystem is adapting to this
faster release cycle.

So I think we should:
  * maintain a 3.x branch with JDK 8 and provide bug fixes
  * set up 4.x branches to require at least the oldest actively supported
JDK at the time the first micro version is released (so that would be 17 by
the time 4.0.0 comes out) and 21 by the end of 2026 (maybe 4.2.0 ?)
JDK 17 can still target JDK 8 for compilation, so that should cover most
needs.

If needed, we could even automatically download a JRE 17 at first usage
(using [1] but we'd have to check for upgrades, etc...) and continue the
work for discovering toolchains [2], etc... to help users. We could also
make JDK toolchains much easier to use by modifying the project model and
adding specific support for it.  That would allow selecting the toolchains
very early in the build, thus allowing toolchain based jdk activation, and
would make the configuration much simpler.  Though I have a feeling that
all this is not really necessary...

Guillaume

[1] https://foojay.io/
[2] https://github.com/apache/maven-toolchains-plugin/pulls

Le mer. 31 mai 2023 à 21:17, Michael Osipov  a écrit :

> I also would like to point out that OpenJDK 8 support will surpass 11 by
> 2030: https://endoflife.date/java
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 

Guillaume Nodet