[RESULT][VOTE] Require Java 17 for Maven 4

[Benjamin Marwell]

Hi all,

the vote has passed with the following result:

PMC +1: Anders Hammar, Arnaud Héritier, Benjamin Marwell, Guillaume
Nodet, Hervé Boutemy, Karl Heinz Marbaise, Konrad Windszus, ,Maarten
Mulders, Olivier Lamy, Romain Manni-Bucau, Sylwester Lachiewicz, Tamás
Cservenák

PMC majority quorum: reached.

Community results:

+1: A.J. Jarmoniuk, Bernd Eckenfels, Brian Demers, Ceki Gulcu,
Christian Stein, Christoph Läubrich, David Jencks, Dirk Olmes, Enrico
Olivelli, Frederik Boster, Gary Gregory, Giacomo Boccardo, Jacques
Etienne Beaudet, Jean-Baptiste Onofré, Jeremy Landis, Jesper Udby,
John Neffenger, Jorge Solórzano, Joseph Kesselman, Kemal Soysal, Kévin
Buntrock, Lasse Lindqvist, Manfred Moser, Mantas Gridinas, Manuel
Dahmen, Mark Eggers, Martin Desruisseaux, Mateusz Gajewski, Matthias
Bünger, Michael Bien, Niels Basjes, Robert Dean, Rodrigo Bourbon,
Slawomir Jaranowski, Stephane Nicoll, Thomas Matthijs, Thorsten Heit,
Tim te Beek, Van Hoa Phan, Xeno Amess, Yeikel Santana, zhongming hua

-1: Elliotte Rusty Harold

We will proceed with the transition of Maven 4 to a Java 17 baseline.
Plugins will also get a "plugin history" page where it will be
documented which version requires which Java version. As a general
rule, we will keep 3.x plugins on Java 8 (notable exception is the
m-jlink-p for obvious reasons).

Thanks everyone for voting and all your voices in the preceding discussions!

- Ben

-
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

[Benjamin Marwell]

Elliotte,

as per guidelines, it is not required. And I did not put it that way in my
email.
However, a reason would have helped in finding alternatives.

Anyway, here's my +1.



On Fri, 1 Mar 2024, 19:14 Elliotte Rusty Harold,  wrote:

> On Wed, Feb 28, 2024 at 2:31 AM Benjamin Marwell 
> wrote:
>
> > 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.
>
> -1
>
> Requiring reasons for downvotes but not upvotes puts a finger on the
> scale. :-)
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Java version for Maven

[Benjamin Marwell]

At this point, we have discussed many aspects.
Please feel to vote:

User List:
https://lists.apache.org/thread/ty321ns72qc6l26bjy58d9430ofg2w5t

Dev List:
https://lists.apache.org/thread/vngchrr3owd92v9y09lyfjjhwkl5hvtn

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

[VOTE] Require Java 17 for Maven 4

[Benjamin Marwell]

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

[Benjamin Marwell]

> Compiling for Java 8 with
> Java 17 -release 8 is not the same as compiling with javac from JDK 8.
> They do not produce the same byte code. There is a need to compile
> *with* JDK 8, not just compile *for* JDK 8.

And when would that be needed?


On Tue, 27 Feb 2024, 13:33 Elliotte Rusty Harold, 
wrote:

> On Mon, Feb 26, 2024 at 7:24 PM Benjamin Marwell 
> wrote:
> >
> > > 1. The Java version required by the project being built. That is, the
> > byte code and API level of the project.
> > > 2. The Java version used to compile the project.
> > > 3. The Java version used to run Maven.
> > > 4. The Java version used to compile and build Maven itself.
> >
> > > For #1, it is mandatory to support Java 8.
> >
> > You can compile Java 8 bytecode with a Java 8 JDK from a Maven running
> > Java 17+ using toolchains
> > or with the -release flag from any version 9+.
> >
> > > For #2, reproducible builds mean we have to be able to support what
> > > customers are using and that can be anything from Java 8 - 21. It is
> > > not sufficient to say Java 21 can compile to Java 8 since that does
> > > not produce the same byte code as compiling with Java 8.
> >
> > That is the point.
> > If you built the project with JDK 21 using the -release=8, you can get
> > the same (reproducible) output with a similar OS and JDK 21.
> >
>
> No, that's not the point. You are claiming that #1 and #2 are the
> same. I do not believe they are the same. Compiling for Java 8 with
> Java 17 -release 8 is not the same as compiling with javac from JDK 8.
> They do not produce the same byte code. There is a need to compile
> *with* JDK 8, not just compile *for* JDK 8.
>
> Toolchains support using JDK 8 to compile even though JDK 17 is
> executing Maven, which does handle this. Unfortunately toolchains are
> poorly designed, badly documented, and not widely understood within
> the community. I'm trying to improve some of the docs for toolchains,
> but that only goes so far. There's a fundamental problem that
> toolchains are incompatible with a hermetic, one click build.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Java version for Maven

[Benjamin Marwell]

> 1. The Java version required by the project being built. That is, the
byte code and API level of the project.
> 2. The Java version used to compile the project.
> 3. The Java version used to run Maven.
> 4. The Java version used to compile and build Maven itself.

> For #1, it is mandatory to support Java 8.

You can compile Java 8 bytecode with a Java 8 JDK from a Maven running
Java 17+ using toolchains
or with the -release flag from any version 9+.

> For #2, reproducible builds mean we have to be able to support what
> customers are using and that can be anything from Java 8 - 21. It is
> not sufficient to say Java 21 can compile to Java 8 since that does
> not produce the same byte code as compiling with Java 8.

That is the point.
If you built the project with JDK 21 using the -release=8, you can get
the same (reproducible) output with a similar OS and JDK 21.

> For #3, any reasonable Java version starts to be acceptable, though
> going past Java 8 makes life inconvenient for Java developers who
> routinely work with older JDKs. This version must be compatible with
> #2.

Where did you get that from?
Even before I switched my projects to 11/17, I required 11+ for
building (b/c of -release=8).
The only inconvenience I see here is installing Java 8,
and all the workarounds needed because Java 8 is the odd man out:
* javadoc linter not as strict as the others
* no release flag

I find projects requiring JDK 8 for builds very inconvenient.

What does *compatible* mean anyway? -release, good enough.
Or just use toolchains

> If JDK
> 17 being used for the Maven codebase, means the user can't compile
> their project with JDK 8

We already said this a few times.
Toolchains.
Release Flag.
Staying on 3.9.x.

- Ben

Am So., 25. Feb. 2024 um 14:50 Uhr schrieb Elliotte Rusty Harold
:
>
> I don't think that quite works. There are *four* Java versions in
> play. In decreasing order of importance, they are:
>
> 1. The Java version required by the project being built. That is, the
> byte code and API level of the project.
> 2. The Java version used to compile the project.
> 3. The Java version used to run Maven.
> 4. The Java version used to compile and build Maven itself.
>
>
> For #1, it is mandatory to support Java 8. There's just too much Java
> 8 still in use today. E.g. Presto, most of Google Cloud Platform, and
> and many, many others
>
> For #2, reproducible builds mean we have to be able to support what
> customers are using and that can be anything from Java 8 - 21. It is
> not sufficient to say Java 21 can compile to Java 8 since that does
> not produce the same byte code as compiling with Java 8.
>
> For #3, any reasonable Java version starts to be acceptable, though
> going past Java 8 makes life inconvenient for Java developers who
> routinely work with older JDKs. This version must be compatible with
> #2. If the JDK used to compile is the same as the JDK used to run
> Maven, then this shouldn't go past Java 8. Toolchains somewhat solve
> this problem. However configuring toolchains requires an extra plugin,
> changes to the pom.xml, and is one more thing for developers to learn
> and be confused by. Perhaps most problematically toolchains can't be
> fully configured in the pom.xml of the project but require setting up
> a completely separate file that needs to be customized per developer
> machine. It is a much better developer experience if Maven "just
> works" with whatever JDK and compiler the user has installed and is
> compiling with. If the JDK is bundled with Maven as some have
> suggested, then that ceases to be an issue as long as it still uses
> JAVA_HOME to compile with.
>
> For #4, sure, whatever. Any version will work as long as it doesn't
> impose constraints on #1, #2, or #3. The trick is to avoid the later
> requirements from forcing upgrades on the earlier requirements. If JDK
> 17 being used for the Maven codebase, means the user can't compile
> their project with JDK 8, then I think Maven should stick with the
> older JDK version too. Again, toolchains help here, but they're
> inconvenient and extra work.
>
> On Sat, Feb 24, 2024 at 10:43 PM 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 

Re: [DISCUSS] Java version for Maven

[Benjamin Marwell]

Brian, any Chance you could make a stacked 100% graph for every *week*
of the past two years?
We could then see where we are heading…
(or the raw numbers per week, so we could work with that).

That's probably a lot to ask, but I think it will show us how "fast"
the progression was (and will be).

@Tamas please consider the support times are different by vendor.
I have seen Java 8 support well beyond 2030 *shudder*.

Seeing all those numbers, I now feel a lot more confident that Maven 4
should be 17 (runtime), 21 (build)
and Java 8 users should stay with 3.x.x.
Elliotte gave a good reason for this: There are two camps now (read: ALREADY).
There is no reason to not go with either of them.

Am Do., 22. Feb. 2024 um 19:56 Uhr schrieb Brian Fox :
>
> We dumped 30 days because that gives a good snapshot of what's happening
> right now. If we dumped for example the whole year, then it really blurs
> the lines all over the place and things newer will be less prominent just
> because they didn't have as much time. 30 days is how we typically bucket
> things when we want a form of relative popularity.
>
> As far as toy projects skewing, Tamas is right, the scale of central data
> is so large that it's insignificant. Also remember we only counted each IP
> once per entry so even projects downloading over and over won't skew the
> results.

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

Re: [DISCUSS] Java version for Maven

[Benjamin Marwell]

FWIW, bazel changed its runtime requirement to Java 21.
But they are shipping their own Java Runtime, so their users won't notice. [1]

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

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

- Ben

Am Di., 20. Feb. 2024 um 21:50 Uhr schrieb Tamás Cservenák
:
>
> Howdy,
>
> I intentionally used "Maven" here, and not "Maven 4" as I am sure the
> majority of Maven users do not run Maven on the same Java version they
> target with their build. We do not do that either.
>
> Some snippets from Herve (who is the ONLY one doing reproducible checks,
> kudos for that) votes:
>
> Sun, Feb 18, 2024, 9:38 AM
> [VOTE] Release Apache Maven Shade Plugin version 3.5.2
> Reproducible Build ok: reference build done with JDK 11 on *nix
>
> Wed, Jan 31, 2024, 5:06 AM
> [VOTE] Release Apache Maven JLink Plugin version 3.2.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
>
> Mon, Jan 8, 2024, 8:29 AM
> [VOTE] Release Maven Plugin Tools version 3.11.0
> Reproducible Builds ok: reference build done with JDK 8 on Windows with
> umask
>
> Mon, Dec 18, 2023, 8:59 AM
> [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
>
> Mon, Dec 18, 2023, 8:59 AM
> [VOTE] Release Apache Maven Compiler Plugin version 3.12.0
> Reproducible Builds ok: reference build done on *nix with JDK 21 and umask
> 022
>
> Wed, Nov 29, 2023, 8:16 AM
> [VOTE] Apache Maven Build Cache Extension 1.1.0
> Reproducible Build ok: reference build done on *nix with JDK 11
>
> Sun, Nov 19, 2023, 5:17 PM
> [VOTE] Release Maven Resolver 1.9.17
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
>
> Sat, Oct 21, 2023, 4:34 PM
> VOTE] Apache Maven 4.0.0-alpha-8 release
> Reproducible Build ok: reference build done with JDK 21 on *nix with umask
> 022
>
> Mon, Oct 2, 2023, 9:11 AM
> [VOTE] Release Apache Maven 3.9.5
> Reproducible not fully ok: reference build done with JDK 17 on *nix and
> umask 022
>
> 
>
> This CLEARLY shows the tendency:
> - Michael does releases on Java 8 (on windows!), he is a known "aligner"
> and windows person :)
> - Olivier used the "minimum" required Java version (for build cache).
> - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could
> use 21 but also 8, but he shot for 11 that was EOL at the moment of release.
> - The rest is 21.
>
> 
>
> So, the question for those refusing anything other than Java 8 to _run_
> Maven (or to revert: for those refusing to run Maven on "latest LTS", that
> is currently 21):
> WHY?
>
>
> Thanks
> T

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

Re: [VOTE] Release Apache Maven Shade Plugin version 3.5.2

[Benjamin Marwell]

+1 for the release as it is

+100 with the way Tamás put it.

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

Re: Use of jspecify in Maven

[Benjamin Marwell]

OK, let's wait for the JEP to arrive then.

> Such a dependency would only be useful if compilers.
> IDEs, and incremental compilers within IDEs (like in Eclipse) would
> know about them to report warnings.

Luckily, at least the IDEs do. For maven builds, you'd need sth like
the checker framework
or Google ErrorProne. But not worth it for existing projects.

> I'm sure they'd want to do so through a JEP API

Yes, JSpecify tries to be what Joda was for java.time.
At the moment, IntelliJ will just use any @Nullable annotation,
and Eclipse can be configured (just add any fqcn).

I hope we get a little bit better parameter documentation, though.

