Re: [VOTE] Release Apache Maven Invoker Plugin version 3.6.1

[Gary Gregory]

The current title of the ticket
https://issues.apache.org/jira/browse/MINVOKER-355 does not mention what is
being updated. Amusing to me :-p since you write about it here ;-)

Gary


On Wed, Mar 27, 2024, 2:45 AM Olivier Lamy  wrote:

> Hi,
> I'd like to release Apache Maven Invoker plugin version 3.6.1
> We solved 3 issues (well that's what Jira says):
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317525=12354446
>
> The main reason is an upgrade of Groovy, which have been done because
> of dependabot but helps to easily test projects with jdk22.
> So this one deserves a special hand-crafted Jira entry!
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2077/
>
> https://repository.apache.org/content/repositories/maven-2077/org/apache/maven/plugins/maven-invoker-plugin/3.6.1/maven-invoker-plugin-3.6.1-source-release.zip
>
> Source release checksum(s):
> maven-invoker-plugin-3.6.1-source-release.zip sha512:
>
> 3fd036cbeb88125a791ff6e3c849de7322b8d8afa65e4b96646a0d7a959069df7bdfba41d83ffafa096811d4ec794659ef44c0508da47ae8f9cbaf6e1eb6
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-invoker-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: release of maven-source-plugin

[Gary Gregory]

I'm glad to hear there is nothing fundamentally wrong. Thank you for the
detailed explanation.

Gary


On Sun, Mar 24, 2024, 3:40 PM Romain Manni-Bucau 
wrote:

> Hi,
>
> I think it is fixed for v4 serie.
> Main issue comes from the default v3 pom (
>
> https://github.com/apache/maven/blob/maven-3.9.2/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L113
> )
> which is no more a thing in v4 so the merge of the plugin executions does
> not happen the same and the issue disappeared.
> The easiest is likely to either let the default be merged and not use "jar"
> (implicit jar-no-fork instead) or just not use the default id
> (attach-sources) and skip the default one.
>
> So there is no source plugin issue (as the plugin will never fix it by "bug
> design") so no reason to hold a release IMHO.
>
> Guess it silently overrided the already built artifact for years - until we
> just fail cause it is a broken design - after this change of goal
> https://issues.apache.org/jira/browse/MNG-5940.
>
> So long story short: we are on track and release can be done I think.
>
> 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. 24 mars 2024 à 18:44, Gary Gregory  a
> écrit :
>
> > Hi All,
> >
> > As long as https://issues.apache.org/jira/browse/MSOURCES-143 is in
> > play, Commons will stay on a pre-3.3.0 version.
> >
> > I re-read the comments, I still don't know what we can do in Commons
> > to address this as this feels like some deep Maven Magic.
> >
> > Gary
> >
> > On Sun, Mar 24, 2024 at 11:48 AM Hervé Boutemy 
> > wrote:
> > >
> > > I'd like to release maven-source-plugin 3.3.1 to drop the umask
> > sensitivity
> > > during Reproducible Builds :)1
> > >
> > > but there are a few issues open
> > >  https://issues.apache.org/jira/projects/MSOURCES/versions/12353471
> > >
> > > they are related to https://issues.apache.org/jira/browse/MSOURCES-121
> :
> > I
> > > don't get what conditions made the build fail previously, but
> > MSOURCES-121
> > > make it fail now always.
> > > Should we just change the ERROR into WARNING?
> > > Should we do something smarter, for example not re-add if it's the same
> > file?
> > > Or warn only if the second file addition is different from the first?
> > Then
> > > replace instead of add?
> > >
> > > Please help clarifying and fixing this issue that seems ignored for a
> > long time
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: release of maven-source-plugin

[Gary Gregory]

Hi All,

As long as https://issues.apache.org/jira/browse/MSOURCES-143 is in
play, Commons will stay on a pre-3.3.0 version.

I re-read the comments, I still don't know what we can do in Commons
to address this as this feels like some deep Maven Magic.

Gary

On Sun, Mar 24, 2024 at 11:48 AM Hervé Boutemy  wrote:
>
> I'd like to release maven-source-plugin 3.3.1 to drop the umask sensitivity
> during Reproducible Builds :)1
>
> but there are a few issues open
>  https://issues.apache.org/jira/projects/MSOURCES/versions/12353471
>
> they are related to https://issues.apache.org/jira/browse/MSOURCES-121: I
> don't get what conditions made the build fail previously, but MSOURCES-121
> make it fail now always.
> Should we just change the ERROR into WARNING?
> Should we do something smarter, for example not re-add if it's the same file?
> Or warn only if the second file addition is different from the first? Then
> replace instead of add?
>
> Please help clarifying and fixing this issue that seems ignored for a long 
> time
>
> Regards,
>
> Hervé
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: [DISCUSS] Maven Dependency Plugin

[Gary Gregory]

The one I use the most from the command line is "tree" (
https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html)

I wish I could say "ignore test scope" to help me understand my runtime
dependencies better.

Gary


On Thu, Mar 21, 2024, 12:06 PM Tamás Cservenák  wrote:

> Howdy,
>
> I'd would be interested in how users and devs are using
> maven-dependency-plugin:
> https://maven.apache.org/plugins/maven-dependency-plugin/
>
> I collected some basic questions I'd like to have answered (but feel free
> to add more info!):
> - which goals are "must have" for you
> - which goals are "I never touched" for you (or, "I really don't need" or
> "never used" or "shrug")
> - what is missing?
>
> Thanks
> T
>

Re: User friendly release notes

[Gary Gregory]

What's wrong with using a changes.xml and the plug in? You have full
control.

Gary

On Wed, Mar 13, 2024, 7:25 PM Elliotte Rusty Harold 
wrote:

> On Wed, Mar 13, 2024 at 7:07 PM Andres Almiray  wrote:
> >
> > First, I’d suggest following a commit message convention. You may define
> your own or follow an existing one such as
> https://www.conventionalcommits.org/en/v1.0.0/
> >
>
> Please don't. I've seen this on too many projects, and it's a huge
> hassle for very little benefit. It would take significantly less time
> to manually write release notes for each release than to micro-format
> each and every commit message. Conventional commits is a huge time
> sink and way too much added friction. It discourages developers and
> decreases velocity with endless nit picking over formatting details
> that just don't matter.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven Core Plugins versioning

[Gary Gregory]

On Fri, Mar 8, 2024, 2:56 PM Michael Osipov  wrote:

> Am 2024-03-08 um 20:51 schrieb Gary Gregory:
> > IMO, the old version + 0.10 is a recipe for confusion and explanations
> for
> > this and that exception.
>
> I totally agree with you, that is a horrible compromise. Do you see a
> better way to reconcile both issues? I don't see any :-(
>

First let me say that I am a Maven fan and I don't want whatever I say here
to be viewed as criticism of tech or people.

>From a user's point of view, using "maven4" as a plugin prefix is both
obvious and simple to explain.

Using a plugin version of 4.x or (gasp) 40.x is not great, mostly because
my personal expectation is that it is the plugins' business to label
themselves with whatever version they wants. The point "this is a core plug
in, so..." is irrelevant to user's just like, as user, I should not need to
know that "cd" is builtin a shell vs. a program like "grep" which is not.

Gary


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

Re: [DISCUSS] Maven Core Plugins versioning

[Gary Gregory]

IMO, the old version + 0.10 is a recipe for confusion and explanations for
this and that exception.

Gary

On Fri, Mar 8, 2024, 2:40 PM Tamás Cservenák  wrote:

> Maarten,
>
> that would need a LOT of work, from maven plugin tools, IDEs and ALL the
> stuff that _assumes_ that a plugin artifactId is either "maven-xxx-plugin"
> or "xxx-maven-plugin".
> Never looked into, but I guess that would be quite a big impact.
>
> T
>
> On Fri, Mar 8, 2024 at 8:22 PM Maarten Mulders 
> wrote:
>
> > It might've been proposed and rejected before, but how about
> >
> > 1. maven4-compiler-plugin
> >
> > -or-
> >
> > 2. maven-compiler-plugin (with maven4/maven5/etc classifier)
> >
> > In both scenario's, we could still use semantic versioning as we do
> > right now, and as Maven users probably expect us to adhere to.
> >
> > Thanks,
> >
> >
> > Maarten
> >
> > On 08/03/2024 20:10, Michael Osipov wrote:
> > > Am 2024-03-08 um 17:20 schrieb Guillaume Nodet:
> > >> I'm slightly hesitant about that.
> > >> It seems to me plugins have mostly been compatible, so we very rarely
> > >> used a major version switch, but we do have plugins in 3.12.1 for
> > >> example, which would be translated to 3.0.12.1.  Not even sure how the
> > >> 4th digit is supported...
> > >> I wonder if an alternative proposal would be to do a 10 unit big jump
> > >> in the minor version to represent a breaking change, so from 3.12.1 to
> > >> 3.23.0
> > >
> > > A four number system would contradict our approach. I guess a ceil to
> > > the next 10 minor version is OK for that. So MSITE would be 3.20.x.
> > > Applies to all reporting plugins as well and major will stay at 3.
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [DISCUSS] Maven Core Plugins versioning

[Gary Gregory]

One issue from a non-Maven dev (me) is that I have no idea what is a
Maven "core" plugin vs. not. I would make that obvious for users, and
no, the "maven-" prefix does not make it obvious:

maven-clean-plugin -> maven-core-clean-plugin or maven4-core-clean-plugin

I'm also not sure the "plugin" suffix is needed:

maven-clean-plugin -> maven-core-clean or maven4-core-clean

My preference is "maven4-core-clean"

Gary

On Wed, Mar 6, 2024 at 8:59 AM Tamás Cservenák  wrote:
>
> Howdy,
>
> We have several topics that need to be discussed.
>
> I. Core Plugin Versioning
>
> History: When Maven2 was born, and started using plugins "as we know them
> today" (Maven 1 was a very different beast), the Core Plugin versions were
> started as 2.0 on purpose. Just check the Maven Central for historical
> versions, some examples:
> * clean
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/
> * compiler
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-compiler-plugin/
> * jar
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-jar-plugin/
> * surefire
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/
> * dependency
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/
>
> So, Maven2 "as a fresh release" got all new shiny 2.0 plugins at the
> beginning. Later on, when Maven3 came to existence, it was able to use
> Maven2 plugins, the plugins were slowly migrated to become "Maven 3
> plugins" (Maven2 could not use them anymore). This was denoted by the "3.x"
> major plugin version jump.
>
> So far, we have no 4.x plugin release of anything (M releases do not
> count). But my question is the following:
>
> How should we distinguish similar changes for Maven4?
>
> Explanation: when a plugin is migrated to Maven4 API, it will mean Maven3
> will NOT be able to use anymore (will be incompatible). Similarly as
> before, Maven4 CAN run the "Maven 3" plugins, and will retain this
> capability for some time. But other ways it does not work, nor never worked
> (Maven3 will not be able to run Maven4 plugin, just like Maven2 never ran
> Maven3 plugin).
>
> For me, the logical answer to this question is the use of major version
> 4.x. So just like it happened with Maven 2 to Maven 3 transition, a plugin
> version 2.x meant "Maven2 plugin", version 3.x of plugin meant "Maven3
> plugin" (Maven2 incompatible).
>
> As otherwise, if we start releasing Core plugins 4.x or 5.x, we will
> confuse the hell out of our users. At least that is what I think.
>
> II. Consequence: How to interpret Core plugin versions
>
> As can be seen above, so far the major version of the plugin was kinda
> showing "which Maven API level" is the plugin.
>
> So, it begs the question: HOW to interpret the Maven Core Plugin version?
>
> My interpretation was always: "shift it once left", meaning: Core plugin
> version "3.2.1" MEANS:
> - Maven API version: 3
> - Core Plugin version 2.1(.0)
>
> III. Consequence: How to express Core plugin "breaking change"?
>
> Today, everyone expects a "major version jump" to express breaking changes.
> BUT, as explained above, that would be totally misleading here, and would
> break the "customary law" that Major expresses Maven lineage.
>
> Ideas and opinions welcome.
>
> T

-
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

[Gary Gregory]

+1

Also good idea to remind folks to stay focused in a vote thread.

Gary

On Wed, Feb 28, 2024, 2:31 AM Benjamin Marwell  wrote:

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

Re: Use of jspecify in Maven

