Re: Maven Daemon release location: Also Maven Central?

[Jorge Solórzano]

Haven't used it yet, but seems that JReleaser could do the trick:
https://jreleaser.org/guide/latest/examples/maven/maven-central.html

On Sat, Oct 5, 2024 at 1:58 PM Guillaume Nodet  wrote:

> Why not, but I’m not sure how to do that.
> That was the primary reason why it has never reached central.  I’d like to
> avoid another manual step,m, so any idea welcomed !
>
> 
> Guillaume Nodet
>
>
>
> Le sam. 5 oct. 2024 à 11:16, Hervé Boutemy  a
> écrit :
>
> > good idea, why not
> >
> > this will be our first project doing full automated release staging from
> CI
> >
> >
> https://github.com/apache/maven-mvnd/blob/master/.github/workflows/release.yaml
> > (= the technical reason why pushing to classical Apache staging
> repository
> > has
> > not been done "as usual")
> >
> > Regards,
> >
> > Hervé
> >
> > Le vendredi 4 octobre 2024, 13:40:29 CEST Niels Basjes a écrit :
> > > Hi,
> > >
> > > Currently the full zip file of maven is released both via the download
> > > servers as it is published in maven central.
> > > -
> > >
> >
> https://dlcdn.apache.org/maven/maven-3/3.9.9/binaries/apache-maven-3.9.9-bin
> > > .zip -
> > >
> >
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.9.9/
> > >
> > > The new mvnd is however only published via  the download servers and
> via
> > > Github releases.
> > > - https://downloads.apache.org/maven/mvnd/1.0.2/
> > > - https://github.com/apache/maven-mvnd/releases
> > >
> > > At work the build environment is closed to the outside world, yet maven
> > > central is available (mirrored).
> > > So we can use the normal maven in the maven wrapper, but not the mvnd
> > > because it cannot be downloaded because of firewalls.
> > >
> > > How do you view publishing the mvnd also to maven central?
> > > I think that would make using it a lot easier for many people.
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4

[Jorge Solórzano]

There are some solutions/alternatives here:

1) Fixed value by default.
2) Warning to the user for having reproducible builds off.
3) Use the SCM last commit date.

I have worked a tiny bit for the Reproducible Builds effort so here is my 2
cents:

* Using the SCM last commit date is a bad choice, not everyone will use SCM
or the source code could be downloaded without scm information (eg.: Source
Code download links from GitHub), so this is a -1 for me.
* Throw a warning to the user to force the set of the project.build
.outputTimestamp value is also a -1 for me, this reminds me of the project.
build.sourceEncoding that was changed in Maven 4 to UTF-8 by default, and
having that default value is the correct way to proceed instead of an ugly
warning.
* This leaves us with the fixed value by default, the current value (in the
PR) is 2001-01-01T00:00:00Z this is a good approach, but my personal
preference is to set it to 1980-01-01T00:00:02Z, the minimal date allowed.

There should be a way to opt out of this and get the previous behavior for
those that don't what this.
As fo the release plugin, it should simply use the fixed date (if the
property is not set), having a warning seem ugly the same way as the
sourceEncoding warning was ugly.

Now, in my experience, sometimes setting the outputTimestamp is not enought
and is not a silver bullet to make a reproducible build.

So just to be clear, what is the really the end goal of enabling it by
default? I know the advantages and benefits, but what would be the goal of
having this opt-out instead of having it opt-in?



On Wed, Sep 25, 2024 at 11:03 AM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Le 2024-09-25 à 06 h 52, Mateusz Gajewski a écrit :
> >>
> >> For me this looks more like an issue of the jar plugin and should
> >> probably be handled there, then even though I wonder why the zip
> >> entries need a timestamp for a jar to be reproducible, should it not
> >> be enough to compare the zip-entries and leave the timestamp alone?
> >>
> > The idea of a reproducible build is to create binary exact artifacts
> > which you can quickly calculate checksum to compare with some
> > reference build. As the timestamp entry is used in zip/JARs, it
> > changes the binary representation of a jar as well. So yeah, that's
> > important.
> >
> (note: I'm duplicating here a comment I just made on the PR). I guess
> that checksum is not a goal in itself, but the higher level goal is
> security (checking that a JAR file has not been compromised)? If yes,
> then we do not necessarily need bit for bit reproducibility.
> "Semantically reproducible build" or "semantic equivalency" can be as
> good or even better, as it does not force us to throw away useful
> metadata like the real build time. Microsoft has short discussion about
> semantic equivalency there:
>
> https://github.com/microsoft/OSSGadget/wiki/OSS-Reproducible
>
> Could the real issue be that we do not have a Maven plugin for making
> semantic equivalency check easy? E.g. a plugin that build a project and
> automatically compare semantically against the JAR file on Maven Central
> or elsewhere?
>
>  Martin
>
>

Re: [VOTE] Release Apache Maven 3.9.9

[Jorge Solórzano]

+1 (nb)

On Tue, Aug 13, 2024, 18:13 Tamás Cservenák  wrote:

> Howdy,
>
> We solved 13 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12354823
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2179/
>
> Dev dist directory (binary bundles updated):
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.9/
>
> Source release checksums:
> apache-maven-3.9.9-src.tar.gz.sha512
>
> e5571a030a98c4f31f655b2a4909434bff69f84e61ab7269ff30c09f8b2db1b9d11010c7bcb6af6a375d142469e9382e06bd33a19788e76e0c38130ab9a535b1
>
> apache-maven-3.9.9-src.zip.sha512
>
> 5f58d932bff07e27f69cfc103f17df80e6e4d1c17c0597baa71e1a7f66e3c0c5c2035b8b7f448ef4adc023125f05a670ff29f1dc163fe4fefc309d02d7e9d9cd
>
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/554
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: Terminology proposal: "Maven module" -> "Maven sub-project"

[Jorge Solórzano]

On Mon, Aug 5, 2024 at 9:57 PM Guillaume Nodet  wrote:

> I think it's very feasible to get rid of  and replace with
>  in the POM.
> Without breaking compatibility of course, as we could keep 
> in POM 4.0 and use  in POM 4.1.
>
>
I like the approach of keeping  in POM 4.0 and using  in
POM 4.1.
+1

Re: [DISCUSS] Maven should ALWAYS install/deploy at end

[Jorge Solórzano]

+1 (nb) to make  installAtEnd and deployAtEnd properties true by default.

BTW, there is a note of "experimental" on the install plugin.


On Fri, Jun 14, 2024, 19:16 Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Le 2024-06-14 à 19 h 11, Gary Gregory a écrit :
> >
> > Thank you Martin for clarifying this! If I understand correctly: If I
> > said 'mvn clean deploy foo bar' in a multi-module project, then 'mvn
> > clean foo bar' happens first for all modules followed by 'mvn deploy'
> > for all modules?
> >
> This is my understanding of Tamas's proposal (maybe more like "mvn
> compile" for all modules followed by "mvn deploy" for all modules). But
> I may be wrong, we will need his confirmation.
>
>  Martin
>
>

Re: [VOTE] Release Apache Maven 3.9.7

[Jorge Solórzano]

On Fri, May 24, 2024 at 6:19 PM Andres Almiray  wrote:

> Looks like sha1 and sha512 are published already. Do you also need sha256
> explicitly?
>

Well, until Maven Wrapper also supports verifying sha512, yes, having
sha256 will be helpful.

Right now you can only set wrapperSha256Sum and distributionSha256Sum.

This is not for this release since is in the process of voting and that
will require a new release, but just for consideration.


> 
>
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/4.0.0-alpha-13/
>
> Cheers,
> Andres
>
>

Re: [VOTE] Release Apache Maven 3.9.7

[Jorge Solórzano]

+1

Can I kindly ask that Maven releases also contain sha256 checksums? This
could help to quickly check the checksum used in the wrapper.

Thanks!

On Fri, May 24, 2024 at 12:39 AM Guillaume Nodet  wrote:

> +1
>
> Le mer. 22 mai 2024 à 12:10, Tamás Cservenák  a
> écrit :
>
> > Howdy,
> >
> > We solved 21 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12353964
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-2125/
> >
> > Dev dist directory (binary bundles updated):
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.7/
> >
> > Source release checksums:
> > apache-maven-3.9.7-src.tar.gz.sha512
> >
> >
> a3c211ce683afbde9c4becf8b32397d14d3e7d8e8261094da037dcf27a697a93134440e055e7a9e7e26af2db543d4d9c4e7b0296560f5193df7ba90b9a68d1d1
> >
> > apache-maven-3.9.7-src.zip.sha512
> >
> >
> cdd8249807e251d07c613a65120058993e47a4cbf7f6dbda8599c7ca7ab4ed3fedc727e651f43cba0e9b0d604055c1106c1243be64a1d52c5ddf72dbec5e65dc
> >
> > Staged site:
> > https://maven.apache.org/ref/3-LATEST/
> >
> > Draft for release notes:
> > https://github.com/apache/maven-site/pull/521
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72h
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
>
>
> --
> 
> Guillaume Nodet
>

Re: Nope, 3.5 isn't dead

[Jorge Solórzano]

Hi Elliotte,

You mentioned that you are trying to upgrade but it seems the problem is
not updating Maven itself, but updating the Docker images and/or CI
infrastructure, that doesn't look like an issue with Maven, and in any
case, for a legacy project that doesn't care to maintain or update Maven,
what is the point of updating in the first place? They are working fine
with an old release and as Slawomir mentioned the best and easier way is to
not touch dependencies and use it as is with old (current) infrastructure.

For instance, if the problem with updating is that they are using Java 7,
Maven will be the least of the issues, they are using an EOL Java version
anyway so they should care less about using an EOL Maven version (keep in
mind that Maven 3.5.x is EOL) if large organizations (especially large tech
companies) require "maintenance" for such older versions, they should pay
for it, Maven developers do a fantastic job by contributing to Maven as
volunteers, so if large companies depend on open-source projects, they
could at least financially contribute back.

In any case, what kind of support do you expect? Maven 3.5.x won't get a
new release or bug fix (at least I think not by the current maintainers)
because is simply EOL, the decision to "require" Maven 3.6.3 affects mostly
plugins, and most plugins have moved to Java 8 anyway, so for a Java 7
project most plugins won't work even on Maven 3.8.8.

I'm assuming Java 7 to illustrate the point of one potential issue, as
updating Maven from 3.5 to 3.6 (or even the latest version) should be
straightforward, but if updating Docker images or the CI infra is a hassle,
even if that version was still maintained, the problem would be there, not
on maven.

So, yes 3.5 is dead.

Regards,

On Sat, Apr 13, 2024 at 1:22 PM Elliotte Rusty Harold 
wrote:

> Maybe it should be, but I wanted to drop a note that about a month
> after December's decision to require Maven 3.6.3, I shifted onto an
> open source project that's been around for 10+ years, is actively
> backed by two large tech companies, and still depends on Maven 3.5.x
> in the continuous integration build. Bleah.
>
> I've been trying to upgrade it, but so far without success. 3.5 seems
> baked pretty deeply into the Docker images or some other part of the
> CI infrastructure that isn't easy to change. This project could well
> be using Maven 3.5 for years to come. It's even possible we will
> rewrite the whole codebase in C++ before we manage to get past Maven
> 3.5. (I wish that was hyperbole. It's not.)
>
> I think we tend to overestimate how fast the installed base updates,
> whether it's JDKs (I got a bug report from someone still using Java 7
> yesterday), Maven versions, operating systems, or pretty much anything
> else. None of us see more than a small fraction of the projects out
> there. It is very easy to look at that small fraction and draw
> conclusions that are falsified with a larger or different sample.
>
> I didn't know about this dependence on Maven 3.5 until I changed
> projects in January. I haven't seen 3.3 lately, but I wouldn't be
> surprised if it's still in use in multiple organizations, perhaps
> because it's what's installed by default in some old Linux distro that
> should also be retired but isn't. Absence of evidence is not evidence
> of absence, including when considering which Maven versions developers
> actively use.
>
> --
> 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] Require Java 17 for Maven 4