Am Di., 13. Feb. 2024 um 04:11 Uhr schrieb Gary Gregory
:
>
> On Mon, Feb 12, 2024 at 6:33 AM Matthias Bünger
>  wrote:
> >
> > (I'm neither a Maven core or plugin maintainer)
> >
> > I don't like such annotations as in my opinion, they save you nothing,
> > but bring an addional dependency and problems with the tools that
> > (don't) support (only a specific version of) them.
>
> I agree 100%. Such a dependency would only be useful if compilers.
> IDEs, and incremental compilers within IDEs (like in Eclipse) would
> know about them to report warnings. If they wanted to do that, then
> I'm sure they'd want to do so through a JEP API, not
> yet-another-attempt-at-null-annotations.
>
> An example of why this is a bad idea is depending on
> com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar's @Nonnull,
> which, in the current version Eclipse at least shows up as an illegal
> annotation when you use it, defeating the purpose: "Annotation types
> that do not specify explicit target element types cannot be applied
> here Objects.java
> /commons-lang3/src/test/java/org/apache/commons/lang3/function line 74
> Java Problem"
>
> Gary
>
> >
> > If my method needs arguments that are not null than I have to check them
> > and throw an exception if the caller of the method tries to pass NULL
> > into it. If I'm too lazy to check my parameters than I deserve it to get
> > NPE e.g. (funny enough an external coder with 20+ years of experience at
> > my work just experience that exactly now, as he just relies that
> > everything is always there...).
> >
> > Am 11.02.2024 um 22:27 schrieb Benjamin Marwell:
> > > Hello devs and plugin maintainers!
> > >
> > > Since JSR 305 (Nullable annotations etc.) did not get implemented
> > > officially, and Maven allows `null` in a lot of locations, I wanted to
> > > ask about your opinions about using jspecify: https://jspecify.dev/
> > >
> > > JSpecify was created by the Java community (i.e. Java decs but also
> > > larger corporations like Google, if I am not mistaken. It was seen as
> > > needed since JSR 305 never materialized and probably never will.
> > > Google hat a Guava Situation [1] and decided to do something about it.
> > >
> > > JSpecify says it is safe to adopt it [2]. Although the current version
> > > is 0.3, it is more like 0.9.
> > >
> > > I honestly think that Maven would benefit from those annotations, as
> > > many recent libraries try to avoid `null` as best as they can. Younger
> > > developers may not be used to seeing nullable parameters, and even
> > > some of us don't know which parameters can be nulled (or not).
> > >
> > > Let me know what you think about this idea.
> > >
> > > My personal opinion: I am pretty confident jspecify will displace
> > > checker-qual as the "top dog" of nullness annotations in the future. I
> > > also want to give plugin authors a way to use null in their plugins,
> > > too, although we could make it an optional dependency (just
> > > annotations...).
> > >
> > > Looking forward to reading your opinions!
> > >
> > > - Ben
> > >
> > > 1: https://github.com/google/guava/issues/2960
> > > 2: https://github.com/jspecify/jspecify/wiki/adoption
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: Java version for Maven 4?

[Benjamin Marwell]

> we need to think about companies
that pay for old JDK support

There was a suggestion on slack that companies could provide "dev and
release manager" for Maven 3 and manage the JDK 8 Maven 3 until they lose
interest. This already works well for other projects.

Even if no one stands up for volunteering: Maven 3 will continue to work
just fine, even after releases of Maven 4.


About the companies who run their own JDK team:
Well, they made that a conscious decision. They surely had planned for
versions after Java 8. If not, I don't see why we should take their problem
and make it ours.

- Ben


On Mon, 5 Feb 2024, 23:15 Gary Gregory,  wrote:

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

Re: Java version for Maven 4?

[Benjamin Marwell]

> I get the impression that folks who haven't worked in such large
> mono-repos aren't aware of just how big a multi-year effort it is to
> move a repo like that onto a new JDK version. And that's just the VM,
> even before you allow devs to change the language level and start
> using the new features and libraries. That's just the two really big
> mono-repos I have personally worked in. I'm willing to bet that some
> other big Java shops are in similar positions.

Sorry that I made the wrong impression. I know this is a big effort
from personal work experience.
But it can be done. It must be done. I asked the CI team to run all CI
builds with a parallel JDK 11 build,
and they did that. This way, it was easy to see which project was not
buildable using Java 11,
so teams could work on that.

For the apps I work on, my team uses all LTS versions plus the latest
GA version (if not an LTS release).
By the way, this was an excellent recommendation by a former IBM employee.

... and that was all done without raising the language level.

Besides that, most big (tech) companies do not allow unmaintained or
unsupported software.
I am puzzled how this could work out with the state of the libraries
you mentioned.
There must be other violations in the first place, and someone allowed
them to happen.
If they hadn't been allowed to happen, there would have been no need
to catch management attention.

> Switching back and forth between JDKs for open source development is
> doable but an unnecessary hassle.

I am puzzled why this would be needed. All Java 8 apps I know were
easy to build on Java 11 (with release=8)
after only very few adjustments.

That said, I do not think Apache Maven should wait for two companies
with mono-repos to update their technical debt.
It is just not justifiable for all the other users.

I agree with Gary that an EOL schedule might be our best shot here.

Am Mo., 5. Feb. 2024 um 19:56 Uhr schrieb Elliotte Rusty Harold
:
>
> On Mon, Feb 5, 2024 at 12:01 PM Benjamin Marwell  wrote:
>
> > Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
> > no advantage of going to 11:
> >
>
> The advantage of going with 11 instead of 17 is that at least 2 really
> big tech companies I could name (and who you can probably guess from
> my linked in) have only recently completed their own migration to Java
> 11. At least one of those two companies might still employ a PMC
> member (though I haven't checked post-layoffs), maybe more than one.
> Both have actively supported Maven development over the years, though
> that support ebbs and flows depending on corporate priorities.
>
> I get the impression that folks who haven't worked in such large
> mono-repos aren't aware of just how big a multi-year effort it is to
> move a repo like that onto a new JDK version. And that's just the VM,
> even before you allow devs to change the language level and start
> using the new features and libraries. That's just the two really big
> mono-repos I have personally worked in. I'm willing to bet that some
> other big Java shops are in similar positions.
>
> Switching back and forth between JDKs for open source development is
> doable but an unnecessary hassle. I've done it before, but even
> switching from JDK 8 to 11 is an extra paper cut. It kills time every
> time spotless fails simply because I'm using Java 8 instead of 11.
>
> Most importantly, it will be even harder to sell management on the
> benefit of spending developer time on Maven 4 development, if it isn't
> suitable for that company's own open source projects which, last I
> checked, were still on Java 8. (OK, I just spot checked and the first
> one I looked at is in fact still compiling for Java *1.7*, probably
> because that's where their customers are).
>
> I'm thinking back to the projects I had to justify to management a few
> years and one company back, and it definitely would have been harder
> then if I had to tell them what we were contributing would only work
> on Java 11 or later. Maybe today I could sell them on Java 11 (or
> maybe not, if they aren't paying attention to Maven at all any more)
> but Java 17 would be a non-starter. They might prefer to spend their
> resources on a build tool they own, or maybe just not spend the dev
> hours at all.
>
> tldr: every uptick in version requirements bleeds that many more
> contributors out of the pool.
>
> --
> 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: Java version for Maven 4?

[Benjamin Marwell]

Those who need Java 8 to *run* Maven will probably not upgrade to
Maven 4 anyway, as their builds will have other problems preventing
them from upgrading.
A few third-party plugins already moved to Java 11+, thinking of spotless.

That said:

+1 Stick with 8 for Maven 3.9.x and maybe a 3.10.x (not part of this thread)
+1 to use Java 17 for Maven 4.

Why 17? 11 is often earlier EOL'd than 8 and 17, so I see absolutely
no advantage of going to 11:

* https://endoflife.date/ibm-semeru-runtime
* https://endoflife.date/azul-zulu
* https://endoflife.date/bellsoft-liberica
* https://endoflife.date/eclipse-temurin (on par here)
* https://endoflife.date/oracle-jdk (valid for premier support, not
for extended support)

Am So., 4. Feb. 2024 um 15:01 Uhr schrieb Elliotte Rusty Harold
:
>
> If we're actually voting
>
> +1 for Java 8
> -1 for Java 17 or any later version.
>
> I can live with Java 11 if I have to, though I really don't see the
> point. Anything past Java 11 ranges from a major hassle to blocker for
> corporate developers, including those at big tech companies like Meta
> and Google, who are stuck on older versions as a matter of policy and
> internal support.
>
> On Sat, Feb 3, 2024 at 2:17 PM Martin Desruisseaux
>  wrote:
> >
> > Hello
> >
> >  From the replies in this thread, it seems to me that there is a
> > consensus for moving Maven 4 to some Java version after 8. I see:
> >
> >   * 0 in favour of Java 11
> >   * 1.5 in favour of Java 17 (the .5 is because I split a vote between
> > Java 17 and 21)
> >   * 2.5 in favour of Java 21
> >   * 4 seem neutral (including myself)
> >
> > Do we take that as an agreement to require Java 21 for building Maven 4?
> >
> > On a related question, what should be the minimal Java version for
> > *running* Maven 4? Keeping in mind that if Java 21 (for example) was
> > required, users would still be able to compile for an older Java version
> > using the --release option.
> >
> >  Martin
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

[ANN] Apache Maven JLink Plugin 3.2.0 Released

[Benjamin Marwell]

The Apache Maven team is pleased to announce the release of the Apache
Maven JLink Plugin, version 3.2.0

The JLink Plugin is intended to create modular Java Run-Time Images via jlink.

https://maven.apache.org/plugins/maven-jlink-plugin/

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


  org.apache.maven.plugins
  maven-jlink-plugin
  3.2.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-jlink-plugin/download.cgi

Release Notes - Maven JLink Plugin - Version 3.2.0

Bug

[MJLINK-62] - Replace ByteArrayOutputStream with StringWriter
[MJLINK-64] - Add-options double quoting

New Feature

[MJLINK-75] - Reproducibility of ZIP artifacts

Improvement

[MJLINK-69] - Update to Java 11
[MJLINK-76] - Upgrade maven-plugin parent to 41

Task

[MJLINK-77] - Update description and parameters of --compress to
reflect JDK21 changes

Dependency upgrade

[MJLINK-63] - Upgrade plexus-java
[MJLINK-66] - Update parent pom to 39
[MJLINK-70] - Update m-site-p to 3.12.1
[MJLINK-71] - Require Maven 3.6.3 as new baseline
[MJLINK-72] - Remove common-lang3
[MJLINK-74] - Update org.codehaus.plexus:plexus-archiver from 4.7.1 to 4.9.1


Enjoy,

-The Apache Maven team

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

[RESULT] [VOTE] Release Apache Maven JLink Plugin version 3.2.0

[Benjamin Marwell]

Hi,

The vote has passed with the following result:

+1 : Sylwester, Romain, Slawomir, Tamás, Olivier, Hervé

PMC quorum: reached

I will promote the source release zip file to the Apache distribution
area, the staging site to the live location and the artifacts to the
central repo.

Thanks!
- Ben

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

[VOTE] Release Apache Maven JLink Plugin version 3.2.0

[Benjamin Marwell]

Hi,

We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12321432=12349496

There are still two issues left in JIRA:
https://issues.apache.org/jira/projects/MJLINK/issues

Staging repo:
https://repository.apache.org/content/repositories/maven-2064
https://repository.apache.org/service/local/repositories/maven-2064/content/org/apache/maven/plugins/maven-jlink-plugin/3.2.0/maven-jlink-plugin-3.2.0-source-release.zip

Source release checksum(s):
maven-jlink-plugin-3.2.0-source-release.zip sha512:
0cedc1a75b2ed7c085017ad65f18a10b2da4d06217dcb0eb6a1e6e22a8dadab2df4986b020392d15c7215e0b594f25e47d7341ed4e157a6b7e60be63158d008b%

Staging site:
https://maven.apache.org/plugins-archives/maven-jlink-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

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

Re: Java version for Maven 4?

[Benjamin Marwell]

To add some more information, I have seen some extreme reduction in
build times after switching from Java 11 to 17 or even 21 (just for
build, not the runtime).
We can still verify it runs on 11/17 by using the integration tests,
but having the (possibly parallel) unit- and integration tests
compile, run and package on 21 is an *extreme* improvement in build
time.

As always, YMMV. But why waste time...

Since with Semeru and Temurin all major vendors have published their
JDK21 at last,
I see no reason to use a lower Java version to build maven with.
It is easily available for everyone who wants to contribute.

If I read the thread correctly, there were no objections to raising
the build time requirements.

It will also remove a lot of unneeded profiles (Java 8 Javadoc fix,
possibly build chains and module-info profiles),
in case any of those are present.

- Ben

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

Re: maven-javadoc-plugin CI is borked

[Benjamin Marwell]

Adopt-OpenJ9 is now Semeru, and their v21 will be released next week if I
am not mistaken.

I'd love to keep that in, because it is the only JVM which does not run on
hotspot.




On Wed, 10 Jan 2024, 15:40 Slawomir Jaranowski, 
wrote:

> śr., 10 sty 2024 o 13:58 Romain Manni-Bucau 
> napisał(a):
>
> > Hi Elliotte,
> >
> > think it was a no luck phenomenon (probably due to the load the matrix
> put
> > on github OSS runners/infra).
> > That said there is a misconfiguration in the GH Actions yaml about
> version
> > 21 but this one is less misterious:
> >
> > Error: Could not find satisfied version for SemVer '21'.
> >
>
> It is a problem, some of the distributions don't have a JDK 21.
> like adopt-openj9,
> we need exclude it
>
>
>
> >
> > Best,
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 10 janv. 2024 à 13:31, Elliotte Rusty Harold  >
> > a
> > écrit :
> >
> > > If anyone has a minute to take a look. I see various failures on
> > > different dependabot PRs that have nothing to do with their content.
> > > E.g.
> > >
> > > Error: Internal server error occurred while resolving
> > > "actions/checkout@v4". Internal server error occurred while resolving
> > > "actions/setup-java@v4". Internal server error occurred while
> > > resolving "actions/upload-artifact@v4"
> > >
> > > https://github.com/apache/maven-javadoc-plugin/pull/263
> > >
> > > --
> > > Elliotte Rusty Harold
> > > elh...@ibiblio.org
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>
>
> --
> Sławomir Jaranowski
>

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

[Benjamin Marwell]

+1

Thanks for the quick fix!




On Thu, 21 Dec 2023, 08:54 Slawomir Jaranowski, 
wrote:

> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317225=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: Changing Minimum Build Requirements for plugins to JDK11

[Benjamin Marwell]

> We (as Maven developers) will have to use Java 11 to build plugins but
> not be able to use Java 11 features in the code.
> That sounds frustrating to me :)
> Or I don't understand the change you are trying to propose?

Not at all. This is how I did it at work.
This already removes a lot of frustration because it removes some
complexity from the build.



Am Di., 14. Nov. 2023 um 09:01 Uhr schrieb Olivier Lamy :
>
> oh right, sorry I didn't read correctly.
> Do you want to build with Java 11 as a minimum but limit to the usage of Java 
> 8?
> What is the point?
> We (as Maven developers) will have to use Java 11 to build plugins but
> not be able to use Java 11 features in the code.
> That sounds frustrating to me :)
> Or I don't understand the change you are trying to propose?
>
> My confusion was I read let's make java 11 as a minimum for plugins.
> Which sounds a good change to me.
> That's why I was thinking about some bytecode enforcer rule to check
> plugins bytecode and not only dependencies so users stucked with Java
> 8 can add such rule.
>
>
> On Tue, 14 Nov 2023 at 17:45, Olivier Lamy  wrote:
> >
> > Hi
> > Do we have a bytecode enforcer rule but for plugins?
> > That would help users who are eventually stuck with Java 8 and so cannot 
> > upgrade plugins going to be 11 required.
> >
> >
> >
> > Cheers
> > Olivier
> >
> >
> > On Tue, 14 Nov 2023 at 5:38 am, 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
> >>
>
> -
> 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

[Benjamin Marwell]

Big +1

I sometimes need to switch back from JDK 21 to 17 or earlier to build
some of the plugins.
If we start building with 11+, we can detect build errors easier for newer JDKs.
The spotless profile might not be the only profile we can remove.

One catch, though. Should we not test on JDK8? Maybe on toolchains?
But I (personally) think from my experience the risk is very low.
I have been building all my Java 8 apps with 11 for years, and now I
am building Java 17 apps with 21 and never had a problem.
On the contrary, build times went down by an insane amount, up to 50%
less build time! :)

Of course, YMMV. If there are technical reasons preventing this... so be it.
But even then I would like to seek solutions first.

- Ben

Am Mo., 13. Nov. 2023 um 20:38 Uhr schrieb Karl Heinz Marbaise
:
>
> 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
>

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

Re: Surefire Plugin: Tests failure on abstract class only shows the abstract class name

[Benjamin Marwell]

Hi Tison,

do you have access to the issue tracker?
https://issues.apache.org/jira/projects/SUREFIRE/issues

Am Mo., 16. Okt. 2023 um 07:51 Uhr schrieb tison :
>
> Bubble up. Or where I can file an issue to track if it's likely an
> improvement.
>
> Best,
> tison.
>
>
> tison  于2023年9月23日周六 09:48写道：
>
> > The "usePhrasedClassNameInRunning" property in
> > "JUnit5StatelessTestsetInfoReporter" helps a bit:
> >
> > @DisplayName("FsTest")
> > public class FsTest extends BehaviorTest {
> > // ...
> > }
> >
> > [INFO] Running FsTest AsyncWriteTest
> > [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> > 0.636 s <<< FAILURE! -- in FsTest AsyncWriteTest
> > [ERROR]
> > org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull --
> > Time elapsed: 0.594 s <<< FAILURE!
> > java.lang.AssertionError:
> >
> > But not in the very end summary:
> >
> > [INFO] Results:
> > [INFO]
> > [ERROR] Failures:
> > [ERROR]
> > org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull
> > [ERROR]   Run 1: BehaviorTest$AsyncWriteTest.testReadFull:110
> >
> > You can clone https://github.com/apache/incubator-opendal/pull/3161 and
> > fail some tests case conditionally for debugging.
> >
> > Best,
> > tison.
> >
> >
> > tison  于2023年9月23日周六 01:17写道：
> >
> >> To demostrate the expected manner, I want:
> >>
> >> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> >> 0.535 s <<< FAILURE! - in
> >> org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest
> >> [ERROR]
> >> org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull  Time
> >> elapsed: 0.491 s  <<< FAILURE!
> >> java.lang.AssertionError:
> >>
> >> to be:
> >>
> >> [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> >> 0.535 s <<< FAILURE! - in
> >> org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest
> >> [ERROR] 
> >> org.apache.opendal.behavior.FsTest>org.apache.opendal.behavior.BehaviorTest$AsyncWriteTest.testReadFull
> >>  Time elapsed: 0.491 s  <<< FAILURE!
> >> java.lang.AssertionError:
> >>
> >> Or other approach to specify the actual test class.
> >>
> >> Best,
> >> tison.
> >>
> >>
> >> tison  于2023年9月23日周六 01:11写道：
> >>
> >>> See https://github.com/junit-team/junit5/issues/3475 for details.
> >>>
> >>> Perhaps JUnit5ConsoleOutputReporter is related but I failed to located
> >>> the certain line constructing the test method name.
> >>>
> >>> Best,
> >>> tison.
> >>>
> >>

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

Re: [VOTE] Release Maven Javadoc Plugin version 3.6.2

[Benjamin Marwell]

+1

Am So., 5. Nov. 2023 um 20:32 Uhr schrieb Michael Osipov :
>
> Am 2023-11-03 um 21:42 schrieb Michael Osipov:
> > Hi,
> >
> > We solved 7 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529=12353815
> >
> > There are still a couple of issues left in JIRA:
> > https://issues.apache.org/jira/projects/MJAVADOC/issues
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-2024/
> > https://repository.apache.org/content/repositories/maven-2024/org/apache/maven/plugins/maven-javadoc-plugin/3.6.2/maven-javadoc-plugin-3.6.2-source-release.zip
> >
> > Source release checksum(s):
> > maven-javadoc-plugin-3.6.2-source-release.zip
> > sha512:
> > 9e6d0a8c9245bfee07b907e9a00390be60be50b9681ef0dcd6c85fc82ac9aeb3f35b9106d3d7e5e61b710be675f0654c0eace54787c02a37fafc314656f32781
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-javadoc-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
>
> +1
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: [VOTE] Release Apache Maven Clean Plugin version 3.3.2

[Benjamin Marwell]

+1




On Mon, 23 Oct 2023, 08:11 Slawomir Jaranowski, 
wrote:

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317224=12353735
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MCLEAN%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2017/
>
> https://repository.apache.org/content/repositories/maven-2017/org/apache/maven/plugins/maven-clean-plugin/3.3.2/maven-clean-plugin-3.3.2-source-release.zip
>
> Source release checksum(s):
> maven-clean-plugin-3.3.2-source-release.zip - SHA-512 :
>
> 7038bca2cc3bc3cdd1dd5d9c363a19150242508e165380feac02bc1b2bf75fee695ecb6fc6f9ed10a3a1ec14f9e46d2963487400b9fce008afa423939b754c5f
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-clean-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 Maven Dependency Plugin version 3.6.1

[Benjamin Marwell]

+1, but consider removing the dependency upgrade for commons from the
release notes. It's been removed anyway.

Improvement
[MDEP-832] - Remove commons-collections-4

vs

Dependency upgrade
[MDEP-869] - commons-collections to 4.4





On Fri, 20 Oct 2023, 23:28 Michael Osipov,  wrote:

> Hi,
>
> we solved 7 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12353360
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MDEP/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2013/
>
> https://repository.apache.org/content/repositories/maven-2013/org/apache/maven/plugins/maven-dependency-plugin/3.6.1/maven-dependency-plugin-3.6.1-source-release.zip
>
> Source release checksum(s):
> maven-dependency-plugin-3.6.1-source-release.zip
> sha512:
>
> 6bdbd4cf4ff355d4e087ee5a7eef24b8812963c4372a6ba5116c8ea8dfdc5291c34edc262fe19eb2fc97a8e77d60c91d9ec843512729b862609f28689f396bd9
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven JXR version 3.3.1

[Benjamin Marwell]

+1

- Ben





Michael Osipov  schrieb am Fr., 20. Okt. 2023, 21:45:

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

Re: [VOTE] Apache Maven 4.0.0-alpha-8 release

[Benjamin Marwell]

+1. -- thanks!

- Ben

Guillaume Nodet  schrieb am Fr., 20. Okt. 2023, 23:38:

> I'm starting a new vote to release this new alpha.
>
> This alpha release provides new cornerstone features for the future Maven
> evolution.
> In particular, the POM model which was set in stone to a 4.0.0 version
> since Maven 3.0, is now able to evolve. For modules that have a packaging
> which is not POM, the flattened consumer POM is now installed/deployed
> instead of the main POM, eventually translated back into a 4.0.0 model
> version for consumer compatibility. The build POM is also installed /
> deployed unchanged. This allows the introduction of the 4.1.0 model which
> already brings a few improvements.
>
> 50 issues solved:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353356
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-2011
>
> Dev dist directory:
> https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-8/
>
> Source release checksums:
> apache-maven-4.0.0-alpha-8-src.zip sha512:
>
>
> 7264b5ae1a567ff9249f8020bc5713386f26bdd297b499e309a70897d03b647ef5a1446d10963529fd50dbab0ee56f5357ab39405462b8a5326a99bae80222c9
>
> apache-maven-4.0.0-alpha-8-src.tar.gz sha512:
>
>
> d645e4015119836428e16bd5d4dd29bed6d4983d552445cdf587a61f0a2347a619e9de02cdc590eda000c4561e60e33e758aa83dca3d6243ede97f5be981b322
>
>
> Binary release checksums:
> apache-maven-4.0.0-alpha-8-bin.zip sha512:
>
>
> 6aa9486e2d880b691580e0071347022b6426f0a6b2c6549879b6a848a4494c70ff8dff25ffe8de2edd82583d7119bf359156ece0f9ef18f1c99ff3db776461f3
>
> apache-maven-4.0.0-alpha-8-bin.tar.gz sha512:
>
>
> 7646b5bbaa0b81e600076055134ba88d5bd02d7a0ae03829b7e217aad9e47c25a3edbf4b091562d4bc9d93b5a50e84449a679f18052dc4f97d0314a8bc9dd961
>
>
> Staged site:
> https://maven.apache.org/ref/4-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/462
>
> https://github.com/apache/maven-site/blob/21deeaf4a0fc4993e0091d214f194195dc66c167/content/markdown/docs/4.0.0-alpha-8/release-notes.md
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Note that this release has been built and uploaded with 4.0.0-alpha-8
> itself, which means it uses the new build and consumer POMs...
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers
> Guillaume
>

Re: Maven 5 pom extension for agents

[Benjamin Marwell]

All this discussion, but I honestly find the idea of mockito creating a
plugin like jacoco a cleaner solution. Are there any drawbacks? It worked
for a long time now.



On Fri, 20 Oct 2023, 22:00 Guillaume Nodet,  wrote:

> If false positives are a problem, we could just have an empty default
> value.
> Users would simply have to configure something like:
>net.bytebuddy:byte-buddy-agent
> Also, a special auto-discover value  (or another predefined value of
> course) could be used to discover agents in the test classpath and add them
> as agents automatically.
>
>
>
>
> Le ven. 20 oct. 2023 à 21:29, Romain Manni-Bucau  a
> écrit :
>
> > Guess we would get a lot of false positive and surefire already has it so
> > not sure it would help to simplify, complexity seems 1-1 :s
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le ven. 20 oct. 2023 à 21:05, Guillaume Nodet  a
> écrit
> > :
> >
> > > Not sure agents are widely used during the build either.
> > > I wonder if surefire should be given a list of artifacts coordinates
> that
> > > it would consider as agents if they are in the test class path...  The
> > > default value would contain bytebuddy, but it could be changed (and
> > ordered
> > > considered in that list) if needed.
> > > That would be very specific to surefire, but I'm not sure there are
> many
> > > use cases...
> > >
> > > Guillaume
> > >
> > > Le ven. 20 oct. 2023, 20:44, Romain Manni-Bucau  >
> > a
> > > écrit :
> > >
> > > > Can be the way to define the lookup, an heuristic will never work by
> > > > design...that said, on my side, not sure JPMS will be widely adopted
> > > > anytime soon so can be a false problem.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le ven. 20 oct. 2023 à 20:24, Henning Schmiedehausen <
> > > > henn...@schmiedehausen.org> a écrit :
> > > >
> > > > > I think we will need to start rethinking dependencies more. A
> similar
> > > > > problem exists with modules; the current heuristics to decide
> > whether a
> > > > > dependency goes on module path or classpath will start to become
> > > painful
> > > > in
> > > > > the very near future.
> > > > >
> > > > > -h
> > > > >
> > > > >
> > > > > On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell <
> > bmarw...@apache.org
> > > >
> > > > > wrote:
> > > > >
> > > > > > If you can still use it twice, works for me, too.
> > > > > >
> > > > > > Either way, you'd need it both as a dependency and as an agent.
> > > > > >
> > > > > > Another requirement Romain mentioned is the order of agent
> loading.
> > > > > Mockito
> > > > > > wants to be first, and others can come later.
> > > > > >
> > > > > > - Ben
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, 18 Oct 2023, 00:11 Tamás Cservenák,  >
> > > > wrote:
> > > > > >
> > > > > > > What about type=java-agent? Basically a new ArtifactHandler?
> > > > > > >
> > > > > > > See https://maven.apache.org/repositories/artifacts.html
> > > > > > >
> > > > > > > T
> > > > > > >
> > > > > > > O

Re: Maven 5 pom extension for agents

[Benjamin Marwell]

If you can still use it twice, works for me, too.

Either way, you'd need it both as a dependency and as an agent.

Another requirement Romain mentioned is the order of agent loading. Mockito
wants to be first, and others can come later.

- Ben




On Wed, 18 Oct 2023, 00:11 Tamás Cservenák,  wrote:

> What about type=java-agent? Basically a new ArtifactHandler?
>
> See https://maven.apache.org/repositories/artifacts.html
>
> T
>
> On Tue, Oct 17, 2023, 23:54 Benjamin Marwell  wrote:
>
> > Hey all,
> >
> > In a mockito issue, JDK maintainers suggested to differentiate between
> > agents and normal dependencies. Starting with JDK 21 already, this makes
> a
> > lot of sense: dynamic loading of agents will be a no-go.
> >
> > One suggestion was:
> >
> > 
> > 
> > ...
> > 
> > 
> > 
> > ...
> > 
> > 
> > 
> >
> > Not sure if this is the best way, but this is something similar might be
> > needed.
> > Currently, the only way to handle agents is to add them manually to the
> > surefire argLine. To make things worse, a deoendency goal is needed until
> > Romains PR is merged:
> > https://github.com/apache/maven/pull/1281
> >
> > Another issue is that a parent pom might not be able to easily define
> this
> > option. There were some concerns that part of the configuration needed to
> > be repeated in every module.
> >
> > So, I wrote Maven 5.
> > Maven 4 is the stepping stone to the build/consumer pom. But this is an
> > extension. Not really a breaking change in terms of parsing, but in terms
> > of building a project. Thus, it should go onto the roadmap.
> >
> > ... unless you want to keep the current status quo, which is also an
> > option. But before making an argument here, I'd recommend reading the
> > lengthy (sorry!) discussion on the mockito issue tracker. Since Karl
> Heinz
> > started the issue, I'd love to hear back from you, too. Link:
> > https://github.com/mockito/mockito/issues/3037
> >
> > If no discussion is needed at this point, let's keep this as a reminder
> for
> > the next Apero and/or Maven 5 then.
> >
> > - Ben
> >
>

Maven 5 pom extension for agents

[Benjamin Marwell]

Hey all,

In a mockito issue, JDK maintainers suggested to differentiate between
agents and normal dependencies. Starting with JDK 21 already, this makes a
lot of sense: dynamic loading of agents will be a no-go.

One suggestion was:



...



...




Not sure if this is the best way, but this is something similar might be
needed.
Currently, the only way to handle agents is to add them manually to the
surefire argLine. To make things worse, a deoendency goal is needed until
Romains PR is merged:
https://github.com/apache/maven/pull/1281

Another issue is that a parent pom might not be able to easily define this
option. There were some concerns that part of the configuration needed to
be repeated in every module.

So, I wrote Maven 5.
Maven 4 is the stepping stone to the build/consumer pom. But this is an
extension. Not really a breaking change in terms of parsing, but in terms
of building a project. Thus, it should go onto the roadmap.

... unless you want to keep the current status quo, which is also an
option. But before making an argument here, I'd recommend reading the
lengthy (sorry!) discussion on the mockito issue tracker. Since Karl Heinz
started the issue, I'd love to hear back from you, too. Link:
https://github.com/mockito/mockito/issues/3037

If no discussion is needed at this point, let's keep this as a reminder for
the next Apero and/or Maven 5 then.

- Ben

Re: [VOTE] Retire Maven Docck Plugin

[Benjamin Marwell]

+1





On Tue, 17 Oct 2023, 00:50 Slawomir Jaranowski, 
wrote:

> Hi,
>
> - Last release was in 2015
> - use Maven 2.2.1
> - we have a Maven Plugin Tools - which should be one project for build and
> check Maven plugins
> - no active development ...
>
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MDOCCK%20AND%20(%20resolution%20%3D%20Unresolved%20OR%20fixVersion%20%3D%203.0.0)
> - no working with current plugins
>
> I therefore propose that we retire maven-docck-plugin -
> https://maven.apache.org/plugins/maven-docck-plugin/
>
> If this vote is successful I will make one final release of the plugin,
> making it clear on the plugin site that it has been retired.
> After that the source code will be moved into read-only mode.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html
>
> The vote is open for 72 hours.
>
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...
>
> [1]
>
> --
> Sławomir Jaranowski
>

Re: HPI plugin

[Benjamin Marwell]

Basil,

I am a Maven committer. If you want to have replies from specific persons,
don't use the developer mailing list. There is no such role as a core
committer. There's only the PMC, which are not necessarily the most active
committers.

To be honest, I don't think "core" committers will give you any different
answers then what I said (minus the nits). The naming will break the build.

- Ben

On Mon, 26 Jun 2023, 09:08 Basil Crow,  wrote:

> Hi Benjamin,
>
> Sorry for the confusion, but my question was directed to the Maven
> core committers.
>
> Basil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: HPI plugin

[Benjamin Marwell]

Hello Basil,

I wrote the mail while the ITs were running.

Please note the naming issue is not "minor". It will break the build very
soon.
There's a reason for this:

SEE:
https://maven.apache.org/guides/plugin/guide-java-plugin-development.html

QUOTE:
You will typically name your plugin -maven-plugin.

Calling it maven--plugin (note "Maven" is at the beginning of
the plugin name) is strongly discouraged since it's a reserved naming
pattern for official Apache Maven plugins maintained by the Apache Maven
team with groupId org.apache.maven.plugins. Using this naming pattern is an
infringement of the Apache Maven Trademark.


On Mon, 26 Jun 2023, 02:03 Basil Crow,  wrote:

> Hi Ben,
>
> While the Jenkins project would likely accept patches fixing those
> issues, they seem to be of very low priority. If you discover any
> issues of substance that ought to be fixed, please let me know.
>
> Basil
>

Re: HPI plugin

[Benjamin Marwell]

Hi Basil,

the first issue I see when using Maven 3.9.2:

[INFO] --- plugin:3.9.0:descriptor (default-descriptor) @ maven-hpi-plugin ---
[WARNING]

Artifact Ids of the format maven-___-plugin are reserved for
plugins in the Group Id org.apache.maven.plugins
Please change your artifactId to the format ___-maven-plugin
In the future this error will break the build.

Your Build *will* break in the next few versions.
Kindly consider releasing a new major version with the name changed.
The repository should be moved, too, if possible.

Then, do not recommend "clean install". Most of the time, a plain
"verify" should suffice.
It will neither clutter your local repo nor lead to side effects, as
"install" would.
The goal "clean" is probably not necessary most of the times, except
major dependency updates
or inproper plugins leaving files behind.

Your file ".mvn/jvm.config" is missing a line break at the end.

Will look into more things later. Please make sure to clean up what I
found so far.

- Ben

Am Fr., 23. Juni 2023 um 17:20 Uhr schrieb Basil Crow :
>
> I recently attempted to modernize the HPI plugin used in the Jenkins project:
>
> https://github.com/jenkinsci/maven-hpi-plugin
>
> This plugin has a Maven baseline of 3.8.1. I think I migrated all
> usages away from deprecated functionality and onto the recommended
> modern Maven functionality.
>
> If a Maven developer could audit this plugin and let me know if
> anything else should be updated, I would be grateful.
>
> Thanks,
> Basil
>
> -
> 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: [VOTE] Release Maven WAR Plugin version 3.4.0

[Benjamin Marwell]

+1

Am So., 11. Juni 2023 um 22:14 Uhr schrieb Michael Osipov :
>
> Hi,
>
> we solved 17 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318121=12350597
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MWAR/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1955/
> https://repository.apache.org/content/repositories/maven-1955/org/apache/maven/plugins/maven-war-plugin/3.4.0/maven-war-plugin-3.4.0-source-release.zip
>
> Source release checksum(s):
> maven-war-plugin-3.4.0-source-release.zip
> sha512:
> ef7b2621697024570522a778318106f1e5ca18bf6944cb9e43e693e8c37312af272036f517d03b3555622f9bad695217ececa078affda6442d76063b5153f998
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-war-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

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

[Benjamin Marwell]

Big +1 for an alternative format, but not sure HOCON is the best of all
those out there.
It surely is one of the better ones, though.

Big plus is easiness to humans, no deps, external docs.

However, TOML gained some popularity.  I'd say Maven should ship no more
than one alternative to XML. And while HOCON is a great candidate, so is
TOML. TOML is much easier to parse.

But HOCON is good for me, too. I just hope completion support / markup /
schema is a thing. Otherwise maintaining the pom documents could be a
little cumbersome.

All in all, +1 to what Romain said.

Am Mi., 7. Juni 2023 um 18:02 Uhr schrieb Guillaume Nodet :

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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Benjamin Marwell]

Hunter,

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

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

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

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

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

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

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

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

See posts from Romain, Delaney and Manfred for reference.

- Ben


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

> Ok, so let's take these points one at a time:* Reduce build matrix, save
> energySo, less builds which is good but pretty minimal value.
> * Attract devsAbsolutely not.  If you want to attract devs, switch to a
> language that is actually growing (no I'm advocating for this).  That isn't
> Java.  If anything, this will lose you devs.  The company I work for will
> be leaving Maven if you stop supporting Java8.  That's 300 users you lose
> right there.  That's just 1 company.  You will lose users in droves if you
> stop Java8 support.  Many companies don't have/put enough resources into
> this type of upgrade.  Its hard to justify to the business and it makes
> lots of work for devs (expensive).  If it is cheaper to switch build
> systems that to upgrade the JVM, that's exactly what folks will do.  My
> company certainly will (not my decision so don't try to convince me, I'm
> not the one you have to convince).
>
> * CDS for non-OpenJ9-usersI'm not sure this is something that is really
> taken advantage of by Maven.  Perhaps I am wrong.
>
> * Better clarity of code (yes, I mean that)That you say that you actually
> mean this says it all.  Clearly this is something that isn't agreed upon
> universally.  Your personal taste shouldn't decide the future of a project
> used by so many others.
> * No additional work (we don't need to migrate, just use the features when
> modifying a line for a bug/feature anyway)This is simply not true.  There
> have been comments by devs on this very list, in this very discussion that
> disprove this point.  It isn't OK to just ignore their input because you
> really want to use lambdas.
>
> * We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.You have
> that backwards.   If you leave Java8, you leave behind everyone who can't
> upgrade their source base.  It seems to me that the size of the group of
> Java8 folks you will leave behind is quite large.  So your argument about
> no drawbacks isn't credible.  There are no drawbacks for you, that isn't
> the same as there being no drawbacks for the entire user base.
> * By the time Maven 4 final is out, your views might have changed!I write
> most of my code in Scala so I doubt it seriously.
>
> Your points are not nearly as strong as you imply with your tone.  Some of
> them indicate a lack of understanding of some more advanced parts of FP
> which is understandable for Java devs but doesn't make your points
> correct.  And your analysis of the impact on the userbase is just plain
> wrong.  If you want people to bomb this list with complains, drop Java 8
> support and enjoy the rage postings you get from 100s to 1000s of devs who
> work for companies and projects that don't have to resources to upgrade.
>
> Hunter
> PS Lambdas are only useful if there is function composition and currying.
> Java lacks both.  So the debate over lambdas is pretty amusing to me.  It
> is just syntactic sugar.  It doesn't actually give you the ability to do
> other things like in Scala or Kotlin.  

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Benjamin Marwell]

Ok, here's a benefit of Java 11/17 or two:

* Reduce build matrix, save energy
* Attract devs
* CDS for non-OpenJ9-users
* Better clarity of code (yes, I mean that)
* No additional work (we don't need to migrate, just use the features when
modifying a line for a bug/feature anyway)
* We leave no one behind b/c of Maven 3.8/3.9, thus no drawbacks.
* By the time Maven 4 final is out, your views might have changed!

So Hunter, these have all been brought up before. We can continue with 8,
yes. But new projects will use Java 17 anyway, and Java 17 gives us less
complex code.

That really should be good enough. Really.

 - Ben


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

>  Hi,  Karl, I'm not sure I agree you have "stated a benefit" so far.
> There have been plenty of hand-wavy arguments but nothing really solid.
> That's why you are getting so much push back.  Point to a specific feature
> you need or some other thing that would help the project in some
> significant way.  At the moment, the argument is basically, "its newer so
> its better", I'm sorry but that simply is not true.  Make a better case and
> you will get less pushback.
> Hunter
>
> On Monday, June 5, 2023 at 06:03:26 AM PDT, Karl Heinz Marbaise <
> khmarba...@gmx.de> wrote:
>
>  Hi,
>
> On 03.06.23 11:46, Hervé Boutemy wrote:
> > +1
> >
> > I really don't what benefit we get from going to Java 17
>
> which was already part of the email:
>
>
>  > Based on the argument we don't need  features of JDK17+ I see a number
>  > of things which could make our handling/maintenance easier for example
>  > using sealed classes to prevent exposing internal things to public which
>  > could be used etc. also some other small features (`var` for example;
>  > Text-Blocks in Tests etc) or using records in some situation (really
> immutability)..
>  >
>  >
>
>
> Kind regards
> Karl Heinz Marbaise
>
> >
> > I perfectly see the impact we'll have on our users: for what benefit?
> >
> > notice that this will also impact all plugins: and given the few work
> done on
> > plugins to clearly show what plugin version remains compatible with a JDK
> > release, I feel we're not taking the topic the right way
> >
> > Le vendredi 2 juin 2023, 01:50:53 CEST Hunter C Payne a écrit :
> >>  I'm not sure I would worry too much about that David.  I think most
> devs
> >> who want better syntax moved from Java sometime ago.  They might still
> be
> >> on the JVM just not writing Java.  Also, Maven is a mature project.  I
> >> don't think devs considering contributing to it are thinking about using
> >> the latest and greatest version of Java.  Compatibility is probably a
> >> bigger concern for the user base.  Just my opinion.
> >>
> >> Hunter
> >>  On Thursday, June 1, 2023 at 04:17:26 PM PDT, David Jencks
> >>  wrote:
> >>
> >>  I wonder if having maven require java 8 syntax discourages any
> potential
> >> contributors who are used to coding using more recent developments. I
> have
> >> no idea how to tell, but maybe someone else does.
> >>
> >> David Jencks
> >>
> >>> On Jun 1, 2023, at 3:02 PM, Karl Heinz Marbaise 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> my clear opinion is to go  with most recent JDK LTS version for the
> >>> release point of Maven 4.0.0 which I assume will be JDK 21...
> >>>
> >>> That means clear the build time requirement which is completely
> >>> different from runtime of an application.
> >>>
> >>>
> >>> Older JDK's are supported by some vendors by having particular special
> >>> support which most of the time requires special contracts (means also
> >>> paying money for it)..some of them offering builds without paying money
> >>> yes..
> >>>
> >>> Older runtime target are supported with different approaches like
> >>> Toolchain or via `--release XX` which exists since JDK9+.
> >>>
> >>>
> >>> Furthermore if someone is not capable of upgrading the build
> environment
> >>> to JDK9+ they can continue to use Maven 3.8.X or Maven 3.9.X...
> >>>
> >>> If it would be requirement to port things back to 3.8.X or 3.9.X it
> >>> could be handled by someone who has the time etc. to do that ... if
> not,
> >>> those people might think of paying someone to do that work...
> >>>
> >>>
> >>> The given argument about JPMS for migration causes issues is from my
> >>> point of view false-positive because migration to newer JDK versions
> >>> does not require JPMS usage...
> >>>
> >>> Even platforms like AWS support JDK17 in the meantime which is the
> >>> runtime...
> >>>
> >>>
> >>> Based on the maintenance part it would mean in consequence to downgrade
> >>> to even JDK7... (or even lower) because you can get support for older
> >>> JDK version in some ways... (JDK7 from azul for example)
> >>>
> >>> Kind regards
> >>> Karl Heinz Marbaise
> >>>
> >>> [1]
> https://www.oracle.com/java/technologies/java-se-support-roadmap.html
>
>
> -
> To unsubscribe, e-mail: 

Re: GH issues and GH discussions

[Benjamin Marwell]

I am pretty sure if that happens (terms changes, GH not an
option), we have plenty of time to migrate.
The same has happened multiple times in the past: SourceForge, BerliOS,
Google Code...
Now it is ASF JIRA and maybe some day we will be migrating away from GitHub
Issues to something else?

But even then, there will be an archive and there will be a migration tool.
None of the above migrations
lost any data AFAIK.

Am Sa., 27. Mai 2023 um 11:24 Uhr schrieb Łukasz Dywicki <
l...@code-house.org>:

> I have no strong feelings, however relying too much on single service
> vendor is never a good idea. In this case if one day, by some
> terms changes, github repos are not an option any more, we are
> fine with ASF infrastructure. But we can't do same thing for issues
> which are embedded in GH database. If you ever found a google code
> project migrated into github/gitlab issues you know what I mean.
>
> While policies imposed on JIRA account creation, are without doubt a
> bearer to contribute first bug report, JIRA itself helps us keeping all
> ASF information together. Just to be clear - I keep being lost with new
> JIRA user interface, I'm just reflecting my personal thoughts.
>
> Best,
> Łukasz
>
>

Re: GH issues and GH discussions

[Benjamin Marwell]

Big +1, as more and more projects are already migrating (including Apache
Shiro).

I'd vote for maven-jlink-plugin: Not many issues currently.

> not having to create an issue if a PR exists first

I'd at least make milestones mandatory in that case.
It is far less work than maintaining an issue.

Am Fr., 26. Mai 2023 um 09:44 Uhr schrieb Olivier Lamy :

> Hi,
> This has been already discussed in the past.
> But due to recent changes in ASF Jira infrastructure (limitation of
> Jira users, validation of account creation).
> Maybe we could reconsider moving from Jira to GH issues and why not
> simplify the workflow as well.
> I imagine not having to create an issue if a PR exists first (sounds
> like duplicate work).
> By the way, release notes will be automatically created from PRs.
> (could be manually modified if a change doesn't have a PR).
>
> Regarding migration, we can start project by project.
> Few options:
> - extreme simplicity, do not migrate any data (just mark the Jira
> project as read only with a banner/link to corresponding gh issues).
> If someone really needs an issue to get fixed he will clone it to GH
> - middle complexity, migrate only open issues (components moved as a label)
> - extreme complexity, migrate all issues of a project (components
> moved as a label and version created)
>
> We can start by small projects such as cache-extension and one plugin
> (compiler?)
>
> Regarding GH discussions, maybe we can open discussions for
> https://github.com/apache/maven which sounds like a natural place for
> users to go. (discussions could be mirrored to a ML)
> I do not have a strong opinion here, but I feel like opening
> discussions for every single repo will be complicated to follow up.
>
> WDYT?
>
> cheers
> Olivier
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSSION] Apache Maven plugins versioning

[Benjamin Marwell]

The advantage is simple.
With "maven4" in the module name, you don't need a compatibility matrix on
every plugins homepage or readme.

Just look at npm modules and webpack... Tables over tables...




On Sun, 26 Mar 2023, 19:29 Michael Osipov,  wrote:

> Am 2023-03-26 um 19:02 schrieb Romain Manni-Bucau:
> > @Benjamin what's the addtion of the "4" except looking weird after 1
> > version since you use semver? It forces 2 changes instead of one without
> > anything else explicit IMHO.
>
> I fully second that!
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSSION] Apache Maven plugins versioning

[Benjamin Marwell]

+1 to your proposal

org.apache.maven:maven4-xyz-plugin:

I don't think it would cause too much trouble as Maven APIs will love for a
few years. It will only occasionally break when a new major Maven release
is published. I can live with that.

Also, maven 3 plugins will be compatible for a while.




On Thu, 23 Mar 2023, 20:58 Slawomir Jaranowski, 
wrote:

> Hi,
>
> I know that historically plugin versions like 2.x was dedicated to Maven
> 2.x and versions 3.x is for Maven 3.x.
>
> We don't have any written documentation about it (or I can't find it), it
> looks like a traditional agreement.
>
> Nowadays Semantic Versioning is very popular and it is understood by people
> and by automatic tools.
> In many cases we use versions which look like Semantic Versioning (x.y.z) -
> but internally we try to classify it in different ways.
>
> When we connect the plugins version with the Maven version as the major
> version,
> we have difficulty introducing breaking changes for plugins for the same
> Maven version.
> Also we can introduce many misunderstandings which version contains new
> features and which only bug fixes.
>
> Authors of plugins outside Maven core in many cases don't use 3.x as for
> Maven 3 and so on.
>
> One of the propositions can be - use Semantic Versioning as is described
> and put a Maven version in the artifact name of the plugin.
>
> So we can have:
>
> maven4-XXX-plugin - for core plugins
> XXX-maven4-plugin - for external plugins
>
> Additionally Maven 4 will have a new Api which is incompatible with Maven
> 3, when we have the target Maven version in artifact it will be easier to
> transition plugins from 3 to 4 and so on.
>
> Simply in many cases business logic which plugin provides can be extracted
> to a common module and next two modules will provide plugins for specific
> Maven.
> It can help maintain one plugin for many Maven versions.
>
>
> --
> Sławomir Jaranowski
>

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

[Benjamin Marwell]

Big +1!

On Wed, 15 Mar 2023, 15:17 Jorge Solórzano,  wrote:

> 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=%22%3Cproject.build.sourceEncoding%3EUTF-8%3C%2Fproject.build.sourceEncoding%3E%22+language%3A%22Maven+POM%22=code
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] m-remote-resources-p