[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

Re: Java version for Maven 4?

[Gary Gregory]

The JVM and JRE don't let you escape out of JPMS. Presumably this is why we
had to redo a bunch of Maven modules for Log4j on the master branch
(unreleased WIP for 3.0).

Gary

On Tue, Feb 6, 2024, 6:43 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Le 2024-02-07 à 00 h 37, Gary Gregory a écrit :
> >
> > I have no use for JPMS today, I just don't want it to get in the way,
> > which is impossible since there is no --dont-bother-me-jpms flag...
> >
> That option exists at the level of the proposed Maven 4 API and has a
> JUnit test [1]. Plugins have the possibility to expose it. Where does
> the idea that JPMS will be imposed to everyone come from?
>
>  Martin
>
> [1]https://github.com/apache/maven/pull/1378#issuecomment-1925933959
>

Re: Java version for Maven 4?

[Gary Gregory]

I have no use for JPMS today, I just don't want it to get in the way, which
is impossible since there is no --dont-bother-me-jpms flag...

Gary

On Tue, Feb 6, 2024, 6:34 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Hello
>
> Le 2024-02-06 à 16 h 11, Hunter C Payne a écrit :
>
> > Nobody wants Jigsaw and the API improvements aren't enough to get
> > people to upgrade.
> >
> I cannot debate on whether a small minority, or a big minority, or a
> majority of developers want JPMS (a.k.a. Jigsaw), because I have no data
> for backing my claims. However, I have not see someone else providing
> reliable data (e.g. a serious study) for backing opposite claims
> neither. But one thing sure is that it is not "nobody wants Jigsaw",
> since at least two persons have expressed interest on this mailing list.
>
> Opinions based on personal experience are indicative of a market segment
> at best. Some peoples may base their opinions on their experience with
> Google or Amazon. My own personal experience is with space agencies,
> meteorological/oceanographical agencies, international standardization
> organizations, etc. They have different consumers, different
> constraints, different priorities. No consumer said directly "I want
> JPMS". But they do said "I want faster / more secure / more reliable
> software", and JPMS is one tool among others for achieving those goals.
> Not a panacea, but a significant help. For example, JPMS improves
> security by blocking at the JVM level all unauthorized accesses to
> internal packages. I'm not aware of any other non-deprecated solution
> providing this security at the JVM level. The few times that I spoke to
> peoples working in defence, they were very receptive to that kind of
> argument.
>
> My opinion is that as long as JPMS is so difficult to use in a
> non-trivial Maven or Gradle project, we cannot know if a relatively low
> adoption is really because of a lack of interest. Even if some
> communities are still not interested by JPMS no matter how easy, no
> personal experience can be generalized to the whole market. If a tool
> improving software security exists, I think it is a responsibility to
> make that tool accessible to developers who want to use it (again, I
> know that JPMS is not a panacea. But it helps).
>
> On the larger topic of API improvements in newer Java versions, Panama
> (coming final in Java 22) is a big feature given the important native
> libraries out there (e.g. for Artificial Intelligence). It may be of
> interest to Maven itself, e.g. for accessing C/C++ or Python build tools.
>
>  Martin
>
>

Re: Java version for Maven 4?

[Gary Gregory]

I like all 5 cents 

Gary

On Tue, Feb 6, 2024, 7:00 AM Tamás Cservenák  wrote:

> Howdy,
>
> For start, I think Martin assumed the "build time Java requirement for
> Maven4"?
>
> If so, my "vote" would be like:
> * build time: "latest LTS" (fixed at the moment when 4.0.0 GA happens,
> until then we just follow LTS), post GA "we adjust to latest LTS on each
> minor release (so 4.1, 4.2, etc)"
> * run time: this is the fun part: with Java 21 we already get a warning
> that `release=8` is deprecated. So, basically that above introduces a hard
> minimum limit (as given LTS allows). But I think we are with that, as it
> really makes sense that a Java build (and comprehension bla bla) tool
> _follow_ Java lifecycle, as things and new features are just flying past us
> (think JPMS support in Maven), etc.
>
> Example for similar setup that we already have:
> * maven-resolver: build enforces Java 21, but most of modules are still
> release=8, while some modules being release=11 and some are multi-release
> JARs (baseline is release=8 but support present for up to 17).
> * maven-indexer: here, dependency on Lucene 9.x (or 8.x? am unsure) made
> project 11+, but similarly as in resolver, Java 11+ HttpClient is used,
> etc. All modules are release=11.
>
> In both cases projects require "latest LTS" _for building the project_ (oh,
> and same is enforced for Maven, "latest Maven" is enforced). This just
> makes us have less work to figure out why (would) it fail on someone etc...
> We are sure requirements are fulfilled, and the one who builds it receives
> "sane" error messages as well, making him able to "fix" (by updating Java
> and/or Maven versions as needed). Again, all these serves _our benefit_, is
> not something done "just for fun".
>
> My 5 cents
> T
>
>
> On Tue, Feb 6, 2024 at 12:12 PM Olivier Lamy  wrote:
>
> > Personnaly (take it as a vote), I find this a good idea to say:
> > - 3.x: jdk 8 (whatever someone wants to release some fixes)
> > - 4.x: jdk 17
> >
> >
> > On Tue, 6 Feb 2024 at 20:50, Kévin Buntrock 
> > wrote:
> > >
> > > From my modest point of view : glued to old stack projects do not move
> at
> > > all. Why move to a new maven version if the one used works?
> > >
> > > Furthermore, I'm quite impressed by the number of projects starting in
> > java
> > > 21 for clients I was considering really shy new adopters. Java 21 is
> > here,
> > > works well, and gets adopted.
> > >
> > > Therefore, my vote goes to the current last LTS to run maven 4, a
> project
> > > not even released.
> > >
> > > Le mar. 6 févr. 2024 à 09:00, Benjamin Marwell  a
> > > écrit :
> > >
> > > > > 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 <
> > elh...@ibiblio.org>
> > > > > wrote:
> > > > >
> > > > > > On Mon, Feb 5, 2024 at 2:22 PM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Elliotte,
> > > > > >
> > > 

Re: Java version for Maven 4?

[Gary Gregory]

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?

[Gary Gregory]

Based on my experience, I think we (FOSS developers) can create our own
momentum by "simply" creating an EOL schedule. I have seen this EOL aspect
motivate the move away from Jetty 9 for example. Since Maven 4 is not out,
there is nothing to EOL in Maven 3 land unless you want to say that only
3.9.x is maintained and old versions are on an EOL schedule of x.

Gary

On Mon, Feb 5, 2024, 1:56 PM Elliotte Rusty Harold 
wrote:

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

Re: Java version for Maven 4?

[Gary Gregory]

FWIW, I work for a large company and our business unit just switched to
Java 17 after eons on Java 8. I think requiring Java 17 or 21 to run Maven
is fine. The existing tooling supports generating Java 8 binaries for those
who need it.

Gary

On Sun, Feb 4, 2024, 9:01 AM Elliotte Rusty Harold 
wrote:

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

Re: maven-javadoc-plugin CI is borked

[Gary Gregory]

The first thing I do when I see issues like this is check
www.githubstatus.com

Gary


On Wed, Jan 10, 2024, 7:31 AM Elliotte Rusty Harold 
wrote:

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

Re: [VOTE] Release Maven Surefire version 3.2.5

[Gary Gregory]

FWIW, we are users or Dependabot over at Apache Commons, so yes please.

Gary

On Mon, Jan 8, 2024, 3:15 AM Slawomir Jaranowski 
wrote:

> +1
>
> We should maintain GitHub releases notes, last is for 3.2.2
> Now we have outdated info which can be confusing for users.
> So we should be consistent - if we have one we should maintain or drop at
> all.
> In my opinion GitHub release notes are useful for user especially
> Dependabot use it.
> At least we can simply put a link to JIRA release notes which is not easy
> to find by users.
>
>
> sob., 6 sty 2024 o 21:05 Michael Osipov  napisał(a):
>
> > Hi,
> >
> > we solved 7 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12354100
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20resolution%20%3D%20Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-2055/
> >
> >
> https://repository.apache.org/content/repositories/maven-2055/org/apache/maven/surefire/surefire/3.2.5/surefire-3.2.5-source-release.zip
> >
> > Source release checksum(s):
> > surefire-3.2.5-source-release.zip
> > sha512:
> >
> >
> 5c894574b5c13813e5cdfec20f47d92e632f625aa53a135d22477b996998119b0c4fbfcabd0bdd35aed20be2d6fa221310e28ce6be6967411f48a7c19aa52dde
> >
> > Staging site:
> > https://maven.apache.org/surefire-archives/surefire-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Sławomir Jaranowski
>

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

[Gary Gregory]

FWIW, at work, we just went from Java 8 to 17, and we are a pretty
conservative organization.

Gary

On Sat, Dec 30, 2023, 10:44 AM Jorge Solórzano  wrote:

> I'm a bit confused here, why would anyone update Maven plugins in a project
> and NOT update Maven Core? Older versions of Maven are EOL, is expected
> that Maven Core is backward-compatible on minor releases so updating Maven
> Core should be straightforward. I might be missing something but I don't
> see a scenario where someone updates plugins but does not update Maven
> itself, I would expect the opposite, it should be more common to update
> Maven core than plugins (although that is just my perception).
>
> The question remains: Why should we use 3.5.4 instead of 3.6.3 as a minimum
> in plugins? don't get me wrong, I don't mind if we use 3.5.4 instead of
> 3.6.3 if the maintenance/support is the same, but knowing that CI uses
> Maven 3.6.3 and newer, and without knowing why plugins should be supported
> on 3.5.4, my vote will go to use 3.6.3.
>
> This discussion reminds me of the minimum required Java version, there was
> even an informal poll
>  with more than
> 80% asking for newer Java releases, and I would love to see Maven 4.0
> require at least Java 11, but here we are, one year later and still on Java
> 8 because some prefer to be working with Java 7 or even Java 6. The
> ecosystem is moving forward, SpringBoot, Quarkus, Jakarta EE, and some
> dependencies are slowly moving to at least Java 11, if a project requires
> Java 8 (for whatever reason), then it will remain on Maven 3.x, moving to
> Java 11 is conservative enough for Maven 4.0.
>
> Regards.
>
>
> On Sat, Dec 30, 2023 at 1:54 PM Michael Osipov 
> wrote:
>
> > Am 2023-12-30 um 11:42 schrieb Slawomir Jaranowski:
> > > sob., 30 gru 2023 o 10:43 Michael Osipov 
> > napisał(a):
> > >
> > >> Am 2023-12-30 um 09:24 schrieb Slawomir Jaranowski:
> > >>> pt., 29 gru 2023 o 18:40 Michael Osipov 
> > >> napisał(a):
> > >>>
> >  Am 2023-12-29 um 14:42 schrieb Slawomir Jaranowski:
> > > Hi,
> > >
> > > Last year we mark all Maven versions 3.6.x and older as EOL [1]
> > >
> > > But we still try to support minimal API version for Core Maven
> > Plugins
> > >> as
> > > 3.2.5
> > >
> > > I would like to  propose to sich it for at least to 3.6.3
> > >
> > > Reasonable reasons: (for me)
> > > - for standard CI build we use Maven 3.6.3 and newer
> > > - many of external plugins, like MojoHaus are switched to 3.6.3
> > > - we have a hacks in code to try support old version in plugin,
> > like
> > > in: EnhancedPluginDescriptorBuilder in plugin-tools [2], we can
> > cleanup
> > > such code
> > > - I don't believe to someone want to do more fixes for EOL Maven
> > >> version
> >  in
> > > plugins - so we should be a honest for users
> > > - and we should go forward
> > >
> > > [1] https://maven.apache.org/docs/history.html
> > > [2]
> > >
> > 
> > >>
> >
> https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-report-plugin/src/main/java/org/apache/maven/plugins/plugin/descriptor/EnhancedPluginDescriptorBuilder.java
> > >
> > 
> >  I remember that we had a discussion that the next base/API version
> >  should be 3.5.4 because it is the first version using
> >  org.apache.maven.resolver:maven-resolver-api [1]. Please don't
> confuse
> >  API compat with maintenance/support for a specific Maven version. I
> >  believe that we have made this clear more than once.
> > 
> >  Is thre anything specific fixed in 3.6.3 behavior you consider
> crucial
> >  which makes maintenance easier than with 3.5.4?
> > 
> > 
> > >>> I remember the discussion ... and next year we are still on 3.2.5
> > >>>
> > >>> I can not a list what was exactly improved in 3.6.3 against to 3.5.4,
> > >> but I
> > >>> see in mentioned code
> > >>>
> > >>>// clear() is required for maven < 3.6.2
> > >>>mojoDescriptor.getParameters().clear();
> > >>
> > >> This one is moot and incorrect. I will change the comment. The real
> > >> improvement has been done by Tamás in 4.0.0-alpha-1:
> > >>
> > >>
> >
> https://github.com/apache/maven/commit/cc51006f2973356a1046ae0757325d5e9be75327
> > >>
> > >>> So my question is:
> > >>>
> > >>> Why should we use 3.5.4 instead of 3.6.4 as minimum in plugins?
> > >>
> > >> If you can provide some real examples where 3.6.x is better/easier I
> > >> will happily accept it.
> > >>
> > >>
> > > There is https://github.com/apache/maven-help-plugin/pull/45
> >
> > I am aware of this one, but m-help-p isn't a core plugin, nor bound to a
> > lifecycle phase. For me, this is out of the ordinary.
> >
> > Let's make a compromise: I'd expect that you provide a list of all
> > plugins you consider core ones and this will be announced on dev@ that
> > in X weeks we will switch. Before 

Re: JDK 21 in CI

[Gary Gregory]

FYI: Somethings to watch out for based on testing Commons:

- Double toString() is less precise
- Odd differences in printing/parsing timestamps/times (unresolved so
far, see Commons ML)

Gary

On Sun, Oct 22, 2023 at 9:23 AM Elliotte Rusty Harold
 wrote:
>
> JDK 21 is now the both the latest and latest LTS release of Java so
> it's worth adding it to our build matrices in place of JDK 20. Worth
> noting: I've seen multiple other open source projects have new test
> failures on JDK 21 so there could be some fixup worth to do in some
> plugins before this is merged.
>
> I filed https://github.com/apache/maven-dependency-plugin/pull/346 to
> switch one project from JDK 20 to JDK 21 but there are a few doxzen
> others. I don't know if anyone has any tooling for search and replace
> and filing PRs across all the repos. If not, I should probably write
> some. It's just a one character change (20 --> 21) in
> .github/workflows/maven-verify.yml
>
> --
> 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: [VOTE] Release Apache Maven 3.9.5

[Gary Gregory]

Understood and thank you for the clarification. Seeing the original in a
VOTE thread gave it top much attention IMO.

Gary

On Sun, Oct 1, 2023, 4:13 PM Tamás Cservenák  wrote:

> Howdy,
>
> Yes, I agree.
>
> To rephrase, i meant more like "our focus should be Maven4", meaning, that
> IMHO we should not push new features into 3 anymore (similarly in resolver,
> all the new features like HTTP/2 are "parked" for resolver 2 [to be used
> with Maven 4]). I did not say "no more 3.x releases", just wanted to
> emphasize the "shift of focus".
>
> T
>
> On Sun, Oct 1, 2023 at 10:03 PM Gary Gregory 
> wrote:
>
> > From the peanut gallery, it feels odd to call anything 3.x in maintenance
> > mode when there is not a 4.0.
> >
> > Gary
> >
> > On Sun, Oct 1, 2023, 3:08 PM Tamás Cservenák 
> wrote:
> >
> > > Howdy,
> > >
> > > Note: This release completes the main goals of Maven 3.9.x lineage,
> among
> > > others moving to Java 8 and transition to latest Resolver 1.9.x
> features
> > > (new robust transports, local repository locking, provided checksums,
> > > remote repository filtering and more). Maven Resolver 1.9.x lineage is
> > > already in "bugfix only" (no new features) maintenance mode, and this
> > makes
> > > Maven 3.9.x lineage getting into this maintenance mode as well. I do
> > > foresee some more Maven 3.9.x releases with usual fluff (bug fixes,
> > > lifecycle plugin updates), but the focus should move to upcoming Maven
> 4,
> > > Resolver 2 and mvnd (at least when "core" is considered).
> > >
> > > ---
> > >
> > > We solved 8 issues:
> > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353460
> > >
> > > There are still a couple of issues left in JIRA:
> > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1995
> > >
> > > Dev dist directory (binary bundles updated):
> > > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.5/
> > >
> > > Source release checksums:
> > > apache-maven-3.9.5-src.zip sha512:
> > >
> > >
> >
> f1e7f36a6423c4f6d98e599120ede3a9f9f62448edeb2d49ffbdc05e36548190049bc83aae4f49e3305da1060d7b8e49477a55cb78b938951fd41ab3d360995f
> > >
> > > apache-maven-3.9.5-src.tar.gz sha512:
> > >
> > >
> >
> fd8f9c4f3c6af001d11146102ba491b248163cd45d8be16907f7dcdc763eef4a081a02286b28a74de7f48c3f377a0a4491d2fa9155c906466aa3c831a5b4ef8e
> > >
> > > Staged site:
> > > https://maven.apache.org/ref/3-LATEST/
> > >
> > > Draft for release notes:
> > > https://github.com/apache/maven-site/pull/458
> > >
> > > Guide to testing staged releases:
> > > http://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for 72h
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> >
>

Re: [VOTE] Release Apache Maven 3.9.5

[Gary Gregory]

>From the peanut gallery, it feels odd to call anything 3.x in maintenance
mode when there is not a 4.0.

Gary

On Sun, Oct 1, 2023, 3:08 PM Tamás Cservenák  wrote:

> Howdy,
>
> Note: This release completes the main goals of Maven 3.9.x lineage, among
> others moving to Java 8 and transition to latest Resolver 1.9.x features
> (new robust transports, local repository locking, provided checksums,
> remote repository filtering and more). Maven Resolver 1.9.x lineage is
> already in "bugfix only" (no new features) maintenance mode, and this makes
> Maven 3.9.x lineage getting into this maintenance mode as well. I do
> foresee some more Maven 3.9.x releases with usual fluff (bug fixes,
> lifecycle plugin updates), but the focus should move to upcoming Maven 4,
> Resolver 2 and mvnd (at least when "core" is considered).
>
> ---
>
> We solved 8 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353460
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1995
>
> Dev dist directory (binary bundles updated):
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.5/
>
> Source release checksums:
> apache-maven-3.9.5-src.zip sha512:
>
> f1e7f36a6423c4f6d98e599120ede3a9f9f62448edeb2d49ffbdc05e36548190049bc83aae4f49e3305da1060d7b8e49477a55cb78b938951fd41ab3d360995f
>
> apache-maven-3.9.5-src.tar.gz sha512:
>
> fd8f9c4f3c6af001d11146102ba491b248163cd45d8be16907f7dcdc763eef4a081a02286b28a74de7f48c3f377a0a4491d2fa9155c906466aa3c831a5b4ef8e
>
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/458
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: [DISCUSS] Major changed for 4.x

[Gary Gregory]

FWIW, I don't have an issue with XML in general, just the style we use.

An as aside, I find it amusing to watch the JSON folks reinvent each and
every wheel that XML has been using for decades.

Gary

On Tue, Aug 22, 2023, 10:34 AM Romain Manni-Bucau 
wrote:

> @Gary Gregory  thing is that we regularly hear
> that but nobody (as in "not significantly enough") embraced polyglot so
> means the verbosity is something you note but don't really care after all
> probably (not 100% sure it would help to solve that since attributes have
> kind of the same cons, ie make the parsing harder for generic consumers -
> and yes, in 202x xml is still not a first citizen in all languages ;)).
>
> 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 mar. 22 août 2023 à 15:55, Gary Gregory  a
> écrit :
>
>> One of Maven's pain points (a criticism hear at least) it's verbosity due
>> to the XML style where almost everything is an element. If I can more
>> succinctly list my dependencies, I would consider that a first win in this
>> new Era that will be highly visible to even the most casual user :-)
>> Hopefully this feature will be documented.
>>
>> Gary
>>
>> On Tue, Aug 22, 2023, 9:35 AM Romain Manni-Bucau 
>> wrote:
>>
>> > @Gary it is the stage "you can do whatever you like on your side", even
>> a
>> > pom.properties flavor would work. I assume one of the most requested
>> > feature will be to flatten attributes more than inlining them
>> > ("org.apache.foo:bar:1.2.3") but on the core side the challenge can be
>> to
>> > not break too fast all the "quick parsers" out there so likely staged
>> for
>> > v5 more than v4?
>> >
>> > 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 mar. 22 août 2023 à 14:58, Guillaume Nodet  a
>> écrit
>> > :
>> >
>> > > Not directly, but a simple extension could allow that...
>> > >
>> > > Le mar. 22 août 2023 à 12:33, Gary Gregory  a
>> > > écrit :
>> > >
>> > > > Hi all,
>> > > >
>> > > > Would any of these changes allow me to write my POM's XML
>> dependencies
>> > > in a
>> > > > single element where the GID, AID, and version are attributes (and
>> not
>> > > > child elements)?
>> > > >
>> > > > > > > > version="2.13.0" ... />
>> > > >
>> > > > In general, I want the XML to more OO, where XML elements are
>> objects
>> > and
>> > > > attributes are, well, attributes.
>> > > >
>> > > > Gary
>> > > >
>> > > > On Tue, Aug 22, 2023, 3:36 AM Guillaume Nodet 
>> > wrote:
>> > > >
>> > > > > Hi everyone,
>> > > > >
>> > > > > I hope you guys have been able to rest a bit during the summer
>> (for
>> > > those
>> > > > > that are back to work already)...
>> > > > >
>> > > > > I've pushed a few important PRs in the past months and I'd really
>> > like
>> > > to
>> > > > > get the discussion going around those.  Those are major changes
>> that
>> > I
>> > > > > think we should introduce in Maven 4 asap:
>> > > > >   * Better support for alternative POM syntaxes
>> > > > >   * Needed infrastructure to evolve the model
>> > > > >   * POM mixins
>> > > > >   * Support for XML entities / XInclude
>> > > > >
>> > > > > The first 3 changes are stacked onto each other. The first one is
>> the
>> > > > > support for alternative P

Re: [DISCUSS] Major changed for 4.x

[Gary Gregory]

One of Maven's pain points (a criticism hear at least) it's verbosity due
to the XML style where almost everything is an element. If I can more
succinctly list my dependencies, I would consider that a first win in this
new Era that will be highly visible to even the most casual user :-)
Hopefully this feature will be documented.

Gary

On Tue, Aug 22, 2023, 9:35 AM Romain Manni-Bucau 
wrote:

> @Gary it is the stage "you can do whatever you like on your side", even a
> pom.properties flavor would work. I assume one of the most requested
> feature will be to flatten attributes more than inlining them
> ("org.apache.foo:bar:1.2.3") but on the core side the challenge can be to
> not break too fast all the "quick parsers" out there so likely staged for
> v5 more than v4?
>
> 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 mar. 22 août 2023 à 14:58, Guillaume Nodet  a écrit
> :
>
> > Not directly, but a simple extension could allow that...
> >
> > Le mar. 22 août 2023 à 12:33, Gary Gregory  a
> > écrit :
> >
> > > Hi all,
> > >
> > > Would any of these changes allow me to write my POM's XML dependencies
> > in a
> > > single element where the GID, AID, and version are attributes (and not
> > > child elements)?
> > >
> > >  > > version="2.13.0" ... />
> > >
> > > In general, I want the XML to more OO, where XML elements are objects
> and
> > > attributes are, well, attributes.
> > >
> > > Gary
> > >
> > > On Tue, Aug 22, 2023, 3:36 AM Guillaume Nodet 
> wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > I hope you guys have been able to rest a bit during the summer (for
> > those
> > > > that are back to work already)...
> > > >
> > > > I've pushed a few important PRs in the past months and I'd really
> like
> > to
> > > > get the discussion going around those.  Those are major changes that
> I
> > > > think we should introduce in Maven 4 asap:
> > > >   * Better support for alternative POM syntaxes
> > > >   * Needed infrastructure to evolve the model
> > > >   * POM mixins
> > > >   * Support for XML entities / XInclude
> > > >
> > > > The first 3 changes are stacked onto each other. The first one is the
> > > > support for alternative POM syntaxes [2].  Note that no syntax is
> > > provided
> > > > by the PR, but an example extension is provided in the IT PR [3], the
> > > > reader being generated using the maven model and the IT's project is
> > > using
> > > > it [4].  The main idea is to provide an enhanced XML syntax if we
> want,
> > > as
> > > > it was discussed for the POM 5.0 [5].
> > > >
> > > > The second one provides the ability to make evolution to the model
> > > without
> > > > breaking the maven ecosystem.  The model has been stuck in 4.0.0
> > version
> > > > for 15 years or so, most of the things that would have required a
> > change
> > > > have been delayed or worked around.  The consumer POM that has been
> > > > introduced in Maven 4 is a first step, but I think we should go
> > further.
> > > > Please read the details in the PR [6].
> > > >
> > > > The third one is the support for POM mixins [7].  That one is still a
> > > > draft.  Two ITs have been written to leverage mixins using GAV or as
> > > > relative paths [8].  This definitely needs some work, but the current
> > > state
> > > > definitely shows that it can be implemented and introduced in the
> next
> > > > alphas.
> > > >
> > > > The last one is a relatively small PR [9] which brings support for
> XML
> > > > entities and XInclude loaded from external files.  All loaded files
> are
> > > > loaded using relative URLs (absolute URLs are rejected for security
> > > > reasons). The entities and xinclude bits are all inlined during the
> raw
> > > ->
> > > > consumer POM transformation so that they don't appear in
> > repositories.  I
>

Re: [DISCUSS] Major changed for 4.x

[Gary Gregory]

I should have said "primitive" attributes plus Strings (and maybe
Durations).

Gary

On Tue, Aug 22, 2023, 8:03 AM Elliotte Rusty Harold 
wrote:

> On Tue, Aug 22, 2023 at 10:33 AM Gary Gregory 
> wrote:
> ="2.13.0" ... />
> >
> > In general, I want the XML to more OO, where XML elements are objects and
> > attributes are, well, attributes.
>
>
> That dog won't hunt for reasons that are not specific to Maven. In OO
> attributes can be arbitrarily complex structured objects. In XML
> attributes are strings. There's a deep mismatch here that can't be
> bridged in any sane way.
>
>
> --
> 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] Major changed for 4.x

[Gary Gregory]

Hi all,

Would any of these changes allow me to write my POM's XML dependencies in a
single element where the GID, AID, and version are attributes (and not
child elements)?



In general, I want the XML to more OO, where XML elements are objects and
attributes are, well, attributes.

Gary

On Tue, Aug 22, 2023, 3:36 AM Guillaume Nodet  wrote:

> Hi everyone,
>
> I hope you guys have been able to rest a bit during the summer (for those
> that are back to work already)...
>
> I've pushed a few important PRs in the past months and I'd really like to
> get the discussion going around those.  Those are major changes that I
> think we should introduce in Maven 4 asap:
>   * Better support for alternative POM syntaxes
>   * Needed infrastructure to evolve the model
>   * POM mixins
>   * Support for XML entities / XInclude
>
> The first 3 changes are stacked onto each other. The first one is the
> support for alternative POM syntaxes [2].  Note that no syntax is provided
> by the PR, but an example extension is provided in the IT PR [3], the
> reader being generated using the maven model and the IT's project is using
> it [4].  The main idea is to provide an enhanced XML syntax if we want, as
> it was discussed for the POM 5.0 [5].
>
> The second one provides the ability to make evolution to the model without
> breaking the maven ecosystem.  The model has been stuck in 4.0.0 version
> for 15 years or so, most of the things that would have required a change
> have been delayed or worked around.  The consumer POM that has been
> introduced in Maven 4 is a first step, but I think we should go further.
> Please read the details in the PR [6].
>
> The third one is the support for POM mixins [7].  That one is still a
> draft.  Two ITs have been written to leverage mixins using GAV or as
> relative paths [8].  This definitely needs some work, but the current state
> definitely shows that it can be implemented and introduced in the next
> alphas.
>
> The last one is a relatively small PR [9] which brings support for XML
> entities and XInclude loaded from external files.  All loaded files are
> loaded using relative URLs (absolute URLs are rejected for security
> reasons). The entities and xinclude bits are all inlined during the raw ->
> consumer POM transformation so that they don't appear in repositories.  I
> wrote this PR as a possible alternative for mixins, that's the main reason
> why I include it in this discussion.
>
> I'm not necessarily looking for in-depth reviews of the PRs, but at least
> to find a consensus and general agreement on the way forward.
>
> Cheers,
> Guillaume
>
> [2] https://github.com/apache/maven/pull/1197
> [3]
>
> https://github.com/apache/maven-integration-testing/pull/276/files#diff-ffb3dec529cab94ebf3c5830444275ad2b2e4826fe1df843454882efadd2446c
> [4]
>
> https://github.com/apache/maven-integration-testing/pull/276/files#diff-8d7362e60d231ad8c5d4b7746873da2855d9cf1fd5aeeca9c143ed942bd94b38
> [5]
> https://cwiki.apache.org/confluence/display/MAVEN/POM+Model+Version+5.0.0
> [6] https://github.com/apache/maven/pull/1160
> [7]
>
> https://github.com/apache/maven/pull/1209/commits/211e27acd21a6cb8cee30ccd066499fc613a5c82
> [8]
>
> https://github.com/apache/maven-integration-testing/tree/b2642d74caae854051dc77acd19b972dfe66b1cd/core-it-suite/src/test/resources/mng-5102-mixins
> [9] https://github.com/apache/maven/pull/1205
>
> --
> 
> Guillaume Nodet
>

Re: Maven plugins and JPMS

[Gary Gregory]

Thanks for the feedback Romain.

I created https://github.com/moditect/moditect/issues/210

Gary

On Mon, Aug 21, 2023 at 7:32 AM Romain Manni-Bucau
 wrote:
>
> Hi Gary,
>
> Most of the module-path listed there is not intended to be used as module
> (maven plugin stack is a good example of that) so looks like moditech
> should support classpath option too as the JVM and not assume everything is
> a module from my window.
>
> 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. 21 août 2023 à 13:26, Gary Gregory  a
> écrit :
>
> > I forgot to say:
> >
> > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> > Maven home: /usr/local/Cellar/maven/3.9.4/libexec
> > Java version: 11.0.20, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk@11/11.0.20/libexec/openjdk.jdk/Contents/Home
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "13.5", arch: "x86_64", family: "mac"
> >
> > Gary
> >
> > On Mon, Aug 21, 2023 at 7:24 AM Gary Gregory 
> > wrote:
> > >
> > > Are there any plans for getting plugins to build with JPMS? For
> > > example, trying to generate a module description with the Moditect
> > > plugin fails for the Commons commons-build-plugin:
> > >
> > > Error:  Modules maven.model and maven.model.builder export package
> > > org.apache.maven.model.merge to module maven.shared.utils
> > >
> > > Details from
> > https://github.com/apache/commons-build-plugin/actions/runs/5925574518/job/16065261054
> > >
> > > [INFO] --- moditect-maven-plugin:1.0.0.Final:add-module-info
> > > (add-module-infos) @ commons-build-plugin ---
> > > [INFO] Running jdeps --generate-module-info
> > >
> > /home/runner/work/commons-build-plugin/commons-build-plugin/target/moditect
> > > --add-modules
> > plexus.utils,org.apache.commons.compress,com.google.guice,plexus.sec.dispatcher,maven.shared.utils,maven.model,org.apache.maven.resolver,plexus.cipher,maven.builder.support,maven.repository.metadata,aopalliance,plexus.component.annotations,
> > plexus.io
> > ,com.github.luben.zstd_jni,org.graalvm.sdk,plexus.classworlds,org.tukaani.xz,maven.settings.builder,maven.resolver.provider,failureaccess,maven.script.ant,maven.plugin.api,javax.annotation.api,plexus.ant.factory,org.slf4j,ant,maven.settings,plexus.archiver,org.graalvm.js,com.oracle.truffle.regex,org.graalvm.js.scriptengine,ant.launcher,org.eclipse.sisu.inject,org.apache.commons.lang3,snappy,com.google.common,
> > org.apache.commons.io
> > ,org.apache.maven.resolver.util,maven.core,org.eclipse.sisu.plexus,plexus.interpolation,org.graalvm.truffle,javax.inject,org.apache.maven.resolver.named,org.apache.maven.resolver.impl,org.apache.maven.resolver.spi,maven.artifact,maven.model.builder
> > > --module-path
> > /home/runner/.m2/repository/org/codehaus/plexus/plexus-utils/3.5.1/plexus-utils-3.5.1.jar:/home/runner/.m2/repository/org/apache/commons/commons-compress/1.23.0/commons-compress-1.23.0.jar:/home/runner/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/home/runner/.m2/repository/org/codehaus/plexus/plexus-sec-dispatcher/2.0/plexus-sec-dispatcher-2.0.jar:/home/runner/.m2/repository/org/apache/maven/shared/maven-shared-utils/3.3.4/maven-shared-utils-3.3.4.jar:/home/runner/.m2/repository/org/apache/maven/maven-model/3.9.4/maven-model-3.9.4.jar:/home/runner/.m2/repository/org/apache/maven/resolver/maven-resolver-api/1.9.14/maven-resolver-api-1.9.14.jar:/home/runner/.m2/repository/org/codehaus/plexus/plexus-cipher/2.0/plexus-cipher-2.0.jar:/home/runner/.m2/repository/org/apache/maven/maven-builder-support/3.9.4/maven-builder-support-3.9.4.jar:/home/runner/.m2/repository/org/apache/maven/maven-repository-metadata/3.9.4/maven-repository-metadata-3.9.4.jar:/home/runner/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/home/runner/.m2/repository/org/codehaus/plexus/plexus-component-annotations/2.1.0/plexus-component-annotations-2.1.0.jar:/home/runner/.m2/repository/org/codehaus/plexus/plexus-io/3.4.1/plexus-io-3.4.1.jar:/home/runner/.m2/repository/com/github/luben/zstd-jni/1.5.5-2/zstd-jni-1.5.5-2.jar:/home/runner/.m2/repository/org/graalvm/sdk/graal-sdk/
> > 22.0.0.2/graal-sdk-22.0.0.2.jar:/home/runner/.m2/repository/org/codehaus/plexus/plexus-classworlds/2.7.0/plexus-classworlds-2.7.0.jar:/home/runner/.m2/