[Jorge Solórzano]

+1


On Wed, Feb 28, 2024, 01:31 Benjamin Marwell  wrote:

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

Re: [DISCUSS] Java version for Maven

[Jorge Solórzano]

On Sat, Feb 24, 2024, 17:24 Hunter C Payne
 wrote:

>  Is a JDK 17 capable of building JDK 8 jars from JDK 17 source?


No, it doesn't, you can use JDK 17 to produce Java 8 bytecode using Java 8
features, that is the distinction I made between runtime and build time,
but it looks it's still not clear.

To use Java 17 features, you need to produce Java 17 bytecode, and that
requires at least Java 17 as runtime.

  If so, what are we discussing/arguing/debating about?  Seems to me that
> that configuration gets you everything you want without forcing Maven 4 to
> not work with JVM/JRE 8.
> Hunter
>
> On Saturday, February 24, 2024 at 03:09:07 PM PST, Jorge Solórzano <
> jor...@gmail.com> wrote:
>
>  On Sat, Feb 24, 2024, 16:55 Tamás Cservenák  wrote:
>
> > Jorge,
> >
> > Allow me one question: why would we need 3.10 for this? Could not we set
> > same thing for existing 3.9.x?
> >
>
> Yes, but 3.10 can be used to better signal that is an LTS since the
> beginning and will only contain critical bug fixes, breaking change should
> not happen, in other words, that's not actively worked on and will be the
> last version of the 3.x line.
>
> Other than that, if it's agreed to just use 3.9 as LTS, then simply
> s/3.10/3.9/ on the previous mail. :)
>
>
>
>
>
> > T
> >
> >
> >
> >
> > On Sat, Feb 24, 2024, 23:43 Jorge Solórzano  wrote:
> >
> > > Hi Maven Developers,
> > >
> > > A lot has been told already from both sides, but please, please, let's
> > > focus on how to improve the current status and define how and what Java
> > > version will be required for Maven, not on trivial discussions about
> > using
> > > var or virtual threads.
> > >
> > > Most developers would love to use the latest and greatest JDK, while
> > > Enterprises want stability for deployments, here, we need to change the
> > > mindset as the OpenJDK release cadence is not going to slow down.
> > >
> > > The Java ecosystem is moving forward and Maven should not get stuck
> with
> > a
> > > 10 years old JDK version.
> > >
> > > There are many trade-offs from both sides, many complaints, and (sorry
> to
> > > be harsh) many absurd arguments for being stuck until 2030 with Java 8.
> > >
> > > I don't want to fall into the trap of "since I use it this way, I'm
> > correct
> > > and you don't ", so I will try to be as impartial as possible, I do
> agree
> > > there is a need to support a Maven compatible with Java 8, I also do
> > agree
> > > that developers would like to use latest JDK features on Maven
> > > core/plugins, so there needs to be a middle ground.
> > >
> > > First, we need to distinguish the difference between the required Java
> > > version used at RUNTIME vs the Java version used at BUILD TIME, anyone
> > can
> > > compile a Java project at build time using Java 21 and target Java 8,
> so
> > > here the issue is not about using Java 9+ (11, 17, 21) to compile code
> > that
> > > will be used at runtime in Java 8, and if every project makes uses of
> the
> > > --release option of java compiler, there will be no issues as we are
> > simply
> > > targeting to Java 8, it doesn't matter if you compile with Java
> 11/17/21
> > > if, in the end, the produced bytecode is Java 8 compatible. What we are
> > > talking about here is the Java version required at RUNTIME, meaning
> that
> > if
> > > we raise the Java version to something like Java 17, it will not work
> > with
> > > Java 11 or 8, with that point being clear, let's continue.
> > >
> > > Before my proposal, a little disclaimer: I'm just an occasional
> > > contributor, not a committer or Maven PMC, and while would be great to
> > have
> > > a full-time job to work on Maven, is currently not my case.
> > >
> > > So, the proposal that could make everyone happy is this:
> > >
> > > This proposal suggests the introduction of a *Long-Term Support (LTS)*
> > > version of *Maven 3.10.x *targeting *Java 8* and *Maven 4.0* targeting*
> > > Java 17.*
> > >
> > > In other words, let's require Java 17 in Maven 4.0 at RUNTIME, and the
> > same
> > > day that Maven 4.0 is released, cut and release a version of Maven
> > 3.10.0,
> > > this version (3.10.x) will be marked as LTS, and "supported" for up to
> 3
> > or
> > > 5 years (dependi

Re: [DISCUSS] Java version for Maven

[Jorge Solórzano]

On Sat, Feb 24, 2024, 16:55 Tamás Cservenák  wrote:

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

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

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





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

Re: [DISCUSS] Java version for Maven

[Jorge Solórzano]

Hi Maven Developers,

A lot has been told already from both sides, but please, please, let's
focus on how to improve the current status and define how and what Java
version will be required for Maven, not on trivial discussions about using
var or virtual threads.

Most developers would love to use the latest and greatest JDK, while
Enterprises want stability for deployments, here, we need to change the
mindset as the OpenJDK release cadence is not going to slow down.

The Java ecosystem is moving forward and Maven should not get stuck with a
10 years old JDK version.

There are many trade-offs from both sides, many complaints, and (sorry to
be harsh) many absurd arguments for being stuck until 2030 with Java 8.

I don't want to fall into the trap of "since I use it this way, I'm correct
and you don't ", so I will try to be as impartial as possible, I do agree
there is a need to support a Maven compatible with Java 8, I also do agree
that developers would like to use latest JDK features on Maven
core/plugins, so there needs to be a middle ground.

First, we need to distinguish the difference between the required Java
version used at RUNTIME vs the Java version used at BUILD TIME, anyone can
compile a Java project at build time using Java 21 and target Java 8, so
here the issue is not about using Java 9+ (11, 17, 21) to compile code that
will be used at runtime in Java 8, and if every project makes uses of the
--release option of java compiler, there will be no issues as we are simply
targeting to Java 8, it doesn't matter if you compile with Java 11/17/21
if, in the end, the produced bytecode is Java 8 compatible. What we are
talking about here is the Java version required at RUNTIME, meaning that if
we raise the Java version to something like Java 17, it will not work with
Java 11 or 8, with that point being clear, let's continue.

Before my proposal, a little disclaimer: I'm just an occasional
contributor, not a committer or Maven PMC, and while would be great to have
a full-time job to work on Maven, is currently not my case.

So, the proposal that could make everyone happy is this:

This proposal suggests the introduction of a *Long-Term Support (LTS)*
version of *Maven 3.10.x *targeting *Java 8* and *Maven 4.0* targeting*
Java 17.*

In other words, let's require Java 17 in Maven 4.0 at RUNTIME, and the same
day that Maven 4.0 is released, cut and release a version of Maven 3.10.0,
this version (3.10.x) will be marked as LTS, and "supported" for up to 3 or
5 years (depending on needs) with only security or critical bug fixes, this
means that any new feature won't be backported to the 3.10.x branch,
something like supporting a new JDK version (like Java 25) will be added to
Maven 4.

Why Java 17 and not Java 21? To be conservative and have a wider audience,
this should not be taken as a set-in-stone version, and if in 2 or 3 years
the Java ecosystem has moved fast enough, then a Maven version that targets
Java 21 or Java 25 should be possible in something like Maven 4.2 (or
whatever version is released to that date), and when the current 3.10.x
version "expires" in 3 or 5 years, mark a new LTS version rinse, and repeat.

*Advantages of Maven 3.10.x (Targeting Java 8):*

   1.

   *Stability and Compatibility:* Maven 3.10.x will provide stability and
   compatibility for projects still reliant on Java 8. Many enterprises and
   legacy projects continue to utilize Java 8 due to its stability and
   extensive support. By maintaining a Maven version specifically for Java 8,
   these projects can benefit from ongoing support without being forced to
   migrate to newer Java versions prematurely.
   2.

   *Extended Support Period:* As an LTS version, Maven 3.10.x will receive
   extended support and bug fixes, ensuring reliability for projects in
   production environments. This extended support period is crucial for
   enterprises with long-term projects that require stability and minimal
   disruption.
   3.

   *Security Patches:* Security vulnerabilities are a significant concern
   for software projects. With an LTS version like Maven 3.10.x, users can
   expect timely security patches to address any potential vulnerabilities,
   thus enhancing the overall security posture of their projects.
   4.

   *Maintaining Legacy Codebases:* Many organizations have substantial
   investments in legacy codebases built on Java 8. Maven 3.10.x enables these
   organizations to continue maintaining and evolving their existing projects
   without the need for an immediate migration to newer Java versions,
   reducing migration overheads and risks.

*Advantages of Maven 4.0 (Targeting Java 17):*

   1.

   *Compatibility with Latest Java Features:* Maven 4.0 targeting Java 17
   will empower developers to leverage the latest features and enhancements
   introduced in newer Java versions. This compatibility fosters innovation
   and enables developers to build modern, high-performance applications.
   2.

   *Performance

Re: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

[Jorge Solórzano]

I know that a build tool is different from a framework, but we are again
missing the point here, is not about framework vs build tools, the point is
that newer projects already require new Java versions, and if legacy
projects require using an old Java version, then those projects will still
be using Maven 3.x anyway and that is perfectly fine. What should be the
threshold to move to a newer Java version? (I'm talking about using Java 11
on Maven 4.0, not on 3.x).

Sorry I didn't want to hijack this thread for the Java version discussion,
yet I wish to know what is the benefit of "supporting" plugins on older
versions of Maven, I'm asking as a user since I'm not a Maven core
developer, PMC,r committer, just an occasional contributor, and again, I
might be missing something, but what is the benefit of updating plugins on
a project and using an older version of Maven? As a user is weird to me
that Maven versions prior 3.8.x are EOL, yet plugins provide Maven API
compatibility down to 3.2.5.

It seems that is indeed a new challenge to require Maven 3.6.3 as minimal
for core plugins ;)