[Benjamin Marwell]

No one ever told me about this convention and I knew about it the
moment I saw the version numbers.
However, Elliote is right, that's not semver.
The alternative would be to put a lookup / compatibility  table in
each plugin's readme. But that would be so annoying as a user, because
Maven is just SO modular!

+1 for keeping the 3.x.x numbers. I think everyone knows about it by now.

Am Fr., 10. März 2023 um 18:52 Uhr schrieb Tamás Cservenák
:
>
> Howdy,
>
> Sure, am fine, but from history:
> Maven1 had 1,x plugins.
> Then Maven2 was fully rewritten, and all plugins became 2.x (despite there
> was no "backward compatibility", as Maven1 plugin could never run in Maven2.
> Then Maven3 was done with full backward compatibility as one of the goals,
> hence things like default lifecycle carried for quite a long time 2.x
> plugins, while 3.x plugins existed as well (even same ones). Simply put,
> 2.x plugin broadly spoken "uses Maven2 API" and works in both Maven2 and
> Maven3 (due it's bw maven-compat), but a 3.x plugin could NOT work in
> Maven2, only in Maven3.
>
> This was always true for core plugins. Mojohause and 3rd party plugins
> never followed this scheme sadly.
>
> So, something like this was envisioned:
> https://gist.github.com/cstamas/b0605a9fad09de4adcbd888baa4c
>
> T
>
>
>
> On Fri, Mar 10, 2023 at 6:37 PM Michael Osipov  wrote:
>
> > Am 2023-03-10 um 18:31 schrieb Tamás Cservenák:
> > > Maven plugin cannot have a new major version, as "by convention" it would
> > > mean it requires Maven 4 to run.
> > > As in this case it would be m-remote-resources-p 4.0.0 (as currently it
> > is
> > > 3.x,x).
> >
> > That's is not necessarily correct. Working on Doxia 2 I have bumped all
> > reporting plugins to next major in a branch to reflect the breaking
> > changes. Just requires proper docs, IMHO.
> >
> > M
> >
> >

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

Re: [DISCUSS] m-remote-resources-p

[Benjamin Marwell]

+1 for dropping. Make it a new minor Version. We may want to add a
migration strategy. But then, if there's not even a hit on GitHub... Just
go with it. We do have a well working mailing list.


On Fri, 10 Mar 2023, 10:56 Olivier Lamy,  wrote:

> not sure how useful this feature is...
> I would say just drop it...
> quick search on github cannot find usage of it...
>
> https://github.com/search?q=%3CrunOnlyAtExecutionRoot%3E+language%3A%22Maven+POM%22=code=Maven+POM
>
>
>
> On Fri, 10 Mar 2023 at 00:44, Tamás Cservenák  wrote:
> >
> > Howdy,
> >
> > I would like to share (and possibly exchange) some recollections about
> the
> > m-remote-resource-p.
> >
> > For start, there is an ongoing PR to drop all the accumulated legacy
> stuff:
> > https://github.com/apache/maven-remote-resources-plugin/pull/26
> >
> > But what caught my eye are these lines:
> >
> https://github.com/apache/maven-remote-resources-plugin/blame/e7cc40df2f5ee99cde90d1dc7308df719f1c1963/src/main/java/org/apache/maven/plugin/resources/remote/ProcessRemoteResourcesMojo.java#L134-L138
> >
> > In short, what this plugin does is (should be) nearly trivial: collect
> > project, project dependencies, resolve some resource bundles, apply
> > Velocity templates, done.
> >
> > BUT, due to the comment and removal of `requiresDependencyResolution`
> this
> > plugin does what Maven should be doing: resolves/collects and builds
> > transitive deps. And I feel this is wrong.
> >
> > As you see in comment, the REASON of removal (and hence bloating the Mojo
> > with all-the-stuff-that-Maven-should-do) was to implement
> > https://issues.apache.org/jira/browse/MRRESOURCES-41 that again looks
> like
> > some 'wish" issue, with idea "to mimic the assembly plugin's
> > runOnlyAtExecutionRoot flag". Also, to me this "smells" like aggregation
> > without aggregator (and resolution without Maven) -- so just a WTH moment
> > one after another.
> >
> > I find this wrong, as it sacrifices simplicity and reusability (plugin
> must
> > do what Maven already does for plugin, if asked for), and it resulted in
> > this plugin to become bloat, and later totally neglected and full of
> > booby-traps.
> >
> > So, my proposal is like in PR:
> >
> > 1. return this Mojo switch `requiresDependencyResolution=TEST` and let
> Mojo
> > filter as it needs. This is already done in PR and big chunk of code is
> > gone, all tests except the one IT that tests the runOnlyAtExecutionRoot
> > passes OK.
> > 2. above implies we drop runOnlyAtExecutionRoot, everything else remains,
> > BUT
> > 3. introduce new mojo aggregate-process (as in PR), that really does what
> > it says: will collect all DEPENDENCIES in BULK at parent level. There
> > are two shortcomings (as seen in IT_RunOnlyAtExecutionRoot source): it is
> > IN BULK, and for this to work, a goal is needed that will produce
> > inter-project dependencies, otherwise build fails.
> >
> > With these changes all passes OK and IMO the plugin itself became much
> > simpler and easier to understand.
> >
> > In short, if you have any idea, I am listening!
> >
> >
> > Thanks
> > T
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Halve the logging

[Benjamin Marwell]

Sadly, --ntp also disables upload progress and ANY information associated
with this.
Maybe it would be beneficial to have an option for that.




On Sun, 19 Feb 2023, 18:26 Michael Osipov,  wrote:

> Am 2023-02-19 um 18:17 schrieb Romain Manni-Bucau:
> > Not sure we can find an agreement on this topic, both opinions are very
> > valid and depends the persona/case so let's keep our default while it is
> > customizable easily it is fine IMHO.
>
> Good point, I could imagine that one could introduce --transfer-progress
> , similar Tamás did with Resolver transports.
>
>

Re: extracting XML classes from plexus-utils to plexus-xml

[Benjamin Marwell]

+1 to what Romain said. Let's reduce dependencies to other orgs where
possible and feasible. It is, in this case.




On Fri, 30 Dec 2022, 10:27 Romain Manni-Bucau, 
wrote:

> Hi Hervé,
>
> As mentionned in the thread I think it makes sense to freeze plexus and
> slowly import to maven the related code so I'd be to import the parts we
> need (guess some abstraction can be dropped at the same time).
> So +1 to split, -0 to do it at plexus, +1 to do it in maven.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 30 déc. 2022 à 10:22, Hervé Boutemy  a
> écrit :
>
> > while working on the XML side of Maven 4 immutable API, we had the idea
> of
> > extracting the XML code from plexus-utils to a new separate plexus-xml
> > artifact
> > that could be done for version 4
> >
> > see https://github.com/codehaus-plexus/plexus-utils/issues/228
> >
> > any  objection?
> >
> > Regards,
> >
> > Hervé
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

TomEE maven build analyses: Why only "mvn install" works and what to do about it

[Benjamin Marwell]

Hello everyone!

Richard asked me a few days ago to take a look at the TomEE maven
build, as it takes up to a few hours to complete. One issue is the
jenkins setup, granted. But I have two findings.

1. shading

Because a few deps, e.g. Apache MQ RA Client, still do not provide
artifacts with the jakarta namespace, they created a module
"deps/activemq-ra-shaded", which does that. A few transformers later
they have a shaded dependency in the Jakarta namespace.

However:
This will mean that modules depending on that will only compile if the
artifact has undergone the packaging phase, as the m-shade-plugin will
operate on packaged artifacts only. Thus, `mvn compile` will fail due
to the required shaded/transformed artifact not existing yet.

Proposed remedy:
Do the required transformations in the compile phase.
Question: Is there already a plugin capable of this?
Possible drawbacks: Re-Packaging gets even more complicated, as the
existing transformers are not available, e.g. for META-INF services
and other resources.
Link: 
https://github.com/apache/tomee/blob/69fbe3d2e1bc8a268382d2c04ba901919afad3b4/deps/activemq-client-shade/pom.xml#L64-L95
And others.


2. Verification on installed artifact

The TomEE team wants to test the generated .zip archive. For the
tests, it needs to be unpacked multiple times per module. That means,
currently they get the installed artifact from the LOCAL repository
(yes, $HOME/.m2/repository) while in the verify phase of other
modules. This also means that `mvn verify` will not work. It also
means cluttering of the repo, complicated Path finding magic, etc.

Proposed remedy:
Modify / enhance the m-dependency-plugin to make specific artifacts
paths form the reactor available via a system property. Maybe one
chosen property per selected/configured artifact, maybe one global
property, colon-seperated for all of them. Or both. This will make
"mvn verify" work again since no previous copying to the local
repository is needed.

Question: Are there currently alternative strategies to find .zip
files from the reactor while ITs are running via the failsafe plugin?

Links:
a. Path finding:
https://github.com/apache/tomee/blob/69fbe3d2e1bc8a268382d2c04ba901919afad3b4/arquillian/ziplock/src/main/java/org/apache/ziplock/JarLocation.java
b. Custom mvn execution:
https://github.com/apache/tomee/blob/69fbe3d2e1bc8a268382d2c04ba901919afad3b4/arquillian/ziplock/src/main/java/org/apache/ziplock/maven/Mvn.java
c: Maven cache:
https://github.com/apache/tomee/blob/main/arquillian/arquillian-tomee-common/src/main/java/org/apache/openejb/arquillian/common/MavenCache.java
d: Tests: 
https://github.com/apache/tomee/blob/main/itests/microprofile-jwt-itests/src/test/java/org/apache/tomee/microprofile/jwt/itest/keys/http/HttpKeyInitializationHttp500Test.java
e: Tests 2: 
https://github.com/apache/tomee/blob/main/itests/failover/src/test/java/org/apache/openejb/itest/failover/RoundRobinConnectionStrategyTest.java


So, what do you think? In my opinion the setup could be "healed" from
not being able to execute compile, test-compile, test, verify by going
the proposed actions. But maybe there are other possibilities you
know. If so, I would be happy to hear them.

If modification of the mentioned plugins is necessary, I would be
willing to code them and cut a 3.x release of those plugins.

Slack channel: #tomee

Have a merry christmas time!
- Ben

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

Re: .well-known/security.txt at maven.apache.org

[Benjamin Marwell]

It is not a draft:
https://datatracker.ietf.org/doc/html/rfc9116

Source:
https://securitytxt.org

Yes, I know apache.org has their own page, and I would not add any
contradicting information. In fact, there's a policy field taking an
URL which should point to the apache.org policy
(https://www.apache.org/security/#reporting-a-vulnerability).

-Ben

Am So., 20. Nov. 2022 um 19:32 Uhr schrieb Romain Manni-Bucau
:
>
> Hi,
>
> AFAIK it is still a draft which can not go anywhere (or go elsewhere like
> .security/ for some exposure reason since .well-known already has adoption
> and rules) and I didn't see it much adopted yet. However at apache we have
> kind of standards for that so isn't it too early to adopt it?
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le dim. 20 nov. 2022 à 18:48, Benjamin Marwell  a
> écrit :
>
> > Hi!
> >
> > Due to the recent GH activities (eg [1]), it came to my attention that
> > there is no file ".well-known/security.txt" on maven.apache.org.
> >
> > We really should adopt it!
> > For some more information, please refer to [2].
> >
> > WDYT?
> >
> > - Ben
> >
> > [1]: https://github.com/apache/maven-project-utils/pull/5
> > [2]: https://developer.okta.com/blog/2021/10/19/intro-security-txt
> >
> > -
> > 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

.well-known/security.txt at maven.apache.org

[Benjamin Marwell]

Hi!

Due to the recent GH activities (eg [1]), it came to my attention that
there is no file ".well-known/security.txt" on maven.apache.org.

We really should adopt it!
For some more information, please refer to [2].

WDYT?

- Ben

[1]: https://github.com/apache/maven-project-utils/pull/5
[2]: https://developer.okta.com/blog/2021/10/19/intro-security-txt

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

Re: [DISCUSS] Quo Vadis Maven Site

[Benjamin Marwell]

Please do NOT consider jbake.
We (shiro team) ported the page to jbake, and it is really a mess.
Many things are not supported which can easily be done in other static
site generators.
There is absolutely no progress. No java.time support. JSON/YAML
support is broken and needs a lot of workarounds.

Look at the repo and build it yourself -- the amount of javadoc will
take very long to process.
https://github.com/apache/shiro-site


Am Mi., 16. Nov. 2022 um 13:21 Uhr schrieb Tamás Cservenák
:
>
> Howdy,
>
> I am pretty much sure your site could be pretty much "transported" to use
> jbake-maven-plugin instead of maven-site-plugin.
>
> I am aware of the long history of the Maven project, being here since 2006,
> but still...
> I don't think what I propose is "build a lamborghini instead of a ford
> pickup".
>
> I see it more like "let's replace the ford battery, but given how old it
> is, we have
> only aftermarket parts for it".
>
> Now that you have shown your site, let me try to de-site it, just as an
> experiment...
> as I never tried this before
>
> Will do it here
> https://github.com/cstamas/jaxen
>
> Thanks
> T
>
> On Wed, Nov 16, 2022 at 1:08 PM Elliotte Rusty Harold 
> wrote:
>
> > I like some parts of this. I don't agree with others. I agree that
> > maven site isn't competitive with other site builders, but that was
> > never really its purpose. I think it's OK for generating  a site for a
> > Maven project. I wouldn't expect it to be used for anything else. As a
> > maintainer of one such site  it
> > would be very inconvenient for me if this plugin disappeared or
> > changed in a major way.
> >
> > The old site design just works. We don't need so-called modern,
> > responsive sites. For our purposes — documenting code — the 20 year
> > old classic HTML we use is just fine. In fact, I'd say it's superior
> > to modern designs as implemented in practice.
> >
> > I do wish Maven hadn't gone its own way with NIH components like
> > Plexus, APT, and Doxia that are all essentially used today by maven
> > and no one else. However in fairness this all happened twenty years
> > ago when alternatives that have become de facto standards was not
> > obviously better or simply did not exist. We should modernize our
> > dependencies where possible, but I don't think a rewrite is worth the
> > effort and I would oppose anything that broke existing sites, links,
> > and workflows.
> >
> > When counting "wasted engineering hours spent on it", these are at
> > least a couple of orders of magnitude lower than would be spent on a
> > radical replacement of the sort being proposed. It's like proposing we
> > build a new Lamborghini to save the money we spend on oil changes for
> > our 2002 Ford pickup. Of course this is open source, so if anyone has
> > the time and money to spend  on an alternative site plugin that
> > scratches their itch, by all means they can do it. However this should
> > be a new plugin projects can adopt or not at a time that's convenient
> > for them. It should not replace the existing plugin so many projects
> > already use.
> >
> > On Wed, Nov 16, 2022 at 5:19 AM Tamás Cservenák 
> > wrote:
> > >
> > > Howdy,
> > >
> > > This is really just a brainstorming thread I'd like to spin, regarding
> > > Maven Site stuff.
> > >
> > > Again, the message is in wiki
> > > https://cwiki.apache.org/confluence/display/MAVEN/Quo+Vadis+Maven+Site
> > >
> > > But I would like to make discussion happen here on dev ML.
> > >
> > > Thanks
> > > T
> >
> >
> >
> > --
> > 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 does'nt find jar

[Benjamin Marwell]

Hi Raivo!

This is a better question for the users list.  The developer list is
for maven development.

But long story short:
javax.xml.bind got removed from Java 9+. So even if you are compiling
TO java 8 (e.g. using switches like maven.compiler.release or
maven.compiler.target), it will still not find these packages in the
Java 9+ JDK it is running.

Best advice is to add the missing dependencies. They do not hurt on
Java 8, but will be needed on Java 9 anyway.

Please find an in-depth answer here on SO: https://stackoverflow.com/a/52502208

HTH,
Ben

Am Mi., 9. Nov. 2022 um 15:52 Uhr schrieb Raivo Rebane :
>
> Hello
>
> I a novice user of maven and I would like to compile with maven OGC
> Validator, but I got error:
>
> [ERROR]
> /C:/Users/Raivo/teamengine/teamengine-realm/src/main/java/com/occamlab/te/realm/PasswordStorage.java:[17,22]
> package javax.xml.bind does not exist.
>
> But it really exist in jdk-8 and jre-8 lib directories.
>
> Where they must saved to be found by Maven Java compiler ?
>
> Regards
>
> Raivo
>
>
> -
> 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: Logging in Maven Plugins - Bridging

[Benjamin Marwell]

> Maven Plugin code should use Plugin Api for logging purpose
> In shared libraries used by Maven and maintained by us - we will use
SLF4J directly

I asked to be allowed to put this on the logging site, but we never had
consensus of this. I agree  here, but ut really needs to get documented.
I saw dozens of plugins switching from Maven's logging API to slf4j
directly - which is probably not what you wanted.

But at least we now have it written down. 
I hope everyone agrees on this.
If so, let's make it official by updating the documentation.

- Ben

On Fri, 4 Nov 2022, 18:42 Slawomir Jaranowski, 
wrote:

> Once again thanks for feedback.
>
> In order to finish discussion and not return to this topic again I will try
> to update documentation about logging in Maven plugins ... so I see the
> message, as Tamás wrote
>
> - Maven core and ecosystem uses SLF4J.
> - Maven Plugin code should use Plugin Api for logging purpose
> - In shared libraries used by Maven and maintained by us - we will use
> SLF4J directly
>
> One case which I would like to discuss was when plugins use something other
> than SLF4J, directly or by using an external library.
> To support proper logging we need forward events to SLF4J.
>
> So I see two ways:
> 1. support forwarding log event from another library to SLF4J by Maven core
> itself
>
> 2. let responsibility of log event forwarding will be on Plugin developers
>
> Personally I'm for the second option - it is not a common case, so
> developers can do it if really needed.
>
> Finally should be documented and will be clear,  discussion will be
> finished.
>
>
> pt., 4 lis 2022 o 15:08 Romain Manni-Bucau 
> napisał(a):
>
> > > perfectly valid solution (classloader)
> >
> > This is a workaround any plugin developer hates to be honest.
> > Guillaume started to make the plugin ClassRealm more customizable, this
> can
> > be an option but still, means we don't leak slf4j.
> > I fully agree the issue is how we expose it to plugins and extensions
> since
> > for the core codebase we don't care which solution we use but it just
> moves
> > the choice to the later stage and lead the same solution.
> >
> > In terms of biggest issue I guess it is the ones people face, logging is
> a
> > common one, not sure others you have in mind but this one and classloader
> > are the two biggest from what I saw, rest are enhancements and nice to
> have
> > from my window.
> >
> > My 2cts indeed
> >
> > Le ven. 4 nov. 2022 à 15:00, Tamás Cservenák  a
> > écrit :
> >
> > > So, you see problems in some plugins (again, what is the ratio we speak
> > > about?)
> > > using some frameworks, and then you tell the perfectly valid solution
> > > (classloader)...
> > >
> > > And regarding slf4j, should I reiterate what Ceki repeated several
> times?
> > >
> > > Sorry, but these are non-issues IMHO.
> > >
> > > Or to rephrase: we have bigger issues to work on, and helping complex
> > > plugin
> > > writers by removing from them one single burden (to use custom
> > classloader,
> > > if must)
> > > is really a small benefit, compared to man hours spent on whole topic
> > > already.
> > >
> > > My 5c.
> > >
> > > T
> > >
> > > On Fri, Nov 4, 2022 at 1:58 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > > wrote:
> > >
> > > > Le ven. 4 nov. 2022 à 13:17, Tamás Cservenák  a
> > > > écrit :
> > > >
> > > > > Howdy,
> > > > >
> > > > > Will we keep asking the same questions over and over again? Until
> we
> > > get
> > > > > the "wanted" answer?
> > > > >
> > > > > Maven core and ecosystem uses SLF4J API. Full stop.
> > > > >
> > > > > Just use SLF4J API, and you will get a pre-configured back-end as
> > well.
> > > > > Done.
> > > > >
> > > > > Now,. this story keeps popping up: "plugin developers using
> > > > framework"
> > > > > begs the question:
> > > > > what framework are we talking about? And how common is this story?
> > What
> > > > > percentage of Maven
> > > > > plugins USE a "framework"?
> > > > >
> > > >
> > > > All plugins with a dependency on slf4j are concerned and best ones
> use
> > > > workarounds (custom classloader instead of mojo one) others can be
> > broken
> > > > by default (exec:java maven plugin needed a dedicated config for that
> > > case
> > > > for ex).
> > > > To cite a few: tomee, spark, cxf, camel, openapi/swagger ones, plus
> all
> > > the
> > > > ones invovling user code with slf4j (most end *apps* included - you
> > like
> > > it
> > > > or not like me ;)).
> > > >
> > > > Indeed the mojo copying a file will not be impacted but it is quite
> > rare
> > > > these days to not have a build with at least one of these plugins.
> > > > We also have the big issue we reported years ago that we leak slf4j
> for
> > > > mojo (maven-core/extensions.xml) so we enforce the slf4j version, API
> > and
> > > > public API whereas we have mojo designed to do what they need to do
> the
> > > way
> > > > they want.
> > > > Exactly like we dropped cdi-api because it was breaking more than

Re: [DISCUSS] Automatically format and sort imports

[Benjamin Marwell]

+1, BUT in addition to Hervé's answer:

Create a file '.git-blame-ignore-revs', which seems to be a common convention:
https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame

This way, we can see CODE changes via diff/blame without those nasty
formatting changes.

---

For the formatting, I can really recommend the spotless-maven-plugin
in combination with the eclipse formatter, which can be fine-tuned in
a very nice manner.
It also supports "ratchetFrom" configuration, i.e. only blame changes
from the current commit.

Checkstyle configuration can then be minimized to things like improper
imports, header checks, N° of return statements etc.
which are not handled by spotless.


Am So., 16. Okt. 2022 um 10:23 Uhr schrieb Hervé Boutemy
:
>
> only one concern: clarify our convention for the initial reformat of any Git
> repository so that it works with git blame --ignore-revs
> (I hope current tools support for this feature is good enough nowadays)
>
> Regards,
>
> Hervé
>
> Le vendredi 14 octobre 2022, 10:41:30 CEST Guillaume Nodet a écrit :
> > So here's my new proposal.
> >
> > I've already merged the two first PRs which did not change anything, as
> > they were just about moving the existing resources (eclipse and intellij
> > xml config) from the website to maven-shared and updating the website.
> >
> > I've updated the two interesting PRs to use spotless, relying on the
> > existing format config now available from maven-shared-resources. The
> > relevant commits can be seen at [1] for maven-core and [2] for
> > maven-resolver.   They add two profiles, the first one will check the
> > source formatting, while the second will reformat the sources.  By default,
> > the first one (check) is activated, and if you pass -Dformat or -Pformat to
> > the command line, the second profile (format) is activated and used
> > instead.  In the same commit, I've deactivated a few checkstyle checks
> > which are enforced by spotless, so the remaining checks are not about code
> > formatting, but rather method/file length, naming, etc...
> > They are followed by big reformat commits to restore all files to the
> > enforced coding style.  The related PRs are [3] and [4].
> >
> > I think this alleviates the concerns that were raised, so if there's no
> > objection, I plan to slowly move all projects to use that.  Or even better,
> > release a new maven parent with the needed changes and simply upgrade the
> > projects.  However, the change would be done after the discussion on
> > changing the coding style has settled so that both things would be done at
> > the same time.
> >
> > Any concerns ?
> >
> > Guillaume
> >
> > [1]
> > https://github.com/apache/maven/pull/824/commits/f1aa72b1dd0fc934417e7f1ca80
> > 027de0fc0d036 [2]
> > https://github.com/apache/maven-resolver/pull/147/commits/4ae0de301fcf2d9f85
> > 09a9a6564c840aa0815258 [3] https://github.com/apache/maven/pull/824
> > [4] https://github.com/apache/maven-resolver/pull/147
> >
> > Le mer. 12 oct. 2022 à 18:23, Guillaume Nodet  a écrit :
> > > I'd like to propose merging the following PRs:
> > >  * https://github.com/apache/maven-shared-resources/pull/1
> > >  * https://github.com/apache/maven-site/pull/329
> > >  * https://github.com/apache/maven/pull/824
> > >  * https://github.com/apache/maven-resolver/pull/147
> > >
> > > ... and more to come
> > >
> > > The idea is to use plugins to automatically reformat the source code and
> > > sort imports to obey the maven coding style.
> > > The first PR adds the necessary resources to maven-shared-resources : a
> > > new header file, as there's a requirement to put the header at the very
> > > beginning for the import sorter plugin to work correctly (else it
> > > considers
> > > the license comment to be part of comment headers and screws the
> > > formatting), and the eclipse xml formatter plugin.
> > > The second PR updates the web site to point to that file which would be in
> > > git instead of on the maven web site, and also updates the instruction for
> > > IDEA since it has been supporting the eclipse xml config for years now).
> > > The third and fourth PRs are updates on maven and maven-resolver to apply
> > > those two plugins.
> > >
> > > Those plugins have been used on mvnd and maven-build-cache-extension
> > > already, although they are not using a single shared resource that would
> > > be
> > > added by the first PR.  Hence mvnd is still using its previous coding
> > > style.
> > >
> > > Another point is that those plugins are fast and only do not process files
> > > if they have been already processed and untouched since the last build.
> > > So
> > > from a daily development pov, this is transparent and does not incur any
> > > additional processing time during the build (or not much really).
> > >
> > > Cheers,
> > > Guillaume
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional 

Re: [DISCUSS] Release Maven 4.0.0-alpha-1 this week

[Benjamin Marwell]

Unpopular opinion:
Deactivate automatic push. If release:perform went well, push main and the tags.

Besides, push --delete works for tags, too (if PMC agrees).
I doubt there are already forks from the tag active anywhere.
But yes, bumping the version is what we used to do in this case.

- Ben


Am Sa., 15. Okt. 2022 um 00:31 Uhr schrieb Guillaume Nodet :
>
> The release:prepare has succeeded but the release:perform failed.
> Hence, the tag has been created on github and can't be deleted.
>
> Le sam. 15 oct. 2022 à 00:26, Gary Gregory  a
> écrit :
>
> > Why are you bumping the version if it failed?
> >
> > Gary
> >
> > On Fri, Oct 14, 2022, 18:13 Guillaume Nodet  wrote:
> >
> > > Just FYI, I've attempted to release 4.0.0-alpha-1, but it failed.  I'll
> > try
> > > to cut another version once the problems are resolved.  So 4.0.0-alpha-1
> > is
> > > a burnt version and next attempt will be 4.0.0-alpha-2.  Stay tuned !
> > >
> > > Le lun. 10 oct. 2022 à 22:32, Guillaume Nodet  a
> > écrit
> > > :
> > >
> > > > The master branch contains a lot of things and has not been released
> > for
> > > a
> > > > long time. With the new addition of the v4 api, I think it would be
> > good
> > > to
> > > > get something out of the door to gather some feedback from users and
> > also
> > > > allow migrating some components and plugins to the new API.
> > > >
> > > > So unless there's an objection, I'd like to start a release process
> > later
> > > > this week after [1] and [2] are merged.
> > > >
> > > > Thoughts ?
> > > >
> > > > Cheers,
> > > > Guillaume Nodet
> > > >
> > > > [1] https://github.com/apache/maven/pull/806
> > > > [2] https://github.com/apache/maven/pull/819
> > > >
> > > >
> > >
> > > --
> > > 
> > > Guillaume Nodet
> > >
> >
>
>
> --
> 
> Guillaume Nodet

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

Re: Surefire 3.0.0-M7 has different modular behavior when compiler's --source flag is set to certain values

[Benjamin Marwell]

After discussing this with the maven team on slack, it does not really
sound like you should have encountered.
Can you give us a small reproducer project and/or post the
exceptions/errors you see?

Am Fr., 2. Sept. 2022 um 14:15 Uhr schrieb Laird Nelson :
>
> Sure; I'm using --add-exports
> jdk.compiler/com.sun.tools.javac.code=com.foo.mymodule and my module reads
> jdk.compiler.  All of that is incompatible with --release.
>
> Best,
> Laird
>
> On Thu, Sep 1, 2022 at 11:47 PM Benjamin Marwell 
> wrote:
>
> > Can you give us a hint why you are using source and target instead of
> > the release parameter?
> >
> > Am Fr., 2. Sept. 2022 um 01:10 Uhr schrieb Laird Nelson <
> > ljnel...@gmail.com>:
> > >
> > > The problem was difficult to uncover due to the swallowed exception at
> > >
> > https://github.com/apache/maven-surefire/blob/surefire-3.0.0-M7/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1425-L1428
> > > .
> > >
> > > On Thu, Sep 1, 2022 at 4:05 PM Laird Nelson  wrote:
> > >
> > > > The problem appears to be plexus-java 1.1.1's dependency on ASM 9.2.
> > > > Adding a dependency on ASM 9.3 in my maven-surefire-plugin
> > configuration
> > > > fixed the problem.
> > > >
> > > >
> > > >
> > > > On Thu, Sep 1, 2022 at 12:54 PM Laird Nelson 
> > wrote:
> > > >
> > > >> (That's the best subject line I could come up with.)
> > > >>
> > > >> I'm using maven-surefire-plugin 3.0.0-M7.
> > > >>
> > > >> I have a modular project (JPMS) with a module-info.java at
> > src/main/java.
> > > >> My module name is com.foo.mymodule.
> > > >>
> > > >> I have specified --source=18 and --target=18 to the compiler.  The
> > > >> compiler is JDK 19 (early access).  I am not using toolchains.
> > > >>
> > > >> My test package (com.foo.mymodule.somepackage) is the same as my main
> > > >> package.
> > > >>
> > > >> In my surefire configuration I have
> > > >> --add-opens=com.foo.mymodule/com.foo.mymodule.somepackage=ALL-UNNAMED.
> > > >>
> > > >> When I run this it all works fine.
> > > >>
> > > >> HOWEVER: when I change --source and --target to 19, and make no other
> > > >> changes, surefire no longer considers my project to be modular, and
> > also
> > > >> does not generate an args file.  For example, I can see my
> > target/classes
> > > >> directory showing up on the classpath instead of the module path, and
> > I no
> > > >> longer see [DEBUG] Path to args file: in my debug output.
> > > >>
> > > >> I've excerpted some debug output and put each Surefire-reported boot
> > > >> classpath entry on its own line for clarity:
> > > >>
> > > >> With --source=18 everything looks good (note: no target/classes), and
> > an
> > > >> args file is produced:
> > > >>
> > > >> [DEBUG] boot classpath:
> > > >>
> > > >>
> > /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M7/surefire-booter-3.0.0-M7.jar
> > > >>
> > > >>
> > /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-M7/surefire-api-3.0.0-M7.jar
> > > >>
> > > >>
> > /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.0.0-M7/surefire-logger-api-3.0.0-M7.jar
> > > >>
> > > >>
> > /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-shared-utils/3.0.0-M7/surefire-shared-utils-3.0.0-M7.jar
> > > >>
> > > >>
> > /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-extensions-spi/3.0.0-M7/surefire-extensions-spi-3.0.0-M7.jar
> > > >>
> > > >>
> > /Users/lairdnelson/Projects/github/ljnelson/forks/foo/foo-bar/target/test-classes
> > > >>
> > > >>
> > /Users/lairdnelson/.m2/repository/org/hamcrest/hamcrest/2.2/hamcrest-2.2.jar
> > > >>
> > > >>
> > /Users/lairdnelson/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.9.0/junit-jupiter-api-5.9.0.jar
> > > >>
> > > >>
> > /Users/lairdnelson/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
> > &g

Re: Surefire 3.0.0-M7 has different modular behavior when compiler's --source flag is set to certain values

[Benjamin Marwell]

Can you give us a hint why you are using source and target instead of
the release parameter?

Am Fr., 2. Sept. 2022 um 01:10 Uhr schrieb Laird Nelson :
>
> The problem was difficult to uncover due to the swallowed exception at
> https://github.com/apache/maven-surefire/blob/surefire-3.0.0-M7/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1425-L1428
> .
>
> On Thu, Sep 1, 2022 at 4:05 PM Laird Nelson  wrote:
>
> > The problem appears to be plexus-java 1.1.1's dependency on ASM 9.2.
> > Adding a dependency on ASM 9.3 in my maven-surefire-plugin configuration
> > fixed the problem.
> >
> >
> >
> > On Thu, Sep 1, 2022 at 12:54 PM Laird Nelson  wrote:
> >
> >> (That's the best subject line I could come up with.)
> >>
> >> I'm using maven-surefire-plugin 3.0.0-M7.
> >>
> >> I have a modular project (JPMS) with a module-info.java at src/main/java.
> >> My module name is com.foo.mymodule.
> >>
> >> I have specified --source=18 and --target=18 to the compiler.  The
> >> compiler is JDK 19 (early access).  I am not using toolchains.
> >>
> >> My test package (com.foo.mymodule.somepackage) is the same as my main
> >> package.
> >>
> >> In my surefire configuration I have
> >> --add-opens=com.foo.mymodule/com.foo.mymodule.somepackage=ALL-UNNAMED.
> >>
> >> When I run this it all works fine.
> >>
> >> HOWEVER: when I change --source and --target to 19, and make no other
> >> changes, surefire no longer considers my project to be modular, and also
> >> does not generate an args file.  For example, I can see my target/classes
> >> directory showing up on the classpath instead of the module path, and I no
> >> longer see [DEBUG] Path to args file: in my debug output.
> >>
> >> I've excerpted some debug output and put each Surefire-reported boot
> >> classpath entry on its own line for clarity:
> >>
> >> With --source=18 everything looks good (note: no target/classes), and an
> >> args file is produced:
> >>
> >> [DEBUG] boot classpath:
> >>
> >> /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M7/surefire-booter-3.0.0-M7.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-M7/surefire-api-3.0.0-M7.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.0.0-M7/surefire-logger-api-3.0.0-M7.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-shared-utils/3.0.0-M7/surefire-shared-utils-3.0.0-M7.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-extensions-spi/3.0.0-M7/surefire-extensions-spi-3.0.0-M7.jar
> >>
> >> /Users/lairdnelson/Projects/github/ljnelson/forks/foo/foo-bar/target/test-classes
> >>
> >> /Users/lairdnelson/.m2/repository/org/hamcrest/hamcrest/2.2/hamcrest-2.2.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/junit/jupiter/junit-jupiter-api/5.9.0/junit-jupiter-api-5.9.0.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/opentest4j/opentest4j/1.2.0/opentest4j-1.2.0.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/junit/platform/junit-platform-commons/1.9.0/junit-platform-commons-1.9.0.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/apiguardian/apiguardian-api/1.1.2/apiguardian-api-1.1.2.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/junit/jupiter/junit-jupiter-engine/5.9.0/junit-jupiter-engine-5.9.0.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/junit/platform/junit-platform-engine/1.9.0/junit-platform-engine-1.9.0.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-junit-platform/3.0.0-M7/surefire-junit-platform-3.0.0-M7.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/common-java5/3.0.0-M7/common-java5-3.0.0-M7.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/junit/platform/junit-platform-launcher/1.9.0/junit-platform-launcher-1.9.0.jar
> >> [...]
> >> [DEBUG] Path to args file:
> >> /Users/lairdnelson/Projects/github/ljnelson/forks/foo/foo-bar/target/surefire/surefireargs-20220901122239246_3
> >>
> >> However, with --source=19 my project is no longer considered modular
> >> (note target/classes and a modular jar dependency both showing up on the
> >> classpath below) and no args file is produced:
> >>
> >> [DEBUG] boot classpath:
> >>
> >> /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M7/surefire-booter-3.0.0-M7.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-M7/surefire-api-3.0.0-M7.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-logger-api/3.0.0-M7/surefire-logger-api-3.0.0-M7.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-shared-utils/3.0.0-M7/surefire-shared-utils-3.0.0-M7.jar
> >>
> >> /Users/lairdnelson/.m2/repository/org/apache/maven/surefire/surefire-extensions-spi/3.0.0-M7/surefire-extensions-spi-3.0.0-M7.jar
> >>
> >> 

Re: JUnit 5 in maven-plugin-testing-harness

[Benjamin Marwell]

Haven't seen a discussion in Slack or on the mailing list, so I guess no.

But I like the idea. Be aware that there are still Junit3 tests iirc.
Updating would be a breaking change, but that's okay for the upcoming Maven
4 release.







On Fri, 12 Aug 2022, 01:37 Vladimir V. Bychkov,  wrote:

> Hello everyone.
>
> Maven-plugin maven-plugin-testing-harness
> 
> still uses JUnit 4
> 
> . Are where plans upgrade it to JUnit 5 ?
>
> With regards,
> Vladimir V. Bychkov
>
>
>

Re: Suggestion for soft-breaking Maven Plugin 4.0 changes

[Benjamin Marwell]

Let's not forget checksum validation by default. I think it's already
planned, but just wanted to mention it.




On Fri, 22 Jul 2022, 07:55 Olivier Lamy,  wrote:

> On Fri, 22 Jul 2022 at 05:59, Guillaume Nodet  wrote:
>
> > I would propose to add the -e flag by default and also the
> >
>
> +1
>
>
> > -DtrimStackTrace=false.
> >
>
> surefire has been changed in 3.0.0-M6 with this default value ;)
>
>
> >
> > Le jeu. 21 juil. 2022 à 20:24, Benjamin Marwell  a
> > écrit :
> >
> > > Hi everyone,
> > >
> > > as discussed in Slack, here are a few ideas for Maven 4.0 Plugin
> > > default's changes.
> > > Rationale: Convention over configuration, but things have diverged
> > > from when Maven 3 was started.
> > >
> > > * Set the default Java Source file encoding to UTF-8.
> > > This seems to receive a broad agreement. Not only is UTF-8 default on
> > > most platforms nowadays (UTF-16 on Windows), it also aligns with Java
> > > 18+, most user configurations and getting rid of the annoying warning
> > > "is platform dependent". Plus, it is 100% compatible with ASCII and
> > > mostly compatible with other encodings.
> > >
> > > * Setting the default javadoc-plugin verbosity to quiet via
> "quiet=true".
> > > [1]
> > > This was the default before Java 1.4.2 anyway, and it will only make
> > > the list of generated html sites disappear.
> > >
> > > * Setting failOnMissingWebXml to "false" by default. Romain suggested
> > > this was planned for the next major release, but I was not able to
> > > find an issue about this.
> > >
> > > There seems to have been some jira tickets about this, all set to
> > > resolved+fixed, but I cannot see the actual implementation which made
> > > it into the plugin. [2], [3]. Setting the default to "false" based on
> > > the existence of annotations or a dependency might still be a valid
> > > idea, but this got vastly more complicated, no question. So just
> > > setting it to "false" might do it, but it will break builds which do
> > > not use annotations. There are good reasons for this, e.g. using a
> > > particular startup order for listeners.
> > >
> > > That said, I am not sure about the last one unless we can identify
> > > *for sure* there are *some* kind servlets/listeners etc. present in
> > > the .war file. My -0.5 on this one unless someone can come up with a
> > > neat solution.
> > >
> > > So, what do you think? Are there more sane defaults we should set for
> > > Maven 4.0?
> > >
> > > - Ben
> > >
> > >
> > > [1]:
> > >
> >
> https://maven.apache.org/plugins/maven-javadoc-plugin/test-jar-mojo.html#quiet
> > > [2]: https://issues.apache.org/jira/browse/MWAR-396
> > > [3]: https://issues.apache.org/jira/browse/MWAR-262
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> > --
> > 
> > Guillaume Nodet
> >
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Benjamin Marwell]

No, 2 JDKs are not required by default. Only if you use --release={<17} and
don't trust running tests on 17 are the same as running tests on 8.
Yes, there are changes (certificates, XML libs, rhino, etc).

So, for most projects that's probably not needed. For those who think it is
needed, I don't have a lot of pity. But it will be a requirement for quite
a few commercial projects, like Containers (JavaEE, as they will need to be
Java 8 as long as 2030ish due to extended support contracts).

That said, I'm still thinking Java 17 will be a sane default.


On Sat, 23 Jul 2022, 10:50 Delany,  wrote:

> Using mvnd with toolchains doesn't improve the situation, in fact
> toolchains seem to invalidate any benefit of using mvnd.
> Even if this was resolved, is it fair to require mvnd?
> Delany
>
>
> On Sat, 23 Jul 2022 at 10:17, Mark Derricutt  wrote:
>
> >  Is that due to cold starting the JVM each time?
> >
> > I wonder if mvnd supports toolchains effectively?  Or if that could be an
> > avenue to try.
> > --
> > "Great artists are extremely selfish and arrogant things" — Steven
> Wilson,
> > Porcupine Tree
> >
> > On 23/07/2022 at 8:13:23 PM, Delany  wrote:
> >
> > > I tried toolchains but dropped it because of the exorbitant performance
> > > costs.
> > > A multi-module build that normally built in 3:50 took 10:34, and that's
> > > with toolchaining only maven-compiler-plugin.
> > >
> > >
> > >
> >
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Benjamin Marwell]

