Re: Weird behavior in plugin phase resolution

[Christoph Läubrich]

The main point is: If my build is "broken" by adding another phase, it 
is not broken by that fact, it was broken before.


> Do you have some example about that, where it is placed it shouldn't
> until you use maven-core as a lib and then you have to reimplement the
> maven preconditions AFAIK.

I'm not completely sure about the question, but at least in 
integration-test phase I often use different plugins that might pull in 
a lot of dependencies, also quite often a phase is specified, so if they 
are now eager resolved it mean that 'mvn clean package' will download 
them eagerly even if never executed while I would more expect it to only 
download things (like its done with dependencies) if the phase is 
actually executed.


If one want to eager resolve everything one could use
'mvn dependency:go-offline'

> It is globally my point, we do an optimization leading to a "looking
> inconsistent" behavior (even if we can explain it, it is misleading).

I think such "inconsistencies" do not occur often enough to break the 
general rule to be as lazy as possible to not download things 
unnecessary (unless requested). I would even say this is a very very 
rare case, each time I add something to the pom I immediately execute 
that new "thing" to see its working and would see that error immediately.


> Not sure it is a point since it means the plugin is not part of the 
build.


At least not of the current executed build, but I thought that was the 
intend here that in such cases no download happen and you maybe miss a 
thing (e.g. wrong group/artifact id).




Am 27.06.23 um 07:37 schrieb Romain Manni-Bucau:

Hi Christoph,

Added a few questions inline cause I'm not sure I got it all.

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



Le mar. 27 juin 2023 à 06:38, Christoph Läubrich  a
écrit :


Just a few remarks:

1) There might be situations were no cache is there so it can hurt
performance to resolve "useless" plugins (e.g. from deploy phase) and
probably long dependency chains.



Do you have some example about that, where it is placed it shouldn't until
you use maven-core as a lib and then you have to reimplement the maven
preconditions AFAIK.




2) one should not optimize for the error case, if I never test my
project it is not the task of maven to help me in that regards



It is globally my point, we do an optimization leading to a "looking
inconsistent" behavior (even if we can explain it, it is misleading).




3) If it is cause by a temporary failure I might be happy that my build
still works if I do not execute that phase (yet)



Not sure it is a point since it means the plugin is not part of the build.
Indeed there are cases like jetty plugin but there are not mainstream and
still, means your build setup is not reliable for dev so I even tend it is
exactly the opposite which should happen to validate it.
If you want the behavior you describe you use profiles in maven world which
are closer to the behavior you mention, not main plugin section.




4) I don't think its inconsistent e.g. if I call mvn validate it might
not download dependencies, if I call mvn compile only some of them so in
general it is consistent to delay things as much as possible.



This is the ambiguous part. Seeing it like that can be consistent but as an
end user you don't see that, you see that adding or not a phase makes your
build broken or not.
This does not "look" consistent at all nor user friendly.
I'm not sure of the outcome but we might either force the resolution of all
plugins on the "line", ie even when a phase is forced we do resolve it
(which is still compatible with the lazy spirit but by "pipe" instead of
item) or we add a log in the case we resolved it for nothing requesting
user to set explicitly the phase which can lead to not using defaultPhase
as a good practise which is something I'm very doubtious about and why I
sent this mail.




Am 26.06.23 um 21:28 schrieb Romain Manni-Bucau:

Hi all,

With JB Onofré we discussed a surprising behavior of maven plugin

execution

chain.
Long story short it is this piece of code:


https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/DefaultLifecycleMappingDelegate.java#L93

.

The overall idea is: if the phase is not explicit then resolve the plugin
to get its descriptor and check its default phase else use the user
explicit phase.

This looks quite good and logical and it can save some plugin resolution
(which should be ~0 saved time after first cache).

However it has a major drawback (what JB hit and why we discussed it): if
you have a plugin which can't be resolved for whatever reason, setting a
phase will not make the build 

Re: Weird behavior in plugin phase resolution

[Romain Manni-Bucau]

Hi Christoph,

Added a few questions inline cause I'm not sure I got it all.

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



Le mar. 27 juin 2023 à 06:38, Christoph Läubrich  a
écrit :

> Just a few remarks:
>
> 1) There might be situations were no cache is there so it can hurt
> performance to resolve "useless" plugins (e.g. from deploy phase) and
> probably long dependency chains.
>

Do you have some example about that, where it is placed it shouldn't until
you use maven-core as a lib and then you have to reimplement the maven
preconditions AFAIK.


>
> 2) one should not optimize for the error case, if I never test my
> project it is not the task of maven to help me in that regards
>

It is globally my point, we do an optimization leading to a "looking
inconsistent" behavior (even if we can explain it, it is misleading).


>
> 3) If it is cause by a temporary failure I might be happy that my build
> still works if I do not execute that phase (yet)
>

Not sure it is a point since it means the plugin is not part of the build.
Indeed there are cases like jetty plugin but there are not mainstream and
still, means your build setup is not reliable for dev so I even tend it is
exactly the opposite which should happen to validate it.
If you want the behavior you describe you use profiles in maven world which
are closer to the behavior you mention, not main plugin section.


>
> 4) I don't think its inconsistent e.g. if I call mvn validate it might
> not download dependencies, if I call mvn compile only some of them so in
> general it is consistent to delay things as much as possible.
>