Regards and Happy New Year!


On Sat, Dec 30, 2023 at 6:30 PM Michael Osipov  wrote:

> Am 2023-12-30 um 16:43 schrieb Jorge Solórzano:
> > I'm a bit confused here, why would anyone update Maven plugins in a
> project
> > and NOT update Maven Core? Older versions of Maven are EOL, is expected
> > that Maven Core is backward-compatible on minor releases so updating
> Maven
> > Core should be straightforward. I might be missing something but I don't
> > see a scenario where someone updates plugins but does not update Maven
> > itself, I would expect the opposite, it should be more common to update
> > Maven core than plugins (although that is just my perception).
> >
> > The question remains: Why should we use 3.5.4 instead of 3.6.3 as a
> minimum
> > in plugins? don't get me wrong, I don't mind if we use 3.5.4 instead of
> > 3.6.3 if the maintenance/support is the same, but knowing that CI uses
> > Maven 3.6.3 and newer, and without knowing why plugins should be
> supported
> > on 3.5.4, my vote will go to use 3.6.3.
> >
> > This discussion reminds me of the minimum required Java version, there
> was
> > even an informal poll
> > <https://twitter.com/khmarbaise/status/1549429653202518016> with more
> than
> > 80% asking for newer Java releases, and I would love to see Maven 4.0
> > require at least Java 11, but here we are, one year later and still on
> Java
> > 8 because some prefer to be working with Java 7 or even Java 6. The
> > ecosystem is moving forward, SpringBoot, Quarkus, Jakarta EE, and some
> > dependencies are slowly moving to at least Java 11, if a project requires
> > Java 8 (for whatever reason), then it will remain on Maven 3.x, moving to
> > Java 11 is conservative enough for Maven 4.0.
>
> You are confusing a low-level tool which should be accessible to
> everyone compared to a specific framework. Regarding Spring Boot: I
> consider that a total dick move dropping javax namespace support for a
> huge user base. Regardless of the Java version.
>
> M
>
>

Re: New year - new challenge - required Maven 3.6.3 as minimal for core Maven Plugins

[Jorge Solórzano]

I'm a bit confused here, why would anyone update Maven plugins in a project
and NOT update Maven Core? Older versions of Maven are EOL, is expected
that Maven Core is backward-compatible on minor releases so updating Maven
Core should be straightforward. I might be missing something but I don't
see a scenario where someone updates plugins but does not update Maven
itself, I would expect the opposite, it should be more common to update
Maven core than plugins (although that is just my perception).

The question remains: Why should we use 3.5.4 instead of 3.6.3 as a minimum
in plugins? don't get me wrong, I don't mind if we use 3.5.4 instead of
3.6.3 if the maintenance/support is the same, but knowing that CI uses
Maven 3.6.3 and newer, and without knowing why plugins should be supported
on 3.5.4, my vote will go to use 3.6.3.

This discussion reminds me of the minimum required Java version, there was
even an informal poll
 with more than
80% asking for newer Java releases, and I would love to see Maven 4.0
require at least Java 11, but here we are, one year later and still on Java
8 because some prefer to be working with Java 7 or even Java 6. The
ecosystem is moving forward, SpringBoot, Quarkus, Jakarta EE, and some
dependencies are slowly moving to at least Java 11, if a project requires
Java 8 (for whatever reason), then it will remain on Maven 3.x, moving to
Java 11 is conservative enough for Maven 4.0.

Regards.


On Sat, Dec 30, 2023 at 1:54 PM Michael Osipov  wrote:

> Am 2023-12-30 um 11:42 schrieb Slawomir Jaranowski:
> > sob., 30 gru 2023 o 10:43 Michael Osipov 
> napisał(a):
> >
> >> Am 2023-12-30 um 09:24 schrieb Slawomir Jaranowski:
> >>> pt., 29 gru 2023 o 18:40 Michael Osipov 
> >> napisał(a):
> >>>
>  Am 2023-12-29 um 14:42 schrieb Slawomir Jaranowski:
> > Hi,
> >
> > Last year we mark all Maven versions 3.6.x and older as EOL [1]
> >
> > But we still try to support minimal API version for Core Maven
> Plugins
> >> as
> > 3.2.5
> >
> > I would like to  propose to sich it for at least to 3.6.3
> >
> > Reasonable reasons: (for me)
> > - for standard CI build we use Maven 3.6.3 and newer
> > - many of external plugins, like MojoHaus are switched to 3.6.3
> > - we have a hacks in code to try support old version in plugin,
> like
> > in: EnhancedPluginDescriptorBuilder in plugin-tools [2], we can
> cleanup
> > such code
> > - I don't believe to someone want to do more fixes for EOL Maven
> >> version
>  in
> > plugins - so we should be a honest for users
> > - and we should go forward
> >
> > [1] https://maven.apache.org/docs/history.html
> > [2]
> >
> 
> >>
> https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-report-plugin/src/main/java/org/apache/maven/plugins/plugin/descriptor/EnhancedPluginDescriptorBuilder.java
> >
> 
>  I remember that we had a discussion that the next base/API version
>  should be 3.5.4 because it is the first version using
>  org.apache.maven.resolver:maven-resolver-api [1]. Please don't confuse
>  API compat with maintenance/support for a specific Maven version. I
>  believe that we have made this clear more than once.
> 
>  Is thre anything specific fixed in 3.6.3 behavior you consider crucial
>  which makes maintenance easier than with 3.5.4?
> 
> 
> >>> I remember the discussion ... and next year we are still on 3.2.5
> >>>
> >>> I can not a list what was exactly improved in 3.6.3 against to 3.5.4,
> >> but I
> >>> see in mentioned code
> >>>
> >>>// clear() is required for maven < 3.6.2
> >>>mojoDescriptor.getParameters().clear();
> >>
> >> This one is moot and incorrect. I will change the comment. The real
> >> improvement has been done by Tamás in 4.0.0-alpha-1:
> >>
> >>
> https://github.com/apache/maven/commit/cc51006f2973356a1046ae0757325d5e9be75327
> >>
> >>> So my question is:
> >>>
> >>> Why should we use 3.5.4 instead of 3.6.4 as minimum in plugins?
> >>
> >> If you can provide some real examples where 3.6.x is better/easier I
> >> will happily accept it.
> >>
> >>
> > There is https://github.com/apache/maven-help-plugin/pull/45
>
> I am aware of this one, but m-help-p isn't a core plugin, nor bound to a
> lifecycle phase. For me, this is out of the ordinary.
>
> Let's make a compromise: I'd expect that you provide a list of all
> plugins you consider core ones and this will be announced on dev@ that
> in X weeks we will switch. Before the switch if there are open releases
> they should be released and the switch will be done with a minor version
> bump.
> With that people can raise voice/prepare for the change.
>
> M
>

Re: [VOTE] Release Apache Maven Compiler Plugin version 3.12.1

[Jorge Solórzano]

+1

On Thu, Dec 21, 2023 at 8:54 AM Slawomir Jaranowski 
wrote:

> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317225&version=12354061
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MCOMPILER%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2051/
>
> https://repository.apache.org/content/repositories/maven-2051/org/apache/maven/plugins/maven-compiler-plugin/3.12.1/maven-compiler-plugin-3.12.1-source-release.zip
>
> Source release checksum(s):
> maven-compiler-plugin-3.12.1-source-release.zip - SHA-512 :
>
> 8aba1fcb580110119422b5e323d36af6179fcefc485d3354189cfecad987825ca168a61687d52c2a6561559d14387946f6f46606649cc3980cb67136d7dbc8eb
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-compiler-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Sławomir Jaranowski
>

Re: [VOTE] Release Apache Maven Compiler Plugin version 3.12.0

[Jorge Solórzano]

+1

On Fri, Dec 15, 2023 at 10:24 PM Sylwester Lachiewicz 
wrote:

> +1
>
> pt., 15 gru 2023, 22:15 użytkownik Tamás Cservenák 
> napisał:
>
> > +1
> >
> > On Fri, Dec 15, 2023, 22:04 Slawomir Jaranowski 
> > wrote:
> >
> > > Hi,
> > >
> > > We solved 22 issues:
> > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317225&version=12353748
> > >
> > > There are still a couple of issues left in JIRA:
> > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MCOMPILER%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-2049/
> > >
> > >
> >
> https://repository.apache.org/content/repositories/maven-2049/org/apache/maven/plugins/maven-compiler-plugin/3.12.0/maven-compiler-plugin-3.12.0-source-release.zip
> > >
> > > Source release checksum(s):
> > > maven-compiler-plugin-3.12.0-source-release.zip - SHA-512 :
> > >
> > >
> >
> 026e4affea10983e11c0b951ecc75b45deae32b9938d03f962174416f79c0bf75f31985e7add2e5312ae1d2c6a9b26f1f7bb54da7a214a0c3db275e0f41bf572
> > >
> > > Staging site:
> > >
> https://maven.apache.org/plugins-archives/maven-compiler-plugin-LATEST/
> > >
> > > Guide to testing staged releases:
> > >
> https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for at least 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>

Re: injecting an object for plugin configuration on Maven CLI

[Jorge Solórzano]

This should be a nice feature to have, this way a configuration of a
complex object could still be done using properties like:

-Dmaven.toolchain.toolchains.jdk.version="11"