Re: Maven plugins and JPMS

[Gary Gregory]

I forgot to say:

Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Maven home: /usr/local/Cellar/maven/3.9.4/libexec
Java version: 11.0.20, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@11/11.0.20/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "13.5", arch: "x86_64", family: "mac"

Gary

On Mon, Aug 21, 2023 at 7:24 AM Gary Gregory  wrote:
>
> Are there any plans for getting plugins to build with JPMS? For
> example, trying to generate a module description with the Moditect
> plugin fails for the Commons commons-build-plugin:
>
> Error:  Modules maven.model and maven.model.builder export package
> org.apache.maven.model.merge to module maven.shared.utils
>
> Details from 
> https://github.com/apache/commons-build-plugin/actions/runs/5925574518/job/16065261054
>
> [INFO] --- moditect-maven-plugin:1.0.0.Final:add-module-info
> (add-module-infos) @ commons-build-plugin ---
> [INFO] Running jdeps --generate-module-info
> /home/runner/work/commons-build-plugin/commons-build-plugin/target/moditect
> --add-modules 
> plexus.utils,org.apache.commons.compress,com.google.guice,plexus.sec.dispatcher,maven.shared.utils,maven.model,org.apache.maven.resolver,plexus.cipher,maven.builder.support,maven.repository.metadata,aopalliance,plexus.component.annotations,plexus.io,com.github.luben.zstd_jni,org.graalvm.sdk,plexus.classworlds,org.tukaani.xz,maven.settings.builder,maven.resolver.provider,failureaccess,maven.script.ant,maven.plugin.api,javax.annotation.api,plexus.ant.factory,org.slf4j,ant,maven.settings,plexus.archiver,org.graalvm.js,com.oracle.truffle.regex,org.graalvm.js.scriptengine,ant.launcher,org.eclipse.sisu.inject,org.apache.commons.lang3,snappy,com.google.common,org.apache.commons.io,org.apache.maven.resolver.util,maven.core,org.eclipse.sisu.plexus,plexus.interpolation,org.graalvm.truffle,javax.inject,org.apache.maven.resolver.named,org.apache.maven.resolver.impl,org.apache.maven.resolver.spi,maven.artifact,maven.model.builder
> --module-path 
> /home/runner/.m2/repository/org/codehaus/plexus/plexus-utils/3.5.1/plexus-utils-3.5.1.jar:/home/runner/.m2/repository/org/apache/commons/commons-compress/1.23.0/commons-compress-1.23.0.jar:/home/runner/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/home/runner/.m2/repository/org/codehaus/plexus/plexus-sec-dispatcher/2.0/plexus-sec-dispatcher-2.0.jar:/home/runner/.m2/repository/org/apache/maven/shared/maven-shared-utils/3.3.4/maven-shared-utils-3.3.4.jar:/home/runner/.m2/repository/org/apache/maven/maven-model/3.9.4/maven-model-3.9.4.jar:/home/runner/.m2/repository/org/apache/maven/resolver/maven-resolver-api/1.9.14/maven-resolver-api-1.9.14.jar:/home/runner/.m2/repository/org/codehaus/plexus/plexus-cipher/2.0/plexus-cipher-2.0.jar:/home/runner/.m2/repository/org/apache/maven/maven-builder-support/3.9.4/maven-builder-support-3.9.4.jar:/home/runner/.m2/repository/org/apache/maven/maven-repository-metadata/3.9.4/maven-repository-metadata-3.9.4.jar:/home/runner/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/home/runner/.m2/repository/org/codehaus/plexus/plexus-component-annotations/2.1.0/plexus-component-annotations-2.1.0.jar:/home/runner/.m2/repository/org/codehaus/plexus/plexus-io/3.4.1/plexus-io-3.4.1.jar:/home/runner/.m2/repository/com/github/luben/zstd-jni/1.5.5-2/zstd-jni-1.5.5-2.jar:/home/runner/.m2/repository/org/graalvm/sdk/graal-sdk/22.0.0.2/graal-sdk-22.0.0.2.jar:/home/runner/.m2/repository/org/codehaus/plexus/plexus-classworlds/2.7.0/plexus-classworlds-2.7.0.jar:/home/runner/.m2/repository/org/tukaani/xz/1.9/xz-1.9.jar:/home/runner/.m2/repository/org/apache/maven/maven-settings-builder/3.9.4/maven-settings-builder-3.9.4.jar:/home/runner/.m2/repository/org/apache/maven/maven-resolver-provider/3.9.4/maven-resolver-provider-3.9.4.jar:/home/runner/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/home/runner/.m2/repository/org/apache/maven/plugin-tools/maven-script-ant/3.9.0/maven-script-ant-3.9.0.jar:/home/runner/.m2/repository/org/apache/maven/maven-plugin-api/3.9.4/maven-plugin-api-3.9.4.jar:/home/runner/.m2/repository/javax/annotation/javax.annotation-api/1.2/javax.annotation-api-1.2.jar:/home/runner/.m2/repository/org/codehaus/plexus/plexus-ant-factory/1.0-alpha-2.1/plexus-ant-factory-1.0-alpha-2.1.jar:/home/runner/.m2/repository/org/slf4j/slf4j-api/1.7.36/slf4j-api-1.7.36.jar:/home/runner/.m2/repository/org/apache/ant/ant/1.10.13/ant-1.10.13.jar:/home/runner/.m2/repository/org/apache/maven/maven-settings/3.9.4/maven-settings-3.9.4.jar:/home/runner/.m2/repository/org/codehaus/plexus/plexus-archiver/4.7.1/plexus-archiver-4.7.1.jar:/home/runner/.m2/repository/org/graalvm/js/js/22.0.0.2/js-22.0.0.2.jar:/home/runner/.m2/repository/org/graalvm/regex/regex/22.0.0.2/regex-22.0.0.2.jar:/home/runner/.m2/repository/org/graalvm/js

Maven plugins and JPMS

[Gary Gregory]

Are there any plans for getting plugins to build with JPMS? For
example, trying to generate a module description with the Moditect
plugin fails for the Commons commons-build-plugin:

Error:  Modules maven.model and maven.model.builder export package
org.apache.maven.model.merge to module maven.shared.utils

Details from 
https://github.com/apache/commons-build-plugin/actions/runs/5925574518/job/16065261054

[INFO] --- moditect-maven-plugin:1.0.0.Final:add-module-info
(add-module-infos) @ commons-build-plugin ---
[INFO] Running jdeps --generate-module-info
/home/runner/work/commons-build-plugin/commons-build-plugin/target/moditect
--add-modules 
plexus.utils,org.apache.commons.compress,com.google.guice,plexus.sec.dispatcher,maven.shared.utils,maven.model,org.apache.maven.resolver,plexus.cipher,maven.builder.support,maven.repository.metadata,aopalliance,plexus.component.annotations,plexus.io,com.github.luben.zstd_jni,org.graalvm.sdk,plexus.classworlds,org.tukaani.xz,maven.settings.builder,maven.resolver.provider,failureaccess,maven.script.ant,maven.plugin.api,javax.annotation.api,plexus.ant.factory,org.slf4j,ant,maven.settings,plexus.archiver,org.graalvm.js,com.oracle.truffle.regex,org.graalvm.js.scriptengine,ant.launcher,org.eclipse.sisu.inject,org.apache.commons.lang3,snappy,com.google.common,org.apache.commons.io,org.apache.maven.resolver.util,maven.core,org.eclipse.sisu.plexus,plexus.interpolation,org.graalvm.truffle,javax.inject,org.apache.maven.resolver.named,org.apache.maven.resolver.impl,org.apache.maven.resolver.spi,maven.artifact,maven.model.builder
--module-path 

Re: [maven-source-plugin] 3.3.0 incompatible with 3.2.1

[Gary Gregory]

On Tue, Aug 15, 2023 at 2:17 PM Konrad Windszus  wrote:
>
> Hi,
> The error message is introduced with 
> https://issues.apache.org/jira/browse/MSOURCES-121 in 3.3.0:
> If you have two goals both attaching an artifact with the same classifier and 
> extension to the current project they will overwrite each other.
> Please check which classifiers are used for both goals:
> By default they should differ: 
> https://maven.apache.org/plugins/maven-source-plugin/test-jar-no-fork-mojo.html#classifier
>  and 
> https://maven.apache.org/plugins/maven-source-plugin/jar-no-fork-mojo.html#classifier
>
> If it can be reproduced without the same classifier parameter, please raise a 
> JIRA issue.

Hi,

We don't specify classifiers and we need to create two jars: the
source jar and the test source jar. I created
https://issues.apache.org/jira/browse/MSOURCES-143

TY!
Gary

>
> Thanks,
> Konrad
>
>
>
>
> > On 15. Aug 2023, at 19:48, Gary Gregory  wrote:
> >
> > On Tue, Aug 15, 2023 at 12:42 PM Michael Osipov  > <mailto:micha...@apache.org>> wrote:
> >>
> >> Am 2023-08-15 um 14:57 schrieb Gary Gregory:
> >>> Hi All,
> >>>
> >>> In Commons Parent [1], we want to configure child POMs to build both
> >>> source and test sources, so we say (among other things):
> >>>
> >>>   
> >>> maven-source-plugin
> >>> 
> >>>   
> >>> create-source-jar
> >>> 
> >>>   jar-no-fork
> >>>   test-jar-no-fork
> >>> 
> >>>   
> >>> 
> >>>   
> >>>
> >>> Which appears to no longer work in 3.3.0:
> >>>
> >>> [ERROR] Failed to execute goal
> >>> org.apache.maven.plugins:maven-source-plugin:3.3.0:jar-no-fork
> >>> (create-source-jar) on project commons-cli: Presumably you have
> >>> configured maven-source-plugn to execute twice times in your build.
> >>> You have to configure a classifier for at least on of them. -> [Help
> >>> 1]
> >>>
> >>> Am I missing something?
> >>
> >> Do you invoke two overlapping phases? E.g., package and install?
> >
> > I get the error with 'mvn clean package'
> >
> > Gary
> > PS: There is also a typo in the error message: maven-source-plugn ->
> > maven-source-plugin
> >
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> >> <mailto:dev-unsubscr...@maven.apache.org>
> >> For additional commands, e-mail: dev-h...@maven.apache.org 
> >> <mailto:dev-h...@maven.apache.org>
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> > <mailto:dev-unsubscr...@maven.apache.org>
> > For additional commands, e-mail: dev-h...@maven.apache.org 
> > <mailto: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-source-plugin] 3.3.0 incompatible with 3.2.1

[Gary Gregory]

On Tue, Aug 15, 2023 at 12:42 PM Michael Osipov  wrote:
>
> Am 2023-08-15 um 14:57 schrieb Gary Gregory:
> > Hi All,
> >
> > In Commons Parent [1], we want to configure child POMs to build both
> > source and test sources, so we say (among other things):
> >
> >
> >  maven-source-plugin
> >  
> >
> >  create-source-jar
> >  
> >jar-no-fork
> >test-jar-no-fork
> >  
> >
> >  
> >
> >
> > Which appears to no longer work in 3.3.0:
> >
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-source-plugin:3.3.0:jar-no-fork
> > (create-source-jar) on project commons-cli: Presumably you have
> > configured maven-source-plugn to execute twice times in your build.
> > You have to configure a classifier for at least on of them. -> [Help
> > 1]
> >
> > Am I missing something?
>
> Do you invoke two overlapping phases? E.g., package and install?

I get the error with 'mvn clean package'

Gary
PS: There is also a typo in the error message: maven-source-plugn ->
maven-source-plugin

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

[maven-source-plugin] 3.3.0 incompatible with 3.2.1

[Gary Gregory]

Hi All,

In Commons Parent [1], we want to configure child POMs to build both
source and test sources, so we say (among other things):

  
maven-source-plugin

  
create-source-jar

  jar-no-fork
  test-jar-no-fork

  

  

Which appears to no longer work in 3.3.0:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-source-plugin:3.3.0:jar-no-fork
(create-source-jar) on project commons-cli: Presumably you have
configured maven-source-plugn to execute twice times in your build.
You have to configure a classifier for at least on of them. -> [Help
1]

Am I missing something?

TY!
Gary
[1] https://gitbox.apache.org/repos/asf/commons-cli

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

Re: [CANCELED][VOTE] Release Apache Maven 3.9.4

[Gary Gregory]

Or a Set.

Gary

On Sat, Jul 29, 2023, 11:37 AM Gary Gregory  wrote:

> Sounds like a Java Map implementation is used that does not preserve
> insertion order.
>
> Gary
>
>
> On Sat, Jul 29, 2023, 11:03 AM Tamás Cservenák 
> wrote:
>
>> Yes, you are right.
>>
>> Seems only the /META-INF/MANIFEST.MF differs, only the Export-Package and
>> Import-Package entries like their ordering is different?
>>
>>
>>
>> T
>>
>> On Sat, Jul 29, 2023, 15:28 Gary Gregory  wrote:
>>
>> > Maybe figuring out the exact difference between the jars will give you a
>> > hint?
>> >
>> > Gary
>> >
>> > On Sat, Jul 29, 2023, 9:19 AM Tamás Cservenák 
>> wrote:
>> >
>> > > Sure,
>> > >
>> > > Will do that, thanks.
>> > >
>> > > What I don't understand is how I got 2 different jars in the first
>> place,
>> > > as i did not release twice (nor build from tag two times)...
>> > >
>> > > T
>> > >
>> > > On Sat, Jul 29, 2023, 11:58 Herve Boutemy 
>> wrote:
>> > >
>> > > > notice that you don't need to go to 3.9.5: rebuilding 3.9.4 from a
>> > clean
>> > > > local repository and Git checkout from tag with `mvn
>> -Papache-release
>> > > > deploy` will do the job that has to be re-done
>> > > >
>> > > > Regards,
>> > > >
>> > > > Hervé
>> > > >
>> > > > On 2023/07/29 08:47:48 Tamás Cservenák wrote:
>> > > > > Am cancelling the vote due Herve -1
>> > > > >
>> > > > > Will need to figure out how this happened.
>> > > > >
>> > > > > T
>> > > > >
>> > > >
>> > > >
>> -
>> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > > >
>> > > >
>> > >
>> >
>>
>

Re: [CANCELED][VOTE] Release Apache Maven 3.9.4

[Gary Gregory]

Sounds like a Java Map implementation is used that does not preserve
insertion order.

Gary


On Sat, Jul 29, 2023, 11:03 AM Tamás Cservenák  wrote:

> Yes, you are right.
>
> Seems only the /META-INF/MANIFEST.MF differs, only the Export-Package and
> Import-Package entries like their ordering is different?
>
>
>
> T
>
> On Sat, Jul 29, 2023, 15:28 Gary Gregory  wrote:
>
> > Maybe figuring out the exact difference between the jars will give you a
> > hint?
> >
> > Gary
> >
> > On Sat, Jul 29, 2023, 9:19 AM Tamás Cservenák 
> wrote:
> >
> > > Sure,
> > >
> > > Will do that, thanks.
> > >
> > > What I don't understand is how I got 2 different jars in the first
> place,
> > > as i did not release twice (nor build from tag two times)...
> > >
> > > T
> > >
> > > On Sat, Jul 29, 2023, 11:58 Herve Boutemy  wrote:
> > >
> > > > notice that you don't need to go to 3.9.5: rebuilding 3.9.4 from a
> > clean
> > > > local repository and Git checkout from tag with `mvn -Papache-release
> > > > deploy` will do the job that has to be re-done
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > On 2023/07/29 08:47:48 Tamás Cservenák wrote:
> > > > > Am cancelling the vote due Herve -1
> > > > >
> > > > > Will need to figure out how this happened.
> > > > >
> > > > > T
> > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > >
> > >
> >
>

Re: [CANCELED][VOTE] Release Apache Maven 3.9.4

[Gary Gregory]

Maybe figuring out the exact difference between the jars will give you a
hint?

Gary

On Sat, Jul 29, 2023, 9:19 AM Tamás Cservenák  wrote:

> Sure,
>
> Will do that, thanks.
>
> What I don't understand is how I got 2 different jars in the first place,
> as i did not release twice (nor build from tag two times)...
>
> T
>
> On Sat, Jul 29, 2023, 11:58 Herve Boutemy  wrote:
>
> > notice that you don't need to go to 3.9.5: rebuilding 3.9.4 from a clean
> > local repository and Git checkout from tag with `mvn -Papache-release
> > deploy` will do the job that has to be re-done
> >
> > Regards,
> >
> > Hervé
> >
> > On 2023/07/29 08:47:48 Tamás Cservenák wrote:
> > > Am cancelling the vote due Herve -1
> > >
> > > Will need to figure out how this happened.
> > >
> > > T
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [HEADS UP] Maven 3.9.4 plan

[Gary Gregory]

Hi all,

Is it worth including more detailed information in the release notes to
short circuit questions or concerns like this one?

I can't recall the last time I hear someone complaining about releasing too
soon ;-) AFAIAC, if any bug fix is made available in a release, that's a
good thing. I'm a fan on RERO though.

Gary

On Thu, Jul 20, 2023, 05:22 Tamás Cservenák  wrote:

> Howdy,
>
> mostly bug fixes in Resolver (that is shipped embedded within Maven), and
> some minor fixes in Maven itself:
> - resolver had 2 notable bugs, one in new BF collector (endless loop, SOEx)
> that blocked VSCode Maven integration users, and a "cluster" of multiple
> smaller bugs rendering provided checksum feature not quite usable. The 3rd
> bug was related to a new "lock diagnostic", that was emitting false
> (impossible) locks states. Rest is "general improvements" (manual route
> config, timeout default value change) and POM update. There is one change
> (undoes partially a change happened in 1.9.13) that is performance related,
> when locking is used.
> - maven had one bugfix (affecting users that may end up in endless loop in
> case of plugin error, for example asciidoctor plugin users), and there was
> a minor fix (bumping guava) for users who are unsavory of CVEs, mostly for
> their peace of mind (as Maven itself is AFAIK not affected by this CVE, but
> don't take my statement for granted).
>
> Of course, if you do not use any of these features like BF-collector,
> provided-checksums, trying to debug locking issues or having endless loops
> when some plugins fail, 3.9.4 will not make a big difference for you, but
> as Romain said, we just want to "move forward", by doing regular minor
> releases.
>
> Maven may receive more changes, as resolver is the first in the pipe, and
> as all releases, takes 3 days.
>
> Thanks
> T
>
> On Thu, Jul 20, 2023 at 4:18 AM Jeremy Landis 
> wrote:
>
> > What exactly does this small release improve so much that it warrants a
> > release this soon since 3.9.3?  We scaled 3.9.3 already a while ago and
> > haven't been any real issues that I can pinpoint that anything in this
> > would address and make better.   Clearly, I'm missing something here that
> > is critical.  We will upgrade right away but want to understand what this
> > gets us that is so important.
> >
> > -Original Message-
> > From: Tamás Cservenák 
> > Sent: Wednesday, July 19, 2023 11:42 AM
> > To: Maven Developers List 
> > Subject: [HEADS UP] Maven 3.9.4 plan
> >
> > Howdy,
> >
> > Plan is as follows:
> > 1. release Resolver 1.9.14
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.14
> > 2. release Maven 3.9.4
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.4
> >
> > I plan to start tomorrow morning (European morning). As usual, if anyone
> > objects, please speak up.
> >
> > Thanks
> > T
> >
> > -
> > 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

[Gary Gregory]

Playing a bit of devil's advocate here: while I've not used it, there is a
maven polyglot plugin that IIRC let's you author your POM in other formats.
But yeah, XML can be a pain but XML Schema is super handy in tooling and
editors. In the meantime, JSON is just reinventing the wheel...

Gary

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

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

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Gary Gregory]

Note that Apache Commons Compress supports pack200.

Gary

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

> Hi Jeremy. We're talking about the possibility of a drop-in replacement.
> But what you're suggesting requires alterations to the code, and having
> struggled with JAXB and its many unofficial plugins I can vouch for the
> difficulty in doing that.
> Perhaps it would have been easier if OpenJDK took responsibility for
> providing the packages and the plugin and setup a nice document somewhere
> to explain, but that's not what I found.
>
> Anyway, today I'm sitting with a version of izpack that depends on the
> Pack200 compression class removed from JDK17. Ok, so just add
> https://github.com/pack200/pack200 right? Oh, but izpack expects
> java.util.jar.Pack200 not io.pack200.Pack200. Should I update izpack? Yeah,
> and I've tried twice already, and will try again. Also tried rebuilding the
> izpack version from source, but it doesn't match with what was released.
> Next I'll try shading, etc, etc.
> Suffice to say there are issues.
> Delany
>
> On Tue, 6 Jun 2023 at 14:34, Jeremy Landis 
> wrote:
>
> > Delany,
> >
> > "You need toolchains if your code needs the JAXB classes removed in
> JDK11.
> > Delany"
> >
> > That isn't accurate.  You do not need toolchains for jaxb.  You need to
> > add the correct libraries.  I can understand that statement from a dev
> that
> > doesn't quite understand the history of EE inside java but its 100% easy
> to
> > do without adding toolchains.
> >
> > Jeremy
> >
> > -Original Message-
> > From: Delany 
> > Sent: Tuesday, June 6, 2023 1:33 AM
> > To: Maven Developers List 
> > Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
> >
> > You need toolchains if your code needs the JAXB classes removed in JDK11.
> > Delany
> >
> >
> > On Tue, 6 Jun 2023 at 01:54, Henning Schmiedehausen <
> > henn...@schmiedehausen.org> wrote:
> >
> > > To get this discussion a bit more back to actual substance:
> > >
> > > Do you still need toolchains with JDK 11/17? I set the release version
> > > to "8" (or anything else) in my builds, ripped out all the toolchains
> > > and it "just works". We have done this for Jdbi for ages (require Java
> > > 11+ as the build JDK; we even enforce "latest LTS" for releases) and
> > > compile to Java 8 bytecode. So far, we had zero complaints from users
> > > that the resulting releases do not work / cause problems on JDK 8.
> > >
> > > It seems to me that toolchains are only relevant if you need to
> > > compile to Java 1.6 or lower (shudder). The current LTS supports any
> > > version post-7 as release target.
> > >
> > > Am I missing something?
> > >
> > > Oh, I am totally cool with Maven 4 requiring Java 17 to run. In fact,
> > > this will give us an opportunity to actually use java 17 code to
> > > *write* maven, which in turn will collapse all of those thousand
> > > little domain objects into single line records. Can't wait for that.
> > > :-)
> > >
> > > The challenge for plugin writers will be to support Maven 3.x (mostly
> > > 3.8,
> > > 3.9) and 4 evenly. The current set of available modules and libraries
> > > makes that hard. A page with "use this to be compatible with that"
> > > would be helpful.
> > >
> > > -h
> > >
> > >
> > >
> > >
> > > On Mon, Jun 5, 2023 at 2:23 PM Delany 
> > wrote:
> > >
> > > > Your inclination to ignore points of the debate doesn't do your own
> > > > arguments any justice.
> > > > Multiple times it's been explained that raising the required runtime
> > > > JDK
> > > in
> > > > Maven 4 will not prevent you from
> > > > - building with a lower JDK (via toolchains)
> > > > - targeting a lower JDK (via the release property)
> > > > - building with Maven 3
> > > >
> > > > This is the main point of the debate, not the language.
> > > >
> > > > On Mon, 5 Jun 2023 at 21:42, Hunter C Payne
> > > >  wrote:
> > > >
> > > > > * Attract devsAbsolutely not.  If you want to attract devs, switch
> > > > > to a language that is actually growing (no I'm advocating for
> > > > > this).  That
> > > > isn't
> > > > > Java.  If anything, this will lose you devs.  The company I work
> > > > > for
> > > will
> > > > > be leaving Maven if you stop supporting Java8.  That's 300 users
> > > > > you
> > > lose
> > > > > right there.  That's just 1 company.  You will lose users in
> > > > > droves if
> > > > you
> > > > > stop Java8 support.  Many companies don't have/put enough
> > > > > resources
> > > into
> > > > > this type of upgrade.  Its hard to justify to the business and it
> > > > > makes lots of work for devs (expensive).  If it is cheaper to
> > > > > switch build systems that to upgrade the JVM, that's exactly what
> > > > > folks will do.  My company certainly will (not my decision so
> > > > > don't try to convince me,
> > > I'm
> > > > > not the one you have to convince).
> > > > >
> > > > > * CDS for non-OpenJ9-usersI'm not sure this is something that is
> > > > > really taken advantage of by Maven.  

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Gary Gregory]