KH just released a video on toolchains.
It's much easier than I remembered.

I'm changing my vote to 17. I don't see a reason to use 11 which will be
out of support soon. It's really just two properties used three times.

https://github.com/khmarbaise/youtube-videos/blob/main/episode-toolchains/pom.xml

https://youtu.be/-KbDcJcglPc

Thanks Karl Heinz for sorting this out.
We should really promote toolchains.

+1 for 17.

  - Ben

On Fri, 22 Jul 2022, 21:33 Arnaud Héritier,  wrote:

> I would say java 11 for maven 4 and 17 for maven 5 with the hope that it
> won’t be here in many years
>
> Le jeu. 21 juil. 2022 à 18:53, Benjamin Marwell  a
> écrit :
>
> > I was going to answer: go for 17.
> >
> > But running the tests on the same language level is really a good
> argument.
> > So much changed: HttpClient, TLS and cipher suites, DNS resolution
> > (starting with Java 18 it will be pluggable!) etc.
> >
> > Yes, in theory it should not fail. But this is (sadly) a strong argument
> > against using Java 11+.
> >
> > If it's just for language features, we could also use kotlin, groovy or
> > just a library like javaslang (now vavr.io) to receive some amount of
> what
> > you would like to see. Groovy is even an Apache project and kotlin has
> > excellent support. Both can mimic sealed classes, have advanced features
> > like traits etc.
> >
> > Not saying I'm a big fan of this myself, but it *might* be an option to
> > think about.
> >
> > Of course we could scare devs away or attract them. Who knows.
> >
> > So, I deeply regret it, but I'd say go for 8 and make an early Maven 5
> > release with Java 17, then make all the major changes (new pom etc) in
> > Maven 6 instead of Maven 5.
> >
> >
> > On Wed, 20 Jul 2022, 17:08 Jorge Solórzano,  wrote:
> >
> > > 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 <https://twitter.com/rmannibucau> |  Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > > >
> > > >
> > > > Le mer. 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
> > >
> > >
> >
> --
> Arnaud Héritier
> Twitter/GitHub/... : aheritier
>