Sisu should definitely add support to this.

Thinking out loud, it would be really nice if Maven supports something
like MicroProfile
Config  (eg.
smallrye-config ), which
would also allow more types of configuration like environment variables:
MAVEN_TOOLCHAIN_TOOLCHAINS_JDK_VERSION=17

Regards,

On Wed, Nov 29, 2023 at 8:48 AM Hervé Boutemy  wrote:

> thank you Konrad
> I feared that
> IIUC, I'll have to add a parameter for CLI use that will parse a specific
> format: I'll try and share, so we can evaluate options
>
> Regards,
>
> Hervé
>
> Le vendredi 17 novembre 2023, 10:55:55 CET Konrad Windszus a écrit :
> > Hi,
> > Only the value classes listed in
> >
> https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping
> > _Value_Objects support conversion from string. There is nothing built in
> for
> > complex classes containing multiple values of different types.
> >
> > Konrad
> >
> > > On 17. Nov 2023, at 08:51, Hervé Boutemy 
> wrote:
> > >
> > > my use case: I want sometimes to execute maven-toolchain-plugin or
> animal-
> > > sniffer-maven-plugin on CLI without updating pom.xml
> > >
> > > the only issue I'm facing is how to write the -D properties to
> populate a
> > > few fields from Objects required in plugin configuration:
> > >
> > > - signature groupId/artifactId/version for Animal Sniffer equivalent to
> > > pom.xml's configuration
> > >
> https://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/usage.
> > > html
> > >
> > > - even simpler for toolchain: just one toolchains.jdk.version value
> like
> > > https://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/
> > > jdk.html#sample-plugin-configuration
> > >
> > > Is there some Sisu magic for that, or do we need to add a specific
> extra-
> > > handling of this use case at goal level?
> > >
> > > 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: Changing Minimum Build Requirements for plugins to JDK11

[Jorge Solórzano]

+1 (non-binding)

Actually, it should not make any difference if one builds a plugin using
Java 11 or Java 17 (or even Java 21 with a warning) and targets Java 8
using the "--release 8" option (and that dependencies are compatible), so
just for using --release option is actually enough (even if the lift was to
Java 9) as it does not restrict the use of a newer JDK, and the --release
option ensures compatibility with previous versions API.

In any case, the ecosystem should start moving forward even if it is just
for lifting the build requirement, yet as many already mentioned there are
some caveats, as there is no big advantage for building with Java 11+ but
compiling to Java 8 (the features are limited to Java 8 anyway) beyond the
safety net and prevent the warning, it could potentially make the testing
with Java 8 harder (maybe not with toolchains?), but if the test matrix
will be Java 11, 17, 21 and latest-ea and crossing fingers that Java 8
works, it's also fine (I also compile with newer JDKs to older bytecode
without major issues), but it should be clear what will be the approach to
follow.

Now, what I would love to see, is the lift of the runtime requirement for
Maven 4.0 to at least Java 11, there has been a lot of discussion around
this without any consensus, but I think it is time, then have plugins
follow the lifting and compile to Java 11 too, leaving the 3.x branch
compatible with Java 8, but the 4.x branch with minimum Java 11, please
note that I'm not talking about breaking API compatibility, one plugin
build for Java 8 (and from the 3.x branch) should work without issues in
Maven 4.x running with Java 11+ as this is one of the goals of Maven 4.x,
and this change will be more meaningful than just lifting the build
requirement.