This is the ambiguous part. Seeing it like that can be consistent but as an
end user you don't see that, you see that adding or not a phase makes your
build broken or not.
This does not "look" consistent at all nor user friendly.
I'm not sure of the outcome but we might either force the resolution of all
plugins on the "line", ie even when a phase is forced we do resolve it
(which is still compatible with the lazy spirit but by "pipe" instead of
item) or we add a log in the case we resolved it for nothing requesting
user to set explicitly the phase which can lead to not using defaultPhase
as a good practise which is something I'm very doubtious about and why I
sent this mail.


>
> Am 26.06.23 um 21:28 schrieb Romain Manni-Bucau:
> > Hi all,
> >
> > With JB Onofré we discussed a surprising behavior of maven plugin
> execution
> > chain.
> > Long story short it is this piece of code:
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/DefaultLifecycleMappingDelegate.java#L93
> > .
> >
> > The overall idea is: if the phase is not explicit then resolve the plugin
> > to get its descriptor and check its default phase else use the user
> > explicit phase.
> >
> > This looks quite good and logical and it can save some plugin resolution
> > (which should be ~0 saved time after first cache).
> >
> > However it has a major drawback (what JB hit and why we discussed it): if
> > you have a plugin which can't be resolved for whatever reason, setting a
> > phase will not make the build being broken until you call it whereas not
> > setting a phase will fail whatever lifecycle you call since you will have
> > to resolve the plugin to get its default phase.
> >
> > Wonder if we would gain to just ensure the plugin is always resolved for
> > behavior consistency.
> > Idea being that setting or not a phase does not have side effects for end
> > users.
> >
> > Side note: didn't check the whole code but can likely apply to other
> > attributes so always resolving sounds like the sanest default to me.
> >
> > 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
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Weird behavior in plugin phase resolution

[Christoph Läubrich]

Just a few remarks:

1) There might be situations were no cache is there so it can hurt 
performance to resolve "useless" plugins (e.g. from deploy phase) and 
probably long dependency chains.


2) one should not optimize for the error case, if I never test my 
project it is not the task of maven to help me in that regards


3) If it is cause by a temporary failure I might be happy that my build 
still works if I do not execute that phase (yet)


4) I don't think its inconsistent e.g. if I call mvn validate it might 
not download dependencies, if I call mvn compile only some of them so in 
general it is consistent to delay things as much as possible.


Am 26.06.23 um 21:28 schrieb Romain Manni-Bucau:

Hi all,

With JB Onofré we discussed a surprising behavior of maven plugin execution
chain.
Long story short it is this piece of code:
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/DefaultLifecycleMappingDelegate.java#L93
.

The overall idea is: if the phase is not explicit then resolve the plugin
to get its descriptor and check its default phase else use the user
explicit phase.

This looks quite good and logical and it can save some plugin resolution
(which should be ~0 saved time after first cache).

However it has a major drawback (what JB hit and why we discussed it): if
you have a plugin which can't be resolved for whatever reason, setting a
phase will not make the build being broken until you call it whereas not
setting a phase will fail whatever lifecycle you call since you will have
to resolve the plugin to get its default phase.

Wonder if we would gain to just ensure the plugin is always resolved for
behavior consistency.
Idea being that setting or not a phase does not have side effects for end
users.

Side note: didn't check the whole code but can likely apply to other
attributes so always resolving sounds like the sanest default to me.

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




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

Weird behavior in plugin phase resolution

[Romain Manni-Bucau]

Hi all,

With JB Onofré we discussed a surprising behavior of maven plugin execution
chain.
Long story short it is this piece of code:
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/internal/DefaultLifecycleMappingDelegate.java#L93
.

The overall idea is: if the phase is not explicit then resolve the plugin
to get its descriptor and check its default phase else use the user
explicit phase.

This looks quite good and logical and it can save some plugin resolution
(which should be ~0 saved time after first cache).

However it has a major drawback (what JB hit and why we discussed it): if
you have a plugin which can't be resolved for whatever reason, setting a
phase will not make the build being broken until you call it whereas not
setting a phase will fail whatever lifecycle you call since you will have
to resolve the plugin to get its default phase.

Wonder if we would gain to just ensure the plugin is always resolved for
behavior consistency.
Idea being that setting or not a phase does not have side effects for end
users.

Side note: didn't check the whole code but can likely apply to other
attributes so always resolving sounds like the sanest default to me.

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

Re: [RESULT] [VOTE] Release Apache Maven 3.9.3

[Karl Heinz Marbaise]

Hi,
On 26.06.23 15:48, Karl Heinz Marbaise wrote:

Hi,

On 26.06.23 12:53, Tamás Cservenák wrote:

Howdy,

The vote has passed with the following result:

+1b: Romain, Henning, Karl Heinz


Missing:
  * Slawomir Jaranowski
  * Tamás Cservanák


and also missed:

* Guillaume Nodet

Kind regards
Karl Heinz


Also please CC post on private pmc list.

Kind regards
Karl Heinz

+2nb: Delany

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release to the board report.

Thanks
T



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

Re: [RESULT] [VOTE] Release Apache Maven 3.9.3

[Karl Heinz Marbaise]

Hi,

On 26.06.23 12:53, Tamás Cservenák wrote:

Howdy,

The vote has passed with the following result:

+1b: Romain, Henning, Karl Heinz


Missing:
 * Slawomir Jaranowski
 * Tamás Cservanák

Also please CC post on private pmc list.

Kind regards
Karl Heinz

+2nb: Delany

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release to the board report.

Thanks
T




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

[ANN] Apache Maven 3.9.3 released

[Tamás Cservenák]