I'm having trouble reading this email, hang on, let me adjust the rabbit
ears on my black and white television... ah better now. I'm sorry what were
you saying? :-)

Gary

On Mon, Jun 5, 2023, 07:22 Elliotte Rusty Harold  wrote:

> On Sun, Jun 4, 2023 at 10:59 AM Delany  wrote:
> >
> > I think the point I'm making is no-one wants to write in an older version
> > of the language they started writing in. Its tedious. Anyone who started
> > writing java11 code is going to have a hard time accepting they need to
> > write in java8, just as a java8 will bulk at writing in java5. Of course
> > for the oldies it just feels nostalgic.
> >
>
> Strongly disagree. I personally would strongly prefer to stick to Java
> *7*, although these days I use mostly 8 and 11. IMHO Java 8 and Java
> 11 were significant downgrades for clarity of code and ease of use.
> While there were some nice improvements in libraries and VM in those
> versions, they are completely swamped by the truly awful lambda syntax
> and the useless pain of the Java Platform Module System.
>
> Nor is it like we've finished the work of migrating onto Java 8. Just
> this past week I replaced some code that hasn't been needed since Java
> *1.4*.
>
> Migrating to still newer Java versions is a distraction from far more
> important work. We haven't even moved all the plugins off Java 7 yet.
> The burden of proof is on people who want to migrate to Java 17 to
> show how that will improve the project. That burden has not been met.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Gary Gregory]

I claim it is not wasteful to run unit tests on Java 8, 11, and 17, which
usually is the longest and most resource intensive part of a build.

How would you do that were it not for a GitHub matrix?

Gary

On Thu, Jun 1, 2023, 08:01 Tamás Cservenák  wrote:

> Howdy,
>
> From recent discussions I see an interesting pattern: it seems that people
> (even our PMCs) are using Maven in a way that is making sure that "same
> Java version" (I guess vendor + version) is used from "beginning" to "end".
>
> And "beginning" here means BUILDING (think workstations and CI and so on),
> while "end" means PRODUCTION (deploying the stuff into production).
>
> Why is that?
>
> We all know that even before this "speedup" of Java releases (so to say, up
> to Java 8) we did put extra effort into supporting this (running Maven on
> different Java versions and producing another bytecode output). One can:
> - use source/target compiler flags + animal sniffer (if on Java 8 or older)
> - use release compiler flag (if Java9+ used)
> - use toolchains
>
> Why does any of these above "does not work" for those "aligning Java from
> beginning to end"?
>
> With today's tools like sdkman, jenv, homebrew, jbang, mvnw (and who knows
> what) it is REALLY HARD to miss the automation of getting JDKs and tools
> (and keeping them up to date!!!) on workstations and CIs (deployment not
> counted here, but hopefully it is automated as well).
>
> Another point is that upcoming Maven 4 has tremendous improvements
> targeting toolchains.
>
> Finally, a bit of digression, but very much related thing: as Niels
> showcased on other thread in
> https://github.com/nielsbasjes/ToolChainsInCiBuilds
>
> The CI "matrix" build's Java version part can be moved into Maven itself.
> Personally, I always hated "matrix" as they explode very easily (size wise)
> but in MOST cases they really just "warm the oceans" (from HB) and do not
> do anything useful. I do keep _matrix useful_ for OS variations, but to
> rebuild the same commit over and over with Java8, Java11, Java17 only to
> "be sure" it will work, is really an overkill (and very wasteful). The
> added beauty of applying this pattern is that one can perform the whole
> build and testing (using different Javas) even on their own workstations.
>
> Does Maven miss some features (aside from those above) to make it possible
> for those "aligning" Java versions to move?
>
> Thanks
> T
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Gary Gregory]

(Non-binding chatter) I'm ok with Java 17 but since M4 feels like it's not
around the corner,  why not go for Java 21-EA and possibly learn even more
cool tech. Surely Java 21 which is an LTS version will be released as GA
before M4.

Gary

On Wed, May 31, 2023, 04:30 Guillaume Nodet  wrote:

> I'd like to resume this discussion about switching master to require JDK
> 17.
>
> These past days, I've been working on improving the usage of toolchains
> (first inside maven, but now completely in the maven-toolchains-plugin)
> with [1].  If we want to go further, we could simplify the selection by
> modifying the POM somehow to add a specific section, but I suspect most
> people will just use the release flag on the compiler to target bytecode.
> The only downside I see, beyond the additional configuration (though the
> goal is that users don't really have to generate/maintain the toolchains)
> is that the selection of the toolchain is done during the build, so that
> JDK profile based activation can not be used.  Note that the use of
> environment variables is also another way to work around, for example in
> github [2].
>
> I think with those improvements, requiring JDK 17 for master should be
> doable.  Any concerns of suggestions ?
>
> Cheers,
> Guillaume
>
> [1] https://github.com/apache/maven-toolchains-plugin/pull/14
> [2]
>
> https://github.com/B3Partners/kadaster-gds2/blob/b0cd5c392bc1f48dec11c83c828254a868264467/.github/ubuntu-toolchains.xml
>
> Le mar. 19 juil. 2022 à 18:25, Karl Heinz Marbaise  a
> écrit :
>
> > Hi to all,
> >
> > what do you think about using JDK17 as minimum requirement for running
> > the future Apache Maven 4.0.0 ?
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> 
> Guillaume Nodet
>

Re: GH issues and GH discussions

[Gary Gregory]

GH has the notion of "projects". Can't we use that?

Gary

On Mon, May 29, 2023, 09:50 Christoph Läubrich  wrote:

> I must confess "another central project" do not feels right:
>
> 1) there already is a "central" one everyone can easily find if
> searching for "maven github": https://github.com/apache/maven/
> 2) for "subprojects" its usually better to discuss things close where
> the code is
>
> Please note that some feature in GH do not work well across repositories
> (e.g. embedding code snippets in issues), also I don't see any advantage
> in scattering things around.
>
> Having a "central place "where contributors need to watch out and move
> things around or need to find out what the topic is about will make
> things more confusing, usually users are quite familiar with finding the
> right place.
>
> If one wants to group things more, it would be better to have an
> apache-maven organization on gihub and move all maven related there (the
> one can also have organization readme, pinned repositories and so on),
> this works quite well (e.g. Eclipse Foundation uses that approach).
>
> Am 29.05.23 um 13:50 schrieb Karl Heinz Marbaise:
> > Hi,
> >
> > I would suggest to create an umbrella project like:
> >
> > apache-maven-project
> >
> > on github and make it the central starting point for users... to ask
> > question (discussions) and optionally reroute them to the appropriate
> > github repos...
> >
> >
> > In general I agree to the tendency to use GH issues etc. instead of JIRA
> > based on the hurdles which exists (for a lot of reasons)...
> >
> > I second Hervé's suggestion to write down the needed/practical steps ...
> > and start going...what about things currently in JIRA and needed to be
> > migrated moved etc. ..We have a large history in JIRA...
> >
> >
> > To fulfill the formalism (also have documented the decision here on the
> > ML) we should start simply a VOTE to get an in general decision about
> > moving to GH-issues to leave JIRA behind... (not about the details) that
> > can be done later on...(for example using GH discussions etc.)
> >
> > afterwards we can decide with which project we would like to start and
> > fiddle the details.
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > On 27.05.23 09:22, Hervé Boutemy wrote:
> >> on testing GH issues migration from Jira: yes
> >>
> >> cache-extension [1] looks like an interesting example, given it has a
> >> small
> >> history with its Jira content
> >> we also have mvnd which uses GH issues from the start: testing and
> making
> >> clear practices on release and release notes could also be worked
> >> there [2]
> >>
> >> we'll need to write down what practical steps such a migration requires
> >> => probably a good fit for our Wiki, where we already organized
> >> equivalent
> >> updates in the past [3]
> >>
> >> on using GH discussions, I suppose this should be an independent next
> >> discussion
> >>
> >>
> >> [1] https://github.com/apache/maven-build-cache-extension
> >>
> >> [2] https://github.com/apache/maven-mvnd
> >>
> >> [3]
> >> https://cwiki.apache.org/confluence/display/MAVEN/Maven+Infrastructure
> >>
> >> Le vendredi 26 mai 2023, 09:44:00 CEST Olivier Lamy a écrit :
> >>> 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: GH issues and GH discussions

[Gary Gregory]

So much spam got into jira, it had to be locked down. You should see the
junk I mod out of the Xalan lists...

Gary

On Sat, May 27, 2023, 06:55 Elliotte Rusty Harold 
wrote:

> On Sat, May 27, 2023 at 6:11 AM Tamás Cservenák 
> wrote:
>
> > In general, my intention with bringing up this on Slack was motivated by
> > following reasons:
> > - we do have ML (signup needed),
> > - we do have JIRA (ask + approval + signup needed),
> >
>
>
> Good points all around.
>
> It occurs to me that not that long ago, Jira used to be open signup.
> is there a specific reason it changed? Does that reason still apply?
>
> --
> 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: GH issues and GH discussions

[Gary Gregory]

How does StackOverflow fit in if at all? Any pros and cons to share?

Gary

On Sat, May 27, 2023, 06:43 tison  wrote:

> > single point of entrance
>
> One last comment - it's a maintainer strategy to reduce the burden of
> monitoring multiple channels, and users generally gather to where their
> questions can be answered. But it's not a user strategy; they ask on the
> platform they are used to or closest to where the issue happens.
>
> So we may not say "a specific channel is _not_ supported, you should not
> ask there", but "most of the critical mass answering questions on platform
> X". Users make their choice reflected to where the critical mass work
> instead of being forced there.
>
> Best,
> tison.
>
>
> tison  于2023年5月27日周六 18:36写道：
>
> > I agree with Tamas' suggestion about the single point of entrance. Here
> > are several examples I experienced:
> >
> > 1. Apache SkyWalking[1] uses a single GH Issue to track all its issues
> and
> > Discussions for user questions and some rough ideas.
> > 2. Apache Pulsar[2] (I'm one of its committers) uses multiple GH Issues
> > for different repos, while for the tightly coupled site repo[3], I merge
> > the Issue tracker to the main repo. Single Discussions instance for all
> > "Pulsar" related questions.
> > 3. Apache Flink[3] (I'm one of its committers) uses a single JIRA project
> > for all its repos issue trackers, and only user@ and user-zh@ mailing
> > lists for user questions. Given their high responsiveness, it works well
> > for most of its users. Although other unofficial channels (with PMC
> members
> > there) (like DingTalk group or Slack workspace) exist to answer
> questions,
> > most users can be guided to the mailing list since it's still the most
> > active channel.
> >
> > Maven has a more complex repo cluster[4], and decisions can differ.
> >
> > Best,
> > tison.
> >
> > [1] https://github.com/apache/skywalking
> > [2] http://github.com/apache/pulsar
> > [3] http://github.com/apache/pulsar-site
> > [4] https://maven.apache.org/scm.html
> >
> >
> > tison  于2023年5月27日周六 18:28写道：
> >
> >> As a Maven user experiencing finding issue tracker recently[1][2], here
> >> are my two coins:
> >>
> >> 1. GitHub Issues help to get issues reported at the exact code repo.
> >>
> >> I found a usage question for ASF parent pom and find the code repo
> at[3],
> >> no GitHub Issues and I jump to the linked JIRA project MPOM, while the
> >> maintainer tells me it's not the correct place.
> >>
> >> I'm familiar with the mailing list way so it's not quite a trouble to
> ask
> >> here. But as time goes on, more and more developers and users get used
> to
> >> the GitHub platform. No matter if it's a good thing, it's a fact[4].
> >>
> >> So, for lowering the bar for user participation, I agree we can give GH
> >> issues and GH discussions a try.
> >>
> >> 2. GitHub is a proprietary service that is unreliable in an
> >> organization's view.
> >>
> >> I agree.
> >>
> >> Part of them can be resolved by we sync all traffic back to an ASF
> >> mailing list, like most of the ASF projects I participated in[5]. We can
> >> thus archive most of the context but since they are for archiving only,
> the
> >> readability can be bad.
> >>
> >> To sum up, as new generation developers and users grow and they are more
> >> familiar with the GitHub platform, before we find a competitor to
> compare
> >> with, and since we can more or less sync the conversation back to ASF
> >> INFRA, I'm +1 for giving GH issue and GH discussion a chance.
> >>
> >> But, in the other hand, if we can link the JIRA project and the code
> repo
> >> properly, given that our mailing list's and JIRA's responsiveness is
> high,
> >> it's good enough for me that we use GH PR for the patching process only,
> >> keep issues on JIRA and make most significant discussion on the mailing
> >> list only. While, GH discussions is a net win as a user forum just like
> a
> >> stack overflow tag - we can ensure no development decision is made there
> >> and everything is back to the mailing list.
> >>
> >> Best,
> >> tison.
> >>
> >> [1] https://issues.apache.org/jira/browse/MPOM-418
> >> [2] https://lists.apache.org/thread/t1f5wws6o4moy0p9kt4726ng5tsgzgln
> >> [3] https://github.com/apache/maven-apache-parent
> >>
> >> [4] https://www.goodreads.com/en/book/show/54140556
> >>
> >> [5]
> >>
> https://github.com/apache/pulsar/blob/a953027aad38c9f54e952133949280ec2f4c04e8/.asf.yaml#L84-L88
> >>
> >>
> >> Tamás Cservenák  于2023年5月27日周六 18:10写道：
> >>
> >>> Howdy,
> >>>
> >>> I do agree with Lukasz here...but
> >>>
> >>> In general, my intention with bringing up this on Slack was motivated
> by
> >>> following reasons:
> >>> - we do have ML (signup needed),
> >>> - we do have JIRA (ask + approval + signup needed),
> >>>
> >>> But all this is a high barrier for "one off" users, many of our users
> >>> want
> >>> to ASK us about something, so going through hoops and loops above (and
> >>> coming back 2 yr after with "please 

Re: [VOTE] Release Maven Checkstyle Plugin version 3.3.0

[Gary Gregory]

Ah, I was misled by the PR title then. Thank you for the clarification!

Gary

On Sat, May 20, 2023, 12:53 Elliotte Rusty Harold 
wrote:

> On Sat, May 20, 2023 at 3:33 PM Gary Gregory 
> wrote:
> >
> > Please don't change the default behavior to exclude test sources!
> > Non-binding -1 from me.
> >
>
> If you're referring to #76, that's not what it does. Test sources are
> still checked. What changes is that **generated code**, test and
> non-test alike, is not checked by default. An example would be Java
> code created when protoc compiles a .proto file. In this case the Java
> code is not hand-written and often doesn't follow other project
> conventions like line length. Furthermore it can't be fixed aside from
> changing the tool that generates the Java code.
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Checkstyle Plugin version 3.3.0

[Gary Gregory]

Please don't change the default behavior to exclude test sources!
Non-binding -1 from me.

Some tests serve as nice examples. I also want to enforce checkstyle for PR
sources consistently whether the changes are in main or test.

Please don't accepting this as is and make me edit dozens and dozens of
POMs.

Gary



On Sat, May 20, 2023, 11:12 Elliotte Rusty Harold 
wrote:

> https://github.com/apache/maven-checkstyle-plugin/pull/76 is in
> progress from an external developer and is, IMHO, a quite nice
> improvement. Might be worth waiting for this to be finished up.
>
> Otherwise, I found some minor issues in dependencies and the tests,
> but nothing blocking.
>
> On Fri, May 19, 2023 at 1:49 PM Michael Osipov 
> wrote:
> >
> > Hi,
> >
> > we solved 4 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223=12353164
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project+%3D+MCHECKSTYLE+AND+resolution+%3D+Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1946/
> >
> https://repository.apache.org/content/repositories/maven-1946/org/apache/maven/plugins/maven-checkstyle-plugin/3.3.0/maven-checkstyle-plugin-3.3.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-checkstyle-plugin-3.3.0-source-release.zip
> > sha512:
> >
> c27aa2dbc287764e097ab044a2780fc52e1afcf4a00a93793156df285f6595ed327fca1638a566c7673b3221dd2b98ee4d6ff54d1e93c5963f95ea0f58018067
> >
> > Staging site:
> >
> https://maven.apache.org/plugins-archives/maven-checkstyle-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
> >
>
>
> --
> 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: maven 3.9.x warnings

[Gary Gregory]

>From this user's POV, I feel these warning force me to spin my wheels: If I
have old plugins I can update their versions, and then I still get the
warnings, none of which I can do anything about. I can do something about
compiler warnings, I can do nothing about these.

I am left to explain up and down the food chain with hand handwaving why
these warnings are "ok" :-(

Gary


On Fri, May 19, 2023, 14:15 Henning Schmiedehausen <
henn...@schmiedehausen.org> wrote:

> Hi Tamas,
>
> Thanks for the quick response.
>
> On Fri, May 19, 2023 at 2:35 AM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > So, have a small local change, probably to go with 3.9.3.
> >
>
> [...]
>
>
> > [WARNING]  * org.basepom.maven:inline-maven-plugin:1.0.1
> > [WARNING]   Declared at location(s):
> > [WARNING]* org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml) @ line
> > 145
> > [WARNING]   Used in module(s):
> > [WARNING]* org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml)
> > [WARNING]   Plugin issue(s):
> > [WARNING]* Plugin descriptor should not contain these Maven
> artifacts:
> > [org.apache.maven:maven-artifact:3.8.4,
> > org.apache.maven:maven-settings-builder:3.8.4,
> > org.apache.maven:maven-repository-metadata:3.8.4,
> > org.apache.maven:maven-builder-support:3.8.4,
> > org.apache.maven:maven-core:3.8.4,
> > org.apache.maven:maven-resolver-provider:3.8.4,
> > org.apache.maven:maven-settings:3.8.4,
> > org.apache.maven:maven-plugin-api:3.8.4,
> > org.apache.maven:maven-model-builder:3.8.4,
> > org.apache.maven:maven-model:3.8.4]
> >
>
> This has *zero* meaning to the person running the build. And it still does
> not help the plugin author either. Because they (I) used the maven tool
> chain that was current at the point in time the plugin was created. There
> is still no actionable advice in here and there is no link to any
> documentation that tells a plugin author what the root cause is and what to
> do. Developers can now either do the "update everything and pray", an
> approach that worked exceedingly well with maven dependencies (look at all
> the incompatibilities with the 4.0.0-M components) or turn around to the
> maven mailing list asking "what should I do".
>
> You need to write documentation that helps your users. All the error
> messages and warnings and "this is wrong, fix it" messages to users do not
> help.
>
> This passive-aggressive attempt to surface problems in an obscure way to
> the end user and hope that "they file bugs with the plugin authors" is a
> terrible way to instigate change.
>
> I understand that there is limited developer time on Maven and this looks
> tempting as the "simplest path" but all you have accomplished is reduce
> trust. "maven suddenly reports problems that were not there before. Were
> those always there? Are my builds still good? Do my older projects still
> build?"
>
> Surfacing non-actionable warnings or errors to a non-audience is a no-no
> for any user experience; this is UX 101.
>
> For Jdbi, I still get complaints
> about org.apache.maven.plugins:maven-pmd-plugin,
> org.apache.maven.plugins:maven-javadoc-plugin,
> org.apache.maven.plugins:maven-source-plugin,
> org.apache.maven.plugins:maven-dependency-plugin.
> So even the official maven plugins have not gotten this right. Of course
> you can say "time heals all wounds". That is not true, because there is
> attrition by people switching tools. Heck, the ASF is now running a gradle
> enterprise server.
>
> You need to turn all of these warnings *OFF* and document the existence of
> the switch *and* give developer documentation what you expect plugin users
> *to do*. And then evangelize that. That will get your allies (which are the
> plugin authors that will *want* to fix the problems) to help you.  Not
> throw out another release with slightly tweaked warnings.
>
> Calling "maven 3.9 is about the journey to 4.0" is ridiculous. Maven 3.9 is
> a, by definition, fully backwards compatible release of Apache Maven 3.x.
> If you need a journey, then release Maven 4.0.0 as that stepping stone and
> then 5.0 as a backwards incompatible version. Maven 4 has been in
> development for many years and developer uptake will take a long time,
> especially if all old builds break left and right. You may even end up
> having to call it "mvn4" and not "mvn" to not break build scripts in
> countless organizations.
>
> -h
>
>
> >
>

Re: [VOTE] Release Apache Maven Dependency Analyzer 1.13.2

[Gary Gregory]

Non-binding +1

I tested git master with Apache Commons BCEL.

Gary

On Mon, May 1, 2023, 11:45 Herve Boutemy  wrote:

> +1
>
> Reproducible Build ok: reference build done with JDK 20 on *nix
>
> notice that using a LTS JDK would be better for such a release
>
> Regards,
>
> Hervé
>
> On 2023/04/30 22:27:43 Slawomir Jaranowski wrote:
> > Hi,
> >
> > We solved 3 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12353152
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-dependency-analyzer
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1933/
> >
> https://repository.apache.org/content/repositories/maven-1933/org/apache/maven/shared/maven-dependency-analyzer/1.13.2/maven-dependency-analyzer-1.13.2-source-release.zip
> >
> > Source release checksum(s):
> > maven-dependency-analyzer-1.13.2-source-release.zip - SHA-512 :
> >
> bd2042b32bb7794b9bc82f6904b143b7aff52f8000d93dcb4110dac0c3a2081a1a8b226469a8ee4374c9668d3c630434f2f12af1ad98a34e3e9aea2e2b757c1f
> >
> > Staging site:
> >
> https://maven.apache.org/shared-archives/maven-dependency-analyzer-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > --
> > Sławomir Jaranowski
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [HEADS UP] ASF/Maven parent poms

[Gary Gregory]

The abundance of Maven warnings is indeed annoying, but it seems like
normal growing pains while migration to new versions of plugins is in
progress ;-) which is a good thing overall IMO.

Gary

On Sat, Apr 15, 2023, 09:19 Konrad Windszus  wrote:

> I agree with that. For me a new ASF parent release is primarily necessary
> due to the fact that using the current version leads to quite some warnings
> when used with Maven 3.9.1.
>
> On 2023/04/15 12:31:07 Slawomir Jaranowski wrote:
> > sob., 15 kwi 2023 o 12:40 Michael Osipov 
> napisał(a):
> >
> > > Am 2023-04-14 um 13:09 schrieb Elliotte Rusty Harold:
> > > > Several of these seem like small red flags to me and while
> > > > individually each might be manageable, put them all together and I
> > > > vote for staying on 39 for a while longer.
> > > >
> > > > I'd also prefer that we complete upgrading the ~80 projects we
> > > > maintain to Java 8, Maven 3.2.5, and parent pom 39 before we start
> > > > moving some projects beyond that. That is, finish the work at hand
> > > > before committing to new work.
> > >
> > > I totally agree here. We haven't done the homework and want to start
> new
> > > topics. We should agressive retire what we do not intend to maintain or
> > > do at least a parent 39 cleanup.
> > >
> > >
> > I agree that we still have some homework to do.
> > The new version of parent is not a new topic for me, simply if we don't
> > upgrade parent in some of components to 39 we have the next version.
> > There are many situations where we bump parent by many numbers and it is
> > not bad.
> >
> > We always will have work to do, for me it is a never ending story.
> >
> > On the other hand ASF parent is not only used by the Maven project.
> > We did many works an plugins updates and should be published in AFS
> parent
> > - last was released at 2022-12-11
> >
> > When we do not publish parents regularly with incremental changes we
> cause
> > other projects to override used plugins versions.
> > So we and others manage plugin versions in many projects, not in one.
> >
> >
> > M
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> > --
> > Sławomir Jaranowski
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [HEADS UP] Release of surefire

[Gary Gregory]

Yes please, I get a raised eyebrow when a surefire and failsafe M version
is reviewed in a PR...

Gary

On Thu, Mar 9, 2023, 07:47 Elliotte Rusty Harold  wrote:

> On Thu, Mar 9, 2023 at 9:36 AM Slawomir Jaranowski
>  wrote:
> >
> > Hi,
> >
> > According to https://issues.apache.org/jira/browse/MNG-7725
> > I would like to release the next version of surefire.
> >
> > Next radical proposal: switch version to 3.0.0 and stop producing next
> > milestone like 3.0.0-M10.
> >
>
> Absolutely. Please do this.
>
> --
> 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: And while I'm on the subject of logging

[Gary Gregory]

This echoes IMO what a higher level app (Maven in this case) should do,
tell me when something unusual happens, like when something is taking a
long time. For us Windows users, the Explorer UI only pops up its progress
dialog when you are copying "a lot" or its taking "a long time", otherwise
it is quiet.

Question: when I ask mvn for -U behavior, I do like to see the download
logging, because I am asking for non-default behavior, I expect the extra
output.

As previously mentioned, there won't be change that makes everyone happy,
but IMO, there should be values I can put in MAVEN_ARGS to make 80% of
folks happy.

Gary

On Wed, Feb 22, 2023, 06:56 Guillaume Nodet  wrote:

> I do agree that logging all downloads is unneeded, and I do agree that the
> hanging case can happen quite often and one needs to be informed.
> However, both goals are not conflicting, we just need to enhance the
> logger/downloader to:
>   * print a single statement that it starts downloading things
>   * if a download is too slow (for example, nothing has been received since
> a few seconds), log a warning message
>   * log a summary when the download finished (like "Downloaded 5 artifacts
> from central and yyy repositories")
> It should not be very difficult to detect stalled downloads.
>
> Le mer. 22 févr. 2023 à 12:51, Romain Manni-Bucau 
> a
> écrit :
>
> > Eliotte I kind of fail to follow your reasoning because it literally
> means
> > don't log any info and just set default log level to ERROR which I don't
> > think will make anyone happy.
> > You also tend to think everything works all the time but network issues
> are
> > not work/fail kind of issue, the hanging case is really bothering and
> > downloading logs really help there when you can keep them.
> > Lastly downloads are not expected by maven after one build so being a bit
> > more verbose is not an issue and going outside the machine should likely
> > always be logged at the beginning these days.
> >
> > 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. 22 févr. 2023 à 12:40, Elliotte Rusty Harold  >
> > a
> > écrit :
> >
> > > On Tue, Feb 21, 2023 at 11:14 PM Romain Manni-Bucau
> > >  wrote:
> > > >
> > > >
> > > > except there is no issue, the download is just slow so why would
> > you
> > > > fail?
> > > > Hapoy to discuss a better solution but logging is a very satisfying
> > one.
> > >
> > > If there is no issue, don't log it. If being slow is an issue
> > > (arguably it isn't) report it when it's slow enough to be an issue,
> > > and only then. Too many developer tools don't finish the job by
> > > accurately diagnosing and reporting on errors. Instead they throw up
> > > their hands and say, "Oops. Something went wrong. Here's an
> > > incomprehensible dump of 50% of everything that happened. Maybe the
> > > thing that went wrong is in there somewhere. Maybe it isn't. You
> > > figure it out."
> > >
> > > Imagine a compiler that instead of identifying the offending line of
> > > syntactically incorrect code simply printed every line of source code
> > > as it parsed it, twice. Would anyone put up with such a compiler or
> > > would the bug reports overflow the Github issue tracker? Why do we
> > > accept that level of error reporting in Maven downloads?
> > >
> > > We shouldn't force people to do what computers can easily do. One of
> > > the things a computer can do is notice when one out of hundreds of
> > > dependencies is causing a problem, and blame  exactly that one
> > > artifact.
> > >
> > > --
> > > 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
> > >
> > >
> >
>
>
> --
> 
> Guillaume Nodet
>

Re: Halve the logging

[Gary Gregory]

Yeah, this is tricky IMO because I would rather know that something has
started and is taking a long time rather than staring at an apparently hung
console.

I think it is fine as it is now and --no-transfer-progress is helpful and
also -ntp work the same? AFK.

Gary

Gary

On Sun, Feb 19, 2023, 09:13 Tamás Cservenák  wrote:

> This is resolver, but the logging listener is provided by maven.
>
> I'd +1 for this, as message can be "Downloaded" or "Failed to
> download..." and imo line for starting of download is chatty, really not
> needed.
>
> T
>
> On Sun, Feb 19, 2023, 14:59 Elliotte Rusty Harold 
> wrote:
>
> > Typical log message in build:
> >
> > Downloading from central:
> >
> >
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> > Downloaded from central:
> >
> >
> https://repo.maven.apache.org/maven2/commons-lang/commons-lang/2.4/commons-lang-2.4.pom
> > (14 kB at 776 kB/s)
> >
> > Which plugin does this come from? Could we kill one of these messages
> > to cut the number of log line junk in half?
> >
> > --
> > 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: Reproducible builds between OSes

[Gary Gregory]

It seems to me that we need a separate EOL setting that is Maven specific,
just like git has a bunch of settings like autocrlf.

Gary

On Sat, Feb 11, 2023, 08:02 Elliotte Rusty Harold 
wrote:

> IMHO in 2023 the problem is that anything relies on a system dependent
> line.separator instead of explicitly specifying which bytes are
> output. I've fixed some instances of that antipattern over the years.
> Please file bugs on any plugin you notice that still does that.
>
> We can't have good reproducible builds until we wean ourselves off
> 1970s-era arcana like system dependent line separators.
>
>
> On Fri, Feb 10, 2023 at 1:42 PM Piotr P. Karwasz
>  wrote:
> >
> > Hi,
> >
> > At Log4j we have solved all the reproducibility problems mentioned on
> > the wiki page[1] and we are approaching the problem of reproducibility
> > between different OSes.
> >
> > My goal is for the following procedure to work regardless of the
> > operating system of the user:
> >
> > 1. a user checks out a tagged release from the Git repository,
> > 2. the user runs the Maven Wrapper: 'mvn package'
> > 3. the user checks the SHA256 of the resulting JAR file with the one
> > from Maven Central.
> >
> > The only problem I have encountered so far is the difference between
> > line endings on Windows and UNIX systems.
> >
> > The line endings of static resources can be easily fixed using a
> > `.gitattributes` file, but the line endings of resources generated by
> > plugins may vary. Many plugins respect `System.lineSeparator()`, but
> > setting the `line.separator` Java system property on the command line
> > is no trivial task and it can not certainly be done in
> > `.mvn/jvm.config`.
> >
> > What do you think about introducing a POM-like system property (e.g.
> > `project.build.lineSeparator`) that would allow setting
> > `line.separator` using a simple `-Dproject.build.lineSeparator=LF` or
> > `-Dproject.build.lineSeparator=CRLF`? Ideally this could be a real POM
> > property, but I am afraid that by the time the POM is resolved,
> > `System.lineSeparator()` is already initialized.
> >
> > Piotr
> >
> > [1]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Surefire version 3.0.0-M8

[Gary Gregory]

What happens if you try Java 8 and 11 and nothing else changes?

Gary


On Tue, Jan 10, 2023, 02:51 Enrico Olivelli  wrote:

> I am seeing this problem
>
> This test Surefire1295AttributeJvmCrashesToTestsIT.test is
> consistently failing on my laptop.
> I am running on JDK17 on Mac ARM
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /Users/enricoolivelli/maven
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime:
> /Users/enricoolivelli/.sdkman/candidates/java/17.0.5-tem
> Default locale: en_IT, platform encoding: UTF-8
> OS name: "mac os x", version: "13.0", arch: "aarch64", family: "mac"
>
> I will try to re-run in with a different JVM
>
> Enrico
>
> Il giorno lun 9 gen 2023 alle ore 13:05 Petr Široký
>  ha scritto:
> >
> > +1 (non-binding). Tested with several projects on Linux. No issue found.
> >
> >
> >
> > --- Original Message ---
> > On Saturday, January 7th, 2023 at 14:07, Michael Osipov <
> micha...@apache.org> wrote:
> >
> >
> > >
> > >
> > > Hi,
> > >
> > > We solved 18 issues:
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12351809
> > >
> > > There are still a couple of issues left in JIRA:
> > > https://issues.apache.org/jira/issues/?jql=project %3D SUREFIRE AND
> resolution %3D Unresolved
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1846/
> > >
> https://repository.apache.org/content/repositories/maven-1846/org/apache/maven/surefire/surefire/3.0.0-M8/surefire-3.0.0-M8-source-release.zip
> > >
> > > Source release checksum(s):
> > > surefire-3.0.0-M8-source-release.zip
> > > sha512:
> > >
> d2a533fc8c89f92c40b20c104beb8da69a45683821cb5432e99e2d12b469067659b117e140ddf66e8ba71f12b1af7aa07207d279289957a52940162ce27599ba
> > >
> > > Staging site:
> > > https://maven.apache.org/surefire-archives/surefire-LATEST/
> > >
> > > Guide to testing staged releases:
> > >
> https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [HEADS UP] Maven 3.8.7

[Gary Gregory]

Is there something I can unzip and test?

Gary

On Sun, Dec 18, 2022, 08:17 Michael Osipov  wrote:

> Folks,
>
> Maven 3.8.7 is almost complete, a few regressions have been addressed.
>
> I'll leave people this business week to work/discuss on potential issues
> for 3.8.x. My plan is to start the release around 2022-12-24. Hoping
> that this well be the last relase of the 3.8.x line.
>
> Michael
>
> -
> 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 4.0.0-alpha-3

[Gary Gregory]

Where can we read about the expected level of compatibility with Maven 3?

TY!
Gary


On Mon, Dec 12, 2022, 08:19 Guillaume Nodet  wrote:

> I've staged a release candidate at:
>   https://repository.apache.org/content/repositories/maven-1835
>
> Source distributions:
>
> https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-3/source/
>
> Binaries are available at:
>
>
> https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-3/binaries/
>
>
> https://repository.apache.org/content/repositories/maven-1835/org/apache/maven/apache-maven/4.0.0-alpha-3/
>
> Release notes:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12352443
>   https://github.com/apache/maven/milestone/1?closed=1
>
> Github release:
>   https://github.com/apache/maven/releases/tag/maven-4.0.0-alpha-3
>
> Please review and vote !
>
> --
> 
> Guillaume Nodet
>

Re: Maven and the Path API

[Gary Gregory]

Nice!

Gary

On Wed, Nov 23, 2022, 14:31 Guillaume Nodet  wrote:

> That's done in the v4 api.
>
> Le mer. 23 nov. 2022 à 19:37, Christoph Läubrich  a
> écrit :
>
> > Currently maven is bound to the Java File API, e.g.
> >
> > org.apache.maven.project.MavenProject.getBasedir()
> > org.apache.maven.project.MavenProject.getFile()
> >
> > while others uses Strings, e.g.
> >
> > org.apache.maven.project.MavenProject.addCompileSourceRoot(String)
> >
> > I wonder if it would be good to move Maven towards Java Path API using
> > Path at all these places (and probably related projects as well for
> > example [1]).
> >
> > [1] https://github.com/codehaus-plexus/plexus-utils/issues/224
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> 
> Guillaume Nodet
>

Re: [DISCUSS] Quo Vadis Maven Site

[Gary Gregory]

I really like that Maven provides the option to build a site, no matter
what technological relics it uses.

I do see two site use cases that are worth teasing out:

I want to build and publish a site for public consumption.

I want a local folder full of HTML reports for my review as a developer.
For example, JaCoCo, PMD, SpotBugs, Checkstyle. Yes, I could look at the
raw output from each plugin and I do that as well. If that raw output,
usually XML is human readable enough, I might not need the HTML.

All of this to say that there is still value in the whole stack IMO and it
would be a shame to lose it.

Gary

On Wed, Nov 16, 2022, 18:14 Tamás Cservenák  wrote:

> Howdy,
>
> So, here is "stage No1" that pretty much already delivers what existing
> site had:
> https://github.com/jaxen-xpath/jaxen/pull/145
>
> Point is: before, it was two runs to build and site (and took a total of 2
> minutes), while now it is 10 seconds more than "build artifacts" (35 sec).
>
> To build it: mvn clean install -P site
>
> Just to clear up: I am NOT promoting JBake nor any other static site
> generator, this was just an exercise to see if we can do simple maven sites
> without site plugin.
>
> HTH
> T
>
> On Wed, Nov 16, 2022 at 7:28 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > I am pretty much convinced it can do all that site is able to do.
> > Let's see the jaxen conversion result once done.
> >
> > Also, this would not push anything, I always wrote (at least intended to)
> > "static site tool is left at discretion of user", I just mentioned JBake
> as
> > something that can buy out functionality of the maven-site-plugin, that's
> > all.
> >
> > T
> >
> > On Wed, Nov 16, 2022 at 7:25 PM Benjamin Marwell 
> > wrote:
> >
> >> 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 <
> >> elh...@ibiblio.org>
> >> > 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 

Re: Maven 3 API, backwards compatibility

[Gary Gregory]

As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or 11 and
adopt JPMS to better define its public APIs.

Gary

On Wed, Nov 16, 2022, 05:06 Tamás Cservenák  wrote:

> Yes, to define rules is quite easy, but to make our users to obey them is
> tricky :D
>
> In general, I guess, we should. For this reason JapiCmp has been used in
> Resolver since 1.9.0 (as noted on refd page end).
>
> But while this was "kinda simple" to achieve in Resolver, I am really
> unsure if it is doable in Maven (sans 4 API) :(
>
> Ultimately, this was the whole reason for API:
> - users "grabbed" whatever could get hold on and used
> - maven progress was really hindered by this, as that meant modifying (even
> internal) interfaces without breaking clients was impossible, so we went
> with tricks, and more tricks and even more tricks that now pays back.
>
> The other day we had a question on ML about 4-alpha compatibility breakage,
> and from mail it was clear that the package of the referred class was
> having "internal" in it. I mean, developers should really take care of what
> they import.
>
> This is another huge plus for Takari lifecycle, it FORBIDS compilation
> against "encapsulated" internal classes
>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>
> T
>
> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus  wrote:
>
> > I guess this is the easy part, the tricky question remains: Do we need to
> > make sure that all Maven 3 API interfaces/classes stay 100% backwards
> > compatible until we reach 4.100/5.0/whatever?
> >
> > This wasn't handled consistently in master till now, e.g. the classes
> > generated from
> >
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> > are now immutable, i.e. lack setter methods in Maven 4.
> > My change in
> >
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> > was not backwards compatible (removed a method on an interface which may
> > have been implemented by extensions...)
> >
> > Konrad
> >
> > On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> > > Unsure we want to deprecate all of Maven :)
> > >
> > > But yes, in general, 3.x "Maven API" was "all that users can grab"
> sadly,
> > > and is probably our major source of problems and reason we started
> Maven
> > 4
> > > API.
> > >
> > > IMO, I'd consider them as "whole", and just say "starting with Maven
> > > 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
> > ACCESSIBLE
> > > ANYMORE FROM PLUGINS.
> > > And done.
> > >
> > > Just as an example, here is what Maven Resolver has to say about same
> > topic
> > > (part of not-yet-released, vote is in process 1.9.1 version):
> > >
> >
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> > >
> > > HTH
> > > T
> > >
> > > On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus 
> > wrote:
> > >
> > > > I see now there is already
> > > >
> >
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> > > > but to me the javadoc is not explicit enough. It should state: Only
> > Maven
> > > > is allowed to implement/extend types with this annotation.
> > > >
> > > > Konrad
> > > >
> > > > On 2022/11/16 09:20:11 Konrad Windszus wrote:
> > > > > Hi,
> > > > > Unfortunately Maven 3 didn’t define a proper API. In effect
> > everything
> > > > somehow exposed through class loaders was considered API by
> > > > plugin/extension developers.
> > > > > For Maven 4 a completely separate API was established in package
> > > > “org.apache.maven.api”, but what about the old packages used and
> > exported
> > > > in Maven 3?
> > > > >
> > > > > For example in the context of
> > > > https://issues.apache.org/jira/browse/MNG-7588 <
> > > > https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
> > > > package “org.apache.maven.plugin.descriptor”.
> > > > > We already figured out that this particular package (although not
> > part
> > > > of the Maven 4 API) is used from both Maven Core as well as Maven
> > Plugin
> > > > Tools, therefore this probably needs to stay backwards compatible.
> > > > > What about others like
> > > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > ?
> > > > <
> > > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > > > ?>
> > > > > This interface should IMHO never been implemented outside Maven
> Core
> > but
> > > > in fact it was exposed to all plugins/extensions (via
> > > >
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > > > <
> > > >
> >
> 

Re: Releases notes ... Jira, GitHub

[Gary Gregory]

What countries are those BTW?

Gary

On Mon, Nov 7, 2022, 21:52 Gary Gregory  wrote:

>
>
> On Mon, Nov 7, 2022, 20:05 Olivier Lamy  wrote:
>
>> On Tue, 8 Nov 2022 at 10:59, Gary Gregory  wrote:
>> >
>> > FYI, and FWIW, Log4j is planning on switch from Jira to GitHub for
>> issues,
>> > and release notes: https://issues.apache.org/jira/browse/LOG4J2-3628
>> >
>>
>> So you mean using ONLY gh for issues?
>> So by doing this, you will exclude people living in countries banned
>> from Github.
>> Is it acceptable from an Apache Foundation POV?
>>
>
> I don't know if this was considered. It must be an issue for other
> projects as well.
>
> Gary
>
>
>> argghhh only 2 answers and the thread is already forking 藍
>>
>>
>> > Gary
>> >
>> > On Mon, Nov 7, 2022, 19:16 Olivier Lamy  wrote:
>> >
>> > > well I just see GH release note as a cherry on the cake.
>> > > as long as the rest is done.
>> > > Just compare the result of generated dependabot PRs
>> > > no GH release notes
>> > > https://github.com/eclipse/jetty.project/pull/8853
>> > > with GH release notes
>> > > https://github.com/eclipse/jetty.project/pull/7727
>> > > I tend to find the second (e.g with GH release note auto generated)
>> > > more human readable and directly accessible (no need to go somewhere
>> > > else and there is even a link to the PR of the changelog entry). but
>> > > yeah maybe it's only me
>> > >
>> > > Regarding "each change must be done by PR", for some reasons we can’t
>> > > really make it mandatory but let's be honest in real life everybody
>> > > does it :)
>> > > At the end, if release drafter is configured it's just one click, and
>> > > if not it's 2 clicks or one command line if using github cli tool gh
>> > >
>> > > On a more general discussion, we are a very large project with plenty
>> > > of sub projects (maintained by different people who are not
>> > > maintaining every project) and we can be happy having few people
>> > > maintaining those during their spare time. So not sure it's  a very
>> > > good idea to have too strict policies/procedures especially when it
>> > > comes to adding a nice to have cherry on the top for users
>> > > Especially when the rest of our long procedure has been done.
>> > >
>> > >
>> > >
>> > > On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski <
>> s.jaranow...@gmail.com>
>> > > wrote:
>> > > >
>> > > > Hi,
>> > > > I start a discussion ... as beginning - some my loose thoughts
>> > > >
>> > > > We use Jira (for most of) as our primary issues management system.
>> > > > We manage release notes in Jira - it is the source for
>> announcements.
>> > > >
>> > > > In some projects we have  GitHub releases notes.
>> > > > In some cases we use release-drafter for preparing GitHub releases
>> notes.
>> > > > Some of release  notes on GH - it is not actual
>> > > >
>> > > > Challenge:
>> > > >  -  make both release notes to have the same information
>> > > >  - minimal additional manual work
>> > > >
>> > > > Release - drafter is fine, but
>> > > >  - requires correct labeling on PR
>> > > >  - eache change must be done by PR
>> > > >  - each PR must be merged on GH with merged status
>> > > >  - no additional issues
>> > > >
>> > > >
>> > > > --
>> > > > Sławomir Jaranowski
>> > >
>> > > -
>> > > 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: Releases notes ... Jira, GitHub

[Gary Gregory]

On Mon, Nov 7, 2022, 20:05 Olivier Lamy  wrote:

> On Tue, 8 Nov 2022 at 10:59, Gary Gregory  wrote:
> >
> > FYI, and FWIW, Log4j is planning on switch from Jira to GitHub for
> issues,
> > and release notes: https://issues.apache.org/jira/browse/LOG4J2-3628
> >
>
> So you mean using ONLY gh for issues?
> So by doing this, you will exclude people living in countries banned
> from Github.
> Is it acceptable from an Apache Foundation POV?
>

I don't know if this was considered. It must be an issue for other projects
as well.

Gary


> argghhh only 2 answers and the thread is already forking 藍
>
>
> > Gary
> >
> > On Mon, Nov 7, 2022, 19:16 Olivier Lamy  wrote:
> >
> > > well I just see GH release note as a cherry on the cake.
> > > as long as the rest is done.
> > > Just compare the result of generated dependabot PRs
> > > no GH release notes
> > > https://github.com/eclipse/jetty.project/pull/8853
> > > with GH release notes
> > > https://github.com/eclipse/jetty.project/pull/7727
> > > I tend to find the second (e.g with GH release note auto generated)
> > > more human readable and directly accessible (no need to go somewhere
> > > else and there is even a link to the PR of the changelog entry). but
> > > yeah maybe it's only me
> > >
> > > Regarding "each change must be done by PR", for some reasons we can’t
> > > really make it mandatory but let's be honest in real life everybody
> > > does it :)
> > > At the end, if release drafter is configured it's just one click, and
> > > if not it's 2 clicks or one command line if using github cli tool gh
> > >
> > > On a more general discussion, we are a very large project with plenty
> > > of sub projects (maintained by different people who are not
> > > maintaining every project) and we can be happy having few people
> > > maintaining those during their spare time. So not sure it's  a very
> > > good idea to have too strict policies/procedures especially when it
> > > comes to adding a nice to have cherry on the top for users
> > > Especially when the rest of our long procedure has been done.
> > >
> > >
> > >
> > > On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> > > wrote:
> > > >
> > > > Hi,
> > > > I start a discussion ... as beginning - some my loose thoughts
> > > >
> > > > We use Jira (for most of) as our primary issues management system.
> > > > We manage release notes in Jira - it is the source for announcements.
> > > >
> > > > In some projects we have  GitHub releases notes.
> > > > In some cases we use release-drafter for preparing GitHub releases
> notes.
> > > > Some of release  notes on GH - it is not actual
> > > >
> > > > Challenge:
> > > >  -  make both release notes to have the same information
> > > >  - minimal additional manual work
> > > >
> > > > Release - drafter is fine, but
> > > >  - requires correct labeling on PR
> > > >  - eache change must be done by PR
> > > >  - each PR must be merged on GH with merged status
> > > >  - no additional issues
> > > >
> > > >
> > > > --
> > > > Sławomir Jaranowski
> > >
> > > -
> > > 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: Releases notes ... Jira, GitHub

[Gary Gregory]

FYI, and FWIW, Log4j is planning on switch from Jira to GitHub for issues,
and release notes: https://issues.apache.org/jira/browse/LOG4J2-3628

Gary

On Mon, Nov 7, 2022, 19:16 Olivier Lamy  wrote:

> well I just see GH release note as a cherry on the cake.
> as long as the rest is done.
> Just compare the result of generated dependabot PRs
> no GH release notes
> https://github.com/eclipse/jetty.project/pull/8853
> with GH release notes
> https://github.com/eclipse/jetty.project/pull/7727
> I tend to find the second (e.g with GH release note auto generated)
> more human readable and directly accessible (no need to go somewhere
> else and there is even a link to the PR of the changelog entry). but
> yeah maybe it's only me
>
> Regarding "each change must be done by PR", for some reasons we can’t
> really make it mandatory but let's be honest in real life everybody
> does it :)
> At the end, if release drafter is configured it's just one click, and
> if not it's 2 clicks or one command line if using github cli tool gh
>
> On a more general discussion, we are a very large project with plenty
> of sub projects (maintained by different people who are not
> maintaining every project) and we can be happy having few people
> maintaining those during their spare time. So not sure it's  a very
> good idea to have too strict policies/procedures especially when it
> comes to adding a nice to have cherry on the top for users
> Especially when the rest of our long procedure has been done.
>
>
>
> On Tue, 8 Nov 2022 at 09:00, Slawomir Jaranowski 
> wrote:
> >
> > Hi,
> > I start a discussion ... as beginning - some my loose thoughts
> >
> > We use Jira (for most of) as our primary issues management system.
> > We manage release notes in Jira - it is the source for announcements.
> >
> > In some projects we have  GitHub releases notes.
> > In some cases we use release-drafter for preparing GitHub releases notes.
> > Some of release  notes on GH - it is not actual
> >
> > Challenge:
> >  -  make both release notes to have the same information
> >  - minimal additional manual work
> >
> > Release - drafter is fine, but
> >  - requires correct labeling on PR
> >  - eache change must be done by PR
> >  - each PR must be merged on GH with merged status
> >  - no additional issues
> >
> >
> > --
> > Sławomir Jaranowski
>
> -
> 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

[Gary Gregory]

On Sat, Nov 5, 2022, 09:09 Elliotte Rusty Harold  wrote:

> After log4shell last year, I no longer have any patience for third
> party logging libraries, full stop.
>

Uh? CVEs have occurred in all types of libraries, there is nothing about
logging that makes it more CVE-prone. You might as well be talking about
all third party libraries.

Gary


> IMO logging should be done through java.util.logging, nothing else.
> This is fully functional since Java 1.4 twenty years ago. Log4j,
> slf4j, plexus-logging, etc. are all efforts to solve a problem we
> don't have any more. They are not needed and they introduce dependency
> problems and security issues.
>
> For one example, Google has used java.util.logging exclusively in all
> its internal Java code since at least 2008 and never needed anything
> more. This is a matter of policy inside Google, and as a result of
> this log4shell was close to a non-event for one of the largest Java
> shops on the planet. It wasn't a complete non-event only because of
> third party libraries that depended on log4j and open source projects
> that weren't quite as strict about following Google rules.
>
> To the extent Maven and its plugins are currently dependent on SLF4J
> and others, this should be fixed. We should not continue down this
> path in any new or updated code. To be clear:
>
> 1. I am willing to do some of the work of ripping out old logging
> calls and replacing them with j.u.l.
>
> 2. It is OK to have mixed logging during a transition period.
>
> 3. It is OK if some log messages are lost or appear when they're not
> expected during a transition period. Logging is never critical
> functionality.
>
> What I am not willing to accept are dependency management problems and
> major security holes like log4shell due to optional, convenience
> functionality.
>
> On Fri, Nov 4, 2022 at 10:57 AM Slawomir Jaranowski
>  wrote:
> >
> > Hi,
> >
> > I want to start ( again :-) ) a discussion about logging in Maven
> plugins.
> >
> > First I agree that plugin developers should use logging methods provided
> by
> > Plugin api.
> >
> > But we can not expect plugin developers to write everything from scratch.
> > In many cases they may want to use an external library to do tasks needed
> > by the plugin.
> >
> > We don't have any control over what logging framework is used in the
> > external library used by plugin developers.
> >
> > We also maintain some libraries which can be used by plugin and also as
> > standalone in another project.
> > In such a case the question is - what logging we should use [1]?
> >
> > Last time I did a test, I use Java util logging from JDK in the Maven
> > plugin.
> > I see that Java util logging use default configuration, eg. we will have
> > two lines for one log event.
> > Even more options -q and -X have no effect for such a logger.
> >
> > One of the solution for such problem is using "Bridging" methods
> supported
> > by slf4j [2]
> > Probably all of existing and future logging frameworks can not be
> covered -
> > but most of common using will be.
> >
> > I hope that, even if we will want to change the logging framework used
> > internally in Maven, we can also use the same method.
> >
> > [1] https://github.com/apache/maven-dependency-analyzer/pull/71
> > [2] https://www.slf4j.org/legacy.html
> >
> >
> > --
> > Sławomir Jaranowski
>
>
>
> --
> 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: Logging in Maven Plugins - Bridging