Based on the 2023 State of the Java Ecosystem[1] it should now be a good
bet to start using Java 11, and those who still need Java 8 compatibility,
can and will still be using the 3.x branch (even if it's unmaintained).

[1] https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem

On Mon, Nov 13, 2023 at 8:38 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> currently we have already the build requirements for Maven Core at JDK11+
>
> So in consequence I would suggest to lift the minimum requirement for
> building plugins to JDK11.
>
> That means also we can use "--release 8" option
> (8) instead of
> source/target which is not correct based on the warnings we get like:
> "[WARNING] bootstrap class path not set in conjunction with -source 8"
> which we get in all plugins based on the configuration in maven parent
> using this:
>
>  8
>  1.${javaVersion}
>  1.${javaVersion}
>
> which is not correct because we don't use animalsniffer anymore.
>
> So my suggestion is to lift the JDK build requirements to JDK11...
> and use the 8 which
> will prevent the warning. Also brings us back the safety net which
> animal-sniffer was before.
>
>
> Later on version of maven-parent (v42?) should change the whole
> configuration (there are some related parts like maven-pmd-plugin,
> maven-enforcer-plugin (enforce-byte-code max)..also toolchain-plugin...
>
> Furthermore we could get rid of the profile for JDK11+ related to
> spotless-maven-plugin ...
>
> Based on the upgrade to maven-parent v41 we could also enhance the build
> pipelines to build on JDK21
>
> WDYT?
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Apache Maven 4.0 with UTF-8 by default

[Jorge Solórzano]

Yes, please, that is the point, avoid to set the two properties.

On Thu, Mar 16, 2023, 21:04 Guillaume Nodet  wrote:

> If the point is to have the default encoding set to UTF-8, which I
> wholeheartedly agree with, could we go for a simple way, i.e. provide a
> default value for the two properties project.build.sourceEncoding and
> project.reporting.outputEncoding, instead of modifying the Model ?
>
> It's just we have not broken the POM 4.0.0 model so far and I've not heard
> any real plan for that.  Or what this would actually mean in terms of
> migration, etc...  My understanding is that the build/consumer pom could
> help, but not sure actually how...
>
> Le mer. 15 mars 2023 à 15:17, Jorge Solórzano  a écrit :
>
> > Hi Maven Devs,
> >
> > I want to bring up the discussion about the default encoding used in
> > Maven, specifically Maven 4.0+ (since it's still in alpha it could be
> > done for that release or possibly wait another decade), we are in
> > 2023, and we still get an encoding warning[1] that should be handled
> > manually by users, and I think there is general consensus that UTF-8
> > is the clear winner as the default encoding for the Java platform, the
> > JEP 400[2] is already delivered in Java 18, so the Maven project
> > should also revisit this default setting and change it from the
> > platform encoding to UTF-8 by default.
> >
> > Specifically, I'm talking about avoiding including
> > [3] and
> > [4] on every project, and possibly
> > if the POM Model Version 5.0.0[5] is included with Maven 4.x, and
> > default to UTF-8 [6].
> >
> > Doing a quick search in GitHub, there are a lot of projects that
> > explicitly set UTF-8 by default[7], probably more than any other
> > encoding, and projects that require a different encoding could still
> > set this property in the project.
> >
> > Regards,
> >
> > [1] https://maven.apache.org/general.html#encoding-warning
> > [2] https://openjdk.org/jeps/400
> > [3]
> >
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Element+for+Source+File+Encoding
> > [4]
> >
> https://cwiki.apache.org/confluence/display/MAVENOLD/Reporting+Encoding+Configuration
> > [5]
> >
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
> > [6] https://issues.apache.org/jira/browse/MNG-2216
> > [7]
> >
> https://github.com/search?l=Maven+POM&q=%22%3Cproject.build.sourceEncoding%3EUTF-8%3C%2Fproject.build.sourceEncoding%3E%22+language%3A%22Maven+POM%22&type=code
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> 
> Guillaume Nodet
>

[DISCUSS] Apache Maven 4.0 with UTF-8 by default

[Jorge Solórzano]

Hi Maven Devs,

I want to bring up the discussion about the default encoding used in
Maven, specifically Maven 4.0+ (since it's still in alpha it could be
done for that release or possibly wait another decade), we are in
2023, and we still get an encoding warning[1] that should be handled
manually by users, and I think there is general consensus that UTF-8
is the clear winner as the default encoding for the Java platform, the
JEP 400[2] is already  delivered in Java 18, so the Maven project
should also revisit this default setting and change it from the
platform encoding to UTF-8 by default.

Specifically, I'm talking about avoiding including
[3] and
[4] on every project, and possibly
if the POM Model Version 5.0.0[5] is included with Maven 4.x, and
default to UTF-8 [6].

Doing a quick search in GitHub, there are a lot of projects that
explicitly set UTF-8 by default[7], probably more than any other
encoding, and projects that require a different encoding could still
set this property in the project.

Regards,

[1] https://maven.apache.org/general.html#encoding-warning
[2] https://openjdk.org/jeps/400
[3] 
https://cwiki.apache.org/confluence/display/MAVEN/POM+Element+for+Source+File+Encoding
[4] 
https://cwiki.apache.org/confluence/display/MAVENOLD/Reporting+Encoding+Configuration
[5] https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
[6] https://issues.apache.org/jira/browse/MNG-2216
[7] 
https://github.com/search?l=Maven+POM&q=%22%3Cproject.build.sourceEncoding%3EUTF-8%3C%2Fproject.build.sourceEncoding%3E%22+language%3A%22Maven+POM%22&type=code

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

Re: [VOTE] Release maven-compiler-plugin 3.11.0

[Jorge Solórzano]

+1 (non binding)

I think that the 72H voting has passed way back, so this is mostly a
reminder for the actual release. ;)

Regards.

On Sat, Feb 18, 2023 at 7:56 AM Jean-Baptiste Onofré  wrote:
>
> +1 (non binding)
>
> Regards
> JB
>
> On Tue, Feb 14, 2023 at 9:51 AM Guillaume Nodet  wrote:
> >
> > Hi,
> > I'd like to release Apache Maven Compiler Plugin 3.11.0
> >
> > 7 issues fixed
> > https://issues.apache.org/jira/projects/MCOMPILER/versions/12351444
> >
> > draft github release notes (sadly only for people with write access as it's
> > a draft:() :
> > https://github.com/apache/maven-compiler-plugin/releases/tag/untagged-0ec6b3d056333c4a2ed0
> >
> >
> > staging repo https://repository.apache.org/content/repositories/maven-1873/
> > artifacts here
> > https://repository.apache.org/content/repositories/maven-1873/org/apache/maven/plugins/maven-compiler-plugin/3.11.0/
> >
> > staging site
> > https://maven.apache.org/plugins-archives/maven-compiler-plugin-LATEST/
> >
> > Vote open for 72H
> >
> >
> > --
> > 
> > Guillaume Nodet
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: GitHub release notes ...

[Jorge Solórzano]

Hi,

First, with every vote for a release, there is a link for the issues
fixed in Jira, but I have seen that some links to the Release Notes of
Jira, and others just link to the filter of "Fix version" in Jira, to
me the link should always be the Release Notes, not the filter of
issues.

A second point is that if Jira will be used, each Release Note has a
"Copy Release Notes" that can be simply copied over. For example, the
Release Notes for Maven 3.9.0 should be
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12350913&projectId=12316922
(not the link for the Fix version filter), and there is nothing to
"maintained" as Jira already generates the HTML in the "Copy Release
Notes" section that can be used to copy/paste on the GitHub release
notes, the only point is to include an additional step on the release
process that every project should follow and that once the release is
"done" this should be copied from Jira to GH, and that's it.

Now, a third point, with some bots like dependabot, they don't create
a Jira issue automatically, this might or might not be ok depending on
each use case (an updated dependency could break something that should
be noted in the release notes), so Jira issues fall short on tracking
this kind of commits unless someone handles manually the creation of
the Jira issue and that is annoying, here I don't see an easy solution
since using "GH Generate release notes" or something like "Release
Drafter" will differ with Jira Release Notes.

In any case, since Jira is the current source of truth, the only
reasonable thing to do is to simply use the "Copy Release Notes"
section and include it in every release process (assuming the release
process is documented somewhere).

Regards,

On Sun, Feb 12, 2023 at 4:15 PM Slawomir Jaranowski
 wrote:
>
> Hi,
>
> I know the subject is returning again ...
>
> When we once create GitHub release notes we should maintain it for each new
> release ...
> I agree the source of truth is our jira release notes.
>
> In other cases we have missing information about releases and users can be
> confused.
>
> Dependabot uses GitHub releases notes for next PR and we can lose some of
> the versions ... like in [1]
>
> For Maven 3.9.0 we also have no current release notes [2]
> probably for other components ...
>
> [1] https://github.com/mojohaus/mojo-parent/pull/342
> [2] https://github.com/apache/maven/releases
>
> --
> Sławomir Jaranowski

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

Re: Maven 3.9,0 plan

[Jorge Solórzano]

Hi, what about the issue (regression) with
https://issues.apache.org/jira/browse/MCOMPILER-481?

Regards,

On Mon, Jan 30, 2023 at 4:24 PM Tamás Cservenák  wrote:
>
> Howdy,
>
> FYI Maven 3.9.0 is good to go.
>
>
> T
>
> On Thu, Jan 26, 2023 at 10:46 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > 3.9.0 on hold for a bit more, an issue (and related PR) just popped in:
> > https://issues.apache.org/jira/browse/MNG-7672
> >
> > Thanks
> > T
> >
> > On Thu, Jan 26, 2023 at 7:49 PM Tamás Cservenák 
> > wrote:
> >
> >> Howdy
> >>
> >> Tomorrow is 27th :) Staging is part of release (release + vote + final
> >> promotion to Central), so hopefully tomorrow will be staged
> >>
> >> T
> >>
> >> On Thu, Jan 26, 2023, 19:28 Delany  wrote:
> >>
> >>> Hi Tamas,
> >>> Will you create a staging for 3.9.0?
> >>> I don't see anything at
> >>>
> >>> https://repository.apache.org/content/repositories/staging/org/apache/maven/maven/
> >>> Delany
> >>>
> >>> On Thu, 19 Jan 2023 at 11:03, Tamás Cservenák 
> >>> wrote:
> >>>
> >>> > Howdy,
> >>> >
> >>> > The 3.9.0 changelist:
> >>> >
> >>> >
> >>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.0
> >>> >
> >>> > It received today one more PR (
> >>> > https://issues.apache.org/jira/browse/MNG-7630), but the plan I'd
> >>> like to
> >>> > propose is following:
> >>> >
> >>> > - Keep the "3.9.0 window" open until the end of next week (27th Jan
> >>> 2023).
> >>> > - On 27th (or a bit after) do the 3.9.0 release
> >>> >
> >>> > So, please anyone able to, test 3.9.0-SNAPSHOT if you can.
> >>> >
> >>> > Aside of detailed changelog above, here is a high level list (to be
> >>> > reworked for site) here:
> >>> >
> >>> >
> >>> https://cwiki.apache.org/confluence/display/MAVEN/Notes+for+Maven+3.9.x+users
> >>> >
> >>> >
> >>> https://cwiki.apache.org/confluence/display/MAVEN/Notes+For+Maven+3.9.x+Plugin+Developers
> >>> >
> >>> > Have fun
> >>> > T
> >>> >
> >>>
> >>

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

Re: [VOTE] Release Apache Maven 4.0.0-alpha-3

[Jorge Solórzano]

It's the same error, I have updated the description in the issue of
flatten-maven-plugin with the full stack trace, I'm not sure if the
idea with Maven 4.0 is to have 100% compatibility with Maven 3, or if
some plugins need to be updated so I report it to the flatten project.

On Tue, Dec 13, 2022 at 12:12 PM Slawomir Jaranowski
 wrote:
>
> Delany
>
> Is your issue the same, as:
> https://github.com/mojohaus/flatten-maven-plugin/issues/330
>
> By the way, the issue should be reported on Maven jira.
>
>
> wt., 13 gru 2022 o 12:07 Guillaume Nodet  napisał(a):
>
> > Could you raise a JIRA issue and attach the full stack trace please ?
> >
> > Le mar. 13 déc. 2022 à 11:12, Delany  a écrit
> > :
> >
> > > Im still getting
> > > Execution flatten of goal
> > > org.codehaus.mojo:flatten-maven-plugin:1.3.0:flatten failed: Unable to
> > load
> > > the mojo 'flatten' (or one of its required components) from the plugin
> > > 'org.codehaus.mojo:flatten-maven-plugin:1.3.0':
> > > java.util.NoSuchElementException
> > >
> > > Do I still need the plugin though?
> > >
> > > Delany
> > >
> > > On Mon, 12 Dec 2022 at 15:19, Guillaume Nodet  wrote:
> > >
> > > > I've staged a release candidate at:
> > > >   https://repository.apache.org/content/repositories/maven-1835
> > > >
> > > > Source distributions:
> > > >
> > > >
> > >
> > https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-3/source/
> > > >
> > > > Binaries are available at:
> > > >
> > > >
> > > >
> > >
> > https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-3/binaries/
> > > >
> > > >
> > > >
> > >
> > https://repository.apache.org/content/repositories/maven-1835/org/apache/maven/apache-maven/4.0.0-alpha-3/
> > > >
> > > > Release notes:
> > > >
> > > >
> > > >
> > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12352443
> > > >   https://github.com/apache/maven/milestone/1?closed=1
> > > >
> > > > Github release:
> > > >   https://github.com/apache/maven/releases/tag/maven-4.0.0-alpha-3
> > > >
> > > > Please review and vote !
> > > >
> > > > --
> > > > 
> > > > Guillaume Nodet
> > > >
> > >
> >
> >
> > --
> > 
> > Guillaume Nodet
> >
>
>
> --
> Sławomir Jaranowski

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

Re: ASF Source Assembly now contains .gitignore and .gitattributes

[Jorge Solórzano]

> > On one hand, we all agree that .gitignore and .gitattributes (and so
> > on) are useful when building a project (prior to the final packaging).
>
> The primary purpose of those files are git commands.
> Having them evaluated by other tools is kind of unexpected (at least for 
> me)...

Well, giving it a second thought, I have to agree that the primary
purpose of those files are git commands, and it might not be a good
idea to depend on them to be able to build the project.

OTOH, if *source-release.zip files act as just the zip source
distribution of the repository (similar to doing the "Download ZIP"
from GitHub), then it makes sense that it includes those files, but it
also means that every other file should also be included (eg.
.cvsignore), but if the intention of the *source-release.zip files is
to have a "clean" distribution of the source distribution then yes I
agree that they should be filtered.

In the end, it might be a matter of preference and/or configuration,
Apache Calcite uses .gitattribute in the build, but many others might
not need them, so a configurable option make sense here.

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

Re: ASF Source Assembly now contains .gitignore and .gitattributes

[Jorge Solórzano]

Hi,

There might be some confusion here, at least I'm a little confused
with this thread.

On one hand, we all agree that .gitignore and .gitattributes (and so
on) are useful when building a project (prior to the final packaging).

On the other hand, once the project is built is useless to have a
.gitignore/.gitattribute, etc. on the final JAR package, this applies
to maven-jar-plugin, maven-source-plugin, maven-javadoc-plugin and so
on...

Since the source-release-assembly generates a buildable release
project, then it makes sense to include .gitignore/.gitattributes on
the *source-release.zip file.



On Fri, Sep 16, 2022 at 11:21 AM Slawomir Jaranowski
 wrote:
>
> Hi,
>
> Also apache-rat-plugin use .gitignore for skipping verification
>
> pt., 16 wrz 2022 o 11:14 Michael Osipov  napisał(a):
>
> > Am 2022-09-16 um 11:03 schrieb Vladimir Sitnikov:
> > >> “.gitignore” and “.gitattributes” files
> > >
> > > .gitignore and .gitattributes can easily be helpful during the build, so
> > it
> > > does sound strange to exclude them.
> > >
> > > For instance, Apache Calcite uses .gitattribute to configure that
> > specific
> > > files should have an "executable" bit in the resulting tar.gz archive:
> > >
> > https://github.com/apache/calcite/blob/e41555f568510df04d3883516b2195393a93426d/.gitattributes#L20-L21
> > > If one deletes the .gitattributes file, the resulting tar.gz will be
> > broken.
> > >
> > > It does sound strange to me to exclude .gitattributes and .gitignore on
> > the
> > > basis of "SCM specific metadata".
> >
> > This is something I need to crunch on. Thanks for raising...
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Sławomir Jaranowski

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

Re: [VOTE] Release Apache Maven JAR Plugin version 3.3.0

[Jorge Solórzano]

+1 (non-binding)

Thank you, Slawomir.

Regards,

On Mon, Sep 12, 2022 at 6:04 PM Slawomir Jaranowski
 wrote:
>
> Hi,
>
> We solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526&version=12351126
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MJAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1807/
> https://repository.apache.org/content/repositories/maven-1807/org/apache/maven/plugins/maven-jar-plugin/3.3.0/maven-jar-plugin-3.3.0-source-release.zip
>
> Source release checksum(s):
> maven-jar-plugin-3.3.0-source-release.zip - SHA-512 :
> 867aa9ac437b9d2fc9fed67373bdf66ab1992469563c896e1006ca032a0af3b9b055834b9b0d3b28de83ddc1bede8e42a654d5649e5dd2d5ac53b4bc55eeed31
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-jar-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> --
> Sławomir Jaranowski

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

Upcoming maven-jar-plugin 3.3.0?

[Jorge Solórzano]

Hi Maven Devs,

Is there an ETA for the release of maven-jar-plugin 3.3.0?

There are not many issues resolved [1], yet I'm interested in the fix
for MJAR-275 [2] so I'm wondering if there is a plan for a release or
if something is pending.

On a side note, there is a PR [3] fixing a site property that needs to
be merged before.

Cheers,

[1] 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317526&version=12351126
[2] https://issues.apache.org/jira/browse/MJAR-275
[3] https://github.com/apache/maven-jar-plugin/pull/51

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

Re: Mojo parameters of type java.nio.file.Path

[Jorge Solórzano]

Hi Konrad,

If I'm not wrong, Eclipse Sisu handles the conversion of parameters, so yes
right now only java.io.File type is supported.

Maven currently uses Sisu 0.3.5
,
and there
is a pre-release of Sisu (0.9.0.M1
)
that includes the PathTypeConverter
 (available in 0.9.0.M1),
yet this means that right now it's not possible to use java.nio.file.Path.

So yes, you are bound to using File parameters, yet it's pretty easy to
convert from/to Path using File.toPath()


On Fri, Jul 29, 2022 at 4:06 PM Konrad Windszus  wrote:
>
> Hi,
> According to
https://maven.apache.org/guides/plugin/guide-java-plugin-development.html#files-and-directories
only java.io.File type parameters are supported for dealing with file paths.
> I was assuming that every complex type is supported which has a
constructor taking a single String value which is used for
coercion/construction.
> That is true for
https://docs.oracle.com/javase/7/docs/api/java/io/File.html#File(java.lang.String)
but not for
https://docs.oracle.com/javase/7/docs/api/java/nio/file/Path.html. Is there
already a ticket for supporting NIO Path parameters?
>
> Which tool is used for doing the injection of parameters under the hood?
Is that also Eclipse Sisu?
> It would be really nice to extend
https://maven.apache.org/guides/mini/guide-configuring-plugins.html#Mapping_Complex_Objects
and
https://maven.apache.org/guides/mini/guide-configuring-plugins.html#mapping-simple-objects
a bit, as it does not really state how the object is actually instantiated.
Is it using the default constructor and field reflection only? If so, how
does it do type coercion as everything given in the pom.xml or on the CLI
is a String?
>
> Thanks in advance for giving some insights on this,
> Konrad
> -
> 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

[Jorge Solórzano]

The auto-detection of toolchains could be a nice feature, I'm not
familiar with Gradle, but I think Gradle has quite advanced toolchains
support that we could use as inspiration.
By default, Gradle automatically detects local JRE/JDK installations
so no further configuration is required by the user:
https://docs.gradle.org/current/userguide/toolchains.html#sec:auto_detection

There are some comments to make Maven download the JDK automatically,
and Gradle also has this support
(https://docs.gradle.org/current/userguide/toolchains.html#sec:provisioning),
but honestly, I think this is really a bad idea, Maven should not
handle the download of the JDK as there are too many JDK vendors and
many more could come in the future, it's not ideal to force users
(even if this feature is optional) to use a specific JDK vendor.

On Thu, Jul 28, 2022 at 8:20 AM Romain Manni-Bucau
 wrote:
>
> Le mer. 27 juil. 2022 à 23:37, Guillaume Nodet  a écrit :
>
> > In response to several comments about toolchains, I wonder if maven should
> > provide something a bit more user friendly for maven 4.
> > I'm thinking about:
> >   * extracting the toolchain out of the plugin config (optional) in
> > something that could be parsed easily so that mvnd (or the maven script)
> > could use the correct JDK directly,
> >   That would be limited to simple use cases (not those were compilation
> > and tests are run with different JDK)
> >   *  a command line tool similar to jenv tool which would be used to
> >  - set up the initial toolchains (maybe automatically if possible) by
> > scanning the system for JDK in known locations
> >  - list / add / remove / select toolchains
> >
>
> Where it can make the usage nicer, it keeps the installation*s* requirement
> and explicit setup on plugins so think it does not solve the overall user
> experience.
>
> However, being able to autoscan well known location (program files,
> .sdkman, ) to gind a matching jdk automatically if settings.xml
> contains a flag sounds neat and helpful for existing toolchain usages.
> Same for enabling mojo exec to set a java version to use different from the
> running java globally (like on an attribute which is not hard to read by a
> grep like solution)...but it means mojo executor is enabled to be forked
> and stays on java 8 (at least this module).
>
>
>
> > Le mar. 19 juil. 2022 à 18:25, Karl Heinz Marbaise  a
> > écrit :
> >
> > > Hi to all,
> > >
> > > what do you think about using JDK17 as minimum requirement for running
> > > the future Apache Maven 4.0.0 ?
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > >
> > > -
> > > 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

[Jorge Solórzano]

Yes, I agree with Romain (and also many others that have the same
concerns), expecting that the behavior of testing with one JDK that
targets a lower JDK will "just works" is naive.

There are differences at bytecode level, just compile a class with
JDK17 --release 11 and the same class with JDK11 --release 11 and then
compare with diffoscope to see them, this is one of the reasons that
you need to use the same major JDK version to get Reproducible Builds,
you can't expect a build to be reproducible even if you target to the
same release.

I don't expect the bytecode differences to be a real issue, yet
without proper testing (using the same runtime that you target) you
can't be sure.

The HttpClient is one example where you have things like this bug:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8245245, fixed
only in Java 16+, meaning that while it *works* on Java 17, it will
fail on Java 11.

We all agree that Toolchains is the way to go for this kind of thing,
but it's important to mention that Toolchains create some friction for
end users and a more involved setup.

And please don't get me wrong, I'm all for using JDK 17, but user
experience is also important.

On Wed, Jul 20, 2022 at 4:23 PM Romain Manni-Bucau
 wrote:
>
> Was more due to tests failling but there is no guarantee there is no
> difference in the bytecode on one side and the most important IMHO is the
> fact the run behavior can be different so at the end of the day you cant
> assume that because your build with java17 -release 8 worked that it will
> run on your prod.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le mer. 20 juil. 2022 à 16:16, Tomo Suzuki  a
> écrit :
>
> > Hi Romain,
> >
> > > the while loop was not exactly the same
> >
> > Did you observe the difference in the while loop bytecode cause an issue in
> > Java 8 users?
> >
> > Regards,
> > Tomo
> >

-
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

[Jorge Solórzano]

> >
> > Fair enough, they can remain just for backward compatibility, but even
> > if javac does not remove it, it doesn't mean that are useful having
> > --release, and there are probably more for backward compatibility than
> > anything else, again, this is just to drop legacy baggage.
>
> That's not legacy baggage because it's officially supported. So no legacy.
>
> To be honest I don't understand that. The JDK (javac) supports that so
> why should be remove such support for that in Maven?

The fact that JDK (javac) supports that, doesn't mean it's not legacy,
there are many
features, APIs, and so on that are still there just for backward compatibility.

I still haven't seen any single project that sets the source and the
target with different
versions and the source should always be lower than the target,
meaning that you still
need to compile up to the current JDK version. Just to give you an
example, you can compile a
class using javac --source 14 --target 17 (you need JDK 17), but you can't use
javac --source 17 --target 14 (you can't use new features that target
older versions),
if you are using --target 17, why would you don't use --source 17 in
the first place?

The JEP 247 (--release) was designed to link against the
implementation of the given
platform version as it was demonstrated that the --source and --target
were not enough
to avoid accidentally using APIs only available in the current version
of the platform.

If you compile with --source 8 and --target 8 using JDK 17, you could
potentially end up
using APIs that should not be supposed to be used for that version.
There are many examples out there like
https://issues.apache.org/jira/browse/LUCENE-7292
that shows this issue.

Just quoting Brian Goetz:
"The --release flag was added later, and in most cases, should replace
uses of --source and --target."
* https://stackoverflow.com/a/61715683/1990790

My point is that if Maven starts requiring JDK 17 (or even JDK 11),
that would mean that
if you want to compile to older platforms you will need to use:
a) Toolchains (which is not the most user-friendly feature)
b) or --release

The use of --source and --target is just error-prone to get
cross-compile issues and should be avoided.
The only single place that might make sense to keep them is when using
Toolchains *and* that the JDK
is version 8 or lower where --release is not included.

So, enough bikeshedding from me, I tried to explain it the best
possible way and I don't really
have any issue if the feature is there as I simply ignore it and use
only --release.

>
> Does that really matter? They build with Java 17 and produce code for
> JDK8 ... that's the point here..
>
> Some test are being executed on different JDK's if really needed.
>
> What kind of tests do you need to run on different JDK's to find which
> kind of issues? If you need such kind of tests I suppose you are using
> very special things... (If that's a good idea anyway) but of course that
> could happen and yes than you can use toolchains in Maven to handle such
> cases.
>

Don't get me wrong, I totally get the point that you can build with
JDK 17 and produce
code for JDK8, as I said, that's the easy part.

Yet when you are running tests, the normal thing to do is to test on
the JDK that you
are targeting even if you are compiling with a recent JDK, it's the
backward scenario
of using JDK8 to compile, but test with JDK 11, JDK 17, etc.
On CI (GitHub Actions, GitLab CI, etc) for instance, you trigger the
build and test with
different JDK versions (a build matrix), to ensure it works with newer JDKs.
If Maven starts to require JDK 17 as runtime, it means that you are
forced to use
Toolchains, and it's not a bad thing, but it creates more friction for users.

-
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

[Jorge Solórzano]

On Tue, Jul 19, 2022 at 7:52 PM Karl Heinz Marbaise  wrote:
>
> Hi,
>
> On 19.07.22 19:44, Jorge Solórzano wrote:
> > I really like the idea.
> >
> > This might also need to go in hand with plugins, the compiler
> > "release" argument is the way to go and this will require removing
> > completely the maven.compiler.source and maven.compiler.target.
>
> No they should not removed because the javac does not remove it either.
>
> For example it cases where you like to write your test with JDK 17 but
> your target will be JDK 8...it makes sometimes sense..
>

I might be missing something but that scenario could be handled by
setting maven.compiler.testRelease to JDK 17 and
maven.compiler.release to JDK 8.

Fair enough, they can remain just for backward compatibility, but even
if javac does not remove it, it doesn't mean that are useful having
--release, and there are probably more for backward compatibility than
anything else, again, this is just to drop legacy baggage.

> >
> > Compiling to an older release is the easy part, yet the only thing
> > that might be a pain is when you want to test with an older release,
> > toolchains might help but if that is not simplified then it will
> > create a lot of friction for users, even right now is not so easy to
> > build with one JDK and test with many, assuming you build for Java 8,
>
> If I would run my build with JDK 17 and --release 8.
>
> Why should I test with Java 8, 11 and 17 or more accurate what should I
> test?

Think of an app that targets Java 8, if you build with Java 17 (even
targeting Java 8), you might want to test (unit test, etc.) using the
Java 8 *runtime* to ensure that everything works as expected.

>
> > you might want to test with Java 8, Java 11, Java 17, and even Java
> > 19-ea, right now it's more a build and test with the same JDK, it's
> > not a big deal when you can build and test with older releases, but it
> > will be problematic when you build with a new release and test with an
> > old release.
>
> What should being tested here?
> For example JUnit Jupiter is doing that for a very long time.

Not sure what are you referring to, taking into account that JUnit
Jupiter is using Gradle.

>
>
>
> >
> > On Tue, Jul 19, 2022 at 6:25 PM Karl Heinz Marbaise  
> > wrote:
> >>
> >> Hi to all,
> >>
> >> what do you think about using JDK17 as minimum requirement for running
> >> the future Apache Maven 4.0.0 ?
> >>
> >> Kind regards
> >> Karl Heinz Marbaise
> >>
> >> -
> >> 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

[Jorge Solórzano]

I really like the idea.

This might also need to go in hand with plugins, the compiler
"release" argument is the way to go and this will require removing
completely the maven.compiler.source and maven.compiler.target.

Compiling to an older release is the easy part, yet the only thing
that might be a pain is when you want to test with an older release,
toolchains might help but if that is not simplified then it will
create a lot of friction for users, even right now is not so easy to
build with one JDK and test with many, assuming you build for Java 8,
you might want to test with Java 8, Java 11, Java 17, and even Java
19-ea, right now it's more a build and test with the same JDK, it's
not a big deal when you can build and test with older releases, but it
will be problematic when you build with a new release and test with an
old release.

On Tue, Jul 19, 2022 at 6:25 PM Karl Heinz Marbaise  wrote:
>
> Hi to all,
>
> what do you think about using JDK17 as minimum requirement for running
> the future Apache Maven 4.0.0 ?
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> 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: Upcoming parent poms release 27/37

[Jorge Solórzano]

Please also wait for maven-jar-plugin, maven-javadoc-plugin and
maven-source-plugin with the updated maven-archiver :)

On Sat, Jul 2, 2022, 11:53 Slawomir Jaranowski 
wrote:

> I've been waiting for assembly ;-)
>
> sob., 2 lip 2022 o 11:21 Tamás Cservenák  napisał(a):
>
> > +1 for assembly
> >
> > On Sat, Jul 2, 2022 at 11:20 AM Michael Osipov 
> > wrote:
> >
> > > Am 2022-07-02 um 11:18 schrieb Slawomir Jaranowski:
> > > > I will start releasing parent poms this weekend.
> > >
> > >
> > > Important: Please include new train of updated packaging plugins,
> > > especially Assembly.
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
> --
> Sławomir Jaranowski
>

Re: [VOTE] Release Apache Maven Wrapper version 3.1.1

[Jorge Solórzano]

+1

Tested on Linux with JDK17.

I think this also fixes MWRAPPER-44 and fixes the abandoned
MWRAPPER-21 Zip-slip issue, making a total of 16 issues fixes ;)