The Apache Maven team is pleased to announce the release of the
Apache Maven 3.9.3

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

For more information read
https://maven.apache.org/docs/3.9.3/release-notes.html

Release Notes - Maven - Version 3.9.3

** Bug
* [MNG-7786] - Maven Plugin Validation message is misleading
* [MNG-7795] - IllegalArgumentException: 'other' has different root
during plugin validation
* [MNG-7796] - Top directory cannot be computed
* [MNG-7799] - Plugin validation falsely reports there are issues (but
shows none)
* [MNG-7811] - Plugins verification - reports are inconsistent
* [MNG-7818] - [REGRESSION] maven improperly excludes hamcrest-core
from junit
* [MNG-7819] - Create IT that exercise file locking with snapshots
** Improvement
* [MNG-7698] - Allow comments in .mvn/maven.config
* [MNG-7785] - Clean usage of SessionData
* [MNG-7787] - Introduce new options for plugin validation
* [MNG-7788] - Plugin Validation Report should be printed before build
summary
* [MNG-7789] - Plugin Dependency Validations use wrong data set
* [MNG-7806] - Plugins verification - remove used in module(s) report
* [MNG-7823] - Make plugin validation level parsing more consistent
** Task
* [MNG-5987] - Document the algorithm calculating the order of plugin
executions inside a phase.
* [MNG-7743] - Make the build work on JDK 20
* [MNG-7790] - Update lifecycle plugins
* [MNG-7791] - Split validation issues into "user actionable" and
"plugin dev actionable"
* [MNG-7797] - Return BRIEF mode, simply map it onto SUMMARY
* [MNG-7807] - Update Super POM plugins
** Dependency upgrade
* [MNG-7800] - Upgrade to Maven Resolver 1.9.13
* [MNG-7816] - Bump maven parent from 39 to 40

Have fun!
- The Maven Team

Re: [RESULT] [VOTE] Release Apache Maven 3.9.3

[Tamás Cservenák]

A slight correction re votes (and my mistake: Henning is not PMC):

+1b: Romain, Karl Heinz, Slawek and Guillaume
+1nb: Delany, Henning

On Mon, Jun 26, 2023 at 12:53 PM Tamás Cservenák 
wrote:

> Howdy,
>
> The vote has passed with the following result:
>
> +1b: Romain, Henning, Karl Heinz
> +2nb: Delany
>
> PMC quorum: reached
>
> I will promote the artifacts to the central repo, the source release ZIP
> file and add this release to the board report.
>
> Thanks
> T
>

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

[Slawomir Jaranowski]

+1

sob., 24 cze 2023 o 12:56 Guillaume Nodet  napisał(a):

> I'm starting a new vote to release this new alpha.
>
> 67 issues solved:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353052
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-1970
>
> Dev dist directory:
> https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-7/
>
> Source release checksums:
> apache-maven-4.0.0-alpha-6-src.zip sha512:
>
>
> bc822a381f84b156f2d5c2b59502db44ef3e8689f534913820dc0c68014e02dc75639c1990df4203d7923318d2b1668b050f452556c15eb638271e1ae3688e87
>
> apache-maven-4.0.0-alpha-6-src.tar.gz sha512:
>
>
> c7e9d13df74797163e816536e76f14c25496cdc8f13faa990bf14ce5a5669ec09cdc44dd4da866dd72d68ba9e2d8d6bdcce57110e21ecbeb8d15c50cad64430b
>
>
> Binary release checksums:
> apache-maven-4.0.0-alpha-6-bin.zip sha512:
>
>
> ec47b84cbf5dd85a8081d218bf105d4664e298d906c28f11192bf563f30087a4d898f872fc73230391579f8aa84e70bddb0ae2eabc42b53a2c574d5793ceb1a2
>
> apache-maven-4.0.0-alpha-6-bin.tar.gz sha512:
>
>
> 9959e537712167094a7909006168404c16b0788862311ef65840f5b8d3afc519e63262b064db7361bc6ef77940bed14ead5e0a59d135bcdeea83be4d9893
>
>
> Staged site:
> https://maven.apache.org/ref/4-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/432
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> --
> 
> Guillaume Nodet
>


-- 
Sławomir Jaranowski

Re: [VOTE] Release Apache Maven 3.9.3

[Guillaume Nodet]

+1

Le ven. 23 juin 2023 à 15:34, Tamás Cservenák  a
écrit :

> Howdy,
>
> We solved 22 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353255
>
> 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-1968/
>
> Dev dist directory:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.3/
>
> Source release checksums:
> apache-maven-3.9.3-src.zip sha512:
>
> a56a9e47e70ba8e3e83ff627b76a712c7b5bda59245d23bcbc541b2358b859f699d4916b7e715c45a5c336676b8b2ab0ab472dffc045ae4db635b21f7ddcc0c2
> apache-maven-3.9.3-src.tar.gz sha512:
>
> 5511b20c36fd09a8ba7260bfa78d29bb683a04828c56e93d176768eb61cb07ab91f29db745460ce9784c84561f359497158f4c800142716d3e590ac2c333e8fb
>
> Binary release checksums:
> apache-maven-3.9.3-bin.zip sha512:
>
> fba80f4bb0429052d558959b1bfbc99984f8cb8ff59a53baae0a0874b71a2601e2805c5e557b7b59d81716a0b4b35d1b2eeccb566c40b23cc575331a4984ef6c
> apache-maven-3.9.3-bin.tar.gz sha512:
>
> 400fc5b6d000c158d5ee7937543faa06b6bda8408caa2444a9c947c21472fde0f0b64ac452b8cec8855d528c0335522ed5b6c8f77085811c7e29e1bedbb5daa2
>
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/424
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>