[Gary Gregory]

And let's not forget that Log4j also is a facade API:
https://logging.apache.org/log4j/2.x/manual/api-separation.html

Gary


On Fri, Nov 4, 2022, 06:56 Slawomir Jaranowski 
wrote:

> Hi,
>
> I want to start ( again :-) ) a discussion about logging in Maven plugins.
>
> First I agree that plugin developers should use logging methods provided by
> Plugin api.
>
> But we can not expect plugin developers to write everything from scratch.
> In many cases they may want to use an external library to do tasks needed
> by the plugin.
>
> We don't have any control over what logging framework is used in the
> external library used by plugin developers.
>
> We also maintain some libraries which can be used by plugin and also as
> standalone in another project.
> In such a case the question is - what logging we should use [1]?
>
> Last time I did a test, I use Java util logging from JDK in the Maven
> plugin.
> I see that Java util logging use default configuration, eg. we will have
> two lines for one log event.
> Even more options -q and -X have no effect for such a logger.
>
> One of the solution for such problem is using "Bridging" methods supported
> by slf4j [2]
> Probably all of existing and future logging frameworks can not be covered -
> but most of common using will be.
>
> I hope that, even if we will want to change the logging framework used
> internally in Maven, we can also use the same method.
>
> [1] https://github.com/apache/maven-dependency-analyzer/pull/71
> [2] https://www.slf4j.org/legacy.html
>
>
> --
> Sławomir Jaranowski
>

Re: Clarify procedure for restarting releases

[Gary Gregory]

On Sun, Oct 30, 2022 at 2:40 PM Elliotte Rusty Harold 
wrote:

> IMO A failed release should not burn an external facing version
> number. If it does, then the release process is flawed and needs to be
> fixed.
>

Big old +1 on that! :-)

Gary


>
> On Sun, Oct 30, 2022 at 11:05 AM Slawomir Jaranowski
>  wrote:
> >
> > Hi,
> >
> > Current procedure of releases is unclear in case of restart releases. [1]
> >
> > I see two cases:
> >
> > - technical problem during release ... something goes wrong after SMC tag
> > was created
> > - canceled vote
> >
> > Technically we have many solutions:
> >
> > 1.
> > - drop old tag and restart with the same version
> > - no need other actions
> >
> > 2.
> > - restart process with next version
> >
> > - don't touch wrong tag in repo
> > - or drop old tag
> >
> > - rename release label in jira
> > - or create next release and add only fixed issues for restart
> >
> >
> > [1]
> >
> https://maven.apache.org/developers/release/maven-project-release-procedure.html#check-the-vote-results
> >
> > --
> > Sławomir Jaranowski
>
>
>
> --
> 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] Raise minimum JDK requirements to 1.8 in parent pom

[Gary Gregory]

Go for it :-)

Gary

On Sat, Oct 22, 2022, 15:44 Guillaume Nodet  wrote:

> Given maven and the resolver have upgraded their minimum JDK requirement to
> 1.8, I think it makes sense to raise it globally in the parent pom.
>
> Any objections ?
>
> Cheers,
> Guillaume Nodet
>

Re: [DISCUSS] Change maven code style

[Gary Gregory]

For my own 2c, all the extra spacing drives me bananas.

Gary

On Mon, Oct 17, 2022, 09:26 Björn Raupach  wrote:

> As someone who has just started opening some PRs for Maven, I would
> appreciate a more common Java Code Style.
>
> Not saying the style is bad, it is just confusing. Especially the C++
> like braces on a new line and the additional space between brackets.
>
> Not sure this will help gaining more committers.
>
> Am 12.10.2022 18:23 schrieb Guillaume Nodet:
> > Related to the discussion about automatically formatting and sorting
> > imports, I think it would be nice, given the big reformat commits if
> > those
> > PRs are to be merged, to eventually discuss some changes to those code
> > style.  In particular, I found out that the code is very sparse and my
> > screen is more wide than height, which means I can usually only see
> > 30-40
> > lines of code, where sometime half of them do not really carry any
> > semantic
> > (open braces, or things like close brace + else + open brace on 3
> > lines).
> > This makes me scroll a lot even on quite small methods to be able to
> > read
> > the full code, and that's a pain imho.
> > So I'd like to propose the following changes that would make maven code
> > more readable imho (and also closer to the usual java coding style) :
> >   * move open braces to the end of the previous line on all places
> >   * allow the else keyword to be directly following a closing brace to
> > allow "} else {" to be on the same line
> >   * eventually relax a bit the checkstyle line length as described in
> > https://github.com/gnodet/maven-shared-resources/pull/2.  This has not
> > much
> > effect, as the formatter will automatically format the lines and wrap
> > them
> > at 120. However, in certain cases, the formatter can find in difficult
> > to
> > wrap the line (for example with a variable declaration and cast with a
> > fully qualified name) and there is either a need to manually force the
> > wrap
> > (using an end of line comment for example) or disabling the check with
> > a
> > @SuppressWarning( "checkstyle:LineLength" ) annotation. This change
> > only
> > removes the checks so that in those rare cases, the formatter can be
> > left
> > without any need to force things.
> >
> > If this is to be accepted, I'd amend the PRs from the other thread to
> > follow those changes.
> >
> > Cheers,
> > Guillaume
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

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

[Gary Gregory]

On Sun, Oct 16, 2022 at 8:24 AM Guillaume Nodet  wrote:
>
> Le sam. 15 oct. 2022 à 14:20, Slawomir Jaranowski 
> a écrit :
>
> > For failed release I would prefer
> > - revert commits if needed - we will have history
> > - remove tag
> > try again :-)
> >
> > If we bump versions only caused by technical problems during release we
> > need to change / create labels in jira, move labeled issues and so on
> > And we can have questions why some versions are missing.
> >
> >
> Fully agreed, that's what I initially tried to do.  But the repository does
> not allow removing a tag.  So this would have to be changed.

It does not if your release candidate tag says it's an RC, over at
Apache Commons we use, for example, RC tags like
"commons-text-1.10.0-RC1", which can be deleted if you want to redo
RC1 before you send out the vote. When the vote passes, a new tag on
the _same_ commit as the RC commit called "rel/commons-text-1.10.0" is
pushed and tags under "rel/" _cannot_ be deleted.

Gary

>
>
> >
> >
> > sob., 15 paź 2022 o 13:31 Benjamin Marwell 
> > napisał(a):
> >
> > > 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 <
> > > gno...@apache.org>:
> > > >
> > > > 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
> > >
> > >
> >
> > --
> > Sławomir Jaranowski
> >
>
>
> --
> 
> Guillaume Nodet

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

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

[Gary Gregory]

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
>

Re: [DISCUSS] Change maven code style

[Gary Gregory]

Non-binding +1 from me.

Gary

On Wed, Oct 12, 2022, 12:23 Guillaume Nodet  wrote:

> Related to the discussion about automatically formatting and sorting
> imports, I think it would be nice, given the big reformat commits if those
> PRs are to be merged, to eventually discuss some changes to those code
> style.  In particular, I found out that the code is very sparse and my
> screen is more wide than height, which means I can usually only see 30-40
> lines of code, where sometime half of them do not really carry any semantic
> (open braces, or things like close brace + else + open brace on 3 lines).
> This makes me scroll a lot even on quite small methods to be able to read
> the full code, and that's a pain imho.
> So I'd like to propose the following changes that would make maven code
> more readable imho (and also closer to the usual java coding style) :
>   * move open braces to the end of the previous line on all places
>   * allow the else keyword to be directly following a closing brace to
> allow "} else {" to be on the same line
>   * eventually relax a bit the checkstyle line length as described in
> https://github.com/gnodet/maven-shared-resources/pull/2.  This has not
> much
> effect, as the formatter will automatically format the lines and wrap them
> at 120. However, in certain cases, the formatter can find in difficult to
> wrap the line (for example with a variable declaration and cast with a
> fully qualified name) and there is either a need to manually force the wrap
> (using an end of line comment for example) or disabling the check with a
> @SuppressWarning( "checkstyle:LineLength" ) annotation. This change only
> removes the checks so that in those rare cases, the formatter can be left
> without any need to force things.
>
> If this is to be accepted, I'd amend the PRs from the other thread to
> follow those changes.
>
> Cheers,
> Guillaume
>

Re: Maven 4.0: Migration path for plugins and extensions?

[Gary Gregory]

Does Maven and it's own plugins use JApiCmp or any tool to detect binary
compatibility breaks?

Gary

On Tue, Oct 4, 2022, 06:53 Tamás Cservenák  wrote:

> Howdy,
>
> It should not break, but if it does, we did something wrong.
>
> The new API will coexist with old stuff, so in essence Maven 3 plugins
> should not break with Maven 4, as long Maven 4 provides this "backward 3.x
> compat window"
> (but no Maven2 compat anymore, we cannot provide two major versions
> spanning compat layer).
> For how long it is undecided yet (4.1? 4.5? etc).
>
> Can you share more details about your breakage so we can fix things up?
>
>
> Thanks
> Tamas
>
>
> On Tue, Oct 4, 2022 at 12:42 PM Marc Philipp  wrote:
>
> > Hi everyone,
> >
> > We’re maintaining a Maven extension and testing it against the latest
> > snapshots. After the merge of https://github.com/apache/maven/pull/703
> our
> > tests started failing because of breaking API changes. I see there are
> PRs
> > to core Maven plugins linked from there. If I understood it correctly,
> this
> > change will break all/most existing Maven plugins.
> >
> > Maven 4.0 is a major new version and as such is obviously allowed to make
> > breaking changes to its API. However, I was wondering if there’s any
> > guidance or a migration path for (third-party) Maven plugins and
> > extensions? Is the idea that they’ll also have to publish new major
> > versions that are compatible with 4.x? If they still need to support 3.x,
> > would they need to maintain long-lived branches and release 3.x and 4.x
> > compatible versions until they decide to drop support for 3.x? Or will
> > there be any kind of compatibility layer?
> >
> > Thanks,
> > Marc
> >
> > --
> >
> > Marc Philipp
> >
> > Senior Principal Software Engineer
> >
> > Gradle GmbH
> > Firmensitz: Danckelmannstr. 21, 14059 Berlin, Germany
> >
> > Registergericht: Amtsgericht Charlottenburg, HRB 162310
> >
> > Geschäftsführer: Dr. Rolf Dockter
> >
> > P. +49 30 609886880
> > W. gradle.com
> >
> > [image:
> >
> >
> https://dpesummit.com/?utm_source=employee-signature_medium=email_campaign=dpesummit
> > ]
> > <
> >
> https://dpesummit.com/?utm_source=employee-signature_medium=email_campaign=dpesummit
> > >
> >
>

[RAT] release 0.15?

[Gary Gregory]

Hi Maven,

Any chance of finishing up RAT 0.15 soon?

Gary

Re: [DISCUSS] Usage of Maven Changes Plugin/Reduction of Features

[Gary Gregory]

Right, all Commons components (over 20) use the plugin to generate their
respective Jira pages.

Gary

On Sun, Aug 14, 2022, 12:55 Bernd Eckenfels  wrote:

> The Apache Commons Project Sites use the jira integration, the plugin
> works in principle, but does not support paging.
>
> https://commons.apache.org/proper/commons-vfs/jira-report.html
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Michael Osipov 
> Gesendet: Sunday, August 14, 2022 5:41:29 PM
> An: Maven Developers List 
> Betreff: [DISCUSS] Usage of Maven Changes Plugin/Reduction of Features
>
> Guys,
>
> does anyone of you use the extended features of MCHANGES besides the
> changes.xml to HTML generation, e.g., messaging, JIRA report, Trac report?
> I'd like to make it savvy for Doxia 2.0.0 and proper generation, but I
> am not willing to keep the luggage of the mentioned additional features
> because of:
> * I don't know they do work or not work,
> * the setup and testing effort of third party systems
> * supporting commercial products I don't have access to.
>
> My rough plan would be:
> * Deprecate all of those in M1
> * Remove all of those in M2
> * Review plugin and update remaining deps in M2
> * Look at open issues for M3
>
> Personally, I have never used the messaging feature and for JIRA, et al.
> I rather provide a link than duplicating the data.
>
> Let me know what you think otherwise this plugin will not survive the
> Doxia 2.0.0 stack migration.
>
> Michael
>
> -
> 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

[Gary Gregory]

FWIW, I agree with Ralph wholeheartedly.

Gary

On Mon, Jul 25, 2022, 15:31 Ralph Goers  wrote:

> Some statistics below. I think you are being very optimistic about how
> fast people will adopt JDK 17. If it follows the trends for Java 8 and 11 I
> would put money on betting it won’t be the predominant version until the
> next LTS is released.
>
> https://adoptium.net/support and
> https://aws.amazon.com/about-aws/whats-new/2020/08/amazon-corretto-8-11-support-extended/
> shows Java 8 being supported through at least 2026 and Java 11 until 2027.
> I don’t think users will be in a hurry to upgrade.
>
> So if Maven were to continue enhancements and support for Maven 3 I don’t
> think there would be any issue with making Maven 4 require Java 17. But the
> Maven project doesn’t have a history of maintaining two major versions
> simultaneously  While lots of company’s are cautious in upgrading the JDK
> they are using, generally they are less reluctant to upgrade Maven. But if
> Maven 4 requires Java 17, most places won’t upgrade to it if they are using
> Java 8 or 11.  Although the -release option should guarantee compatibility
> I am sure lots of folks won’t trust that it is.
>
> So my vote would be +1 for Maven 4 requiring Java 17 under the condition
> that Maven 3 continues to get new releases.
>
> Ralph
>
>
> https://newrelic.com/resources/report/2022-state-of-java-ecosystem#:~:text=More%20than%2048%25%20of%20applications,using%20the%20version%20in%20production
> .
>
> https://www.infoworld.com/article/3652408/java-8-still-dominates-but-java-17-wave-is-coming-survey.html
>
>
> > On Jul 23, 2022, at 12:05 PM, Enno Thieleke 
> wrote:
> >
> > Fwiw:
> >
> > Romain, I think you're exaggerating. The answer is, like in most cases:
> "it depends".
> >
> > Most people, we're most likely talking 95-99% here, will happily use JDK
> 17 with Maven 4.
> >
> > Some people might need to compile for lower sources and targets, but
> running tests for those builds in JDK 17 instead of, let's say 11, _will
> suffice in most cases_.
> >
> > Yes, there will be edge cases where people will be forced to use
> different JDKs at least for tests, some even for builds. But that's
> possible, so they won't get left behind.
> >
> > Regarding mvnd: It's not a silver bullet. It never was and it never will
> be. Whenever a build spawns new JVMs (for tests or other tasks), it doesn't
> benefit from mvnd anymore (in as much as it would without spawning new
> JVMs).
> >
> > To not use the latest (LTS) JDK in order to "better" support the 1-5% of
> the Maven users, who're still using obsolete JVMs (I'm obviously referring
> to Karl's assumption, which I agree with), would be a kick in the teeth of
> all Maven developers, who finally want to embrace the present (not even the
> future).
> >
> > Long story short, +1 for JDK 17 as minimum for Maven 4.
> >
> > Kind regards,
> > Enno
> >
> > 
> > From: Romain Manni-Bucau 
> > Sent: Saturday, July 23, 2022 6:55 PM
> > To: Maven Developers List 
> > Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
> >
> > Le sam. 23 juil. 2022 à 17:25, Benjamin Marwell  a
> > écrit :
> >
> >> 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).
> >>
> >
> > As explained it means you dont write a single test or dont care of the
> test
> > results so yes it needs 2 jdk.
> >
> >
> >
> >> 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: Apache RAT plugin and .gitattributes

[Gary Gregory]

On Sun, Jul 17, 2022 at 10:04 AM Jochen Wiedmann
 wrote:
>
> On Sun, Jul 17, 2022 at 2:22 PM Gary Gregory  wrote:
> >
> > It looks like the Apache RAT plugin tries to validate the
> > .gitattributes file (in contrast to excluding .gitignore).
> >
> > Is that an issue to be fixed or documented?
>
> Looking into the relevant sources [1], I notice, that the
> .gitattributes file must be added explicitly by changing the source
> code. So, a bug report would help. On the other hand, there already is
> one [2].

Ah, thanks for the pointers! :-)

Gary

>
> Jochen
>
> 1: 
> https://gitbox.apache.org/repos/asf?p=creadur-rat.git;a=blob_plain;f=apache-rat-plugin/src/main/java/org/apache/rat/mp/util/ExclusionHelper.java;hb=HEAD
> 2. 
> https://issues.apache.org/jira/projects/RAT/issues/RAT-308?filter=allopenissues
>
> -
> 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

Apache RAT plugin and .gitattributes

[Gary Gregory]

It looks like the Apache RAT plugin tries to validate the
.gitattributes file (in contrast to excluding .gitignore).

Is that an issue to be fixed or documented?

Gary

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

Re: AbstractMethodError at org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument

[Gary Gregory]

On Sun, Jul 17, 2022 at 7:04 AM Michael Osipov  wrote:
>
> Am 2022-07-17 um 13:02 schrieb Gary Gregory:
> > (Sorry for the top post) So it sounds like the simplest from a user's POV
> > is to wait for JDepend 2.1.
>
> Technically yes, but given the requirements I have depicted I don't
> expect any release soon. I won't put any effort into this plugin beyond
> a pure release.

k, I've dropped jdepend-maven-plugin from commons-parent, we can
always put it back when it is fixed later.

Gary

>
> M
>
> > On Sat, Jul 16, 2022, 16:21 Michael Osipov  wrote:
> >
> >> Gary,
> >>
> >> went through. It is jdepend-maven-plugin only. With:
> >>> D:\Entwicklung\Projekte\commons-dbcp [master ≡ +0 ~1 -0 !]> git diff
> >>> diff --git a/pom.xml b/pom.xml
> >>> index 1269f8b3..694d24e1 100644
> >>> --- a/pom.xml
> >>> +++ b/pom.xml
> >>> @@ -365,6 +365,11 @@
> >>>   
> >>> 
> >>>   
> >>> + 
> >>> +  org.apache.maven.plugins
> >>> +  maven-site-plugin
> >>> +  3.12.0
> >>> +
> >>>   
> >>>   
> >>> org.apache.maven.plugins
> >>> @@ -457,6 +462,11 @@
> >>> 
> >>> 
> >>>   
> >>> + 
> >>> +org.codehaus.mojo
> >>> +jdepend-maven-plugin
> >>> +2.1-SNAPSHOT
> >>> +
> >>> 
> >>>   com.github.siom79.japicmp
> >>>   japicmp-maven-plugin
> >>
> >> it works:
> >>> [INFO] Generating "JDepend" report   ---
> >> jdepend-maven-plugin:2.1-SNAPSHOT:generate
> >>>
> >>> Unknown constant: 18
> >>>
> >>> Unknown constant: 18
> >>>
> >>> Unknown constant: 18
> >>>
> >>> Unknown constant: 18
> >>>
> >>> Unknown constant: 18
> >>>
> >>> Unknown constant: 18
> >>>
> >>> Unknown constant: 18
> >>>
> >>> Unknown constant: 18
> >>>
> >>> Unknown constant: 18
> >>>
> >>> Unknown constant: 18
> >>>
> >>> Unknown constant: 18
> >>>
> >>> Unknown constant: 18
> >>
> >>
> >> The report looks good as well. We now have the following problems:
> >>
> >> * JDepend 2.10 isn't in Central and has trouble with Java 8
> >> * The ITs are horribly outdated plugin/dependency-wise
> >>
> >> I'd push a new relese of this plugin if someone could take care at least
> >> of the ITs.
> >>
> >> Note: Since the last relese of this plugin is ages ago it depends on a
> >> deprecated class for about 10 years ago. The ABI incompat is my fault,
> >> it was already reported by the Asciidoctor team on ASF JIRA and they
> >> simply aligned their code and it worked again.
> >>
> >> Let me know how you'd like to proceed.
> >>
> >> M
> >>
> >> M
> >>
> >
>

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

Re: AbstractMethodError at org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument

[Gary Gregory]

(Sorry for the top post) So it sounds like the simplest from a user's POV
is to wait for JDepend 2.1.

Gary

On Sat, Jul 16, 2022, 16:21 Michael Osipov  wrote:

> Gary,
>
> went through. It is jdepend-maven-plugin only. With:
> > D:\Entwicklung\Projekte\commons-dbcp [master ≡ +0 ~1 -0 !]> git diff
> > diff --git a/pom.xml b/pom.xml
> > index 1269f8b3..694d24e1 100644
> > --- a/pom.xml
> > +++ b/pom.xml
> > @@ -365,6 +365,11 @@
> >  
> >
> >  
> > + 
> > +  org.apache.maven.plugins
> > +  maven-site-plugin
> > +  3.12.0
> > +
> >  
> >  
> >org.apache.maven.plugins
> > @@ -457,6 +462,11 @@
> >
> >
> >  
> > + 
> > +org.codehaus.mojo
> > +jdepend-maven-plugin
> > +2.1-SNAPSHOT
> > +
> >
> >  com.github.siom79.japicmp
> >  japicmp-maven-plugin
>
> it works:
> > [INFO] Generating "JDepend" report   ---
> jdepend-maven-plugin:2.1-SNAPSHOT:generate
> >
> > Unknown constant: 18
> >
> > Unknown constant: 18
> >
> > Unknown constant: 18
> >
> > Unknown constant: 18
> >
> > Unknown constant: 18
> >
> > Unknown constant: 18
> >
> > Unknown constant: 18
> >
> > Unknown constant: 18
> >
> > Unknown constant: 18
> >
> > Unknown constant: 18
> >
> > Unknown constant: 18
> >
> > Unknown constant: 18
>
>
> The report looks good as well. We now have the following problems:
>
> * JDepend 2.10 isn't in Central and has trouble with Java 8
> * The ITs are horribly outdated plugin/dependency-wise
>
> I'd push a new relese of this plugin if someone could take care at least
> of the ITs.
>
> Note: Since the last relese of this plugin is ages ago it depends on a
> deprecated class for about 10 years ago. The ABI incompat is my fault,
> it was already reported by the Asciidoctor team on ASF JIRA and they
> simply aligned their code and it worked again.
>
> Let me know how you'd like to proceed.
>
> M
>
> M
>

Source plugin site out of date

[Gary Gregory]

Hi all,

The current version seems to be 3.2.1 but the site says 3.2.0.

Gary

Re: AbstractMethodError at org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument

[Gary Gregory]

aven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:171)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:163)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:566)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)

Can this be fixed in a new site plugin release?
Is the JDepend plugin dead and should be in the attic? No releases since 2014.

Gary

>
> (package was needed as then japicmp would fail)
>
> HTH
> T
>
>
> On Mon, Jul 11, 2022 at 3:52 PM Gary Gregory  wrote:
>
> > Hi All,
> >
> > I'm looking for help in how to remedy an AbstractMethodError at
> > org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
> >
> > Running:
> >
> > git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
> > cd commons-dbcp
> > maven clean site -DskipTests
> >
> > Any thoughts?
> >
> > [INFO] Generating "JDepend" report   ---
> > jdepend-maven-plugin:2.0:generate-no-fork
> > [WARNING] An issue has occurred with
> > jdepend-maven-plugin:2.0:generate-no-fork report, skipping
> > LinkageError null, please report an issue to Maven dev team.
> > java.lang.AbstractMethodError
> > at
> > org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
> > (ReportDocumentRenderer.java:235)
> > at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
> > (DefaultSiteRenderer.java:348)
> > at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
> > (SiteMojo.java:194)
> > at org.apache.maven.plugins.site.render.SiteMojo.execute
> > (SiteMojo.java:143)
> > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> > (DefaultBuildPluginManager.java:137)
> > at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> > (MojoExecutor.java:370)
> > at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> > (MojoExecutor.java:351)
> > at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > (MojoExecutor.java:215)
> > at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > (MojoExecutor.java:171)
> > at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > (MojoExecutor.java:163)
> > at
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> > (LifecycleModuleBuilder.java:117)
> > at
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> > (LifecycleModuleBuilder.java:81)
> > at
> > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> > (SingleThreadedBuilder.java:56)
> > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> > (LifecycleStarter.java:128)
> > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> > at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Met

AbstractMethodError at org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument

[Gary Gregory]

Hi All,

I'm looking for help in how to remedy an AbstractMethodError at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument

Running:

git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git
cd commons-dbcp
maven clean site -DskipTests

Any thoughts?

[INFO] Generating "JDepend" report   ---
jdepend-maven-plugin:2.0:generate-no-fork
[WARNING] An issue has occurred with
jdepend-maven-plugin:2.0:generate-no-fork report, skipping
LinkageError null, please report an issue to Maven dev team.
java.lang.AbstractMethodError
at 
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:235)
at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
(DefaultSiteRenderer.java:348)
at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
(SiteMojo.java:194)
at org.apache.maven.plugins.site.render.SiteMojo.execute (SiteMojo.java:143)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:370)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:351)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:171)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:163)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)

TY,
Gary

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

Re: [ANN] Apache Maven 3.8.6 released

[Gary Gregory]

It can take a few hours to sync up...

Gary

On Sat, Jun 11, 2022, 16:46 Dan Tran  wrote:

> Thanks for releasing this needed release
>
> looks like it is slow to appear at maven central? [1]
>
> -D
>
> [1] https://repo1.maven.org/maven2/org/apache/maven/apache-maven/
>
>
>
> On Sat, Jun 11, 2022 at 8:48 AM Michael Osipov 
> wrote:
>
> > The Apache Maven team is pleased to announce the release of the Apache
> > Maven 3.8.6
> >
> > Apache Maven is a software project management and comprehension tool.
> > Based on the concept
> > of a project object model (POM), Maven can manage a project's build,
> > reporting and documentation
> > from a central piece of information.
> >
> > Maven 3.8.6 is available via https://maven.apache.org/download.cgi
> >
> > The core release is independent of plugin releases. Further releases of
> > plugins will be made
> > separately.
> >
> > If you have any questions, please consult:
> >
> > - the web site: https://maven.apache.org/
> > - the maven-user mailing list:
> https://maven.apache.org/mailing-lists.html
> > - the reference documentation: https://maven.apache.org/ref/3.8.6/
> >
> >
> > Release Notes - Maven - Version 3.8.6
> >
> > ** Bug
> >  * [MNG-7432] - [REGRESSION] Resolver session contains
> > non-MavenWorkspaceReader
> >  * [MNG-7433] - [REGRESSION] Multiple maven instances working on
> > same source tree can lock each other
> >  * [MNG-7441] - Update Version of (optional) Logback to Address
> > CVE-2021-42550
> >  * [MNG-7448] - Don't ignore bin/ otherwise bin/ in apache-maven
> > module cannot be readded
> >  * [MNG-7455] - [REGRESSION] IllegalStateException in SessionScope
> > during guice injection in multithreaded build
> >  * [MNG-7459] - Revert MNG-7347 (SessionScoped beans should be
> > singletons for a given session)
> >  * [MNG-7467] - [REGRESSION] Compilation failure with relocated
> > transitive dependency
> >  * [MNG-7487] - Fix deadlock during forked lifecycle executions
> >  * [MNG-7493] - [REGRESSION] Resolving dependencies between
> > submodules fails
> >
> > ** New Feature
> >  * [MNG-7486] - Create a multiline message helper for boxed log
> > messages
> >
> > ** Improvement
> >  * [MNG-7445] - to refactor some useless code
> >  * [MNG-7476] - Display a warning when an aggregator mojo is locking
> > other mojo executions
> >
> > ** Task
> >  * [MNG-7466] - Align Assembly Descriptor NS versions
> >
> > ** Dependency upgrade
> >  * [MNG-7488] - Upgrade SLF4J to 1.7.36
> >  * [MNG-7489] - Upgrade JUnit to 4.13.2
> >  * [MNG-7490] - Upgrade Plexus Utils to 3.3.1
> >
> >
> > For more information read
> > https://maven.apache.org/docs/3.8.6/release-notes.html
> >
> > Enjoy!
> >
> > - The Maven Team
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Proposing various improvements

[Gary Gregory]

I am a Maven user and we have custom plugins we wrote over at Apache
Commons and this type of change has been painful in the past, see
https://issues.apache.org/jira/browse/MNG-7316

I do not think we can make a blanket statement like "everything is
immutable" without causing a world of pain.

Gary

On Thu, May 19, 2022, 07:32 Doyon Sebastien  wrote:

> Hi Garry,
>
> I understand what you are saying. I though that there was a discussion
> about making the API immutable for mvn4. I also read that to modify some
> values on the API, the best practice was to replace the value (collection?)
> with a new one and not modify the actual one. What do you think?
>
> Regards
>
> > Le 19 mai 2022 à 13:23, Gary Gregory  a écrit :
> >
> > Bad idea unless you can look at each call site and _guarantee_ that you
> > want an immutable Collection instead of a mutable one... which I do not
> see
> > how you can do especially once a Collection escapes an API. Unless you're
> > ok with breaking behavioral compatibility...
> >
> > Gary
> >
> > On Thu, May 19, 2022, 02:34 Sebastien Doyon 
> > wrote:
> >
> >> Hi,
> >>
> >> Recently I found some small potential improvements that could help clean
> >> the maven code. I would be glad to contribute it back to my most useful
> >> Java project, if you find it of interest.
> >>
> >> The changes are mostly :
> >>
> >> - Use of Collections.emptyList() instead of new ArrayList() when
> possible.
> >> - Use of Collections.emptyMap() instead of new concrete Map object when
> >> possible
> >> - Use of Collections.singletonList() instead of new concrete List object
> >> when possible
> >> - Guarding logging statements with conditionals on isEnabled() to
> >> avoid garbage
> >> - Replacing StringBuilder or StringBuffer usage when + operator is more
> >> appropriate
> >> - Various small improvements
> >>
> >> Please tell me if this is something that can be contributed to the Maven
> >> project and I will proceed with the creation a Jira ticket and GitHub
> PR.
> >> You can find the changes on this branch :
> >>
> >> https://github.com/sebastien-doyon/maven/tree/codeImprovements2022
> >>
> >> Please note that this would be my first contribution to the project and
> I
> >> would like to do more in the futur. I am looking forward for your
> >> comment/review.
> >>
> >> Regards
> >>
> >> Sebastien Doyon
> >>
> >>
> >> -
> >> 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: Proposing various improvements

[Gary Gregory]

Bad idea unless you can look at each call site and _guarantee_ that you
want an immutable Collection instead of a mutable one... which I do not see
how you can do especially once a Collection escapes an API. Unless you're
ok with breaking behavioral compatibility...

Gary

On Thu, May 19, 2022, 02:34 Sebastien Doyon 
wrote:

> Hi,
>
> Recently I found some small potential improvements that could help clean
> the maven code. I would be glad to contribute it back to my most useful
> Java project, if you find it of interest.
>
> The changes are mostly :
>
> - Use of Collections.emptyList() instead of new ArrayList() when possible.
> - Use of Collections.emptyMap() instead of new concrete Map object when
> possible
> - Use of Collections.singletonList() instead of new concrete List object
> when possible
> - Guarding logging statements with conditionals on isEnabled() to
> avoid garbage
> - Replacing StringBuilder or StringBuffer usage when + operator is more
> appropriate
> - Various small improvements
>
> Please tell me if this is something that can be contributed to the Maven
> project and I will proceed with the creation a Jira ticket and GitHub PR.
> You can find the changes on this branch :
>
> https://github.com/sebastien-doyon/maven/tree/codeImprovements2022
>
> Please note that this would be my first contribution to the project and I
> would like to do more in the futur. I am looking forward for your
> comment/review.
>
> Regards
>
> Sebastien Doyon
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

AbstractMethodError at org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument

[Gary Gregory]

Hi all,

I am not sure which component broke binary compatibility for the Apache RAT
plugin, so I am emailing here. This happens in Apache Commons Parent git
master with Maven 3.8.5 running the default mvn goal for our POM:

(If my mailer uglies this up, it is also here
https://gist.github.com/garydgregory/967e40f120b8ed6f82d16cad973a2c4e)

[INFO] Generating "Rat Report" report--- apache-rat-plugin:0.13:rat
[WARNING] An issue has occurred with apache-rat-plugin:0.13:rat report,
skipping LinkageError
org.apache.rat.mp.RatReportMojo.generate(Lorg/apache/maven/doxia/sink/Sink;Ljava/util/Locale;)V,
please report an issue to Maven dev team.
java.lang.AbstractMethodError:
org.apache.rat.mp.RatReportMojo.generate(Lorg/apache/maven/doxia/sink/Sink;Ljava/util/Locale;)V
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:235)
at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render
(DefaultSiteRenderer.java:348)
at org.apache.maven.plugins.site.render.SiteMojo.renderLocale
(SiteMojo.java:194)
at org.apache.maven.plugins.site.render.SiteMojo.execute
(SiteMojo.java:143)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:301)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:211)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:165)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:157)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:121)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:127)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)

Gary

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M1

[Gary Gregory]

FWIW, from my POV milestones are confusing because there is no roadmap for
what the milestones ahead are, unlike what Eclipse usually does for
example. Instead from this user's POV milestones feel like static snapshots
without expectations set, unlike an alpha or a beta which most people have
an understanding of. For whatever reason, the alpha and beta labels have
fallen out of favor these days, this is unfortunate. Maybe these labels
push away users, maybe the are old fashioned, regardless, setting user's
expectations is what matters most, so some guidance would be helpful.

ty,
Gary

On Sat, Apr 30, 2022, 03:44 Slawomir Jaranowski 
wrote:

> Hi,
>
> ###
> From technical perspective
>
>  - build ok from source-release
>
> - wong jenkins url [1]
> - empty "L10n Status" report [2]
>
> ###
> From informations / documentation perspective
> - there should be explanation why 4xx
> - why -M1 (milestone), what plan to reach release version without milestone
> - there can be many questions about what the version is ...
>
> I am afraid that milestone versions are not used at all by many users ...
>
> [1]
>
> https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/ci-management.html
>
> [2]
>
> https://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/l10n-status.html
>
>
>
>
> śr., 27 kwi 2022 o 23:25 Michael Osipov  napisał(a):
>
> > Hi,
> >
> > We solved 6 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317923=12351657
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSITE%20AND%20resolution%20%3D%20Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1748/
> >
> >
> https://repository.apache.org/content/repositories/maven-1748/org/apache/maven/plugins/maven-site-plugin/4.0.0-M1/maven-site-plugin-4.0.0-M1-source-release.zip
> >
> > Source release checksum(s):
> > maven-site-plugin-4.0.0-M1-source-release.zip
> > sha512:
> >
> >
> 170fcefd12099f4b527b3ad9bc94098b1ee0cab7788982dfebfa69097f24746f847a6e181dfaab3caa54f508f13994195fa44c64fe1deef66ddb723fe852
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-site-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
> >
> >
>
> --
> Sławomir Jaranowski
>

Re: Maven Release Plugin 3.0.0-M6

[Gary Gregory]

Can someone explain the M release meaning? Is it an alpha release? A beta
version? Is it production ready? Does it depend on the plugin (please say
no)?

Gary

On Tue, Apr 26, 2022, 07:49 Samuel Le Berrigaud  wrote:

> Hello devs,
>
> I'd just like to get an idea of when a potential 3.0.0-M6 of the
> maven-release-plugin might happen.
>
> I've managed to contribute a bug fix MRELEASE-1022 (1). Thanks for the
> quick PR & merge. And now, obviously, I would love to be able to use a
> regular build of the plugin.
>
> Thanks for your help,
> SaM
>
> (1) https://issues.apache.org/jira/browse/MRELEASE-1022
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Gary Gregory]

Also note that in log4j 2.17.2 that was released a few days ago, I added
many improvements to the log4j-1.2-api module which aims to provide
compatibility with 1.2.

Gary

On Thu, Mar 3, 2022, 08:37 Bernd Eckenfels  wrote:

> All of the (known) remaining log4j1.x security bugs (none of which are as
> severe as log4shell) are fixed in reload4j 1.2.18+. If you need to stick
> with 1.2 you should use that. Otherwise you can try to migrate to the log4j
> bridge, it’s compatibility was increased in 2.17.2 or 2.12.4.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> Von: Martin Gainty 
> Gesendet: Thursday, March 3, 2022 1:18:50 PM
> An: Maven Developers List 
> Cc: David Milet ; iss...@maven.apache.org <
> iss...@maven.apache.org>; VZ-Product-OneTalk <
> vz-product-onet...@verizon.com>; Danylo Volokh <
> danylo.vol...@globallogic.com>
> Betreff: RE: Maven Dependency Plugin - Log4j vulnerabilities
>
> I *thought* log4j 1.2.15 had the patch to mitigate the JNDI Security
> Vulnerabity?
> Is this not the case?
> Thanks John
> M.
>
>
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
>
>
>  Original message 
> From: John Patrick 
> Date: 3/3/22 4:07 AM (GMT-05:00)
> To: Maven Developers List 
> Cc: David Milet , iss...@maven.apache.org,
> VZ-Product-OneTalk , Danylo Volokh <
> danylo.vol...@globallogic.com>
> Subject: Re: Maven Dependency Plugin - Log4j vulnerabilities
>
> Sorry I thought you where talking about log4j v2, not v1. I can see it
> downloads the metadata about the project but non or the jars;
> local-repo/log4j
> local-repo/log4j/log4j
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
> local-repo/log4j
> local-repo/log4j/log4j
> local-repo/log4j/log4j/1.2.12
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
> local-repo/log4j/log4j/1.2.12/_remote.repositories
>
> So I would still say false positive, as the jar is not actually used.
>
> But looking at the dependency tree it would need the apache commons to
> update commons-logging:commons-logging, then
> ommons-digester:commons-digester then org.apache.velocity:velocity-tools,
> then it gets to the 1st dependency within the maven ecosystem.
> So 5 ish patches to 5 separate projects to upgrade, test and release, each
> before then next pr can progress.
>
> John
>
>
> On Thu, 3 Mar 2022 at 07:53, Thomas Matthijs  wrote:
>
> > That was just to demonstrate how i got the dependency chain, that file
> > was there, but if you're going to be this hostile, i'm not interested
> > anymore, muting thread
> >
> > On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło 
> > wrote:
> > >
> > > On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
> > > >
> > > > Can confirm this project downloads log4j 1.12.12 for me
> > >
> > > As I see it - you confirm something else.
> > >
> > > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> > >
> > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> > > _artifact descriptor_
> > >
> > > --
> > > Piotrek
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Maven Dependency Plugin - Log4j vulnerabilities

[Gary Gregory]

Do note that reload4j is not 100% compatible with log4j 1.2.17, code has
just be deleted to "fix" some CVEs.