On Fri, May 13, 2022 at 9:29 AM Delany  wrote:
>
> +1
>
> JDK11 on *nix
>
> Delany
>
>
> On Fri, 13 May 2022 at 08:11, Herve Boutemy  wrote:
>
> > here is my +1
> >
> > Reproducible Build confirmed: reference done with JDK 8 on *nix
> >
> > I need more votes, please
> >
> > On 2022/05/08 09:28:32 Hervé BOUTEMY wrote:
> > > Hi,
> > >
> > > We solved 14 issues:
> > >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12350929&styleName=Text&projectId=12323721
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1750/
> > >
> > https://repository.apache.org/content/repositories/maven-1750/org/apache/maven/wrapper/maven-wrapper/3.1.1/maven-wrapper-3.1.1-source-release.zip
> > >
> > > Source release checksum(s):
> > > maven-wrapper-3.1.1-source-release.zip:
> > b110aef3a123c5f1ab77669c53baee3b1a71471ad672af4812d39ef302234f64789edd89f70f20c169eb5d4cc45fb4a94a24f64f98adbf863d0e5013a762aea0
> > >
> > > Staging site:
> > > https://maven.apache.org/wrapper-archives/wrapper-LATEST/
> > >
> > > Guide to testing staged releases:
> > > https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for at least 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >

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