-- 

Guillaume Nodet

Re: [VOTE] Release Apache Maven 3.9.3

[Slawomir Jaranowski]

+1

pt., 23 cze 2023 o 15:34 Tamás Cservenák  napisał(a):

> Howdy,
>
> We solved 22 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353255
>
> 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-1968/
>
> Dev dist directory:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.3/
>
> Source release checksums:
> apache-maven-3.9.3-src.zip sha512:
>
> a56a9e47e70ba8e3e83ff627b76a712c7b5bda59245d23bcbc541b2358b859f699d4916b7e715c45a5c336676b8b2ab0ab472dffc045ae4db635b21f7ddcc0c2
> apache-maven-3.9.3-src.tar.gz sha512:
>
> 5511b20c36fd09a8ba7260bfa78d29bb683a04828c56e93d176768eb61cb07ab91f29db745460ce9784c84561f359497158f4c800142716d3e590ac2c333e8fb
>
> Binary release checksums:
> apache-maven-3.9.3-bin.zip sha512:
>
> fba80f4bb0429052d558959b1bfbc99984f8cb8ff59a53baae0a0874b71a2601e2805c5e557b7b59d81716a0b4b35d1b2eeccb566c40b23cc575331a4984ef6c
> apache-maven-3.9.3-bin.tar.gz sha512:
>
> 400fc5b6d000c158d5ee7937543faa06b6bda8408caa2444a9c947c21472fde0f0b64ac452b8cec8855d528c0335522ed5b6c8f77085811c7e29e1bedbb5daa2
>
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/424
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>


-- 
Sławomir Jaranowski

Re: [VOTE] Release Apache Maven 3.9.3

[Tamás Cservenák]

And just as an afterthought...

This is clear example of "good outcome" of plugin warning, see this issue:
https://github.com/jacoco/jacoco/issues/1435

If these would NOT be shown by default to users, I assume this issue would
never be reported either.


T

On Mon, Jun 26, 2023 at 12:47 PM Tamás Cservenák 
wrote:

> Howdy,
>
> created https://issues.apache.org/jira/browse/MNG-7826
> as it seems that:
> * jacoco 0.8.10 is "bad" in this respect (FTR is fixed but not yet
> released, see JIRA issue),
> * validation report by Maven 3.9.2 is correct,
> * while Maven 3.9.3 misses to report it
>
> This is not a deal-breaker, but seems we ended up on the other end of the
> horse now, at least regarding plugin validation :(
>
> On Sun, Jun 25, 2023 at 12:10 PM Karl Heinz Marbaise 
> wrote:
>
>> Hi,
>>
>> difference between Maven 3.9.2, getting the following output: (mvn clean
>> verify):
>>
>> [INFO] BUILD SUCCESS
>> [INFO]
>> 
>> [INFO] Total time:  2.397 s
>> [INFO] Finished at: 2023-06-25T11:48:38+02:00
>> [INFO]
>> 
>> [WARNING]
>> [WARNING] Plugin validation issues were detected in 2 plugin(s)
>> [WARNING]
>> [WARNING]  * org.jacoco:jacoco-maven-plugin:0.8.10
>> [WARNING]  * org.apache.maven.plugins:maven-site-plugin:3.12.1
>> [WARNING]
>> [WARNING] For more or less details, use 'maven.plugin.validation'
>> property with one of the values (case insensitive): [BRIEF, DEFAULT,
>> VERBOSE]
>> [WARNING]
>>
>> This is a good conclusion at the end of the build.
>>
>> Now using Maven 3.9.3:
>>
>> [INFO]
>> 
>> [INFO] BUILD SUCCESS
>> [INFO]
>> 
>> [INFO] Total time:  2.321 s
>> [INFO] Finished at: 2023-06-25T11:49:01+02:00
>> [INFO]
>> 
>>
>> Not even the smallest hint.
>>
>> If I change the calling for Maven 3.9.3: (mvn clean verify
>> -Dmaven.plugin.validation=VERBOSE):
>>
>>
>> [INFO]
>> [INFO] --- jacoco:0.8.10:report (default) @ jdk21 ---
>> [INFO] Skipping JaCoCo execution due to missing execution data file.
>> [WARNING]
>> [WARNING] Plugin [INTERNAL, EXTERNAL] validation issues were detected in
>> following plugin(s)
>> [WARNING]
>> [WARNING]  * org.apache.maven.plugins:maven-site-plugin:3.12.1
>> [WARNING]   Declared at location(s):
>> [WARNING]* com.soebes.smpp:smpp:6.0.3
>> (/Users/khm/.m2/repository/com/soebes/smpp/smpp/6.0.3/smpp-6.0.3.pom) @
>> line 580
>> [WARNING]   Plugin EXTERNAL issue(s):
>> [WARNING]* Plugin depends on the deprecated Maven 2.x compatibility
>> layer, which will be not supported in Maven 4.x
>> [WARNING]   Mojo EXTERNAL issue(s):
>> [WARNING]* Mojo site:attach-descriptor
>> (org.apache.maven.plugins.site.descriptor.SiteDescriptorAttachMojo)
>> [WARNING]  - Parameter 'localRepository' uses deprecated parameter
>> expression '${localRepository}': ArtifactRepository type is deprecated
>> and its use in Mojos should be avoided.
>> [WARNING]
>> [WARNING]
>> [WARNING] Fix reported issues by adjusting plugin configuration or by
>> upgrading above listed plugins. If no upgrade available, please notify
>> plugin maintainers about reported issues.
>> [WARNING] For more or less details, use 'maven.plugin.validation'
>> property with one of the values (case insensitive): [NONE, INLINE,
>> SUMMARY, BRIEF, VERBOSE]
>> [WARNING]
>>
>>
>> The interesting part here is that the jacoco-maven-plugin is NOT
>> reported at all for Maven 3.9.3.
>>
>> Does that mean the jacoco-maven-plugin is ok or not? Or was the
>> reporting in Maven 3.9.2 wrong?
>>
>>
>>  From my point of view the difference in behaviour is confusing...
>>
>>
>> +1 from me
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> On 23.06.23 15:33, Tamás Cservenák wrote:
>> > Howdy,
>> >
>> > We solved 22 issues:
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353255
>> >
>> > 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-1968/
>> >
>> > Dev dist directory:
>> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.3/
>> >
>> > Source release checksums:
>> > apache-maven-3.9.3-src.zip sha512:
>> >
>> a56a9e47e70ba8e3e83ff627b76a712c7b5bda59245d23bcbc541b2358b859f699d4916b7e715c45a5c336676b8b2ab0ab472dffc045ae4db635b21f7ddcc0c2
>> > apache-maven-3.9.3-src.tar.gz sha512:
>> >
>> 5511b20c36fd09a8ba7260bfa78d29bb683a04828c56e93d176768eb61cb07ab91f29db745460ce9784c84561f359497158f4c800142716d3e590ac2c333e8fb
>> >
>> > Binary release checksums:
>> > apache-maven-3.9.3-bin.zip sha512:
>> >
>> 

[RESULT] [VOTE] Release Apache Maven 3.9.3

[Tamás Cservenák]

Howdy,

The vote has passed with the following result:

+1b: Romain, Henning, Karl Heinz
+2nb: Delany

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release to the board report.

Thanks
T

Re: [VOTE] Release Apache Maven 3.9.3

[Tamás Cservenák]

Howdy,

created https://issues.apache.org/jira/browse/MNG-7826
as it seems that:
* jacoco 0.8.10 is "bad" in this respect (FTR is fixed but not yet
released, see JIRA issue),
* validation report by Maven 3.9.2 is correct,
* while Maven 3.9.3 misses to report it

This is not a deal-breaker, but seems we ended up on the other end of the
horse now, at least regarding plugin validation :(

On Sun, Jun 25, 2023 at 12:10 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> difference between Maven 3.9.2, getting the following output: (mvn clean
> verify):
>
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time:  2.397 s
> [INFO] Finished at: 2023-06-25T11:48:38+02:00
> [INFO]
> 
> [WARNING]
> [WARNING] Plugin validation issues were detected in 2 plugin(s)
> [WARNING]
> [WARNING]  * org.jacoco:jacoco-maven-plugin:0.8.10
> [WARNING]  * org.apache.maven.plugins:maven-site-plugin:3.12.1
> [WARNING]
> [WARNING] For more or less details, use 'maven.plugin.validation'
> property with one of the values (case insensitive): [BRIEF, DEFAULT,
> VERBOSE]
> [WARNING]
>
> This is a good conclusion at the end of the build.
>
> Now using Maven 3.9.3:
>
> [INFO]
> 
> [INFO] BUILD SUCCESS
> [INFO]
> 
> [INFO] Total time:  2.321 s
> [INFO] Finished at: 2023-06-25T11:49:01+02:00
> [INFO]
> 
>
> Not even the smallest hint.
>
> If I change the calling for Maven 3.9.3: (mvn clean verify
> -Dmaven.plugin.validation=VERBOSE):
>
>
> [INFO]
> [INFO] --- jacoco:0.8.10:report (default) @ jdk21 ---
> [INFO] Skipping JaCoCo execution due to missing execution data file.
> [WARNING]
> [WARNING] Plugin [INTERNAL, EXTERNAL] validation issues were detected in
> following plugin(s)
> [WARNING]
> [WARNING]  * org.apache.maven.plugins:maven-site-plugin:3.12.1
> [WARNING]   Declared at location(s):
> [WARNING]* com.soebes.smpp:smpp:6.0.3
> (/Users/khm/.m2/repository/com/soebes/smpp/smpp/6.0.3/smpp-6.0.3.pom) @
> line 580
> [WARNING]   Plugin EXTERNAL issue(s):
> [WARNING]* Plugin depends on the deprecated Maven 2.x compatibility
> layer, which will be not supported in Maven 4.x
> [WARNING]   Mojo EXTERNAL issue(s):
> [WARNING]* Mojo site:attach-descriptor
> (org.apache.maven.plugins.site.descriptor.SiteDescriptorAttachMojo)
> [WARNING]  - Parameter 'localRepository' uses deprecated parameter
> expression '${localRepository}': ArtifactRepository type is deprecated
> and its use in Mojos should be avoided.
> [WARNING]
> [WARNING]
> [WARNING] Fix reported issues by adjusting plugin configuration or by
> upgrading above listed plugins. If no upgrade available, please notify
> plugin maintainers about reported issues.
> [WARNING] For more or less details, use 'maven.plugin.validation'
> property with one of the values (case insensitive): [NONE, INLINE,
> SUMMARY, BRIEF, VERBOSE]
> [WARNING]
>
>
> The interesting part here is that the jacoco-maven-plugin is NOT
> reported at all for Maven 3.9.3.
>
> Does that mean the jacoco-maven-plugin is ok or not? Or was the
> reporting in Maven 3.9.2 wrong?
>
>
>  From my point of view the difference in behaviour is confusing...
>
>
> +1 from me
>
> Kind regards
> Karl Heinz Marbaise
>
> On 23.06.23 15:33, Tamás Cservenák wrote:
> > Howdy,
> >
> > We solved 22 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353255
> >
> > 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-1968/
> >
> > Dev dist directory:
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.3/
> >
> > Source release checksums:
> > apache-maven-3.9.3-src.zip sha512:
> >
> a56a9e47e70ba8e3e83ff627b76a712c7b5bda59245d23bcbc541b2358b859f699d4916b7e715c45a5c336676b8b2ab0ab472dffc045ae4db635b21f7ddcc0c2
> > apache-maven-3.9.3-src.tar.gz sha512:
> >
> 5511b20c36fd09a8ba7260bfa78d29bb683a04828c56e93d176768eb61cb07ab91f29db745460ce9784c84561f359497158f4c800142716d3e590ac2c333e8fb
> >
> > Binary release checksums:
> > apache-maven-3.9.3-bin.zip sha512:
> >
> fba80f4bb0429052d558959b1bfbc99984f8cb8ff59a53baae0a0874b71a2601e2805c5e557b7b59d81716a0b4b35d1b2eeccb566c40b23cc575331a4984ef6c
> > apache-maven-3.9.3-bin.tar.gz sha512:
> >
> 400fc5b6d000c158d5ee7937543faa06b6bda8408caa2444a9c947c21472fde0f0b64ac452b8cec8855d528c0335522ed5b6c8f77085811c7e29e1bedbb5daa2
> >
> > Staged site:
> > https://maven.apache.org/ref/3-LATEST/
> >
> > Draft for release notes:
> > https://github.com/apache/maven-site/pull/424
> >
> > Guide to testing staged releases:
> > 

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

[Slawomir Jaranowski]

One finding after my tests:
https://issues.apache.org/jira/browse/MNG-7825

sob., 24 cze 2023 o 12:56 Guillaume Nodet  napisał(a):

> I'm starting a new vote to release this new alpha.
>
> 67 issues solved:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353052
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-1970
>
> Dev dist directory:
> https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-7/
>
> Source release checksums:
> apache-maven-4.0.0-alpha-6-src.zip sha512:
>
>
> bc822a381f84b156f2d5c2b59502db44ef3e8689f534913820dc0c68014e02dc75639c1990df4203d7923318d2b1668b050f452556c15eb638271e1ae3688e87
>
> apache-maven-4.0.0-alpha-6-src.tar.gz sha512:
>
>
> c7e9d13df74797163e816536e76f14c25496cdc8f13faa990bf14ce5a5669ec09cdc44dd4da866dd72d68ba9e2d8d6bdcce57110e21ecbeb8d15c50cad64430b
>
>
> Binary release checksums:
> apache-maven-4.0.0-alpha-6-bin.zip sha512:
>
>
> ec47b84cbf5dd85a8081d218bf105d4664e298d906c28f11192bf563f30087a4d898f872fc73230391579f8aa84e70bddb0ae2eabc42b53a2c574d5793ceb1a2
>
> apache-maven-4.0.0-alpha-6-bin.tar.gz sha512:
>
>
> 9959e537712167094a7909006168404c16b0788862311ef65840f5b8d3afc519e63262b064db7361bc6ef77940bed14ead5e0a59d135bcdeea83be4d9893
>
>
> Staged site:
> https://maven.apache.org/ref/4-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/432
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> --
> 
> Guillaume Nodet
>


-- 
Sławomir Jaranowski

Re: HPI plugin

[Tamás Cservenák]

What was left out: get rid of get rid
org.apache.maven.shared.dependency.graph.DependencyGraphBuilder and replace
it with direct resolver, you can find plenty of examples here
https://github.com/apache/maven-resolver/tree/master/maven-resolver-demos/maven-resolver-demo-snippets/src/main/java/org/apache/maven/resolver/examples

HTH
Tamas

On Mon, Jun 26, 2023 at 11:42 AM Tamás Cservenák 
wrote:

> Howdy,
>
> In general looks ok (aside the plugin artifactId, that is a valid
> concern), but here are few remarks:
> * get rid org.apache.maven.shared.dependency.graph.DependencyGraphBuilder
> (maven-dependency-tree). While not officially deprecated (yet), this
> suffers from same issues as all other legacy/maven2 things (MAT for
> example), (mis)uses project building request everywhere, uses deprecated
> classes (ArtifactRepository), etc
> * while not a problem per se, I find use of mojo-executor problematic,
> especially in cases where the plugin invokes itself (RunMojo)? (the other
> use is dependency:tree that could be replaced with that refactoring above)
> * I'd avoid the use of mrm plugin. You already pull Jetty, simplest (and
> most straightforward and least error prone) is to just fire up Jetty to
> serve files from somewhere as "remote repository" as in that case you are
> 100% in control of what is being served, while with MRM you are not.
>
> HTH
> Tamas
>
>
> On Fri, Jun 23, 2023 at 5:20 PM Basil Crow  wrote:
>
>> I recently attempted to modernize the HPI plugin used in the Jenkins
>> project:
>>
>> https://github.com/jenkinsci/maven-hpi-plugin
>>
>> This plugin has a Maven baseline of 3.8.1. I think I migrated all
>> usages away from deprecated functionality and onto the recommended
>> modern Maven functionality.
>>
>> If a Maven developer could audit this plugin and let me know if
>> anything else should be updated, I would be grateful.
>>
>> Thanks,
>> Basil
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: HPI plugin

[Tamás Cservenák]

Howdy,

In general looks ok (aside the plugin artifactId, that is a valid concern),
but here are few remarks:
* get rid org.apache.maven.shared.dependency.graph.DependencyGraphBuilder
(maven-dependency-tree). While not officially deprecated (yet), this
suffers from same issues as all other legacy/maven2 things (MAT for
example), (mis)uses project building request everywhere, uses deprecated
classes (ArtifactRepository), etc
* while not a problem per se, I find use of mojo-executor problematic,
especially in cases where the plugin invokes itself (RunMojo)? (the other
use is dependency:tree that could be replaced with that refactoring above)
* I'd avoid the use of mrm plugin. You already pull Jetty, simplest (and
most straightforward and least error prone) is to just fire up Jetty to
serve files from somewhere as "remote repository" as in that case you are
100% in control of what is being served, while with MRM you are not.