Gary

On Thu, Mar 3, 2022, 08:37 Bernd Eckenfels  wrote:

> All of the (known) remaining log4j1.x security bugs (none of which are as
> severe as log4shell) are fixed in reload4j 1.2.18+. If you need to stick
> with 1.2 you should use that. Otherwise you can try to migrate to the log4j
> bridge, it’s compatibility was increased in 2.17.2 or 2.12.4.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> Von: Martin Gainty 
> Gesendet: Thursday, March 3, 2022 1:18:50 PM
> An: Maven Developers List 
> Cc: David Milet ; iss...@maven.apache.org <
> iss...@maven.apache.org>; VZ-Product-OneTalk <
> vz-product-onet...@verizon.com>; Danylo Volokh <
> danylo.vol...@globallogic.com>
> Betreff: RE: Maven Dependency Plugin - Log4j vulnerabilities
>
> I *thought* log4j 1.2.15 had the patch to mitigate the JNDI Security
> Vulnerabity?
> Is this not the case?
> Thanks John
> M.
>
>
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
>
>
>  Original message 
> From: John Patrick 
> Date: 3/3/22 4:07 AM (GMT-05:00)
> To: Maven Developers List 
> Cc: David Milet , iss...@maven.apache.org,
> VZ-Product-OneTalk , Danylo Volokh <
> danylo.vol...@globallogic.com>
> Subject: Re: Maven Dependency Plugin - Log4j vulnerabilities
>
> Sorry I thought you where talking about log4j v2, not v1. I can see it
> downloads the metadata about the project but non or the jars;
> local-repo/log4j
> local-repo/log4j/log4j
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
> local-repo/log4j
> local-repo/log4j/log4j
> local-repo/log4j/log4j/1.2.12
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom
> local-repo/log4j/log4j/1.2.12/log4j-1.2.12.pom.sha1
> local-repo/log4j/log4j/1.2.12/_remote.repositories
>
> So I would still say false positive, as the jar is not actually used.
>
> But looking at the dependency tree it would need the apache commons to
> update commons-logging:commons-logging, then
> ommons-digester:commons-digester then org.apache.velocity:velocity-tools,
> then it gets to the 1st dependency within the maven ecosystem.
> So 5 ish patches to 5 separate projects to upgrade, test and release, each
> before then next pr can progress.
>
> John
>
>
> On Thu, 3 Mar 2022 at 07:53, Thomas Matthijs  wrote:
>
> > That was just to demonstrate how i got the dependency chain, that file
> > was there, but if you're going to be this hostile, i'm not interested
> > anymore, muting thread
> >
> > On Thu, 3 Mar 2022 at 08:48, Piotr Żygieło 
> > wrote:
> > >
> > > On Thu, 3 Mar 2022 at 08:37, Thomas Matthijs  wrote:
> > > >
> > > > Can confirm this project downloads log4j 1.12.12 for me
> > >
> > > As I see it - you confirm something else.
> > >
> > > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> > >
> > > Failed to read artifact descriptor for log4j:log4j:jar:1.2.12:
> > > _artifact descriptor_
> > >
> > > --
> > > Piotrek
> > >
> > > -
> > > 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: Formal identification of license in a POM license element

[Gary Gregory]

Hi Michael,

I'm looking for an intersection where Maven and this CFF plugin can be made
to work together, I don't know where that is. I'd be willing to offer a PR
here or there but there would need to be agreement on what the
solution would be.

Gary

On Sat, Feb 12, 2022, 04:48 Michael Osipov  wrote:

> https://issues.apache.org/jira/browse/MNG-6677
>
> Gary, don't confuse an ID with a name. Those are two different things. I
> guess adding an ID element is currently impossible. Even if, what about
> expressions SPDX supports? How to mdel that?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Formal identification of license in a POM license element

[Gary Gregory]

Hi All:

While researching GitHub's citation support [1], I found that there is a
plugin to convert a pom.xml into a CFF file [2]. I'd like to generate a CFF
file for Apache Commons Components like Commons Lang, Commons IO, and so
on. This plugin works but does not generate a license field [3] because the
POM license element does not hold a slot to identify a license with a
formal ID, in this case, the Linux Foundation SPDX ID [4]
https://spdx.dev/ids/

Any thoughts about supporting such a field for example "spdxID" or even
just "id" ?


   1. 
   2. 
   3. Apache-2.0 
   4. Apache License, Version 2.0
   5. https://www.apache.org/licenses/LICENSE-2.0.txt
   6. repo
   7. A business-friendly OSS license
   8. 
   9. 


?
Gary
[1]
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-citation-files
[2] https://github.com/hexatomic/cff-maven-plugin
[3] https://github.com/hexatomic/cff-maven-plugin/issues/28
[4] https://spdx.dev/ids/

Re: [RESULT] [VOTE] Release Maven JAR Plugin version 3.2.1

[Gary Gregory]

Congrats! :-)

Gary

On Sat, Jan 8, 2022, 14:53 Michael Osipov  wrote:

> Hi,
>
> The vote has passed with the following result:
>
> +1: Hervé Boutemy, Sylwester Lachiewicz, Romain Manni-Bucau, Michael
> Osipov, Tamás Cservenák, Jason van Zyl, Arnaud Héritier
>
> PMC quorum: reached
>
> I will promote the artifacts to the central repo, the source release ZIP
> file
> and add this release the board report.
>

Re: [VOTE] Release Maven Plugin Tools version 3.6.3

[Gary Gregory]

On Sat, Jan 8, 2022 at 10:20 AM Michael Osipov  wrote:

> Am 2022-01-08 um 15:24 schrieb Slawomir Jaranowski:
> > Ok,
> > I see now.
> >
> > But the problem still exists ...
> > m-p-p can not be used with Nexus staging maven plugin
> >
> > Looking into nexus staging plugin [1]  I'm afraid that will not be fixed
> in
> > the near future ... I'd like to be wrong
> >
> > But on the other side, the nexus staging plugin is quite often used ...
> [2]
> >
> >
> > [1]
> >
> https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin
> > [2]
> >
> https://github.com/search?l=Maven+POM=nexus-staging-maven-plugin=Code
>
> WEll, I see a name on the committer list who pissed me off on several
> occasions and the Java code and POM haven't been touched for five years,
> I guess the project is deeply dormant. Maybe Hervé can ping someone at
> work because of this.
>

Phew, glad my name is not on that list! ;-)

Gary


>
> M
>

Re: Using of Travis

[Gary Gregory]

FWIW, I plan on doing the same for most Apache Commons components.

Gary

On Mon, Dec 20, 2021, 11:22 Elliotte Rusty Harold 
wrote:

> +1 to drop Travis, for multiple reasons
>
> On Fri, Dec 17, 2021 at 7:52 AM 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
>
>
>
> --
> 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: Surefire next release

[Gary Gregory]

At work, some of my colleagues balk at seeing milestone versions in our
builds. What is preventing the next version from being "3.0.0", no "M". I
thought I read here a while back that the code was production ready.

Gary

On Sun, Dec 19, 2021, 12:26 Olivier Lamy  wrote:

> Sounds good.
> I'd really like to review/include this PR as well
> https://github.com/apache/maven-surefire/pull/400
> I hope to finish the review for this one during the week.
>
> On Sun, 19 Dec 2021 at 18:22, Slawomir Jaranowski 
> wrote:
>
> > Hi
> >
> > Last time I did the surefire build more stable.
> >
> > Now build looks ok on Jenkins
> >
> >
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-surefire/job/master/
> >
> > I prepared proposition for using shared GitHub action for project
> > https://github.com/apache/maven-surefire/pull/410
> >
> > Most of the tests look stable now.
> >
> > There are still about 260 issues on Jira.
> > Many of them was create some year ago ... so probably are not actual or
> are
> > duplicated
> > Some look like they are in progress without finishing,
> > I will work with Jira. I will try to ask about current issue status.
> >
> > The last release was in Jun 2020 so 1 and half year ago.
> > I think that we should plan the next release for Surefire which can help
> > resolve some of the issues.
> >
> > I don't know what the next version should be - in code we have
> > 3.0.0-M6-SNAPSHOT.
> >
> > There are also about 30 PRs, some of them also created a years ago ..
> > should be closed or merged.
> >
> > I need your help to plan and finally prepare for release.
> >
> >
> > Below is the result of the investigation for project status from
> repository
> > perspective and Jira perspective.
> >
> >
> > Current repository status
> >
> > ===
> > branch release/2.22.3
> >
> > f14da3b89 [SUREFIRE-1764] Upgrade JUnit Platform to 1.6.1
> > https://github.com/apache/maven-surefire/commit/f14da3b89
> >
> > current version in master is 1.3.2 for junit-platform-launcher - the
> newest
> > available version is 1.8.2
> > SUREFIRE-1764 - reopened
> >
> > ===
> > branch release/3.0.0-M6
> >
> > 8a6b33453 (upstream/release/3.0.0-M6, origin/release/3.0.0-M6)
> > [SUREFIRE-1432] Add extension interface with two implementations for
> > trimStackTrace
> > https://github.com/apache/maven-surefire/commit/8a6b33453
> >
> > SUREFIRE-1432 - reopened
> >
> > ===
> > There is about 130 commit to master since last tag surefire-3.0.0-M5
> >
> https://github.com/apache/maven-surefire/compare/surefire-3.0.0-M5...master
> >
> >
> > ===
> > ===
> >
> > JIRA status
> >
> > ===
> > RELEASE Backlog
> > - don't look here ...
> >
> > ===
> > RELEASE 2.21.1
> >  - SUREFIRE-1371 - only planed - no PR
> >  - SUREFIRE-1374 - in progres  some commit exist in master
> >
> >
> > ===
> > RELEASE 2.22.3
> >  - SUREFIRE-1679 - commit on master OK
> >  - SUREFIRE-1764 - reopened only in release/2.22.3 branch
> >
> > ===
> > RELEASE 3.0
> > 22 issues, 4 issues mark as done but all without changes
> >
> > ===
> > RELEASE 3.0.1
> > 1 issues - SUREFIRE-1430 - only planed
> >
> > ===
> > RELEAAE 3.0.0-M6
> > 69 issues, 46 done, 3 in progress, 20 to do
> >
> >
> > --
> > Sławomir Jaranowski
> >
>

Re: Any reason xi:include is not allowed?

[Gary Gregory]

The parsers I've seen don't "prevent" XI, you have to enable the feature;
note that some folks don't like DTD processing and XI for security reasons.

Gary

On Wed, Nov 17, 2021, 09:17 Romain Manni-Bucau 
wrote:

> Hi all,
>
> Almost everything is in the subject: any reason our pom parser prevents to
> use XML includes (https://www.w3.org/TR/xinclude/)?
>
> It would be very convenient to import some part of pom definition from
> .mvn/ or a project folder (indeed remote/insecured imports would be
> forbidden).
>
> Just a xpp3 limitation or something deeper?
> Do we want to support it?
>
> 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
> >
>

Re: GitHub Actions on Maven projects

[Gary Gregory]

At first glance, I can't tell if my projects would benefit from this plugin
or not. It seems to me the readme assumes to much domain knowledge.

Gary

On Sun, Nov 7, 2021, 12:13 Slawomir Jaranowski 
wrote:

> Hi,
>
> We have created maven-gh-actions-shared [1] with the first shared workflow.
> I hope that will be usable and help with less maintenance work.
>
> I'm starting to use this workflow in some of project [2]
>
> Lastly, what I think we need is a jira project to track changes.
>
> Thanks Olivier for supporting me.
>
> [1] https://github.com/apache/maven-gh-actions-shared
> [2]
>
> https://github.com/search?l=YAML=%22apache%2Fmaven-gh-actions-shared%2F%22=Code
>
>
> czw., 7 paź 2021 o 19:41 Slawomir Jaranowski 
> napisał(a):
>
> > Ok,
> >
> > if we want have to implement shared  Github Action  (I hope we do) I see
> > such steps:
> >
> > - create repository for share / common GitHub Actions like
> > maven-jenkins-lib maybe: maven-actions-lib - I need help what issue
> should
> > be created for it
> > - prepare proposition for shared workflows  - I can try to do it
> > - use and test in some project
> > - propagate for other project after confirm
> >
> > Now (at last) GitHub support shared workflows [1] [2] not only composite
> > action - it is something new, so we can start real shared workflows
> >
> > [1]
> >
> https://github.blog/changelog/2021-10-05-github-actions-dry-your-github-actions-configuration-by-reusing-workflows/
> > [2]
> >
> https://docs.github.com/en/actions/learn-github-actions/reusing-workflows
> >
> >
> > niedz., 19 wrz 2021 o 21:49 Slawomir Jaranowski 
> > napisał(a):
> >
> >> Fo jlink on maven jenkins (a last log [1]) I don't see toolchains ...
> and
> >> on java 8 simple it tests are skipped ...
> >>
> >> Maybe instead complicate build configuration - drop unsupported java 8
> >> from matrix.
> >> I don't know this project, I may not see the reason for build it on java
> >> 8 even then plugin require java 9+ for working
> >>
> >> I hope that most of projects can use common build steps. Of course we
> can
> >> prepare more than one build template.
> >>
> >>
> >>
> https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-jlink-plugin/job/master/112/execution/node/221/log/
> >>
> >> niedz., 19 wrz 2021 o 20:47 Benjamin Marwell 
> >> napisał(a):
> >>
> >>> 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 <
> >>> ta...@cservenak.net>:
> >>> >
> >>> > > +1 for global action
> >>> > >
> >>> > > T
> >>> > >
> >>> > > On Sat, Sep 18, 2021, 13:35 Slawomir Jaranowski <
> >>> s.jaranow...@gmail.com>
> >>> > > 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 <
> martinkant...@apache.org
> >>> >
> >>> > > > 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
> >>> 

Re: Upcoming Maven 3.8.4

[Gary Gregory]

That's the normal release process for any project AFAIK, if you want to put
a release candidate out to on https://dist.apache.org/repos/dist/dev/ that
is done via svn, we've automated those steps.

Then the actual release goes to https://dist.apache.org/repos/dist/release/,
same for Maven https://dist.apache.org/repos/dist/release/maven/

After that, the files are mirrored all over by various servers.

Publishing to Maven Central is a separate process but critical since that
is what most builds (Maven, Ant Ivy, and so on) expect and use.

Gary

On Sun, Oct 24, 2021, 05:27 Slawomir Jaranowski 
wrote:

> Hi,
>
> Very strange release process for common components ... some of the
> artifacts are published to the Central Repository and some of them are
> published by svn repository ...
> I don't see benefit for customizing maven core for one of case of usage
>
> but it is discussion for another place, here I only point it
>
>
> sob., 23 paź 2021 o 22:51 Gary Gregory 
> napisał(a):
>
> > HI All:
> >
> > I discovered a regression this morning that prevents me from creating
> > a release candidate for Apache Commons CLI:
> >
> > https://issues.apache.org/jira/browse/MNG-7316
> > https://github.com/apache/maven/pull/601
> >
> > May this be included for 3.8.4 please?
> >
> > Gary
> >
> > On Sat, Oct 23, 2021 at 3:48 PM Falko Modler  wrote:
> > >
> > > Hi,
> > >
> > > > Given that we had two releases with regressions I tend *not* to merge
> > > > #578. Give it more time and thought.
> > >
> > > As written before on GH, not merging #578 or a backport of #476 will
> > > bring back MNG-6843.
> > > This will catch users off guard that were happily benefitting from
> > > MNG-6843 being fixed in 3.8.2 and 3.8.3.
> > >
> > > If you still want to do it this way, then please at least document that
> > > MNG-6843 is back under "Known Issues" in 3.8.4 "Release Notes".
> > > Additionally, MNG-6843 should be reopened.
> > >
> > > I'd really prefer if we could keep MNG-6843 fixed, by whichever PR
> > > (doesn't need to be mine).
> > >
> > > Cheers,
> > >
> > > Falko
> > >
> > > Am 23.10.2021 um 21:22 schrieb Michael Osipov:
> > > > Folks,
> > > >
> > > > all important tickets for Maven 3.8.4 have been addressed in
> > > > maven-3.8.x branch.
> > > >
> > > > We have two open PRs:
> > > > * #578: Alternative to the ThreadLocal approach
> > > > * #476: As far as I understand a more global approach to the issue
> and
> > > > supersedes #576, but requires Java 8. So Maven 3.9+
> > > >
> > > > Given that we had two releases with regressions I tend *not* to merge
> > > > #578. Give it more time and thought. Maybe go over to #476 directly
> in
> > > > 3.9.0 and 4.0.0.
> > > >
> > > > Please test and let me know whether you still see errors. If I don't
> > > > read any objections I will start the new release somewhere around mid
> > > > next week.
> > > >
> > > > Michael
> > > >
> > > > -
> > > > 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
> >
> >
>
> --
> Sławomir Jaranowski
>

Re: Upcoming Maven 3.8.4

[Gary Gregory]

HI All:

I discovered a regression this morning that prevents me from creating
a release candidate for Apache Commons CLI:

https://issues.apache.org/jira/browse/MNG-7316
https://github.com/apache/maven/pull/601

May this be included for 3.8.4 please?

Gary

On Sat, Oct 23, 2021 at 3:48 PM Falko Modler  wrote:
>
> Hi,
>
> > Given that we had two releases with regressions I tend *not* to merge
> > #578. Give it more time and thought.
>
> As written before on GH, not merging #578 or a backport of #476 will
> bring back MNG-6843.
> This will catch users off guard that were happily benefitting from
> MNG-6843 being fixed in 3.8.2 and 3.8.3.
>
> If you still want to do it this way, then please at least document that
> MNG-6843 is back under "Known Issues" in 3.8.4 "Release Notes".
> Additionally, MNG-6843 should be reopened.
>
> I'd really prefer if we could keep MNG-6843 fixed, by whichever PR
> (doesn't need to be mine).
>
> Cheers,
>
> Falko
>
> Am 23.10.2021 um 21:22 schrieb Michael Osipov:
> > Folks,
> >
> > all important tickets for Maven 3.8.4 have been addressed in
> > maven-3.8.x branch.
> >
> > We have two open PRs:
> > * #578: Alternative to the ThreadLocal approach
> > * #476: As far as I understand a more global approach to the issue and
> > supersedes #576, but requires Java 8. So Maven 3.9+
> >
> > Given that we had two releases with regressions I tend *not* to merge
> > #578. Give it more time and thought. Maybe go over to #476 directly in
> > 3.9.0 and 4.0.0.
> >
> > Please test and let me know whether you still see errors. If I don't
> > read any objections I will start the new release somewhere around mid
> > next week.
> >
> > Michael
> >
> > -
> > 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: Regression in Maven 3.8.2? site/javadoc generation fails

[Gary Gregory]

Sounds good Michael, thanks for the update.

Gary

On Sun, Sep 5, 2021, 12:50 Michael Osipov  wrote:

> Gary, I plan to address open issues in the course of the next two weeks.
> Followed by week of testing by the community. If everything goes well I
> will call the vote by the end of this month.
>
> M
>
> Am 2021-09-05 um 16:46 schrieb Gary Gregory:
> > Hopefully 3.8.3 is around the corner.
> >
> > Gary
> >
> > On Sat, Sep 4, 2021, 11:09 Stefan Seifert  .invalid>
> > wrote:
> >
> >> hello falko.
> >>
> >> i can confirm the problem is fixed with PR #527! - will add a comment to
> >> about it in MNG-7220.
> >>
> >> stefan
> >>
> >>> -Original Message-
> >>> From: Falko Modler 
> >>> Sent: Saturday, September 4, 2021 12:39 PM
> >>> To: Maven Developers List 
> >>> Subject: Re: Regression in Maven 3.8.2? site/javadoc generation fails
> >>>
> >>> I haven't checked, but there is a good chance
> >>> https://github.com/apache/maven/pull/527 might fix that problem.
> >>>
> >>> Cheers,
> >>>
> >>> Falko
> >>>
> >>> 03.09.2021 16:02:04 Stefan Seifert  .INVALID>:
> >>>
> >>>> thanks for the pointer - but i think my problem is different. in my
> case
> >>> it's not a problem of looking up a site descriptor, but resolving
> >>> dependencies from parent POMs during the javadoc generation that is
> part
> >> of
> >>> the site build.
> >>>>
> >>>> i tried the tarball from https://issues.apache.org/jira/browse/MNG-
> >>
> >>>
> 7218?focusedCommentId=17400589=com.atlassian.jira.plugin.system.issuet
> >>> abpanels:comment-tabpanel#comment-17400589 which reverts the change
> from
> >>> MGN-7170, and it fixes the problem with getting the right skin for the
> >>> site, but did not fix the problem with the dependencies in javadoc
> >>> generation described here initially.
> >>>>
> >>>> should i create a new MNG issue for it?
> >>>>
> >>>> stefan
> >>>>
> >>>>> -Original Message-
> >>>>> From: Gary Gregory 
> >>>>> Sent: Friday, September 3, 2021 2:41 PM
> >>>>> To: Maven Developers List 
> >>>>> Subject: Re: Regression in Maven 3.8.2? site/javadoc generation fails
> >>>>>
> >>>>> See https://issues.apache.org/jira/browse/MNG-7215 and the short
> >> thread
> >>>>> here "Wrong site skin in 3.8.2 vs 3.6.3"
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>> On Fri, Sep 3, 2021, 08:08 Stefan Seifert  >>>>> e.com.invalid>
> >>>>> wrote:
> >>>>>
> >>>>>> i've encountered a problem in numerous of our Maven builds at
> wcm.io
> >>> [1]
> >>>>>> which started failing yesterday when GitHub switched to latest Maven
> >>>>> 3.8.2
> >>>>>> release for their images.
> >>>>>>
> >>>>>> an example is described in [2], build log [3], to sum it up:
> >>>>>> - build fails in when generating the maven site during the javadoc
> >>> step,
> >>>>>> which is unable to find a couple of dependencies which are defined
> >>>>>> correctly (they are defined as "provided" in the 
> section
> >>> of
> >>>>>> one of the parent POMs)
> >>>>>> - the build does not fail when "javadoc:javadoc" is executed
> directly,
> >>>>>> only as part of the "site" goal
> >>>>>> - everything runs fine with Maven 3.8.1 or 3.6.3
> >>>>>>
> >>>>>> i'm not sure if this is an issue in either site mojo or javadoc mojo
> >> or
> >>>>>> Maven itself. the release notes [4] contain a pointer to a change
> >>> around
> >>>>>> MNG-6843, but i'm not aware that site or javadoc plugin are spwaning
> >>> new
> >>>>>> threads.
> >>>>>>
> >>>>>> any ideas about the root cause?
> >>>>>>
> >>>>>> stefan
> >>>>>>
> >>>>>> [1] https://github.com/wcm-io
> >>>>>> [2] https://wcm-io.atlassian.net/browse/WTOOL-78
> >>>>>> [3]
> >>>>>> https://github.com/wcm-io/wcm-io-wcm-core-
> >>>>> components/runs/3505611228?check_suite_focus=true
> >>>>>> [4] https://maven.apache.org/docs/3.8.2/release-notes.html
> >>>>>>
> >>>>>>
> -
> >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>