Suggestion for soft-breaking Maven Plugin 4.0 changes

[Benjamin Marwell]

Hi everyone,

as discussed in Slack, here are a few ideas for Maven 4.0 Plugin
default's changes.
Rationale: Convention over configuration, but things have diverged
from when Maven 3 was started.

* Set the default Java Source file encoding to UTF-8.
This seems to receive a broad agreement. Not only is UTF-8 default on
most platforms nowadays (UTF-16 on Windows), it also aligns with Java
18+, most user configurations and getting rid of the annoying warning
"is platform dependent". Plus, it is 100% compatible with ASCII and
mostly compatible with other encodings.

* Setting the default javadoc-plugin verbosity to quiet via "quiet=true". [1]
This was the default before Java 1.4.2 anyway, and it will only make
the list of generated html sites disappear.

* Setting failOnMissingWebXml to "false" by default. Romain suggested
this was planned for the next major release, but I was not able to
find an issue about this.

There seems to have been some jira tickets about this, all set to
resolved+fixed, but I cannot see the actual implementation which made
it into the plugin. [2], [3]. Setting the default to "false" based on
the existence of annotations or a dependency might still be a valid
idea, but this got vastly more complicated, no question. So just
setting it to "false" might do it, but it will break builds which do
not use annotations. There are good reasons for this, e.g. using a
particular startup order for listeners.

That said, I am not sure about the last one unless we can identify
*for sure* there are *some* kind servlets/listeners etc. present in
the .war file. My -0.5 on this one unless someone can come up with a
neat solution.

So, what do you think? Are there more sane defaults we should set for
Maven 4.0?

- Ben


[1]: 
https://maven.apache.org/plugins/maven-javadoc-plugin/test-jar-mojo.html#quiet
[2]: https://issues.apache.org/jira/browse/MWAR-396
[3]: https://issues.apache.org/jira/browse/MWAR-262

-
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

[Benjamin Marwell]

I was going to answer: go for 17.

But running the tests on the same language level is really a good argument.
So much changed: HttpClient, TLS and cipher suites, DNS resolution
(starting with Java 18 it will be pluggable!) etc.

Yes, in theory it should not fail. But this is (sadly) a strong argument
against using Java 11+.

If it's just for language features, we could also use kotlin, groovy or
just a library like javaslang (now vavr.io) to receive some amount of what
you would like to see. Groovy is even an Apache project and kotlin has
excellent support. Both can mimic sealed classes, have advanced features
like traits etc.

Not saying I'm a big fan of this myself, but it *might* be an option to
think about.

Of course we could scare devs away or attract them. Who knows.

So, I deeply regret it, but I'd say go for 8 and make an early Maven 5
release with Java 17, then make all the major changes (new pom etc) in
Maven 6 instead of Maven 5.


On Wed, 20 Jul 2022, 17:08 Jorge Solórzano,  wrote:

> 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 <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > 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: MojoExecutionException and MojoFailureException

[Benjamin Marwell]

Here you go.

https://issues.apache.org/jira/browse/MSHARED-1032




On Mon, 11 Jul 2022, 20:21 Benjamin Marwell,  wrote:

>
> Please note there are more exceptions, e.g. in reporting. That's always
> been a problem. Not sure, but I must have opened an issue for this
> somewhere.
>
> Just for the sake of completeness.
>
>
> On Mon, 11 Jul 2022, 14:12 Guillaume Nodet,  wrote:
>
>> Yes, that's why I only kept a single exception in the new API.
>>
>> Le lun. 11 juil. 2022 à 13:59, Romain Manni-Bucau 
>> a
>> écrit :
>>
>> > It got aligned AFAIK ->
>> >
>> >
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L382
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> > <https://rmannibucau.metawerx.net/> | Old Blog
>> > <http://rmannibucau.wordpress.com> | Github <
>> > https://github.com/rmannibucau> |
>> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > <
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > >
>> >
>> >
>> > Le lun. 11 juil. 2022 à 13:47, Christoph Läubrich 
>> a
>> > écrit :
>> >
>> > > I might be wrong, but in case of "build FAILURE" only a short error is
>> > > printed saying user should enable -X while with "BUILD ERROR" the
>> > > exception is printed, maybe with a hint not to blame maven :-)
>> > >
>> > > Am 11.07.22 um 13:43 schrieb Romain Manni-Bucau:
>> > > > Hi,
>> > > >
>> > > > In all discussions about this topic it seems that this distinctions
>> > never
>> > > > had been useful so there seems to be an agreement to get a single
>> > > exception
>> > > > "something went wrong in the mojo".
>> > > > Guess at the end being finer grain is not that useful for end user
>> and
>> > > > makes writing mojo harder but I agree it can be neat to wrap the
>> error
>> > > in a
>> > > > MavenMojoRuntimeException (mojo writer shouldn't instantiate) and
>> add
>> > the
>> > > > source of the error...but at the end for end user it is the same, it
>> > > failed
>> > > > so he must read why and fix it so not sure it is worth the effort.
>> > > >
>> > > > Romain Manni-Bucau
>> > > > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> > > > <https://rmannibucau.metawerx.net/> | Old Blog
>> > > > <http://rmannibucau.wordpress.com> | Github <
>> > > https://github.com/rmannibucau> |
>> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>> > > > <
>> > >
>> >
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>> > > >
>> > > >
>> > > >
>> > > > Le lun. 11 juil. 2022 à 12:38, Tamás Cservenák 
>> a
>> > > > écrit :
>> > > >
>> > > >> Howdy,
>> > > >> and along this line...
>> > > >>
>> > > >> BUILD FAILURE - uncompilable source, test failed, badly configured
>> > > plugin,
>> > > >> missing something from build, etc. all the issues that user CAN
>> (and
>> > > >> should) fix to have build pass, usually by editing sources, POM or
>> > > >> settings.
>> > > >>
>> > > >> BUILD ERROR - disk full, no perm to write to disk (ie. during
>> > resolve),
>> > > >> remote repo unreachable (during resolve), etc. issues  user MAY fix
>> > (ie.
>> > > >> wrong URL in POM) but also MAY NOT fix (ie. corp repoman down)
>> > > >>
>> > > >> T
>> > > >>
>> > > >> On Mon, Jul 11, 2022 at 12:32 PM Tamás Cservenák <
>> ta...@cservenak.net
>> > >
>> > > >> wrote:
>> > > >>
>> > > >>> Howdy,
>> > > >>>
>> > > >>> AFAIR one of the reasons for these two exceptions were to
>> distinguish
>> > > >>> cases like:
>> > > >>> * expected exception during execution of Mojo

Re: MojoExecutionException and MojoFailureException

[Benjamin Marwell]

Please note there are more exceptions, e.g. in reporting. That's always
been a problem. Not sure, but I must have opened an issue for this
somewhere.

Just for the sake of completeness.


On Mon, 11 Jul 2022, 14:12 Guillaume Nodet,  wrote:

> Yes, that's why I only kept a single exception in the new API.
>
> Le lun. 11 juil. 2022 à 13:59, Romain Manni-Bucau 
> a
> écrit :
>
> > It got aligned AFAIK ->
> >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L382
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 11 juil. 2022 à 13:47, Christoph Läubrich 
> a
> > écrit :
> >
> > > I might be wrong, but in case of "build FAILURE" only a short error is
> > > printed saying user should enable -X while with "BUILD ERROR" the
> > > exception is printed, maybe with a hint not to blame maven :-)
> > >
> > > Am 11.07.22 um 13:43 schrieb Romain Manni-Bucau:
> > > > Hi,
> > > >
> > > > In all discussions about this topic it seems that this distinctions
> > never
> > > > had been useful so there seems to be an agreement to get a single
> > > exception
> > > > "something went wrong in the mojo".
> > > > Guess at the end being finer grain is not that useful for end user
> and
> > > > makes writing mojo harder but I agree it can be neat to wrap the
> error
> > > in a
> > > > MavenMojoRuntimeException (mojo writer shouldn't instantiate) and add
> > the
> > > > source of the error...but at the end for end user it is the same, it
> > > failed
> > > > so he must read why and fix it so not sure it is worth the effort.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Blog
> > > >  | Github <
> > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Book
> > > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > > >
> > > >
> > > > Le lun. 11 juil. 2022 à 12:38, Tamás Cservenák 
> a
> > > > écrit :
> > > >
> > > >> Howdy,
> > > >> and along this line...
> > > >>
> > > >> BUILD FAILURE - uncompilable source, test failed, badly configured
> > > plugin,
> > > >> missing something from build, etc. all the issues that user CAN (and
> > > >> should) fix to have build pass, usually by editing sources, POM or
> > > >> settings.
> > > >>
> > > >> BUILD ERROR - disk full, no perm to write to disk (ie. during
> > resolve),
> > > >> remote repo unreachable (during resolve), etc. issues  user MAY fix
> > (ie.
> > > >> wrong URL in POM) but also MAY NOT fix (ie. corp repoman down)
> > > >>
> > > >> T
> > > >>
> > > >> On Mon, Jul 11, 2022 at 12:32 PM Tamás Cservenák <
> ta...@cservenak.net
> > >
> > > >> wrote:
> > > >>
> > > >>> Howdy,
> > > >>>
> > > >>> AFAIR one of the reasons for these two exceptions were to
> distinguish
> > > >>> cases like:
> > > >>> * expected exception during execution of Mojo: most typical,
> > > uncompilable
> > > >>> source, or bad config/param, or something alike, condition the user
> > CAN
> > > >>> (and should) fix, usually by editing sources, POM or settings.
> > > >>> * unexpected exception during execution of Mojo: IO/permission,
> disk
> > > >> full,
> > > >>> network, whatever -- this condition user MAY fix or may not be able
> > to
> > > >> fix
> > > >>> (ie. some remote resource is down)
> > > >>>
> > > >>> Re Guillaume proposal: IMHO it lacks this distinction above
> > > >>>
> > > >>> T
> > > >>>
> > > >>>
> > > >>> On Sat, Jul 9, 2022 at 9:56 PM Guillaume Nodet 
> > > >> wrote:
> > > >>>
> > >  I have the following proposal for the new API:
> > > 
> > > 
> > > 
> > > >>
> > >
> >
> https://github.com/gnodet/maven/tree/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/plugin
> > > 
> > >  Le sam. 9 juil. 2022 à 15:23, Slawomir Jaranowski <
> > > >> s.jaranow...@gmail.com
> > > >
> > >  a écrit :
> > > 
> > > > Hi
> > > >
> > > > Today - Maven 3.8.6 both exception generate the same message:
> BUILD
> > >  FAILURE
> > > >
> > > > We have some inconsistencies in javadocs descriptions [1].
> > > > We also have the wrong description on guide page [2].
> > > >
> > > > There was a discussion about it, some on slack, some on GitHub
> [3]
> > > and
> > > > connected issue MNG-7351 [4]
> > > >
> > > > As I remember we want one exception for Mojo in Maven 4.
> > > >
> > > > So it will be good to make a decision about it and fix mentioned
> > > place
> > > 

Re: Social Media Plug-ins - Apache Maven pages

[Benjamin Marwell]

You can use this solution.

https://github.com/heiseonline/shariff

The PHP part is not needed, only if you want to display share count.
It's widely known in Germany due to the c't magazine, but not much
maintained anymore. Same applies to the forks.
However, works like a charm.

WDYT?


On Sat, 11 Jun 2022, 12:33 Michael Osipov,  wrote:

> Am 2022-06-11 um 12:23 schrieb Slawomir Jaranowski:
> > Hi,
> >
> > Apache Maven documentation pages contains social media references like:
> > Twitter follow button and Google search box.
> >
> > According to Data Policy [1] such external resources must be loaded only
> on
> > user request, as in issue [2]
> >
> > Currently I don't know how to implement this requirement, so I will
> remove
> > it from Maven pages.
> >
> > If someone finds a way to be compatible with ASF Data Policy we can add
> it
> > later.
> >
> > [1] https://privacy.apache.org/policies/privacy-policy-public.html
> > [2] https://issues.apache.org/jira/browse/MSKINS-192
> >
>
>
> LONG overdue! I have reported this years ago:
> https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-383
>
> There was an issue to solve this:
> https://issues.apache.org/jira/browse/MSKINS-112.
>
> Honestly, don't waste your time. Just drop them and move on.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [ANN] Apache Maven Wrapper 3.1.1 Released

[Benjamin Marwell]

Thanks everyone involved, and thank you to Brian Demers for starting this
project in the first place!




On Sat, 14 May 2022, 16:07 Hervé Boutemy,  wrote:

> The Apache Maven team is pleased to announce the release of the Apache
> Maven
> Wrapper, version 3.1.1.
>
> The Maven Wrapper is an easy way to ensure a user of your Maven build has
> everything necessary to run your Maven build.
>
> This is the first release of this project in its Apache Maven new home: it
> was
> previously maintained by community at
> https://github.com/takari/maven-wrapper
> and was kindly donated to the Maven team. Thank you to all people who
> permitted this.
>
> See https://maven.apache.org/wrapper/ for instructions on how to use this
> updated Maven Wrapper.
>
> You can download the appropriate sources etc. from the download page:
>
> https://maven.apache.org/wrapper/download.cgi
>
>
> Release Notes - Maven Wrapper - Version 3.1.1
>
> ** Bug
> * [MWRAPPER-21] - Arbitrary file write during archive extraction ("Zip
> Slip") in wrapper
> * [MWRAPPER-38] - build from source-release has different result from
> Git
> * [MWRAPPER-40] - Wrapper Properties File License system dependant
> line
> separator
> * [MWRAPPER-41] - Goals documentation missing from site
> * [MWRAPPER-42] - maven-wrapper fails to self-update maven-wrapper.jar
> * [MWRAPPER-44] - maven-wrapper may use outdated
> MavenWrapperDownloader.class
> * [MWRAPPER-58] - curl cannot follow 302 code when downloading wrapper
> jar
>
> ** Improvement
> * [MWRAPPER-39] - release as maven-wrapper instead of
> maven-wrapper-parent
> * [MWRAPPER-43] - Download of jar must be quiet by default
> * [MWRAPPER-47] - Use name wrapperUrl consistently in Maven Wrapper
> files/
> scripts
> * [MWRAPPER-49] - add Wrapper version in mvnw/mvnw.cmd scripts
> * [MWRAPPER-51] - Refactor using Java Path API (NIO.2)
> * [MWRAPPER-53] - cygwin path tidy for java and class
>
> ** Task
> * [MWRAPPER-56] - Remove M2_HOME from mvnw script
>
> ** Dependency upgrade
> * [MWRAPPER-62] - Upgrade Parent to 35
> * [MWRAPPER-63] - Upgrade Parent to 36
>
>
> Enjoy,
>
> -The Apache Maven team
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Help to create Maven Plugin for Checker Framework

[Benjamin Marwell]

Hi Daniele,

sorry that no one has answered you in more than a month.

We can all help with specific questions, but I guess there are too few
volunteers to make it an ASF project.
However, there is also the mojohaus organization which has seen some
activity lately.

Would that work for you?

Am Mo., 21. März 2022 um 14:13 Uhr schrieb Daniele Sala
:
>
> Hi guys,
> can some of you help Checker Framework to build a nice Maven plugin?
> I'm not in the crew, I only found the request-for-help :-)
>
> https://github.com/typetools/checker-framework/issues/2782
>
>
> Thanks,
> Daniele

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

Re: Checkstyle 10.0, Java 11, Maven Checkstyle Plugin, and toolchain support

[Benjamin Marwell]

Hi Tim,

tbh I did not even notice, because I use Java 11 to compile Java 8 projects.
You can either use the properties maven.compiler.source/target or
maven.compiler.release (recommended for Java 9+).

This would require Java 11+ for your build, but the compiled bytecode
will still be Java 8 bytecode.

Would that work for you?

- Ben

Am Mo., 7. März 2022 um 19:57 Uhr schrieb Timothy Stone :
>
> Devs,
>
> I'm researching the possibility of committing a patch to the Maven
> Checkstyle Plugn to support toolchains.
>
> This support would be critical with Checkstyle 10.0 now requiring Java 11.
>
> I did not see any work pending on this in the JIRA board, yet. I'm not
> aware of any pending work from the Checkstyle team.
>
> Any awareness of work would be appreciated, before I begin.
>
> Thanks!
> Tim
>
> --
> Timothy Stone
> =
> Some call me ... Tim.
> Husband, Father, Blogger, OSS, Wargamer, Home Brewer, and D
> Find me on GitHub | Linked In | MeWe | PGP

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

Re: Switch to Matomo Tracking code

[Benjamin Marwell]

Hi Christian!

I am happy to help where I can.

In case you made me an admin, I would be happy to tune the settings for
projects as needed and/or switch more projects to Matomo once it is
established well.

- Ben




On Sun, 6 Mar 2022, 20:45 Christian Grobmeier,  wrote:

> Hi Olivier,
>
> we (either me or Martijn) will set up a project.
>
> Glad to see Maven will do this.
>
> Or Benjamin, if he wants to give us a helping hand :-) In this case i
> gladly add you as an admin in Matomo there
>
> Kind regards,
> Christian
>
> --
> The Apache Software Foundation
> V.P., Data Privacy
>
>
> On Sun, Mar 6, 2022, at 18:37, Benjamin Marwell wrote:
>
>
> Exactly for this question I CC'd Martijn . You accidentally clicked on
> "reply" instead of "reply all", I guess...
>
> You can also find us in #privacy-matomo in our Slack instance.
>
> I'm not sure how much infra is involved at this point. Martijn and
> Christian can answer these questions.
>
>
> On Sun, 6 Mar 2022, 12:04 Olivier Lamy,  wrote:
>
> Hi
> looks good.
> how do we have access to manage tracking id etc?
>
> On Sat, 5 Mar 2022 at 22:41, Benjamin Marwell  wrote:
>
> > Hi everyone!
> >
> > The ASF now runs a public Matomo instance [1].
> > They are open for more projects now.
> >
> > If it is okay with you, we could add a tracking code to our site.xml file
> > [2].
> > It is an easy change, just add a body-head section [4].
> >
> > Even if you do not agree to add Matomo, I will create a PR to remove
> > the Google Analytics tracking code, as it violates our privacy policy
> > [3] and is already illegal to use in some countries, e.g. France.
> >
> > Let me know what you think.
> >
> > - Ben
> >
> > PS: Someone with access to Google Analytics, please provide some rough
> > numbers (daily hits) to Martijn, who is CC'd. Thanks!
> >
> > [1]: https://matomo.privacy.apache.org/
> > [2]:
> https://github.com/apache/maven-parent/blob/master/src/site/site.xml
> > [3]:
> >
> https://www.apache.org/foundation/policies/privacy.html#:~:text=We%20do%20not%20track%20or,for%20the%20purpose%20described%20above
> > .
> > [4]:
> >
> https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Inject_xhtml_into_.3Chead.3E
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
>

Re: Switch to Matomo Tracking code

[Benjamin Marwell]

Exactly for this question I CC'd Martijn . You accidentally clicked on
"reply" instead of "reply all", I guess...

You can also find us in #privacy-matomo in our Slack instance.

I'm not sure how much infra is involved at this point. Martijn and
Christian can answer these questions.


On Sun, 6 Mar 2022, 12:04 Olivier Lamy,  wrote:

> Hi
> looks good.
> how do we have access to manage tracking id etc?
>
> On Sat, 5 Mar 2022 at 22:41, Benjamin Marwell  wrote:
>
> > Hi everyone!
> >
> > The ASF now runs a public Matomo instance [1].
> > They are open for more projects now.
> >
> > If it is okay with you, we could add a tracking code to our site.xml file
> > [2].
> > It is an easy change, just add a body-head section [4].
> >
> > Even if you do not agree to add Matomo, I will create a PR to remove
> > the Google Analytics tracking code, as it violates our privacy policy
> > [3] and is already illegal to use in some countries, e.g. France.
> >
> > Let me know what you think.
> >
> > - Ben
> >
> > PS: Someone with access to Google Analytics, please provide some rough
> > numbers (daily hits) to Martijn, who is CC'd. Thanks!
> >
> > [1]: https://matomo.privacy.apache.org/
> > [2]:
> https://github.com/apache/maven-parent/blob/master/src/site/site.xml
> > [3]:
> >
> https://www.apache.org/foundation/policies/privacy.html#:~:text=We%20do%20not%20track%20or,for%20the%20purpose%20described%20above
> > .
> > [4]:
> >
> https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Inject_xhtml_into_.3Chead.3E
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Switch to Matomo Tracking code

[Benjamin Marwell]

Hi everyone!

The ASF now runs a public Matomo instance [1].
They are open for more projects now.

If it is okay with you, we could add a tracking code to our site.xml file [2].
It is an easy change, just add a body-head section [4].

Even if you do not agree to add Matomo, I will create a PR to remove
the Google Analytics tracking code, as it violates our privacy policy
[3] and is already illegal to use in some countries, e.g. France.

Let me know what you think.

- Ben

PS: Someone with access to Google Analytics, please provide some rough
numbers (daily hits) to Martijn, who is CC'd. Thanks!

[1]: https://matomo.privacy.apache.org/
[2]: https://github.com/apache/maven-parent/blob/master/src/site/site.xml
[3]: 
https://www.apache.org/foundation/policies/privacy.html#:~:text=We%20do%20not%20track%20or,for%20the%20purpose%20described%20above.
[4]: 
https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Inject_xhtml_into_.3Chead.3E

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

[MNG-7393] API change reguested for Maven 4

[Benjamin Marwell]

Hi everyone,

I would like to change the API from the ReportMojo.

I was recently looking at
https://github.com/apache/maven-reporting-impl/blob/9050da0e7c2defed851621b62c0160b52716ba11/src/main/java/org/apache/maven/reporting/AbstractMavenReport.java#L338-L342

But it seems the method boolean canGenerate() does not throw any exceptions.
OTOH I see that a lot of reports are scanning for files and have to
(possibly) deal with IOExceptions at some point, either via
Files.walk() or FileUtils.getFiles().

Sadly, we cannot just wrap them into a MojoExecutionException or
MavenReportException, because both are not thrown from that method,
AND the method canGenerate is called from two locations.So, what is
the recommended approach, if canGenerate encounters an IOException?

For this reason, I would like to introduce this API change:
https://issues.apache.org/jira/browse/MNG-7393

Thanks,,
Ben

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

Re: Commit Review Policy

[Benjamin Marwell]

Hi!

Aside from typo fixes, PRs might slow down the dev speed, but greatly
improve code quality.
Even small PRs might have side effects you might not notice at first glance.

But then, even with typo fixes I have seen people introducing more
fixes or unintentionally
thought they would fix something when in fact they introduced a type.

In my humble opinion, reviews BEFORE commit should be the default case.

Am Di., 25. Jan. 2022 um 20:47 Uhr schrieb Slawomir Jaranowski
:
>
> Hi,
>
> On the page "Apache Maven Project Roles" [1] we have paragraph
> about Committers with:
>
> The Apache Maven project uses a Commit then Review policy and has a number
> of conventions which should be followed.
>
>
> Looks like Review then Commit policy is from svn time, so should be
> refreshed or confirmed that is actual.
>
> When we want Review than Commit policy, we need some rules which allow us
> to effectively work if nobody is interested for feedback.
> We also need rules / examples for direct commits, when they are acceptable.
>
> Do we need different rules for Maven core, plugins, shared ... etc
>
> Example of rule:
>
> PR -> no feedback for X days -> send a mail on dev@, if still not feedback
> after X days after mail  -> proceed alone
>
> [1] https://maven.apache.org/project-roles.html#committers
>
> --
> Sławomir Jaranowski

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

Re: Using of Travis

[Benjamin Marwell]

+1 to drop

Am Fr., 17. Dez. 2021 um 10:24 Uhr schrieb Romain Manni-Bucau
:
>
> +1 to drop
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le ven. 17 déc. 2021 à 10:19, Olivier Lamy  a écrit :
>
> > +1 to get rid of travis
> >
> > On Fri, 17 Dec 2021 at 08:52, Slawomir Jaranowski 
> > wrote:
> >
> > > Hi,
> > >
> > > As the primary CI environment we use Jenkins.
> > > Now also using GH Actions  ...
> > > I think that those both are enough.
> > >
> > > Some projects contain scripts for Travis, like surefire.
> > >
> > > Do we want to still use Travis?
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >

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

Re: Maven Resolver + Wagon

[Benjamin Marwell]

Hi Tamas,

this is great news! I agree with you that most protocols are either
file:// (project-relative repositories) or https:// based nowadays.

Thanks!

Am Mi., 15. Dez. 2021 um 14:44 Uhr schrieb Guillaume Nodet :
>
> Such a massive performance improvement is really nice ! I don't know the
> whole history behind wagon and other transports so I don't have a strong
> opinion about the location of such an improvement , but I definitely
> welcome it !
>
> Le mer. 15 déc. 2021 à 09:26, Tamás Cservenák  a
> écrit :
>
> > Howdy,
> >
> > I'd like to pitch a topic about maven-resolver and usage of Wagon in it.
> > As IMHO, Wagon use in maven-resolver is far from optimal (is very
> > suboptimal).
> >
> > Typical example is this PR:
> > https://github.com/apache/maven-resolver/pull/140
> >
> > This PR _halves HTTP requests made by resolver_ against Maven Central (!)
> > by utilizing hashes sent by Maven Central in HTTP response header. Hence,
> > instead of doing GET /a.jar and then GET /a.jar.sha1 it does both at once
> > with one HTTP request. IMHO, this is huge. But, this works only with
> > maven-resolver-transport-http that is NOT used with Maven (as it uses
> > maven-resolver-transport-wagon). Moreover, doing this in Wagon, that is
> > layer by layer ... of abstractions is just very hard.
> >
> > IMHO, back in Maven2 times, when Wagon was conceived, the "transport
> > agnosticism" and "universal transport" was really a life saver: back then,
> > people used sticks and duct-tapes to craft "repo solutions", hence access
> > like SSHFS, Apache httpd + mod_dav and who knows what  were common, and
> > Wagon having supporting all these cases was really a cool thing to have.
> >
> > But fast forward 10+ years, there is really no reason to do this today, as
> > the landscape changed a LOT, there are MRMs on every corner popping up like
> > mushrooms. I don't really see use of maven-resolver (and maven's use of
> > maven-resolver) that does not involve HTTP or FILE.
> >
> > In short, resolver NOT involving HTTP is something you will VERY RARELY
> > see. Or in other words, maven-resolver concerning anything NOT HTTP (and
> > FILE) is just sub optimal.
> >
> > So I propose to retarget maven-resolver (and it's use within maven) to use
> > maven-resolver-transport-http instead of Wagon. Wagon, similarly like
> > Plexus, is there to stay in Maven, but it's use in maven-resolver is really
> > really suboptimal.
> >
> >
> > WDYT?
> >
> > Tamas
> >
>
>
> --
> 
> Guillaume Nodet

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

Re: Maven Code Style and imports layouts

[Benjamin Marwell]

+1!

 Sandra and I tried similar Suggestions a while back.
This will help new contributors a lot.

Thanks for your efforts!

On Mon, 18 Oct 2021, 07:10 Slawomir Jaranowski, 
wrote:

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

Re: [maven-gh-actions-shared] branch main updated: first workflow

[Benjamin Marwell]

+1, we also do this in Apache Shiro [1]
and the aspectj-maven-plugin (mojohaus) [2].

We don't reuse workflows yet, but what you have is just great!

Thanks!
- Ben

[1]: 
https://github.com/apache/shiro/blob/df2f5481260bd778226473a658d237c047b7e840/.github/workflows/maven.yml
[2]: 
https://github.com/mojohaus/aspectj-maven-plugin/blob/e19704cc40017ac69408e007c423f4ddbe865bca/.github/workflows/maven.yml


Am Fr., 15. Okt. 2021 um 01:45 Uhr schrieb Olivier Lamy :
>
> We had a discussion on slack about having a first build such as only
> ubuntu/jdk1,8 before running all the matrix and holding a lot of nodes from
> the Apache org..
> This PR definitely does not do this! So I don't understand why this has
> been merged!
> Remember (as far I understand) nodes are shared between all projects from
> Apache org.
> There is no need to hold a lot of nodes if we are sure it fail (especially
> as Apache have a lot projects using gh-actions)
>
> On Fri, 15 Oct 2021 at 07:52,  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > slachiewicz pushed a commit to branch main
> > in repository
> > https://gitbox.apache.org/repos/asf/maven-gh-actions-shared.git
> >
> >
> > The following commit(s) were added to refs/heads/main by this push:
> >  new eee837a  first workflow
> > eee837a is described below
> >
> > commit eee837abbc62df4e1097841b7cec8c5db6b30e2a
> > Author: Slawomir Jaranowski 
> > AuthorDate: Thu Oct 14 22:41:33 2021 +0200
> >
> > first workflow
> > ---
> >  .github/workflows/maven-verify-with-its.yml |  67 +
> >  .gitignore  |   1 +
> >  LICENSE | 202
> > 
> >  README.md   |  43 +-
> >  4 files changed, 312 insertions(+), 1 deletion(-)
> >
> > diff --git a/.github/workflows/maven-verify-with-its.yml
> > b/.github/workflows/maven-verify-with-its.yml
> > new file mode 100644
> > index 000..a24464d
> > --- /dev/null
> > +++ b/.github/workflows/maven-verify-with-its.yml
> > @@ -0,0 +1,67 @@
> > +# Licensed to the Apache Software Foundation (ASF) under one
> > +# or more contributor license agreements.  See the NOTICE file
> > +# distributed with this work for additional information
> > +# regarding copyright ownership.  The ASF licenses this file
> > +# to you under the Apache License, Version 2.0 (the
> > +# "License"); you may not use this file except in compliance
> > +# with the License.  You may obtain a copy of the License at
> > +#
> > +#   http://www.apache.org/licenses/LICENSE-2.0
> > +#
> > +# Unless required by applicable law or agreed to in writing,
> > +# software distributed under the License is distributed on an
> > +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> > +# KIND, either express or implied.  See the License for the
> > +# specific language governing permissions and limitations
> > +# under the License.
> > +
> > +name: Verify
> > +
> > +on:
> > +  workflow_call:
> > +inputs:
> > +  os-matrix:
> > +description: 'os matrix as json array'
> > +default: '[ "ubuntu-latest", "windows-latest", "macOS-latest" ]'
> > +type: string
> > +
> > +  jdk-matrix:
> > +description: 'jdk matrix as json array'
> > +default: '[ "8", "11", "17" ]'
> > +type: string
> > +
> > +  matrix-exclude:
> > +description: 'exclude for matrix as json'
> > +default: '[]'
> > +type: string
> > +
> > +jobs:
> > +
> > +  verify:
> > +name: ${{ matrix.os }} jdk-${{ matrix.jdk }}
> > +
> > +runs-on: ${{ matrix.os }}
> > +
> > +strategy:
> > +  fail-fast: true
> > +  matrix:
> > +os:   ${{ fromJSON( inputs.os-matrix ) }}
> > +jdk:  ${{ fromJSON( inputs.jdk-matrix ) }}
> > +exclude:  ${{ fromJSON( inputs.matrix-exclude ) }}
> > +
> > +steps:
> > +  - name: Checkout
> > +uses: actions/checkout@v2.3.4
> > +
> > +  - name: Set up JDK
> > +uses: actions/setup-java@v2.3.1
> > +with:
> > +  java-version: ${{ matrix.jdk }}
> > +  distribution: 'temurin'
> > +  cache: 'maven'
> > +
> > +  - name: Build with Maven
> > +run: mvn --errors --batch-mode --show-version -P run-its
> > -D"invoker.streamLogsOnFailures" verify
> > +
> > +  - name: Build Maven Site
> > +run: mvn --errors --batch-mode --show-version site
> > diff --git a/.gitignore b/.gitignore
> > new file mode 100644
> > index 000..485dee6
> > --- /dev/null
> > +++ b/.gitignore
> > @@ -0,0 +1 @@
> > +.idea
> > diff --git a/LICENSE b/LICENSE
> > new file mode 100644
> > index 000..d645695
> > --- /dev/null
> > +++ b/LICENSE
> > @@ -0,0 +1,202 @@
> > +
> > + Apache License
> > +   Version 2.0, January 2004
> > +http://www.apache.org/licenses/
> > +
> > +   TERMS AND CONDITIONS 

Re: system path dependency warning, accurate or not?

[Benjamin Marwell]

Hi Michael!

Setups like "${project.basedir}/m2/" are a common thing.

While "system" scope was probably invented to use system
(i.e. jdk-related) jar files, but otoh
it is the only way to pull in artifacts
which are stored next to the project's directory.

If you don't think "system" scope should be used for this purpose,
a lot of projects will need a new "filesystem" scope.

Thus, I'd say "+1" to remove the warning if the repo is inside the
project.basedir OR
session.executionRootDirectory OR
maven.multiModuleProjectDirectory.

- Ben


Am Fr., 24. Sept. 2021 um 20:23 Uhr schrieb Michael Osipov
:
>
> Am 2021-09-24 um 16:42 schrieb Romain Manni-Bucau:
> > Hi all,
> >
> > wonder if there is any reason to see this warning when using a jar in the
> > project in system scope:
> >
> >
> > [WARNING]
> > [WARNING] Some problems were encountered while building the effective model
> > for io.yupiik.foo:foo:jar:0.0.1-SNAPSHOT
> > [WARNING] 'dependencies.dependency.systemPath' for foo:bar:jar should not
> > point at files within the project directory,
> > ${project.basedir}/m2/lib/bar.jar will be unresolvable by dependent
> > projects @ line 71, column 19
> > [WARNING]
> > [WARNING] It is highly recommended to fix these problems because they
> > threaten the stability of your build.
> > [WARNING]
> > [WARNING] For this reason, future Maven versions might no longer support
> > building such malformed projects.
> > [WARNING]
> >
> > since the absolute path starts with a "in project" path the build will be
> > stable, the jar will be resolvable etc so there is no reason for the
> > warnings nor maven to not support it in a future version.
> >
> > Is it just due to fixing the "tools.jar" dependency (where the warning is
> > relevant) or is there another rational behind that and the warning is not a
> > bug?
> > If so i'm concerned there is no real alternative until you get a m2 https
> > server which is not always an option so the last sentence requires us to
> > work toward a solution (that said it will likely be the same so I'd prefer
> > to drop the warning if the dpeendency is in the project).
>
>
> I think the purpose of system is to use dependencies *outside* of the
> project!
>
>
> -
> 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 Actions on Maven projects

[Benjamin Marwell]

That won't work for all plugins.
The jlink plugin and others are using complicated setups so they can use
toolchains on GitHub Actions. It's a little bit complicated there because
the plugin does work with java 8 as long as a java 9+ is configured via
toolchains.

Please make sure those actions continue to work.




On Sun, 19 Sep 2021, 20:22 Martin Kanters,  wrote:

> Sounds like a great idea!
>
> Martin
>
> Op zo 19 sep. 2021 om 00:26 schreef Tamás Cservenák :
>
> > +1 for global action
> >
> > T
> >
> > On Sat, Sep 18, 2021, 13:35 Slawomir Jaranowski 
> > wrote:
> >
> > > Hi,
> > >
> > > Thanks for your response. I know that jenkins build is the master for
> > > Apache projects,
> > > but most of the projects have some GA workflows configuration which
> many
> > > times are different.
> > > This situation generates more work for maintainer.
> > >
> > > Thanks to composite actions [1] we can create one global action which
> has
> > > defined all required steps and one action for providing configurations
> > > values like jkd list,
> > > both of these actions can be in one repository.
> > >
> > > In the rest of the project we can use those global actions, so when
> next
> > > time we want to change, e.g. jdk list (it changes every 6 month ;-) )
> we
> > > only change it in one place.
> > > This approach can make less maintenance work in maven projects.
> > >
> > > If you are interested let me know, I can prepare some spikes for you
> and
> > > provide more details.
> > >
> > >
> > > [1]
> > >
> > >
> >
> https://docs.github.com/en/actions/creating-actions/creating-a-composite-action
> > >
> > >
> > > sob., 18 wrz 2021 o 08:27 Martin Kanters 
> > > napisał(a):
> > >
> > > > Hi Slawomir, sorry for the late reply.
> > > >
> > > > Great that you see the value of the workflows.
> > > > I don't think there are any strict rules or guidelines around how the
> > > > workflow should be configured exactly, but I think it makes sense to
> > have
> > > > them in place.
> > > > Perhaps we should also look into a way of reusing workflows in all or
> > > most
> > > > of the projects (maven-core is a bit different).
> > > >
> > > > Just wanted to mention that for the Apache team the Apache Jenkins
> > server
> > > > is what matters most. GA are helpful for contributors and committers
> > > > working via PRs, but in the end Apache Jenkins has to pass before a
> > merge
> > > > is allowed. Hence, I think we should go for a reasonable workflow
> > > > configuration, it does not have to be more extensive than the Jenkins
> > > > setup. Still, having macOS builds is very useful, Jenkins does not
> have
> > > > that AFAIK.
> > > >
> > > > Martin
> > > >
> > > >
> > > >
> > > >
> > > > Op za 11 sep. 2021 om 20:43 schreef Slawomir Jaranowski <
> > > > s.jaranow...@gmail.com>:
> > > >
> > > > > Hi,
> > > > >
> > > > > Many of maven, maven plugins projects have GutHub Action build
> > > > configured.
> > > > > It is very useful for contributors - we can verify PR early,
> > especially
> > > > on
> > > > > many different operating systems - which can't be done locally, or
> is
> > > > more
> > > > > complicated.
> > > > >
> > > > > Most of workflows have define build matrix like:
> > > > >
> > > > >   matrix:
> > > > > os: [ubuntu-latest, windows-latest, macOS-latest]
> > > > > java: [8, 11, 16, 17-ea]
> > > > >
> > > > > But some have:
> > > > >
> > > > >   matrix:
> > > > >os: [ubuntu-latest, windows-latest, macOS-latest]
> > > > >java: [8, 11, 16, 17-ea]
> > > > >jdk: [adopt, zulu]
> > > > >
> > > > >
> > > > > Question:
> > > > >
> > > > > Are there some guidelines about how GitHub Action should be
> > configured?
> > > > > If no guidelines, which build matrix will be the most expected?
> > > > >
> > > > >  I ask in conjunction to
> > > https://issues.apache.org/jira/browse/MDEP-768
> > > > >
> > > > >
> > > > > --
> > > > > Sławomir Jaranowski
> > > > >
> > > > > https://twitter.com/SlawekJaran
> > > > > https://github.com/slawekjaranowski
> > > > > https://linkedin.com/in/slawomirjaranowski
> > > > >
> > > >
> > >
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >
>

Re: Commandline inheritance

[Benjamin Marwell]

Yup, that's what I meant. Big +1!

On Tue, 10 Aug 2021, 22:18 Tamás Cservenák,  wrote:

> A git like behavior sound good for me as well.
>
> So install/system-wise < user < project
>
> T
>
>
> On Tue, Aug 10, 2021, 08:22 Benjamin Marwell  wrote:
>
> > I read Michaels message the way like option 6:
> >
> > > Since we have only two files: installation and user, I'd expect
> > that first the installation settings are parsed followed by user
> > settings (generic to specific).
> >
> > Installation is more generic (global) than user.
> >
> > Same for git: it will first parse the installation settings (/etc), then
> > any user settings, then any project settings.
> >
> > Or are we mixing up terms here?
> >
> > NPM does the same, too.
> >
> >
> >
> >
> > On Mon, 9 Aug 2021, 16:35 Robert Scholte,  wrote:
> >
> > > I'll add it, but it doesn't match the order of GIT[1] as mentioned by
> > > Michael.
> > > Maybe there should be a list of other comparable tools with their order
> > >
> > >
> > > Robert
> > >
> > >
> > > [1] https://git-scm.com/docs/git-config#FILES
> > > On 9-8-2021 15:09:30, Benjamin Marwell  wrote:
> > > Hi Robert,
> > >
> > > I would like to propose another solution.
> > > According to the wiki page and to the documentation, we have
> > >
> > > user
> > >
> > > where "
> > >
> > > From what I understand from other build systems, a more common approach
> > > would be
> > >
> > > installation (aka global)
> > >
> > > This would fix the naming issue (global becomes global).
> > > Of course this is a breaking change, but for maven 4, this seems
> > > reasonable to me.
> > >
> > > Am So., 8. Aug. 2021 um 11:48 Uhr schrieb Robert Scholte :
> > > >
> > > > During a discussion with Michael we noticed there's something odd
> about
> > > the names of some flags and the order of inheritance.
> > > >
> > > > I've tried to explain it on a separate wiki page[1] together with the
> > > first 3 options how we could fix it.
> > > > Please have a look at it and share your thoughts.
> > > >
> > > > thanks,
> > > > Robert
> > > >
> > > > [1]
> > >
> >
> https://cwiki.apache.org/confluence/display/MAVEN/Commandline+inheritance
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
>

Re: Commandline inheritance

[Benjamin Marwell]

I read Michaels message the way like option 6:

> Since we have only two files: installation and user, I'd expect
that first the installation settings are parsed followed by user
settings (generic to specific).

Installation is more generic (global) than user.

Same for git: it will first parse the installation settings (/etc), then
any user settings, then any project settings.

Or are we mixing up terms here?

NPM does the same, too.




On Mon, 9 Aug 2021, 16:35 Robert Scholte,  wrote:

> I'll add it, but it doesn't match the order of GIT[1] as mentioned by
> Michael.
> Maybe there should be a list of other comparable tools with their order
>
>
> Robert
>
>
> [1] https://git-scm.com/docs/git-config#FILES
> On 9-8-2021 15:09:30, Benjamin Marwell  wrote:
> Hi Robert,
>
> I would like to propose another solution.
> According to the wiki page and to the documentation, we have
>
> user
>
> where "
>
> From what I understand from other build systems, a more common approach
> would be
>
> installation (aka global)
>
> This would fix the naming issue (global becomes global).
> Of course this is a breaking change, but for maven 4, this seems
> reasonable to me.
>
> Am So., 8. Aug. 2021 um 11:48 Uhr schrieb Robert Scholte :
> >
> > During a discussion with Michael we noticed there's something odd about
> the names of some flags and the order of inheritance.
> >
> > I've tried to explain it on a separate wiki page[1] together with the
> first 3 options how we could fix it.
> > Please have a look at it and share your thoughts.
> >
> > thanks,
> > Robert
> >
> > [1]
> https://cwiki.apache.org/confluence/display/MAVEN/Commandline+inheritance
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Commandline inheritance

[Benjamin Marwell]

Hi Robert,

I would like to propose another solution.
According to the wiki page and to the documentation, we have

user < installation (aka global) < project.

where "<" means "is overridden by".

>From what I understand from other build systems, a more common approach would 
>be

installation (aka global) < user < project

This would fix the naming issue (global becomes global).
Of course this is a breaking change, but for maven 4, this seems
reasonable to me.

Am So., 8. Aug. 2021 um 11:48 Uhr schrieb Robert Scholte :
>
> During a discussion with Michael we noticed there's something odd about the 
> names of some flags and the order of inheritance.
>
> I've tried to explain it on a separate wiki page[1] together with the first 3 
> options how we could fix it.
> Please have a look at it and share your thoughts.
>
> thanks,
> Robert
>
> [1] https://cwiki.apache.org/confluence/display/MAVEN/Commandline+inheritance

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

Re: JPMS, Maven and test jars

[Benjamin Marwell]

> So now you would have a maven module with only the main source and no tests,
>  and a second module
> where the “main” source is actually the test classes
> and the unit tests test the code in a different Maven
> module with a module info that opens the module-info of the main source jar.
> Seems downright weird to me.

Well, it is not. First of all, you can test your main code nicely
using standard non-modularized tests.
No problem here.

Then you can use your module containing the abstract/common test
classes with the scope test.
This is actually what junit etc. is – you are using their main classes
in YOUR test scope.
So, nothing weird here, too.

The third project pulls them in altogether and is modularized.
Call it "IT" or "integration test", and everything feels normal again.

This will also help your IDE recognize the code.
And as this is a common pattern, it will also help other coders to
more easily recognize the structure of your project.

Am Di., 22. Juni 2021 um 20:46 Uhr schrieb Ralph Goers
:
>
> Yes, you understand correctly. And yes, the test classes could be moved to a 
> separate maven module, but
> then the unit tests would also have to move as well as they are dependent on 
> those test classes. Of course,
> the test classes are dependent on the main source. As an example, log4j-core 
> has a LoggerContext class,
> the test jar has a LoggerContextRule class that uses the LoggerContext and 
> the LoggerContextRule is used
> by many unit tests.
>
> So now you would have a maven module with only the main source and no tests, 
> and a second module
> where the “main” source is actually the test classes and the unit tests test 
> the code in a different Maven
> module with a module info that opens the module-info of the main source jar.
>
> Seems downright weird to me.
>
> Yes, I realize this doesn’t fit in the normal Maven lifecycle. I brought it 
> up because if and/or when more
> stuff starts becoming JPMS modularized this issue is going to become more and 
> more common.
>
> To be honest, I’d be OK living with the build the way it is except people are 
> complaining that their IDE
> has no idea what to do with the project.
>
> Ralph
>
> > On Jun 22, 2021, at 11:16 AM, Robert Scholte  wrote:
> >
> > If I understand correctly you want both log4j-core main classes and test 
> > classes be distributed as modularized jars.
> > To me with JPMS you should move the modularized test-classes to a separate 
> > Maven module as a first citizen artifact.
> > That should make it a lot easier.
> > It should also make the separation more clear: classes under 
> > target/test-classes are there to unittest its main classes.
> > Whereas this new module contains reusable (main) code for testing (which 
> > should be tested too ;) )
> > I understand that this will change the GA(-classifier) for the testing 
> > module, but to me for a good reason.
> >
> > Even with your very small reduction of steps to simplify the process, it 
> > doesn't fit in the default lifecycle unless you write you introduce a new 
> > lifecycle-binding or write a new extension.
> >
> > Robert
> >
> > On 22-6-2021 07:02:59, Ralph Goers  wrote:
> > Sorry for posting again. I really need to proof-read better. Please ignore 
> > the prior email.
> >
> > I have recently had quite an adventure modifying several of Log4j’s Maven 
> > modules to
> > implement JPMS on our master branch. It was an adventure due to a few 
> > issues:
> >
> > 1. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8265826 .
> > This bug has been fixed in Java 17 but Log4j uses Java 11 to build.
> > 2. Log4j-plugins builds an annotation processor, packages it with the 
> > annotations
> > and classes necessary to build and run plugins, creates and test jar and 
> > runs unit tests.
> > 3. It is not possible to compile an annotation processor with a 
> > module-info.java present.
> > The compile will fail because it can’t find the annotation processor 
> > “service” when
> > compiling module-info.java.
> > 4. It is very difficult to compile an annotation processor and then use it 
> > in the same Maven
> > module. JPMS expects the annotation processor to either be on the classpath 
> > or specified
> > with the processorpath option. When a module-info.java is present, Maven 
> > automatically
> > moves everything to the module path. Maven only supports using coordinates 
> > to specify the
> > processor path, which don’t exist when the processor is in the same module. 
> > The only way
> > to solve this is to compile all the classes with proc=only without a 
> > module-info.java present.
> > 5. Although number 4 might seem bad, it really doesn’t matter because javac 
> > will fail if a
> > module-info.java is present because module-info.java will have a reference 
> > to the service
> > class being generated by the annotation processor and for some reason 
> > module-info.java
> > is resolved before the annotation processor runs.
> > 6. If the main set of 

Re: [VOTE] Import mvndaemon/mvnd project @ Apache

[Benjamin Marwell]

+1 (nb)

On Wed, 16 Jun 2021, 08:50 Olivier Lamy,  wrote:

> Hi
> As already proposed by Guillaume, it looks to be a good idea to
> import mvndaemon/mvnd here at Apache.
>
> I'd like to propose a vote for this.
> +1: import the project here
> 0  : no real idea
> -1 : no (please explain why)
>
> cheers
> --
> Olivier
> PS: Actually I have no idea how binding works in such vote.
>

Re: Supporting building with incompatible JDK versions on a single project

[Benjamin Marwell]

Hi Tamás,

So hazelcast runs in the module path. Maven used the class path only. Thus,
add-opens does not do anything.

UNLESS... you start sub pocesses from Maven, eg using the exec plugin.

This means we still need an example where you have this issue with Maven.

On Tue, 15 Jun 2021, 20:27 Tamás Cservenák,  wrote:

> Or xstream for that matter...
>
> ToP
>
> On Tue, Jun 15, 2021, 20:26 Tamás Cservenák  wrote:
>
> > Just try to run hazelcast 3 (latest of 3.x) on java11. It will log what
> it
> > needs to be opened up.
> >
> > T on phone
> >
> > On Tue, Jun 15, 2021, 20:19 Benjamin Marwell 
> wrote:
> >
> >> Tamás,
> >>
> >> which module do you open?
> >>
> >> In most cases I have encountered, adding jaxb as a dependency to the
> >> project is sufficient. But to be sure, we would need to see an example.
> >>
> >> I think this would have long been noticed if it was a common problem.
> >>
> >> Ben
> >>
> >>
> >> On Tue, 15 Jun 2021, 19:18 Tamás Cservenák, 
> wrote:
> >>
> >> > Howdy,
> >> >
> >> > Robert, I think you are wrong:
> >> >
> >> > from Java 11 migration guide
> >> >
> >> > --add-opens
> >> > If you have to allow code on the class path to do deep reflection to
> >> access
> >> > nonpublic members, then use the --add-opens runtime option.
> >> > Some libraries do deep reflection, meaning setAccessible(true), so
> they
> >> can
> >> > access all members, including private ones. You can grant this access
> >> using
> >> > the --add-opens option on the java command line. No warning messages
> are
> >> > generated as a result of using this option.
> >> >
> >> > Hence, it is needed even for CP applications, that do require "deep
> >> > reflection".
> >> >
> >> > HTH
> >> > Tamas
> >> >
> >> > On Tue, Jun 15, 2021 at 7:04 PM Robert Scholte 
> >> > wrote:
> >> >
> >> > > AFAIK the --add-opens is only useful when using the module path.
> Maven
> >> > > itself and the plugins use the classpath, so I would like to have an
> >> > > example to better understand your issue.
> >> > >
> >> > > thanks,
> >> > > Robert
> >> > > On 15-6-2021 18:43:35, Guillaume Nodet  wrote:
> >> > > Hi everyone !
> >> > >
> >> > > There are some small incompatibilities between JDK around the
> >> supported
> >> > > command line versions. Usually, those do not cause any real
> problems.
> >> > > However, the "--add-opens" are sometimes necessary and only
> supported
> >> on
> >> > > JDK >= 9, as the JVM exits with an error on JDK 8.
> >> > > Some plugins may require the use of those options when running on
> JDK
> >> >=
> >> > > 9. What would be the way to solve this ?
> >> > >
> >> > > For mvnd, when the client launches the daemon, the JDK_JAVA_OPTIONS
> >> > > environment property is used. But it works because we have control
> on
> >> the
> >> > > client environment. But when you just clone a git repo, asking the
> >> user
> >> > to
> >> > > set a specific environment is problematic imho. The
> .mvn/maven.config
> >> or
> >> > > .mvn/jvm.config can't be used to set up environment variables or to
> >> > > conditionally set up arguments afaik.
> >> > >
> >> > > Any idea ?
> >> > >
> >> > > --
> >> > > 
> >> > > Guillaume Nodet
> >> > >
> >> >
> >>
> >
>

Re: Supporting building with incompatible JDK versions on a single project

[Benjamin Marwell]

Tamás,

which module do you open?

In most cases I have encountered, adding jaxb as a dependency to the
project is sufficient. But to be sure, we would need to see an example.

I think this would have long been noticed if it was a common problem.

Ben


On Tue, 15 Jun 2021, 19:18 Tamás Cservenák,  wrote:

> Howdy,
>
> Robert, I think you are wrong:
>
> from Java 11 migration guide
>
> --add-opens
> If you have to allow code on the class path to do deep reflection to access
> nonpublic members, then use the --add-opens runtime option.
> Some libraries do deep reflection, meaning setAccessible(true), so they can
> access all members, including private ones. You can grant this access using
> the --add-opens option on the java command line. No warning messages are
> generated as a result of using this option.
>
> Hence, it is needed even for CP applications, that do require "deep
> reflection".
>
> HTH
> Tamas
>
> On Tue, Jun 15, 2021 at 7:04 PM Robert Scholte 
> wrote:
>
> > AFAIK the --add-opens is only useful when using the module path. Maven
> > itself and the plugins use the classpath, so I would like to have an
> > example to better understand your issue.
> >
> > thanks,
> > Robert
> > On 15-6-2021 18:43:35, Guillaume Nodet  wrote:
> > Hi everyone !
> >
> > There are some small incompatibilities between JDK around the supported
> > command line versions. Usually, those do not cause any real problems.
> > However, the "--add-opens" are sometimes necessary and only supported on
> > JDK >= 9, as the JVM exits with an error on JDK 8.
> > Some plugins may require the use of those options when running on JDK >=
> > 9. What would be the way to solve this ?
> >
> > For mvnd, when the client launches the daemon, the JDK_JAVA_OPTIONS
> > environment property is used. But it works because we have control on the
> > client environment. But when you just clone a git repo, asking the user
> to
> > set a specific environment is problematic imho. The .mvn/maven.config or
> > .mvn/jvm.config can't be used to set up environment variables or to
> > conditionally set up arguments afaik.
> >
> > Any idea ?
> >
> > --
> > 
> > Guillaume Nodet
> >
>

Re: Build windows-jdk11

[Benjamin Marwell]

Maybe works on some notes, not on others?
The build I tested (linked in the issue) worked later on. But I didn't
check which node it ran on.

On Mon, 7 Jun 2021, 20:08 Robert Scholte,  wrote:

> I don't understand why INFRA-21954 was closed, the issue is still
> occurring.
> I've changed INFRA-21690 to blocker, but still no response.
>
> Robert
> On 7-6-2021 15:32:29, Benjamin Marwell  wrote:
> I also opened
>
> https://issues.apache.org/jira/browse/INFRA-21954
>
> #asfinfra on slack
>
> On Mon, 7 Jun 2021, 14:52 Michael Osipov, wrote:
>
> > Am 2021-06-07 um 14:36 schrieb Elliotte Rusty Harold:
> > > Build windows-jdk11 has been broken for a week+ now. Anyone want to
> > > take a look? I couldn't find any useful log output.
> >
> >
> > https://issues.apache.org/jira/browse/INFRA-21690
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Build windows-jdk11

[Benjamin Marwell]

I also opened

https://issues.apache.org/jira/browse/INFRA-21954

#asfinfra on slack

On Mon, 7 Jun 2021, 14:52 Michael Osipov,  wrote:

> Am 2021-06-07 um 14:36 schrieb Elliotte Rusty Harold:
> > Build windows-jdk11 has been broken for a week+ now. Anyone want to
> > take a look? I couldn't find any useful log output.
>
>
> https://issues.apache.org/jira/browse/INFRA-21690
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Moving away from Modello

[Benjamin Marwell]

> - For some time, JAXB has been bundled with the JRE.
> As of this writing, this still applies to Java 8.
>In Java 9, and 10, there's --add-modules=java.xml.bind.
> As of Java 11, it has been removed from the JDK.
>  I'd consider that to be a migration problem.

You can just include jaxb-api and jaxb-impl for any version of Java.
This will work and it won't even break Java 8.

Am Mi., 2. Juni 2021 um 22:46 Uhr schrieb Jochen Wiedmann
:
>
> On Wed, Jun 2, 2021 at 2:38 PM Gary Gregory  wrote:
> >
> > On Wed, Jun 2, 2021 at 8:30 AM Jochen Wiedmann
> >  wrote:
> > >
> > > On Wed, Jun 2, 2021 at 1:02 PM Elliotte Rusty Harold  
> > > wrote:
> > >
> > > > What do folks think about slowly moving away from Modello where
> > > > feasible to simplify the build? Does anyone find Modello a net
> > > > positive, especially in longterm maintenance, not just in initial code
> > > > generation?
> > >
> > > To me, it sounds feasible to replace Modello with a Sax parser
> > > (reading), and a Sax
> > > event generator (writing), that take as input a bean class (either
> > > written manually,
> > > or generated by Modello, and do the serialization/deserialization.
> > >
> > > Would, most likely, not be a drop-in-replacement, but definitely a 
> > > medium-term
> > > solution.
> >
> > What about JAXB?
>
> In general, JAXB is an excellent technology. For use in Maven, I'd
> foresee a few gotchas:
>
>   - For some time, JAXB has been bundled with the JRE. As of this
> writing, this still applies to Java 8.
> In Java 9, and 10, there's --add-modules=java.xml.bind. As of Java
> 11, it has
> been removed from the JDK. I wouldn't want to deal with that.
>   - To use JAXB, one either needs to have an XSD, or rather specific
> annotations on the Java beans.
>  I'd consider that to be a migration problem.
>
> Jochen
>
>
> --
>
> Look, that's why there's rules, understand? So that you think before
> you break 'em.
>
> -- (Terry Pratchett, Thief of Time)
>
> -
> 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: Security/Versioning policy proposal

[Benjamin Marwell]

I tend to agree to Robert, although I find your idea appealing and do
understand the motivation.

If you look at some Eclipse projects, they also refer you to companies like
IBM if you want anything beyond [1].

Ben

[1]: e.g.
https://adoptopenjdk.net/support.html

On Tue, 20 Apr 2021, 19:55 Robert Scholte,  wrote:

> Romain,
>
> I still don't like this approach.
>
> What you're asking tend to look like contracts and SLA's and as long as
> we're maintaining Maven with a very small group of volunteers and aren't
> backed full time by some company we shouldn't do this.
> If there are companies that use Maven and want this kind of commitment, we
> need to start a different discussion.
> E.g. could/should I (or any other Maven developer) start to offer Maven
> Support contracts and under what conditions?
>
> Keep in mind that you are the only that keeps pushing this topic.
> I noticed that it frustrates some and that it they loose their motivation
> to work on Maven.
> Please reconsider if it is still worth the discussion or that you can
> solve it for yourself.
>
> thanks,
> Robert
> On 19-4-2021 20:05:53, Romain Manni-Bucau  wrote:
> Le lun. 19 avr. 2021 à 17:20, Benjamin Marwell a
> écrit :
>
> > > Do we write 3.6 and 4 are active and maintained branches currently or
> > do we
> > > drop 3.x with first 4.x release?
> >
> > Dropping 3.x with the first 4.x release would not make sense from the
> > point you presented earlier.
> > I'd drop 3.x as soon as we reach 4.1.0.
> >
>
> I can agree but it also means we define what is 4.1.0 and since we "jump"
> versions it will require us to better respect what we plan (I think it is
> very good, don't take it wrong).
>
>
> >
> > > maintenance branches on demands
> > My vote would be to cherry pick security fixes for the previous minor
> > version.
> > E.g. if we release 4.0.1, also release a 3.8.2 (assuming the current
> > latest versions are 4.0.0. and 3.8.1).
> >
> > I mean, we can try this for a single release and see if we like it.
> > If not, we can still drop this again and revert back to "on demand"
> > maintenance branches.
> >
> > Backporting features does not make sense (imo) how maven treats releases.
> >
>
> I think it is the whole point: what when we fix a security issue by a new
> feature -> "does not make sense" (quoting your words but that's what was
> the outcome for 3.8.1) and it is exactly the issue I face and I want we
> fix: no predictability on stable maven versions with a minimal maintenance
> "guaranteed" (no security issue opened in CVE databases).
> So I think we either write we backport the security fixes in last 2
> maintained branches with some duration (we can align on java LTS duration
> for example which should be close to our major breaking changes) or we
> write we don't care and only maintain the last release branch and it is the
> only one guaranteed to get fixes (which kind of means there will be no
> anticipation of version but it is known upfront).
> Indeed I'm not a fan of such "you will see" policies but it clarifies the
> point which is my main blocker at the moment at least we can justify our
> last behavior.
> This is really the answer I'm after: explicit what we do and continue or
> make us more rigorous in the future.
>
> That said I note the "we can still revert back" point which is surely a
> very good one so idea can be to write "we will do " and add a banner on
> top saying "experimental policy until " (for example for a year) and we
> can change the policy (and update the deadline) within this duration if it
> does not fit. This would enable us to test and validate the policy with an
> error right and let the user know it upfront.
>
> So proposal can be:
>
> [Experimental policy until June 2022]
> 1. We maintain two major releases, ie 3.x and 4.x as of today (no minor in
> particular, just the highest one)
> 2. We maintain versions and notify the EOL 3 years before it is reached (so
> if we want to EOL v3 in 2025 we will notify users in 2022)
> 3. We backport and release security fixes (new feature or not) in all
> maintained branches
>
> Wdyt?
>
>
> >
> > Am So., 18. Apr. 2021 um 22:45 Uhr schrieb Romain Manni-Bucau
> > :
> > >
> > > Hi all,
> > >
> > > Back on this topic - which prepares v4 releases too btw.
> > >
> > > What do we finally write?
> > >
> > > That maven will always fix the latest (stable) version and can release
> > > maintenance branches on demands (lazily)?
> > >
&

Re: Security/Versioning policy proposal

[Benjamin Marwell]

>  Do we write 3.6 and 4 are active and maintained branches currently or do we
> drop 3.x with first 4.x release?

Dropping 3.x with the first 4.x release would not make sense from the
point you presented earlier.
I'd drop 3.x as soon as we reach 4.1.0.

> maintenance branches on demands
My vote would be to cherry pick security fixes for the previous minor version.
E.g. if we release 4.0.1, also release a 3.8.2 (assuming the current
latest versions are 4.0.0. and 3.8.1).

I mean, we can try this for a single release and see if we like it.
If not, we can still drop this again and revert back to "on demand"
maintenance branches.

Backporting features does not make sense (imo) how maven treats releases.

Am So., 18. Apr. 2021 um 22:45 Uhr schrieb Romain Manni-Bucau
:
>
> Hi all,
>
> Back on this topic - which prepares v4 releases too btw.
>
> What do we finally write?
>
> That maven will always fix the latest (stable) version and can release
> maintenance branches on demands (lazily)?
>
> Do we write 3.6 and 4 are active and maintained branches currently or do we
> drop 3.x with first 4.x release?
>
> Indeed I'd like the 2 branches option but I am fine with whatever policy
> while written and clear for end users upfront. I'd love we solve that
> before next release if possible cause it always create pointless work due
> to the blurry exchanges on this topic over our website and the net/mail
> archives.
>
>
> Le lun. 5 avr. 2021 à 19:51, Romain Manni-Bucau  a
> écrit :
>
> >
> >
> >
> > Le lun. 5 avr. 2021 à 17:42, Ralph Goers  a
> > écrit :
> >
> >> I don’t understand the point. The very next version of Maven did get the
> >> security fix. Just because the release manager decided to follow a peculiar
> >> version numbering practice unique to Maven doesn’t mean there is a problem.
> >>
> >
> > This had been an issue only because the versioning policy of maven is
> > undefined.
> > If defined it is perfectly fine for me.
> >
> >
> >>
> >> I don’t know what you mean by random, nor do I know what you mean by a
> >> stability statement. AFAIK Maven has been very stable from the 2.x versions
> >> through the 3.x versions. In some ways too stable, which is why introducing
> >> new concepts that have been wanted for years is so hard.
> >>
> >
> > Last statements tend to mean that once 4.x will be there, 3.x will be
> > forgotten and no more maintained.
> > Since it is a breaking change and if you picked 3.x today it is a big deal
> > since you have no guarantee you can upgrade without a lot of investment and
> > get security fixes when needed by just upgrading (and potentially tuning a
> > bit the conf but not by rewriting the poms for ex).
> >
> > For 2.x -> 3.x time, the 2.x was maintained some years.
> > This is very close to the LTS concept, and this is mainly this kind of
> > statement I'm trying to get to let projects plan properly and not have
> > maven on their road too easily.
> > If properly defined it will not impact much maven dev but can save a lot
> > of time for enterprises and enable them to properly setup their projects in
> > time.
> >
> > So overall the definition points are still the same:
> >
> > 1. which versions are maintained (ie can get security fixes - new features
> > are not required to be in the box here)
> > 2. for how long
> > 3. what does mean version (major.minor.*, major.* for ex) in 1.
> >
> > "3.x will be supported for 3 more years when 4.x is out and maintained
> > major versions are guaranteed to get security fixes" is a kind of statement
> > which solves that - we can also use N=current and N+1 in the statement to
> > not stick it to 3 and 4.
> > "4.x is the current released branch, other branch will never be released
> > anymore" does not work for me for example IMHO (but we can put it on vote
> > if that's the community desire).
> >
> >
> >>
> >> FWIW, my employer’s repository manager still uses http since it is behind
> >> a VPN. After trying 3.8.1 I found I had to specify mirrors for all the
> >> repos even though they are not defined in pom’s. Apparently the fix also
> >> affects repositories defined in settings.xml.
> >>
> >
> > Yes because it is a mirror and wildcard one.
> > Using a custom global settings - to override default one - is a solution
> > if you know all http repositories you want to force to be blocked (can be
> > hard since you never know all of them by definition and mirroring does not
> > support custom patterns but can be a quick workaround to upgrade without
> > blocking builds).
> >
> >
> >>
> >> Ralph
> >>
> >> > On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau 
> >> wrote:
> >> >
> >> > Hmm, general/common asf way of doing is to move forward until users ask
> >> > (and if so any branch is patched while a pr is done).
> >> > If maven does not follow that practise it cant say "last version will
> >> get
> >> > the security fix" too because it means "we dont care of users, to get
> >> the
> >> > cve fix you will have to rewrite your build".
> >> > So at 

Re: [MJLINK] Create JavaFX application runtime

[Benjamin Marwell]

Glad it helped!

I was thinking maybe this should be filed as an issue at the javafx mailing
list.




On Thu, 1 Apr 2021, 22:59 Abhinay,  wrote:

> Hi Robert,
>
> The issue can be reproduced using theJavaFX application hosted on Github
> . It uses
> the maven-jlink-plugin to create a native image and fails.
>
> Ben's example hosted at https://github.com/alttpj/MemeforceHunt does
> work and I was able to successfully apply the same logic to my
> application. It needs the user to exclude the transitive dependency and
> provide a platform classifier to make it work, which IMO isn't very idle
> :). The working `pom.xml` is available here:
>
> https://github.com/abhinayagarwal/maven-jlink-plugin-javafx/blob/working/pom.xml
>
> -Abhinay
>
>
> On 2021/04/01 10:39:48, "Robert Scholte"  wrote:
>  > I'm missing a project to reproduce the issue, but I would expect that
> adding provided on those dependencies would fix it.>
>  >
>  > Robert>
>  > On 1-4-2021 08:16:06, Abhinay Agarwal  wrote:>
>  > Hi,>
>  >
>  > I tried to create runtime images for JavaFX applications using
> maven-jlink-plugin. The jlink:jlink goal fails as some JavaFX
> dependencies are "Automatic Modules". More information on this can be
> found here:
>
> https://github.com/abhinayagarwal/maven-jlink-plugin-javafx/blob/master/README.md>
>
>
>  >
>  > maven-jlink-plugin extracts all the modules from the module-path and
> adds them to the `--add-modules` list. The existing JavaFX Maven plugin
> adds only the base module to the `--add-modules` list overcoming this
> issue.>
>  >
>  > It would be great if the plugin can be extended to create runtimes
> for JavaFX applications.>
>  >
>  > Best regards,>
>  > Abhinay>
>  >
>

Re: [MJLINK] Create JavaFX application runtime

[Benjamin Marwell]

Also had troubles, but in the end I got it working. You can use my simple
GUI app for ROM manipulation as a template if you like.

https://github.com/alttpj/MemeforceHunt

It's a bit complicated as multiple OSes need to be supported.

HTH

Ben

On Thu, 1 Apr 2021, 08:16 Abhinay Agarwal,  wrote:

> Hi,
>
> I tried to create runtime images for JavaFX applications using
> maven-jlink-plugin. The jlink:jlink goal fails as some JavaFX dependencies
> are "Automatic Modules". More information on this can be found here:
> https://github.com/abhinayagarwal/maven-jlink-plugin-javafx/blob/master/README.md
>
> maven-jlink-plugin extracts all the modules from the module-path and adds
> them to the `--add-modules` list. The existing JavaFX Maven plugin<
> https://github.com/openjfx/javafx-maven-plugin>  adds only the base
> module to the `--add-modules` list overcoming this issue.
>
> It would be great if the plugin can be extended to create runtimes for
> JavaFX applications.
>
> Best regards,
> Abhinay
>

Re: Why no mvn daemon?

[Benjamin Marwell]

Add my +1 to Romain's.
As said, it is drop-in replacement most of the times, has a nice TUI, sane
defaults and speeds up your build.

If you haven't tried it yet, definitely do.

As for the resident memory: no software is ever finished, there will always
be something which can be done better. I don't mind, we can make it better
if we want to. That's why we're here in the first place, no? 

Haven't tried it on Jenkins nor GH actions, though. But I don't remember I
built shiro without mvnd. It's just so much faster using 3+ threads (plus
you *will* discover badly isolated tests). It also made me rework projects
at work into mire modules, which also lead to (imho) better design, as we
now have better encapsulated responsibility (and extra API projects for
CDI) PLUS faster builds.