Re: We need to lay down strategy

[Jorge Solórzano]

I fully agree, but all of this must be clearly defined on the web page.

Right now https://maven.apache.org/docs/history.html is not clear
about what is and what is not "maintained", and also many plugins
still "target" Maven 3.1.1 or 3.2.5, hopefully this proposal along
with the "Radical Fast Forward to 3.5.4"[1] will help to lay down the
strategy to use.

[1] 
https://cwiki.apache.org/confluence/display/MAVEN/Baseline+Upgrade+to+Maven+3.5.4


On Mon, Apr 11, 2022 at 12:02 PM Tamás Cservenák  wrote:
>
> Howdy,
>
> Personally, I'd NOT use the term "supported" at all, as it comes from the
> commercial realm (at least for me it sounds like it).
> We do not support anything :)
>
> I'd use the word "maintained" instead. So, according to that:
> maven 3.8.x is "maintained ONLY for critical regressions"
> maven 3.9.x is coming next out, but more about it later.
> maven 4.x is round the corner, and is our main focus (or will be very soon).
> Anything else of Maven Core is unmaintained.
> Regarding plugins, the very first response we usually do on ML is "did you
> try the latest version?".
>
> But regarding core, Maven major versions 2.x and 3.x were "backward
> compatible", the heck, MANY builds today still use plugins having
> MAJOR version 2.x, implying they use Maven 2 API:
> - m-install-p (2.5.2 released in 2014),
> - m-deploy-p (2.8.2 released in 2014)
> - m-surefire-p (2.22.2 released in 2019)
> etc
>
> The Maven 2.x -> 3.x transition -- as example shows -- was made with a
> major goal set to "ease the transition",
> and it worked: Maven core was radically changed (container, resolver, etc),
> but surrounding 2.x Mojos kept working as expected.
>
> OTOH, exactly this "smooth transition" caused a lot of technical issues and
> debt, that needs to be addressed,
> and will be addressed in Maven 4.x, but this time it will not tackle only
> things "behind the curtain", but may
> be a bit more jolty for plugins as well, hence for end users. Probably will
> require a new 4.x line of plugins as well
> (as we tried to introduce a 3.x line of plugins telling they are "aligned"
> with maven 3.x).
>
> The maven-3.9.x branch is technically at a similar level as maven-3.8.x,
> but the exact intent is to up its Java level
> to Java 8, to make it able to "keep up" with dependencies surrounding it
> and pick up the latest features from them,
> like new resolver is, etc. The Maven 3.9.x will be "just" a new Maven 3.x
> release with great and new (already done
> elsewhere) features, but no major Maven feature itself. Once maven-3.9.x is
> out, maven-3.8.x becomes "not maintained",
> and 3.9.x is "maintained for regressions".
>
> For new features, we should really focus on Maven 4.x.
>
> IMHO, just like (hopefully) you do with your OS and IDE, keep it up to
> date, I see no reason why someone would
> not do the same for their development environment as well. Keep it up to
> date. Especially now with the "new" Java
> LTS programme, where Java 8 is really OLDEST LTS for many years, but
> current LTS Java is 17, and the next LTS
> is behind the corner as well (2023?).
>
> I fully understand developers stuck on Java 5 or 7 or anything pre 8, but
> they should understand us as well:
> - we have no commercial licenses for those things
> - hence, we cannot test against them, even if we would have access to
> those, we are OSS project, we have no resources to do that
> Nb: same happened in SCM project: commercial SCM systems were dropped, we
> cannot maintain something we cannot test.
>
> So, if for some business reason you are forced to use any pre Java 8 for
> development, you have two options:
> - use the latest Maven and toolchains targeting old Java
> - use the same versions of tools that are from the era when that Java was
> latest. Accept that with non-evolved Java your Java toolbox cannot evolve
> either.
>
> My 5 cents
> T
>
>
> On Mon, Apr 11, 2022 at 11:25 AM Jorge Solórzano  wrote:
>
> > Honestly, the first thing to clarify is, what it means supported/EOL
> > in Maven terms?. There is a lot of confusion of what it's supported
> > since it's expected that newer versions of Maven should be
> > "backward-compatible" with previous versions of Maven.
> >
> > If I have a project that was "initially" designed for Maven 3.1.1
> > (meaning that the pom works perfectly fine with that version) and then
> > I simply upgrade Maven to 3.8.x, the project should "just works"? or
> > there is a need to update the pom.xml/plugins, etc too

Re: We need to lay down strategy

[Jorge Solórzano]

Honestly, the first thing to clarify is, what it means supported/EOL
in Maven terms?. There is a lot of confusion of what it's supported
since it's expected that newer versions of Maven should be
"backward-compatible" with previous versions of Maven.

If I have a project that was "initially" designed for Maven 3.1.1
(meaning that the pom works perfectly fine with that version) and then
I simply upgrade Maven to 3.8.x, the project should "just works"? or
there is a need to update the pom.xml/plugins, etc too?
And the reverse should be possible? if I have a project designed for
3.8.x, should it work with Maven 3.2.5? At least I know that 3.6.x and
3.8.x should be more or less "backward-compatible", but it's hard to
tell if others are.