HTH
Tamas


On Fri, Jun 23, 2023 at 5:20 PM Basil Crow  wrote:

> I recently attempted to modernize the HPI plugin used in the Jenkins
> project:
>
> https://github.com/jenkinsci/maven-hpi-plugin
>
> This plugin has a Maven baseline of 3.8.1. I think I migrated all
> usages away from deprecated functionality and onto the recommended
> modern Maven functionality.
>
> If a Maven developer could audit this plugin and let me know if
> anything else should be updated, I would be grateful.
>
> Thanks,
> Basil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

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

[Slawomir Jaranowski]

niedz., 25 cze 2023 o 12:33 Karl Heinz Marbaise 
napisał(a):

> Hi,
>
> I've tested several projects with it and also in relationship with Maven
> 3.9.X..
>
> The same as in Maven 3.9.3 .. plugins used which have issues like the
> maven-site-plugin (3.12.1) and being reported via
> `-Dmaven.plugin.validation=VERBOSE` (in Maven 3.9.3) will not produce
> even a hint in Maven 4.0.0-alpha-7 without the supplemental parameter
> "-Dmaven.plugin.validation=VERBOSE"
>
> My opinion is to report such plugins in Maven 4 always to make sure
> people and more important plugin maintainers/author becoming aware of
> possible issues...or maybe reporting it already in 3.9.3 as well as in
> Maven 4.X
>
>
My opinion is the same ... we should always report plugin issues in 4.x
I have tried to encourage that in 3.9.x should also be report like is in
3.9.2 - now we go step back in plugin verification feature
but it is another discussion ...