- Ben


On Wed, 31 Mar 2021, 08:52 Romain Manni-Bucau, 
wrote:

> Le mer. 31 mars 2021 à 08:17, Hervé BOUTEMY  a
> écrit :
>
> > I think mvnd is not so well known [1]: I did never test it, I should
> > probably
> > do...
> >
> > and as incremental compilation discussion have started recently, we'll
> > need to
> > have a global discussion on evaluating and eventually mixing differents
> > ways of
> > improving build performance
> >
>
> +10, mvnd is awesome but solves the JVM pitfalls mainly, incremental
> support is per mojo to be optimized and both would be awesome.
> Basically optimizing the JVM + the runtime at the same time.
>
>
> >
> > when evaluating, I think we'll need to keep in mind one key aspect: from
> a
> > user perspective, which deployment and usage complexities does every
> > solution
> > bring for which performance improvement?
> >
>
> I think the main one maven should target is the "local" env (this is why
> mvnd fits so well) - by opposition of a remote server as gradle enterprise
> one which requires some infra, typically maven does not produce nexus byt
> stick on local software and I think it is sane to target it primarly.
>
>
> >
> > I feel that each solution that brings more expected performance
> > improvement
> > comes with at least a deployment complexity, perhaps sometimes use
> > complexity
> > also (per-project configuration, ...)
> >
>
> Hmm, here the only drawback of mvnd is to have the daemon running and
> consume the related memory but it is also why you use it so it is almost
> free for me - at least in usage. It is not like having to setup a server
> and configure the client in maven since launching mvnd instead of mvn you
> launch the mvnd client + the daemon if not already running so in terms of
> user experience you can alias mvn=mvnd and you will not notice the
> difference if you have enough memory.
> My typicall pitfall with 16G of ram is to have idea+chrome+minikube
> launched and mvd preventing a graalvm build (not enough memory)...but it is
> not mainstream too as memory consumption.
> Also there is a ticket about improving mvnd daemon auto-monitoring to kill
> itself if machine memory is too low and it is not used (
> https://github.com/mvndaemon/mvnd/issues/364) so this pitfall can
> disappear
> too.
>
>
> >
> > but currently mvnd is the only free solution publicly available: I should
> > definitely test it to better know it when we'll have more in depth
> > discussions
> > in the future
> >
> > Please keep posting your factual returns on experience: that's definitely
> > useful
> >
> > Regards,
> >
> > Hervé
> >
> > [1] https://github.com/mvndaemon/mvnd
> >
> > Le mardi 30 mars 2021, 22:32:37 CEST Romain Manni-Bucau a écrit :
> > > Le mar. 30 mars 2021 à 22:16, Jochen Wiedmann <
> jochen.wiedm...@gmail.com>
> > a
> > >
> > > écrit :
> > > > On Tue, Mar 30, 2021 at 7:58 PM Benjamin Marwell <
> bmarw...@apache.org>
> > > >
> > > > wrote:
> > > > > Other than that, I use mvnd at work and we never had problems on
> any
> > > > > project. We consistently save time without the need of adding the
> -T
> > > > > parameter manually. Another big question is probably: is there
> enough
> > > > > community demand to merge it into core?
> > > > >
> > > > > Tbh, I expected more mails on this thread.
> > > >
> > > > The question for me: Who's launching this mvnd? I wouldn't want to
> > > > have a dedicated server for that. However, if (for example) m2e would
> > > > launch it automatically when I open Eclipse, and perform a shutdown,
> > > > when Eclipse closes, then I'd be perfectly happy to use it.
&g

Re: Why no mvn daemon?

[Benjamin Marwell]

The class cache is also available since Java 8 in the OpenJ9 VM, which also
has faster startup times in most cases (for me).
Not sure if the scc is portable when using different Java language levels,
though.

But you can give it a try:

https://www.eclipse.org/openj9/docs/shrc/

Other than that, I use mvnd at work and we never had problems on any
project. We consistently save time without the need of adding the -T
parameter manually. Another big question is probably: is there enough
community demand to merge it into core?

Tbh, I expected more mails on this thread.



On Mon, 29 Mar 2021, 20:49 Romain Manni-Bucau, 
wrote:

> Le lun. 29 mars 2021 à 19:26, Markus KARG  a
> écrit :
>
> > Looking at the impressively reduced bootstrap times of modern JDKs with
> > features like Automatic AppCDS, I wonder if in the year 2021 this still
> > makes sense? In rather near future there will be native precompilation
> > available in most JDKs, effectively reducing bootstrap time to few ms. So
> > is it worth investing this time and complexity? In the past, yes, up to
> JDK
> > 8, it definitively was. But NOW?
> >
>
> Yep it makes sense more than ever IMHO because nothing actually changed for
> maven:
>
> 1. CDS impact on maven is more or less 0 since maven bootstrap everything
> in subclassloaders of the app loader and it is the only one able to benefit
> from it (+ it is not the main benefit of a daemon, it also bypasses
> resolution and all other steps the JVM will never do since it must be maven
> aware)
> 2. Making it GraalVM - ignoring the effort required to do it, run it on CI
> (in time) and maintain it - will not help much for the same daemon goal
> reason
>
> So is it worth doing a daemon -> clearly, this is what mvnd proves
> (leveraging a mvnd client in native mode when possible btw).
>
>
> >
> > -Markus
> >
> >
> > -Ursprüngliche Nachricht-
> > Von: Romain Manni-Bucau [mailto:rmannibu...@gmail.com]
> > Gesendet: Montag, 29. März 2021 12:21
> > An: Maven Developers List
> > Cc: Jason Dillon
> > Betreff: Re: Why no mvn daemon?
> >
> > Up 4 years later ;)
> >
> > Now mvnd exists and proves it is very interesting to have such a feature,
> > should it be something which can fit maven standard delivery?
> > If overall yes we can start by asking mvnd if it can be contributed with
> > main codebase and if not we can either decide to do our own (hope not ;))
> > or that maven does not care about caching/optimizations in its "core" and
> > that it is only done in extensions (I know 3 "main" ones as of today).
> >
> > Wdyt?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 9 mars 2016 à 23:58, Jeff Jensen <
> > jeffjen...@upstairstechnology.com>
> > a écrit :
> >
> > > Thanks!  It's running just fine.  :-)  It's very cool.  Really nice
> > > directory traversal and completion, colors, and commands/features I
> don't
> > > know yet!
> > >
> > > Very interesting timing diffs (for each casual test, I ran the command
> > for
> > > each multiple times to seed infra caches):
> > >  * on some asciidoc gen with "mvn generate-resources", it was about the
> > > same duration as CLI but after running each about 10 times, mvnshell
> > saved
> > > about 20% consistently (possibly due to JIT? besides directory
> traversal,
> > > this was the first things I did).  This was my key use case for
> wanting a
> > > "mvn server" - handling situations like this with repeated runs
> > (asciidoc,
> > > site, etc.).
> > >
> > >  * on a simple "mvn clean", mvnshell was about 2x faster than CLI.
> > >
> > >  * on a small module build, "mvn install" was about 20% faster over CLI
> > > (after a mvn clean for each).
> > >
> > > I look forward to trying more things.
> > >
> > > Nice to have, thank you Jason!
> > >
> > >
> > > On Wed, Mar 9, 2016 at 4:17 PM, Jason Dillon 
> > > wrote:
> > >
> > > > Jason, if you have a built version, do you mind adding it as a
> download
> > > to
> > > >
> > > > the release files?
> > > >
> > > > I can make a binary of this, though I do plan on fixing it up so that
> > > > folks can build it in the near future.
> > > >
> > > > Build up here for the moment:
> > > >
> > > >
> > >
> >
> https://www.dropbox.com/sh/yvt1g43r2pr2scj/AADqM__VhJaFf_x57OiUEZXva?dl=0
> > > >
> > > > gshell:master should be buildable with just central now, dangling ref
> > to
> > > > older version of jline for classifer=tests which was unused and
> > polluting
> > > > the build dependencies.
> > > >
> > > > —jason
> > > >
> > > >
> > > >
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For 

Re: Core IT failures with AdoptOpenJDK 11 OpenJ9, but not with HotSpot

[Benjamin Marwell]

Hi Falko,

I regularly work with OpenJ9 and encountered such issues. Sometimes it
is a coding error which does not lead to an error in Hotspot,
sometimes it is a J9 problem (e.g. JIT problems, class loading, etc.).

If you want to dig in, there are a few things you can try:
The JVM option -verbose:class will show every class loaded.
You could also enable verbose GC to see if the class got somehow unloaded [1].
If it was loaded and is then unloaded early, you can try to use
-Xnoclassgc [2] and see if that helps.
If it does, please write down the exact commit ID you are working with
and create a github issue [3] at OpenJ9.

Please note that those options might not work on a hotspot VM.

Let us know if you found anything!

- Ben

[1]: https://www.eclipse.org/openj9/docs/xverbosegclog/
[2]: https://www.eclipse.org/openj9/docs/xclassgc/
[3]: https://github.com/eclipse/openj9/issues/new/choose

Am So., 28. Feb. 2021 um 19:59 Uhr schrieb Falko Modler :
>
> Hi everyone,
>
> with AdoptOpenJDK 11.0.10, I'm getting three test failures/errors with
> current masters of maven and maven-integration-testing, but only with
> the OpenJ9 variant, not with HotSpot.
>
> Is this a known problem?
>
> [ERROR] Failures:
> [ERROR]
> MavenITmng5482AetherNotFoundTest>AbstractMavenIntegrationTestCase.runTest:255->testPluginDependency:49->check:93
> Url to ClassNotFoundAether was not found in output.
> [ERROR]
> MavenITmng5482AetherNotFoundTest>AbstractMavenIntegrationTestCase.runTest:255->testPluginSite:55->check:93
> Url to ClassNotFoundAether was not found in output.
> [ERROR] Errors:
> [ERROR]
> MavenITmng5958LifecyclePhaseBinaryCompat>AbstractMavenIntegrationTestCase.runTest:255->testBad:43
> » Verification
>
> Cheers,
>
> Falko
>
>
> -
> 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: JDeprscan plugin 3.0.0 ?

[Benjamin Marwell]

Sure, I can do that (again) :)

If you don’t mind, I would like to remove some deep nesting in a few
methods and extract some methods in other places as well,
because I might re-use some functionality in a later feature (for
scanning dependencies).

GH Actions would be a nice addition, too.
Maybe add some more ITs, some nits here and there,
and have some never-to-be-merged-branches of other plugins which use this plugin
so we have some more "real life" examples.

Oh, and docs, of course. I would like to add example output.
Please be sure to watch the bug tracker. ;-)

- Ben

Am Mi., 24. Feb. 2021 um 21:22 Uhr schrieb Robert Scholte
:
>
> Hi,
>
> I would like to see the plugin being able to use the ToolProvider, as done 
> with the jlink plugin.
> This will make it possible to run on on Windows too with a long list of 
> arguments.
>
> https://issues.apache.org/jira/projects/MJDEPRSCAN is empty (although I will 
> create one for the ToolProvider)
>
> Andres, we did discuss some improvements, not sure the status of it.
> Please file Jira tickets in case you're missing something.
>
> thanks,
> Robert
>
>
> On 24-2-2021 12:12:48, Andres Almiray  wrote:
> Indeed. Scanning compile & runtime dependencies is a feature Robert and I
> discussed back at JCrete 2018 if not mistaken.
> For comparison the Gradle jdeprscan plugin (for which I'm the author) has
> this feature.
>
> I believe this feature was even added to the issue tracker at some point.
>
> Cheers,
> Andres
>
> On Wed, Feb 24, 2021 at 12:08 PM Benjamin Marwell
> wrote:
>
> > Sounds interesting! Is anyone using this yet?
> >
> > Seems to be a reasonable default plugin for builds, additional to
> > -Dmaven.compiler.showDeprecation=true
> >
> > Probably another (maybe even more useful) goal would be to scan
> > compile- and runtime dependencies as well.
> >
> > Am Di., 23. Feb. 2021 um 20:40 Uhr schrieb Andres Almiray
> > aalmi...@gmail.com>:
> > >
> > > Hello everyone,
> > >
> > > While doing research on Maven plugins hat help you work with modular
> > > applications I couldn't fail to notice that the jdeprscan plugin is
> > listed
> > > at version 3.0.0-alpha-1 and its page marks it as prerelease since 2017
> > >
> > > https://maven.apache.org/plugins/maven-jdeprscan-plugin/
> > >
> > > As you may be aware this was the case for the jlink plugin which received
> > > some love from Benjamin, Sandra, Karl-Heinz and co. and was able to cross
> > > the 3.0.0 line in late 2020. It's actually now at 3.1.0.
> > >
> > > I wonder what's missing in the current state to turn it into 3.0.0? What
> > > can be done to make this plugin cross the 3.0.0 line as well? Happy to
> > help.
> > >
> > > Cheers,
> > > Andres
> > >
> > > ---
> > > Java Champion; Groovy Enthusiast
> > > http://andresalmiray.com
> > > http://www.linkedin.com/in/aalmiray
> > > --
> > > What goes up, must come down. Ask any system administrator.
> > > There are 10 types of people in the world: Those who understand binary,
> > and
> > > those who don't.
> > > To understand recursion, we must first understand recursion.
> >
> > -
> > 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: JDeprscan plugin 3.0.0 ?

[Benjamin Marwell]

Sounds interesting! Is anyone using this yet?

Seems to be a reasonable default plugin for builds, additional to
-Dmaven.compiler.showDeprecation=true

Probably another (maybe even more useful) goal would be to scan
compile- and runtime dependencies as well.

Am Di., 23. Feb. 2021 um 20:40 Uhr schrieb Andres Almiray :
>
> Hello everyone,
>
> While doing research on Maven plugins hat help you work with modular
> applications I couldn't fail to notice that the jdeprscan plugin is listed
> at version 3.0.0-alpha-1 and its page marks it as prerelease since 2017
>
> https://maven.apache.org/plugins/maven-jdeprscan-plugin/
>
> As you may be aware this was the case for the jlink plugin which received
> some love from Benjamin, Sandra, Karl-Heinz and co. and was able to cross
> the 3.0.0 line in late 2020. It's actually now at 3.1.0.
>
> I wonder what's missing in the current state to turn it into 3.0.0? What
> can be done to make this plugin cross the 3.0.0 line as well? Happy to help.
>
> Cheers,
> Andres
>
> ---
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.

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

Re: Maven compiler plugin Unsupported major.minor version

[Benjamin Marwell]

Hi Andrea,

thank you very much! I can confirm that this should not happen.
The error seems to be that the preparePaths method tries to parse the
existing module-info.class, but does not use the Toolchain provided
JDK for this.

The issue for this: https://issues.apache.org/jira/browse/MCOMPILER-455
cc to the dev mailing list. Issue is free to grab. Probably needs to
be fixed in plexus java, therefore also created
https://github.com/codehaus-plexus/plexus-languages/issues/64.

Am Mi., 10. Feb. 2021 um 12:51 Uhr schrieb Andrea Vacondio
:
>
> Ok, I created a super simple repo here https://github.com/torakiki/testme
>
> The pom is stripped to the minimum, here are the steps I use to reproduce:
> - git clone https://github.com/torakiki/testme.git
> - mvn compile
> - mvn compile
>
> The first compilation works, the second doesn't unless I clean.
> The error is pretty much the same:
> Execution default-compile of goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile failed:
> Unsupported major.minor version 59.0
>
> Using Maven 3.6.3
> My toolchain.xml:
> 
>   
> jdk
> 
>   15
>   openjdk
> 
> 
>   /usr/lib/jvm/jdk-15.0.1+9
> 
>   
> 
> My .mavenrc:
> export JAVA_HOME=/usr/lib/jvm/jdk-11
>
>
> I'm on Linux but I tested on Windows 7 and got the same result.
> A side note, while with this simple project the first compile works, the
> second doesn't, in my multi-module project with a parent module plus 8
> child modules it fails on the second module with 'mvn clean compile' from
> the parent.
>
> I hope it helps.
> Andrea
>
> Il giorno mar 9 feb 2021 alle ore 21:46 Benjamin Marwell <
> bmarw...@apache.org> ha scritto:
>
> > Hi,
> >
> > do you have a public repository to share? Have you tried other JVM
> > implementations? Have you tried cooling without preview features?
> >
> > On Mon, 8 Feb 2021, 15:30 Andrea Vacondio, 
> > wrote:
> >
> > > Thanks for the reply. I tried that and I got:
> > > [ERROR] Failed to execute goal
> > > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> > > (default-compile) on project pdfblack-model: Execution default-compile of
> > > goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> > failed: A
> > > required class was missing while executing
> > > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile:
> > >
> > org/codehaus/plexus/languages/java/jpms/ResolvePathsResult$ModuleNameSource
> > > [ERROR] -
> > > [ERROR] realm =
> > > plugin>org.apache.maven.plugins:maven-compiler-plugin:3.8.1
> > > [ERROR] strategy =
> > > org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> > > [ERROR] urls[0] =
> > >
> > file:/home/torakiki/.m2/repository/org/apache/maven/plugins/maven-compiler-plugin/3.8.1/maven-compiler-plugin-3.8.1.jar
> > > [ERROR] urls[1] =
> > >
> > file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-java/0.9.11/plexus-java-0.9.11.jar
> > > [ERROR] urls[2] =
> > >
> > file:/home/torakiki/.m2/repository/org/ow2/asm/asm/7.0-beta/asm-7.0-beta.jar
> > > [ERROR] urls[3] =
> > >
> > file:/home/torakiki/.m2/repository/com/thoughtworks/qdox/qdox/2.0-M9/qdox-2.0-M9.jar
> > > [ERROR] urls[4] =
> > >
> > file:/home/torakiki/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> > > [ERROR] urls[5] =
> > >
> > file:/home/torakiki/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> > > [ERROR] urls[6] =
> > >
> > file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-utils/2.0.4/plexus-utils-2.0.4.jar
> > > [ERROR] urls[7] =
> > >
> > file:/home/torakiki/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> > > [ERROR] urls[8] =
> > >
> > file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> > > [ERROR] urls[9] =
> > >
> > file:/home/torakiki/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.7.1/plexus-component-annotations-1.7.1.jar
> > > [ERROR] urls[10] =
> > >
> > file:/home/torakiki/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> > > [ERROR] urls[11] =
> > >
> > file:/home/torakiki/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> > > [ERROR] urls[12] =
> > >
> > file:/home/torakiki/.m2/re