Second, supported means that it still receives updates or patches, and
gets released every now and then, this is not true at all, the last
version of Maven 3.1.x was 3.1.1 released on 2013-10-04, the other
name for "supported" of older versions is in "maintenance", that might
receive critical fixes, yet again this might never happen. In the same
line, Maven 3.1.x requires Java 5 which is essentially dead since a
very long time ago, "supporting" Maven 3.1.x is pretty much nonsense.
(Here I'm talking about Maven core).

Even trying to "support" Maven 3.2.x (3.2.5 released on 2014-12-20) as
it requires Java 6 is impractical, as Java 6 was EOL 3 years ago (31
Dec 2018). In other words if a plugin "claims" to support Maven 3.1.1,
it should work with Java 5, in any other case it's just "partially"
compatible and having a table of compatibility is required as it's not
true that it "supports" Maven 3.1.1.

So, it's hard to define what it means "supported" and "EOL" here, does
it mean that "plugins" are supported? in other words, that if a new
plugin is released it should work with Maven 3.1.0? (even if it's hard
to test on that combination), the CI matrix should test plugins with a
combo of Java 6, Java 7, Java 8, Java 11 and Java 17, multiplied by
Maven 3.1.1, Maven 3.2.5, Maven 3.3.9, 3.5.4, 3.6.3, and 3.8.5, which
I seriously doubt it happen.

In the end, if my project was initially designed for Maven 3.1.1, I do
not expect that I (or many other users) will just update plugins
without also testing or updating to newer Maven versions too, so,
having plugins "supporting" such older versions of Maven is not
necessarily a good thing, it might make sense if the "supported"
definition is latest + 2 older versions (3.8.x, 3.6.3, 3.5.4), this if
we are speaking of plugins, as for Maven itself is still not clear to
me what it means "supported" as once a new versions is released
(3.8.x) the older one never get any update (3.6.x).

And yet again, we enter into a new conflict with this definition, if
Maven 3.9.x requires Java 8 and a lot of plugins are also moving to
Java 8, then it effectively means that "older" versions will not be
supported by plugins (in the combination of Java 6 and 7).

Welcome to the pandora box!

On Mon, Apr 11, 2022 at 11:08 AM  wrote:
>
> you're focusing on Maven core only
> I'm talking about Maven = core + plugins
>
> and on Maven core, 3.9 and master are for new features, 3.8 is a 
> stabilisation branch only (bugfixes) = the intent of initial message from 
> Tamas
>
> older releases are stable: yes, we don't expect fixes because they are 
> considered stable
>
> does stable mean EOL?
>
> no, because it would mean that we only support unstable versions of Maven core
>
> - Mail original -
> De: "Slawomir Jaranowski" 
> À: "Maven Developers List" 
> Envoyé: Dimanche 10 Avril 2022 21:20:33
> Objet: Re: We need to lay down strategy
>
> our CI has running build for branches:
>  - master
>  - 3.9.x
>  - 3.8.x
>
> It is only versions for which we can do changes, for others we simply don't
> have running infrastructure, so the rest of the versions should be
> officially mentioned as EOL.
>
> To be clear we also should add information what kind of change will be
> accepted for specific version, like: 3.8.x, 3.9.x only critical regression
> bugs as Tamás mentions
>
> niedz., 10 kwi 2022 o 19:59 Hervé BOUTEMY 
> napisał(a):
>
> > Le dimanche 10 avril 2022, 09:56:46 CEST Michael Osipov a écrit :
> > > Am 2022-04-10 um 09:10 schrieb Hervé BOUTEMY:
> > >
> > > >> I think that the truth is that versions less than 3.8.x are also EOL.
> > > >
> > > > no
> > > > please read the EOL message we took a lot of discussion to define for
> > > > Maven
> >  3.0.x:
> > > > "Maven 3.0 has now reached its end of life. New plugin releases will
> > > > require
> >  Maven 3.1 or later."
> > > >
> > > > yes, the definition of what "EOL" and "supported" mean for a project
> > like
> > > > ours
> >  is not so easy: finding the right message is not easy
> > >
> > >
> > > But I don't think that this is the full truth.
> > > What we actually do is to compile against a specific Maven version, but
> > > only test latest. I don't expect that everyone tests with 3.1.x, 3.2.x
> > > and so it -- I do

Re: [DISCUSS] Radical Fast Forward to 3.5.4

[Jorge Solórzano]

FYI, it looks like RHEL-based 7 uses maven 3.0.5, RHEL-based 8 uses
3.5.4 and 3.6.3.

My guess is that even if the new upgraded plugins depend on Maven
3.5.4 it wouldn't cause major issues as if anyone is using an olver
Maven version they will likely use older versions of the
plugins/components.

Anyway, as Hervé mentioned, there is a lack of better documentation of
the compatibility of plugins, and based on this page
https://maven.apache.org/developers/compatibility-plan.html since Jun
2020, plugins can have Java 8 prerequisite, and even for Maven 3.8.x
that means a breaking change.


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

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

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Jorge Solórzano]

Just to add my 2 cents:

Many security scanning tools are not smart enough to detect the context, or
in other words, they will mark as an issue a dependency that's only used
with "test" scope even if it's not used in the final jar, and in the same
line, there are some dependencies that can be optional and that might or
might not be present in the final classpath.

Anyway, I agree that since log4shell, for many of us, a (small) security
issue can cause panic, and with the actual events it gets more relevance,
and actually I think it's a good thing since we are now more aware of
security, but the issue is that we need to distinguish case by case if
there is a security issue or not, and not blindly follow the suggestion of
a scanning tool.

Nevertheless, the issue comes from the velocity dependency in this chain:

> [INFO] +- org.apache.maven.reporting:maven-reporting-impl:jar:3.1.0:compile
> [INFO] |  +-
> org.apache.maven.reporting:maven-reporting-api:jar:3.1.0:compile
> [INFO] |  +- org.apache.maven.doxia:doxia-sink-api:jar:1.11.1:compile
> [INFO] |  |  \- org.apache.maven.doxia:doxia-logging-api:jar:1.11.1:compile
> [INFO] |  +-
> org.apache.maven.doxia:doxia-decoration-model:jar:1.11.1:compile
> [INFO] |  +- org.apache.maven.doxia:doxia-core:jar:1.11.1:compile
> [INFO] |  |  +-
> org.codehaus.plexus:plexus-container-default:jar:2.1.0:compile
> [INFO] |  |  |  +- org.apache.xbean:xbean-reflect:jar:3.7:compile
> [INFO] |  |  |  \-
> com.google.collections:google-collections:jar:1.0:compile
> [INFO] |  |  +- org.apache.commons:commons-text:jar:1.3:compile
> [INFO] |  |  +- org.apache.httpcomponents:httpclient:jar:4.5.13:compile
> [INFO] |  |  |  \- commons-codec:commons-codec:jar:1.11:compile
> [INFO] |  |  \- org.apache.httpcomponents:httpcore:jar:4.4.14:compile
> [INFO] |  \- org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1:compile
> [INFO] | +- org.apache.maven.doxia:doxia-skin-model:jar:1.11.1:compile
> [INFO] | +-
> org.apache.maven.doxia:doxia-module-xhtml:jar:1.11.1:compile
> [INFO] | +-
> org.apache.maven.doxia:doxia-module-xhtml5:jar:1.11.1:compile
> [INFO] | +- org.codehaus.plexus:plexus-i18n:jar:1.0-beta-10:compile
> [INFO] | +- org.codehaus.plexus:plexus-velocity:jar:1.2:compile
> [INFO] | +- org.apache.velocity:velocity:jar:1.7:compile
> [INFO] | |  \- commons-lang:commons-lang:jar:2.4:compile
> [INFO] | \- org.apache.velocity:velocity-tools:jar:2.0:compile
> [INFO] |+- commons-digester:commons-digester:jar:1.8:compile
> [INFO] |+- commons-chain:commons-chain:jar:1.1:compile
> [INFO] |+- dom4j:dom4j:jar:1.1:compile
> [INFO] |\- oro:oro:jar:2.0.8:compile
>

The velocity version that the doxia-site-renderer dependency uses is
org.apache.velocity:velocity:jar:1.7:compile, and the velocity dependency
declares this:

> 
>   log4j
>   log4j
>   1.2.12
>   provided
> 
>

So, the root issue comes from the doxia-site-renderer that uses an old
(29-Nov-201) version of velocity.


On Fri, Mar 4, 2022 at 7:41 AM Ralph Goers 
wrote:

> This appears to be plugin dependencies though, not project dependencies.
> The
> issue should really be raised with whatever plugin is causing it to be
> used. My
> recollection is that Maven itself hasn’t used Log4j in quite some time for
> logging.
>
> Ralph
>
> > On Mar 3, 2022, at 8:21 AM, Gary Gregory  wrote:
> >
> > Also note that in log4j 2.17.2 that was released a few days ago, I added
> > many improvements to the log4j-1.2-api module which aims to provide
> > compatibility with 1.2.
> >
> > Gary
> >
> > On Thu, Mar 3, 2022, 08:37 Bernd Eckenfels 
> wrote:
> >
> >> All of the (known) remaining log4j1.x security bugs (none of which are
> as
> >> severe as log4shell) are fixed in reload4j 1.2.18+. If you need to stick
> >> with 1.2 you should use that. Otherwise you can try to migrate to the
> log4j
> >> bridge, it’s compatibility was increased in 2.17.2 or 2.12.4.
> >>
> >> Gruss
> >> Bernd
> >> --
> >> http://bernd.eckenfels.net
> >> 
> >> Von: Martin Gainty 
> >> Gesendet: Thursday, March 3, 2022 1:18:50 PM
> >> An: Maven Developers List 
> >> Cc: David Milet ; iss...@maven.apache.org <
> >> iss...@maven.apache.org>; VZ-Product-OneTalk <
> >> vz-product-onet...@verizon.com>; Danylo Volokh <
> >> danylo.vol...@globallogic.com>
> >> Betreff: RE: Maven Dependency Plugin - Log4j vulnerabilities
> >>
> >> I *thought* log4j 1.2.15 had the patch to mitigate the JNDI Security
> >> Vulnerabity?
> >> Is this not the case?
> >> Thanks John
> >> M.
> >>
> >>
> >>
> >> Sent from my Verizon, Samsung Galaxy smartphone
> >>
> >>
> >>
> >>  Original message 
> >> From: John Patrick 
> >> Date: 3/3/22 4:07 AM (GMT-05:00)
> >> To: Maven Developers List 
> >> Cc: David Milet , iss...@maven.apache.org,
> >> VZ-Product-OneTalk , Danylo Volokh <
> >> danylo.vol...@globallogic.com>
> >> Subject: Re: Maven Dependency Plugin - Log4j vulnerabilities
> >>
>