> Furthermore related to https://issues.apache.org/jira/browse/MNG-7228
> rechecked and confirming that it now works.
>
> https://issues.apache.org/jira/browse/MNG-7604
>   * We have now surefire/failsafe 3.X versions related to pom.*
> interpolations. We might think about failing the build if finding such
> things
>
> * MNG-5600 Dependency management import should support exclusions.
>
>From my point of view this means we have to change the model version
> because that can technically being read by Maven 3.X but it simply will
> not work at all.
>
> * MNG-7805 This means we introduce NS but Maven 3.X can not read it
> anymore. That requires modelVersion change to fail Maven 3.X very early
> (Also XSD has to be changed for tools/IDE's etc.)
> I don't know how Maven 3.X behaves in cases of NS in the XML
>
> * Also found that the hint at the beginning of Maven 4 build:
>
> "Unable to find the root directory. Create a .mvn directory in the root
> directory or add the root="true" attribute on the root project's model
> to identify it."
>
> If I add that attribute to the ` project fails with Maven 3... which means that it requires a model
> version change...including an XSD change (required for tools, IDE's etc)
> !! It must be clear for users having a Maven 4 pom in front of them or a
> Maven 3 pom file ...
>
> Othwise +1 from me.
>
> Kind regards
> Karl Heinz Marbaise
>
>
> On 24.06.23 12:56, Guillaume Nodet wrote:
> > I'm starting a new vote to release this new alpha.
> >
> > 67 issues solved:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353052
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/maven-1970
> >
> > Dev dist directory:
> > https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-7/
> >
> > Source release checksums:
> > apache-maven-4.0.0-alpha-6-src.zip sha512:
> >
> >
> bc822a381f84b156f2d5c2b59502db44ef3e8689f534913820dc0c68014e02dc75639c1990df4203d7923318d2b1668b050f452556c15eb638271e1ae3688e87
> >
> > apache-maven-4.0.0-alpha-6-src.tar.gz sha512:
> >
> >
> c7e9d13df74797163e816536e76f14c25496cdc8f13faa990bf14ce5a5669ec09cdc44dd4da866dd72d68ba9e2d8d6bdcce57110e21ecbeb8d15c50cad64430b
> >
> >
> > Binary release checksums:
> > apache-maven-4.0.0-alpha-6-bin.zip sha512:
> >
> >
> ec47b84cbf5dd85a8081d218bf105d4664e298d906c28f11192bf563f30087a4d898f872fc73230391579f8aa84e70bddb0ae2eabc42b53a2c574d5793ceb1a2
> >
> > apache-maven-4.0.0-alpha-6-bin.tar.gz sha512:
> >
> >
> 9959e537712167094a7909006168404c16b0788862311ef65840f5b8d3afc519e63262b064db7361bc6ef77940bed14ead5e0a59d135bcdeea83be4d9893
> >
> >
> > Staged site:
> > https://maven.apache.org/ref/4-LATEST/
> >
> > Draft for release notes:
> > https://github.com/apache/maven-site/pull/432
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72h
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
>
> Mit freundlichem Gruß
> Karl Heinz Marbaise
> --
> SoftwareEntwicklung Beratung Schulung  Tel.: +49 (0) 2405 / 415 893
> Inhaber Dipl.Ing.(FH) Karl Heinz Marbaise  USt.IdNr: DE191347579
> Hauptstrasse 177
> 52146 Würselen https://www.soebes.de
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Sławomir Jaranowski

Re: HPI plugin

[Benjamin Marwell]

Basil,

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

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

- Ben

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

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

Re: HPI plugin

[Basil Crow]

Hi Benjamin,

Sorry for the confusion, but my question was directed to the Maven
core committers.

Basil

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

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

[Romain Manni-Bucau]

Hi,

Isn't the line "Unable to find the root directory. Create a .mvn directory
in the root directory or add the root="true" attribute on the root
project's model to identify it." unexpected (at least not being printed
with a logger even if I get it is pre-java world, output is quite weirdish.

We still have warning for not pinned versions - think it was fixed on 3.9
("[WARNING] Version not locked for default bindings plugins
[maven-resources-plugin, maven-surefire-plugin, maven-jar-plugin], you
should define versions in pluginManagement section of your pom.xml or
parent").

Rest is ok, compared to last one only the new not log line is question to
debate since it will miss integrations so should either be done in java
later if the prop is not set or not done at all IMHO.

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



Le dim. 25 juin 2023 à 14:59, Guillaume Nodet  a écrit :

> Le dim. 25 juin 2023 à 12:33, Karl Heinz Marbaise  a
> écrit :
>
> > Hi,
> >
> > I've tested several projects with it and also in relationship with Maven
> > 3.9.X..
> >
> > The same as in Maven 3.9.3 .. plugins used which have issues like the
> > maven-site-plugin (3.12.1) and being reported via
> > `-Dmaven.plugin.validation=VERBOSE` (in Maven 3.9.3) will not produce
> > even a hint in Maven 4.0.0-alpha-7 without the supplemental parameter
> > "-Dmaven.plugin.validation=VERBOSE"
> >
> > My opinion is to report such plugins in Maven 4 always to make sure
> > people and more important plugin maintainers/author becoming aware of
> > possible issues...or maybe reporting it already in 3.9.3 as well as in
> > Maven 4.X
> >
> > Furthermore related to https://issues.apache.org/jira/browse/MNG-7228
> > rechecked and confirming that it now works.
> >
> > https://issues.apache.org/jira/browse/MNG-7604
> >   * We have now surefire/failsafe 3.X versions related to pom.*
> > interpolations. We might think about failing the build if finding such
> > things
> >
> > * MNG-5600 Dependency management import should support exclusions.
> >
> >From my point of view this means we have to change the model version
> > because that can technically being read by Maven 3.X but it simply will
> > not work at all.
> >
>
> Shouldn't that be validated and fail in 3.x ?
>
>
> >
> > * MNG-7805 This means we introduce NS but Maven 3.X can not read it
> > anymore. That requires modelVersion change to fail Maven 3.X very early
> > (Also XSD has to be changed for tools/IDE's etc.)
> > I don't know how Maven 3.X behaves in cases of NS in the XML
> >
>
> I don't understand, this is not different from other build/consumer poms
> features.
> The xsd can still be used to validate those build poms, but yes, they can
> only be used on maven 4.
> See below
>
>
> >
> > * Also found that the hint at the beginning of Maven 4 build:
> >
> > "Unable to find the root directory. Create a .mvn directory in the root
> > directory or add the root="true" attribute on the root project's model
> > to identify it."
> >
> > If I add that attribute to the ` > project fails with Maven 3... which means that it requires a model
> > version change...including an XSD change (required for tools, IDE's etc)
> > !! It must be clear for users having a Maven 4 pom in front of them or a
> > Maven 3 pom file ...
> >
>
> Well, that's related to the discussions on the model version.  I do agree
> it's a bad idea to add attributes or elements to the model and not version
> the schema, but it seems it has been agreed on and has been done a couple
> of times in the past 10 years or so.
>
> The build/consumer pom could be an opt-in with a new 4.1.0 model version,
> which would make it clear that such projects now require Maven 4.  This
> cannot be done by changing the namespace only, as if you change your xml
> namespace to 4.1.0, maven 3.x will not complain, as it simply ignores the
> namespace.
>
> Please have a look https://github.com/apache/maven/pull/1160.
>
>
>
> >
> > Othwise +1 from me.
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
> > On 24.06.23 12:56, Guillaume Nodet wrote:
> > > I'm starting a new vote to release this new alpha.
> > >
> > > 67 issues solved:
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12353052
> > >
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/maven-1970
> > >
> > > Dev dist directory:
> > > https://dist.apache.org/repos/dist/dev/maven/maven-4/4.0.0-alpha-7/
> > >
> > > Source release checksums:
> > > apache-maven-4.0.0-alpha-6-src.zip sha512:
> > >
> > >
> >
> bc822a381f84b156f2d5c2b59502db44ef3e8689f534913820dc0c68014e02dc75639c1990df4203d7923318d2b1668b050f452556c15eb638271e1ae3688e87
> > >
> > >