Re: [VOTE] Release Apache Maven 3.9.8

[Manfred Moser]

+1 .. works flawlessly with Trino Gateway and a few other smaller projects

manfred

mmo...@apache.org

On 2024-06-14 7:28 a.m., Sylwester Lachiewicz wrote:

+1

pt., 14 cze 2024, 08:33 użytkownik Karl Heinz Marbaise
 napisał:


Hi,

+1 from me.

Kind regards
Karl Heinz Marbaise
On 13.06.24 10:49, Tamás Cservenák wrote:

Howdy,

We solved 16 issues:


https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354748

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

Dev dist directory (binary bundles updated):
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.8/

Source release checksums:
apache-maven-3.9.8-src.tar.gz.sha512


624156967432be2e8805e5eace3c74b5f05d3ad74616e11733149cce5dda1b60443d6b5cba2f10744a9a71efc490108d2be373aa13760829ab62c6b73bdd6162

apache-maven-3.9.8-src.zip.sha512


a55b7ee36639645f4034d47c4068e0a30927647e5d445d189188c053afd233fdb2362d459d98bff30ab979dce04e6262ce8449e6098f4f2b2485ab4318fcac74

Staged site:
https://maven.apache.org/ref/3-LATEST/

Draft for release notes:
https://github.com/apache/maven-site/pull/541

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72h

[ ] +1
[ ] +0
[ ] -1


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




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

Re: [VOTE] Release Apache Maven mvnd 1.0.0

[Jermaine Hua]

+1

Guillaume Nodet  于2024年6月15日周六 06:57写道：
>
> +1
>
> 
> Guillaume Nodet
>
>
>
> Le ven. 14 juin 2024 à 16:04, Tamás Cservenák  a
> écrit :
>
> > Howdy,
> >
> > Note: mvnd 1.x will from now on wrapping Maven 3.9.x and 2.x will wrap
> > Maven 4.x.
> >
> > This release provides distribution on Apache Maven 3.9.8 (under vote,
> > staged only).
> >
> > The release candidate is here:
> > https://dist.apache.org/repos/dist/dev/maven/mvnd/1.0.0/
> >
> > Release notes: (visible to committers only as remains draft during the
> > vote)
> >
> > https://github.com/apache/maven-mvnd/releases/tag/untagged-65524f868c0424675d24
> >
> > Release notes (gist copy of that above for wider public):
> > https://gist.github.com/cstamas/68ab0862a84b405c709307f46bb6
> >
> > SHA512(maven-mvnd-1.0.0-src.tar.gz)=
> >
> > 0a44c56b8597049ff462f02e23e9063c592f5758334642701619f26881171c28441f6cf32f0ec018dae7a5f2d281db789723478cb01e1465cb19021741e37d79
> >
> > SHA512(maven-mvnd-1.0.0-src.zip)=
> >
> > 243340dee95501a2e231b7d96fcaaf526e57cde61bbd4b24591ddd63e0cfd8c59adc971d12980938108ef6e5fc89f919bd8f48bb2c55854ac63b2a97d6e1aa16
> >
> > Vote open for 72h
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >

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

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

[Christoph Läubrich]

If a build fails, maven suggest to use -rf / --resume-from I think that 
needed "install" in some cases (but I might be wrong).


Am 14.06.24 um 21:27 schrieb Tamás Cservenák:

Howdy,

Everybody has "quirks", and your project "using the fact a previous module
was installed" is probably an exception.
For example no Maven project expects this (and we have circa 200 of them?).
Anyway, -DdeployAtEnd=false is your friend then (maybe best in
.mvn/maven.config).

Thanks
T

On Fri, Jun 14, 2024 at 9:21 PM Romain Manni-Bucau 
wrote:


Hi

I'm mixed about it since I have a lot of projects using the fact a previous
module was installed in default repo.
While I can understand the intent I also think both make sense so I don't
think why we should break existing projects (when there are two values and
both are needed I'd priviledge the backward compat one).

Side note: indeed this does not work with split repo but this one has more
issues for my cases so this will not be enabled like that so not a topic
there.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github <
https://github.com/rmannibucau> |
LinkedIn  | Book
<
https://www.packtpub.com/application-development/java-ee-8-high-performance





Le ven. 14 juin 2024 à 21:04, Tamás Cservenák  a
écrit :


Just to clarify, the "snapshot lock down technique" as explained here:



https://www.mojohaus.org/versions/versions-maven-plugin/examples/lock-snapshots.html


It WORKS even today if dependency in question is one artifact. But, it
USUALLY becomes impossible, if you depend on some multi module build.

Where I extensively use this technique is exactly with Maven and Maven
Resolver: I deploy "controlled" builds to ASF "snapshots" and then "lock

it

down" in other (usually PR), and enjoy the benefit of full CI coverage

and

all (ITs etc) while at same time as sure it is "my change" that is being
tested on.

Resolver 2.0.0 had quite some changes:
* new modules (that started at buildNumber 1)
* module renames (transport http -> apache), similarly as above, apache
transport was 1, etc

Hence, referencing "I want a resolver reactor build that I know exactly
comes from this PR/branch/whatever" (for example from a PR) is

impossible,

as "lock down" as explained on versions plugin becomes impossible, as
modules have different buildNumbers.

In this case, I "adjusted" the buildNo (basically ALIGNED them)
using MNG-8055 (mvn 3.9.7) [and other tricks before 3.9.7 was out], and
then I knew (as ASF CI deployed) which buildNo I really want, and then
created Maven PR with that _exact_ TS "locked down" snapshot version, and
was sure CI tested my change and my change only.

Thanks
T


On Fri, Jun 14, 2024 at 8:36 PM Tamás Cservenák 
wrote:


Howdy,

If for example sake, we define "maven" as mvn CLI and "build end" as

"user

got on console "BUILD SUCCESS/FAILED" output and CLI process exited,

then

at that point, this change would cause ZERO difference for SUCCESS

builds.


Where difference WILL happen, is in case of FAILED builds: nothing will

be

installed to local repo and nothing will be deployed to remote repo.

Which

is usually what we want, in reality.

Re install today:
Let's assume that your project first "morning build fails in the

middle"

(at module N+1), hence the first N module ends up installed in your

local

repo, but second M modules (of some multi module build that has N+M

modules

in total) are not. When you want to build some other project, that

depends

on this project, the installed N JARs will be used that were built now
(this morning) as they are "fresh", just installed, but other M will be
pulled from remote (as last you installed yesterday, before you left

the

office). basically ending with JARs on classpath that may come even

from

different commits (depending what remote JARs, etc).

Re deploy today:
Similarly, if you have a multi module build (N+M modules) and you

deploy

snapshots as today, and the build fails at module N+1 (CI or dev
workstation, does not matter), after fixing the thing, and redeploy,

all

is

seemingly ok. But what happens is that due the first failure, the

first N

modules will have "build number" in their timestamped version +1 offset
from those last M modules (basically as first N modules were deployed
twice, while last M modules only once). Hence, if you would like to

"lock

down" or address whole reactor artifacts built together with a given TS
snapshot number, you cannot. But the same happens in the following
scenario: you have a multi module build of N modules, but this morning

you

add one new module, hence you have N+1 modules. And you (or CI) deploy.

The

"new" module will have buildNumber 1 (as it was deployed the first

time),

while all the others may have 50 or even 100. Again, you cannot address
(and be sure) you use all the artifacts that were built 

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

[Matthias Bünger]

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

Am 14.06.2024 um 19:24 schrieb Jorge Solórzano:

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

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


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


Le 2024-06-14 à 19 h 11, Gary Gregory a écrit :

Thank you Martin for clarifying this! If I understand correctly: If I
said 'mvn clean deploy foo bar' in a multi-module project, then 'mvn
clean foo bar' happens first for all modules followed by 'mvn deploy'
for all modules?


This is my understanding of Tamas's proposal (maybe more like "mvn
compile" for all modules followed by "mvn deploy" for all modules). But
I may be wrong, we will need his confirmation.

  Martin




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

Re: [VOTE] Release Apache Maven mvnd 1.0.0

[Guillaume Nodet]

+1


Guillaume Nodet



Le ven. 14 juin 2024 à 16:04, Tamás Cservenák  a
écrit :

> Howdy,
>
> Note: mvnd 1.x will from now on wrapping Maven 3.9.x and 2.x will wrap
> Maven 4.x.
>
> This release provides distribution on Apache Maven 3.9.8 (under vote,
> staged only).
>
> The release candidate is here:
> https://dist.apache.org/repos/dist/dev/maven/mvnd/1.0.0/
>
> Release notes: (visible to committers only as remains draft during the
> vote)
>
> https://github.com/apache/maven-mvnd/releases/tag/untagged-65524f868c0424675d24
>
> Release notes (gist copy of that above for wider public):
> https://gist.github.com/cstamas/68ab0862a84b405c709307f46bb6
>
> SHA512(maven-mvnd-1.0.0-src.tar.gz)=
>
> 0a44c56b8597049ff462f02e23e9063c592f5758334642701619f26881171c28441f6cf32f0ec018dae7a5f2d281db789723478cb01e1465cb19021741e37d79
>
> SHA512(maven-mvnd-1.0.0-src.zip)=
>
> 243340dee95501a2e231b7d96fcaaf526e57cde61bbd4b24591ddd63e0cfd8c59adc971d12980938108ef6e5fc89f919bd8f48bb2c55854ac63b2a97d6e1aa16
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: [VOTE] Release Apache Maven mvnd 1.0.0

[Ozgun Oz]

Tested on a few maven plugins and extension, works flawlessly.
Thanks Tamas, this is awesome ! 

On Fri, Jun 14, 2024 at 7:04 PM Brian Demers  wrote:

> +1 nb
>
> Tested on a couple different projects without issue.
>
> On Fri, Jun 14, 2024 at 12:02 PM Romain Manni-Bucau  >
> wrote:
>
> > +1
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le ven. 14 juin 2024 à 16:28, Mateusz Gajewski <
> > mateusz.gajew...@starburstdata.com> a écrit :
> >
> > > Tested with Trino locally: +1 nb.
> > >
> > > Thanks! This is gonna to be a great release   
> > >
> > >
> > > On Fri, Jun 14, 2024 at 10:04 AM Tamás Cservenák 
> > > wrote:
> > >
> > > > Howdy,
> > > >
> > > > Note: mvnd 1.x will from now on wrapping Maven 3.9.x and 2.x will
> wrap
> > > > Maven 4.x.
> > > >
> > > > This release provides distribution on Apache Maven 3.9.8 (under vote,
> > > > staged only).
> > > >
> > > > The release candidate is here:
> > > > https://dist.apache.org/repos/dist/dev/maven/mvnd/1.0.0/
> > > >
> > > > Release notes: (visible to committers only as remains draft during
> the
> > > > vote)
> > > >
> > > >
> > >
> >
> https://github.com/apache/maven-mvnd/releases/tag/untagged-65524f868c0424675d24
> > > >
> > > > Release notes (gist copy of that above for wider public):
> > > > https://gist.github.com/cstamas/68ab0862a84b405c709307f46bb6
> > > >
> > > > SHA512(maven-mvnd-1.0.0-src.tar.gz)=
> > > >
> > > >
> > >
> >
> 0a44c56b8597049ff462f02e23e9063c592f5758334642701619f26881171c28441f6cf32f0ec018dae7a5f2d281db789723478cb01e1465cb19021741e37d79
> > > >
> > > > SHA512(maven-mvnd-1.0.0-src.zip)=
> > > >
> > > >
> > >
> >
> 243340dee95501a2e231b7d96fcaaf526e57cde61bbd4b24591ddd63e0cfd8c59adc971d12980938108ef6e5fc89f919bd8f48bb2c55854ac63b2a97d6e1aa16
> > > >
> > > > Vote open for 72h
> > > >
> > > > [ ] +1
> > > > [ ] +0
> > > > [ ] -1
> > > >
> > >
> >
>

Re: Apache Maven mvnd 1.0.0 "early access"

[Basil Crow]

I have tested the latest build and confirmed that it can successfully
compile Jenkins core. Very nice!

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

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

[Romain Manni-Bucau]

@Tamas was not project but projects, maybe not 200 but diverse ones
compared to maven which are 4-5 types only so don't think it is just a
random exception. As discussed since 10+ years now - without consensus I
agree, we are no more in a world we just build a simple jar with only
classes in there.

Now Kemal has a point, we don't need install anymore for maven plain
standard (maven-* projects) so if install is called it is intended to be
done so I think a sane default is the current one and installAtEnd fits
another need which is staging need.
So I think we shouldn't change install semantic which breaks module work
unit definition (if a module is in success it must...have succeeded).
However I agree it can make sense to have another built-in lifecycle  for
that ("install-at-end" and ultimately "deploy-at-end") since it stays a
common need IMHO.

I would also favor the "post-build" mojo definition from the pom and
lifecycle - ie a mojo without any project (or a virtual one technically
maybe) which would enable us to drop all the fake logic for atend - not
speaking only of install/deploy there.

So long story short: let's enable atEnd feature cleanly and keep current
lifecycles.

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



Le ven. 14 juin 2024 à 21:45, Tamás Cservenák  a
écrit :

> nexus-staging-maven-plugin does something similar (was authored by me while
> at Sonatype), hence, it could even do "two phase deploy", one phase collect
> and in next mvn run deploy collected artifacts...
>
> And yes, this was in 2010s, when "parallel" was not yet a thing :)
>
> T
>
>
> On Fri, Jun 14, 2024 at 9:42 PM Kemal Soysal <
> kemal.soy...@ls-it-solutions.de> wrote:
>
> > Yes, Tamás, I wrote that for maven 3 in 2017.
> > It is quite simple. I used an XML-file to log the artifacts in the build
> > along with all needed identifications.
> > When already built artifacts were needed just loaded them from there -
> > especially the extra attached artifacts were problematic for us.
> > Back then building in parallel was troublesome, especially deploying to
> > the local repo.
> > That could cause inconsistencies because of missing serialization of
> write
> > access and half way failing builds.
> >
> > > Am 14.06.2024 um 21:32 schrieb Tamás Cservenák :
> > >
> > > Hi Kemal,
> > >
> > > Interesting idea...
> > >
> > > Maven4 has something for this ("project repo" that is project-local as
> > > opposed to "local repo" that is global).
> > > But my discussion is about Maven3 and local repo and remote repo (both
> > are
> > > global).
> > >
> > > Thanks
> > > T
> > >
> > > On Fri, Jun 14, 2024 at 9:29 PM Kemal Soysal <
> > > kemal.soy...@ls-it-solutions.de> wrote:
> > >
> > >> Hi,
> > >>
> > >> maybe an artifact recorder is in fact the real need here… so if some
> > >> module is built, the generated artifacts should be accessible to
> > subsequent
> > >> maven executions….
> > >> this way an install would be superfluous and multiple builds could be
> > run
> > >> after each other without changing the installed heap.
> > >>
> > >> Only in case of success the recorded artifacts would be installed
> and/or
> > >> deployed.
> > >>
> > >> I used this technique to build a huge project and run numerous
> > integration
> > >> tests. I would write the extension again, if needed.
> > >> We had non standard artifact attachments that forced to write the
> > >> extension back then in that project..
> > >>
> > >>
> > >>> Am 14.06.2024 um 21:20 schrieb Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > >>> :
> > >>>
> > >>> Hi
> > >>>
> > >>> I'm mixed about it since I have a lot of projects using the fact a
> > >> previous
> > >>> module was installed in default repo.
> > >>> While I can understand the intent I also think both make sense so I
> > don't
> > >>> think why we should break existing projects (when there are two
> values
> > >> and
> > >>> both are needed I'd priviledge the backward compat one).
> > >>>
> > >>> Side note: indeed this does not work with split repo but this one has
> > >> more
> > >>> issues for my cases so this will not be enabled like that so not a
> > topic
> > >>> there.
> > >>>
> > >>> Romain Manni-Bucau
> > >>> @rmannibucau  |  Blog
> > >>>  | Old Blog
> > >>>  | Github <
> > >> https://github.com/rmannibucau> |
> > >>> LinkedIn  | Book
> > >>> <
> > >>
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >>>
> > >>>
> > >>>
> > >>> Le ven. 14 juin 2024 à 21:04, Tamás Cservenák 
> a
> > >>> écrit :
> > >>>
> >  Just to clarify, the "snapshot lock 

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

[Tamás Cservenák]

nexus-staging-maven-plugin does something similar (was authored by me while
at Sonatype), hence, it could even do "two phase deploy", one phase collect
and in next mvn run deploy collected artifacts...

And yes, this was in 2010s, when "parallel" was not yet a thing :)

T


On Fri, Jun 14, 2024 at 9:42 PM Kemal Soysal <
kemal.soy...@ls-it-solutions.de> wrote:

> Yes, Tamás, I wrote that for maven 3 in 2017.
> It is quite simple. I used an XML-file to log the artifacts in the build
> along with all needed identifications.
> When already built artifacts were needed just loaded them from there -
> especially the extra attached artifacts were problematic for us.
> Back then building in parallel was troublesome, especially deploying to
> the local repo.
> That could cause inconsistencies because of missing serialization of write
> access and half way failing builds.
>
> > Am 14.06.2024 um 21:32 schrieb Tamás Cservenák :
> >
> > Hi Kemal,
> >
> > Interesting idea...
> >
> > Maven4 has something for this ("project repo" that is project-local as
> > opposed to "local repo" that is global).
> > But my discussion is about Maven3 and local repo and remote repo (both
> are
> > global).
> >
> > Thanks
> > T
> >
> > On Fri, Jun 14, 2024 at 9:29 PM Kemal Soysal <
> > kemal.soy...@ls-it-solutions.de> wrote:
> >
> >> Hi,
> >>
> >> maybe an artifact recorder is in fact the real need here… so if some
> >> module is built, the generated artifacts should be accessible to
> subsequent
> >> maven executions….
> >> this way an install would be superfluous and multiple builds could be
> run
> >> after each other without changing the installed heap.
> >>
> >> Only in case of success the recorded artifacts would be installed and/or
> >> deployed.
> >>
> >> I used this technique to build a huge project and run numerous
> integration
> >> tests. I would write the extension again, if needed.
> >> We had non standard artifact attachments that forced to write the
> >> extension back then in that project..
> >>
> >>
> >>> Am 14.06.2024 um 21:20 schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com
> >>> :
> >>>
> >>> Hi
> >>>
> >>> I'm mixed about it since I have a lot of projects using the fact a
> >> previous
> >>> module was installed in default repo.
> >>> While I can understand the intent I also think both make sense so I
> don't
> >>> think why we should break existing projects (when there are two values
> >> and
> >>> both are needed I'd priviledge the backward compat one).
> >>>
> >>> Side note: indeed this does not work with split repo but this one has
> >> more
> >>> issues for my cases so this will not be enabled like that so not a
> topic
> >>> there.
> >>>
> >>> Romain Manni-Bucau
> >>> @rmannibucau  |  Blog
> >>>  | Old Blog
> >>>  | Github <
> >> https://github.com/rmannibucau> |
> >>> LinkedIn  | Book
> >>> <
> >>
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >>>
> >>>
> >>>
> >>> Le ven. 14 juin 2024 à 21:04, Tamás Cservenák  a
> >>> écrit :
> >>>
>  Just to clarify, the "snapshot lock down technique" as explained here:
> 
> 
> >>
> https://www.mojohaus.org/versions/versions-maven-plugin/examples/lock-snapshots.html
> 
>  It WORKS even today if dependency in question is one artifact. But, it
>  USUALLY becomes impossible, if you depend on some multi module build.
> 
>  Where I extensively use this technique is exactly with Maven and Maven
>  Resolver: I deploy "controlled" builds to ASF "snapshots" and then
> >> "lock it
>  down" in other (usually PR), and enjoy the benefit of full CI coverage
> >> and
>  all (ITs etc) while at same time as sure it is "my change" that is
> being
>  tested on.
> 
>  Resolver 2.0.0 had quite some changes:
>  * new modules (that started at buildNumber 1)
>  * module renames (transport http -> apache), similarly as above,
> apache
>  transport was 1, etc
> 
>  Hence, referencing "I want a resolver reactor build that I know
> exactly
>  comes from this PR/branch/whatever" (for example from a PR) is
> >> impossible,
>  as "lock down" as explained on versions plugin becomes impossible, as
>  modules have different buildNumbers.
> 
>  In this case, I "adjusted" the buildNo (basically ALIGNED them)
>  using MNG-8055 (mvn 3.9.7) [and other tricks before 3.9.7 was out],
> and
>  then I knew (as ASF CI deployed) which buildNo I really want, and then
>  created Maven PR with that _exact_ TS "locked down" snapshot version,
> >> and
>  was sure CI tested my change and my change only.
> 
>  Thanks
>  T
> 
> 
>  On Fri, Jun 14, 2024 at 8:36 PM Tamás Cservenák 
>  wrote:
> 
> > Howdy,
> >
> > If for example sake, we define "maven" as mvn CLI and "build end" as
>  "user
> 

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

[Kemal Soysal]

Yes, Tamás, I wrote that for maven 3 in 2017.
It is quite simple. I used an XML-file to log the artifacts in the build along 
with all needed identifications.
When already built artifacts were needed just loaded them from there - 
especially the extra attached artifacts were problematic for us.
Back then building in parallel was troublesome, especially deploying to the 
local repo.
That could cause inconsistencies because of missing serialization of write 
access and half way failing builds.

> Am 14.06.2024 um 21:32 schrieb Tamás Cservenák :
> 
> Hi Kemal,
> 
> Interesting idea...
> 
> Maven4 has something for this ("project repo" that is project-local as
> opposed to "local repo" that is global).
> But my discussion is about Maven3 and local repo and remote repo (both are
> global).
> 
> Thanks
> T
> 
> On Fri, Jun 14, 2024 at 9:29 PM Kemal Soysal <
> kemal.soy...@ls-it-solutions.de> wrote:
> 
>> Hi,
>> 
>> maybe an artifact recorder is in fact the real need here… so if some
>> module is built, the generated artifacts should be accessible to subsequent
>> maven executions….
>> this way an install would be superfluous and multiple builds could be run
>> after each other without changing the installed heap.
>> 
>> Only in case of success the recorded artifacts would be installed and/or
>> deployed.
>> 
>> I used this technique to build a huge project and run numerous integration
>> tests. I would write the extension again, if needed.
>> We had non standard artifact attachments that forced to write the
>> extension back then in that project..
>> 
>> 
>>> Am 14.06.2024 um 21:20 schrieb Romain Manni-Bucau >> :
>>> 
>>> Hi
>>> 
>>> I'm mixed about it since I have a lot of projects using the fact a
>> previous
>>> module was installed in default repo.
>>> While I can understand the intent I also think both make sense so I don't
>>> think why we should break existing projects (when there are two values
>> and
>>> both are needed I'd priviledge the backward compat one).
>>> 
>>> Side note: indeed this does not work with split repo but this one has
>> more
>>> issues for my cases so this will not be enabled like that so not a topic
>>> there.
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn  | Book
>>> <
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>> 
>>> 
>>> 
>>> Le ven. 14 juin 2024 à 21:04, Tamás Cservenák  a
>>> écrit :
>>> 
 Just to clarify, the "snapshot lock down technique" as explained here:
 
 
>> https://www.mojohaus.org/versions/versions-maven-plugin/examples/lock-snapshots.html
 
 It WORKS even today if dependency in question is one artifact. But, it
 USUALLY becomes impossible, if you depend on some multi module build.
 
 Where I extensively use this technique is exactly with Maven and Maven
 Resolver: I deploy "controlled" builds to ASF "snapshots" and then
>> "lock it
 down" in other (usually PR), and enjoy the benefit of full CI coverage
>> and
 all (ITs etc) while at same time as sure it is "my change" that is being
 tested on.
 
 Resolver 2.0.0 had quite some changes:
 * new modules (that started at buildNumber 1)
 * module renames (transport http -> apache), similarly as above, apache
 transport was 1, etc
 
 Hence, referencing "I want a resolver reactor build that I know exactly
 comes from this PR/branch/whatever" (for example from a PR) is
>> impossible,
 as "lock down" as explained on versions plugin becomes impossible, as
 modules have different buildNumbers.
 
 In this case, I "adjusted" the buildNo (basically ALIGNED them)
 using MNG-8055 (mvn 3.9.7) [and other tricks before 3.9.7 was out], and
 then I knew (as ASF CI deployed) which buildNo I really want, and then
 created Maven PR with that _exact_ TS "locked down" snapshot version,
>> and
 was sure CI tested my change and my change only.
 
 Thanks
 T
 
 
 On Fri, Jun 14, 2024 at 8:36 PM Tamás Cservenák 
 wrote:
 
> Howdy,
> 
> If for example sake, we define "maven" as mvn CLI and "build end" as
 "user
> got on console "BUILD SUCCESS/FAILED" output and CLI process exited,
>> then
> at that point, this change would cause ZERO difference for SUCCESS
 builds.
> 
> Where difference WILL happen, is in case of FAILED builds: nothing will
 be
> installed to local repo and nothing will be deployed to remote repo.
 Which
> is usually what we want, in reality.
> 
> Re install today:
> Let's assume that your project first "morning build fails in the
>> middle"
> (at module N+1), hence the first N module ends up installed in your
>> local
> repo, but second M modules (of 

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

[Tamás Cservenák]

Hi Kemal,

Interesting idea...

Maven4 has something for this ("project repo" that is project-local as
opposed to "local repo" that is global).
But my discussion is about Maven3 and local repo and remote repo (both are
global).

Thanks
T

On Fri, Jun 14, 2024 at 9:29 PM Kemal Soysal <
kemal.soy...@ls-it-solutions.de> wrote:

> Hi,
>
> maybe an artifact recorder is in fact the real need here… so if some
> module is built, the generated artifacts should be accessible to subsequent
> maven executions….
> this way an install would be superfluous and multiple builds could be run
> after each other without changing the installed heap.
>
> Only in case of success the recorded artifacts would be installed and/or
> deployed.
>
> I used this technique to build a huge project and run numerous integration
> tests. I would write the extension again, if needed.
> We had non standard artifact attachments that forced to write the
> extension back then in that project..
>
>
> > Am 14.06.2024 um 21:20 schrieb Romain Manni-Bucau  >:
> >
> > Hi
> >
> > I'm mixed about it since I have a lot of projects using the fact a
> previous
> > module was installed in default repo.
> > While I can understand the intent I also think both make sense so I don't
> > think why we should break existing projects (when there are two values
> and
> > both are needed I'd priviledge the backward compat one).
> >
> > Side note: indeed this does not work with split repo but this one has
> more
> > issues for my cases so this will not be enabled like that so not a topic
> > there.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le ven. 14 juin 2024 à 21:04, Tamás Cservenák  a
> > écrit :
> >
> >> Just to clarify, the "snapshot lock down technique" as explained here:
> >>
> >>
> https://www.mojohaus.org/versions/versions-maven-plugin/examples/lock-snapshots.html
> >>
> >> It WORKS even today if dependency in question is one artifact. But, it
> >> USUALLY becomes impossible, if you depend on some multi module build.
> >>
> >> Where I extensively use this technique is exactly with Maven and Maven
> >> Resolver: I deploy "controlled" builds to ASF "snapshots" and then
> "lock it
> >> down" in other (usually PR), and enjoy the benefit of full CI coverage
> and
> >> all (ITs etc) while at same time as sure it is "my change" that is being
> >> tested on.
> >>
> >> Resolver 2.0.0 had quite some changes:
> >> * new modules (that started at buildNumber 1)
> >> * module renames (transport http -> apache), similarly as above, apache
> >> transport was 1, etc
> >>
> >> Hence, referencing "I want a resolver reactor build that I know exactly
> >> comes from this PR/branch/whatever" (for example from a PR) is
> impossible,
> >> as "lock down" as explained on versions plugin becomes impossible, as
> >> modules have different buildNumbers.
> >>
> >> In this case, I "adjusted" the buildNo (basically ALIGNED them)
> >> using MNG-8055 (mvn 3.9.7) [and other tricks before 3.9.7 was out], and
> >> then I knew (as ASF CI deployed) which buildNo I really want, and then
> >> created Maven PR with that _exact_ TS "locked down" snapshot version,
> and
> >> was sure CI tested my change and my change only.
> >>
> >> Thanks
> >> T
> >>
> >>
> >> On Fri, Jun 14, 2024 at 8:36 PM Tamás Cservenák 
> >> wrote:
> >>
> >>> Howdy,
> >>>
> >>> If for example sake, we define "maven" as mvn CLI and "build end" as
> >> "user
> >>> got on console "BUILD SUCCESS/FAILED" output and CLI process exited,
> then
> >>> at that point, this change would cause ZERO difference for SUCCESS
> >> builds.
> >>>
> >>> Where difference WILL happen, is in case of FAILED builds: nothing will
> >> be
> >>> installed to local repo and nothing will be deployed to remote repo.
> >> Which
> >>> is usually what we want, in reality.
> >>>
> >>> Re install today:
> >>> Let's assume that your project first "morning build fails in the
> middle"
> >>> (at module N+1), hence the first N module ends up installed in your
> local
> >>> repo, but second M modules (of some multi module build that has N+M
> >> modules
> >>> in total) are not. When you want to build some other project, that
> >> depends
> >>> on this project, the installed N JARs will be used that were built now
> >>> (this morning) as they are "fresh", just installed, but other M will be
> >>> pulled from remote (as last you installed yesterday, before you left
> the
> >>> office). basically ending with JARs on classpath that may come even
> from
> >>> different commits (depending what remote JARs, etc).
> >>>
> >>> Re deploy today:
> >>> Similarly, if you have a multi module build (N+M modules) and you
> deploy
> >>> snapshots as 

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

[Kemal Soysal]

Hi,

maybe an artifact recorder is in fact the real need here… so if some module is 
built, the generated artifacts should be accessible to subsequent maven 
executions….
this way an install would be superfluous and multiple builds could be run after 
each other without changing the installed heap.

Only in case of success the recorded artifacts would be installed and/or 
deployed.

I used this technique to build a huge project and run numerous integration 
tests. I would write the extension again, if needed.
We had non standard artifact attachments that forced to write the extension 
back then in that project..


> Am 14.06.2024 um 21:20 schrieb Romain Manni-Bucau :
> 
> Hi
> 
> I'm mixed about it since I have a lot of projects using the fact a previous
> module was installed in default repo.
> While I can understand the intent I also think both make sense so I don't
> think why we should break existing projects (when there are two values and
> both are needed I'd priviledge the backward compat one).
> 
> Side note: indeed this does not work with split repo but this one has more
> issues for my cases so this will not be enabled like that so not a topic
> there.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le ven. 14 juin 2024 à 21:04, Tamás Cservenák  a
> écrit :
> 
>> Just to clarify, the "snapshot lock down technique" as explained here:
>> 
>> https://www.mojohaus.org/versions/versions-maven-plugin/examples/lock-snapshots.html
>> 
>> It WORKS even today if dependency in question is one artifact. But, it
>> USUALLY becomes impossible, if you depend on some multi module build.
>> 
>> Where I extensively use this technique is exactly with Maven and Maven
>> Resolver: I deploy "controlled" builds to ASF "snapshots" and then "lock it
>> down" in other (usually PR), and enjoy the benefit of full CI coverage and
>> all (ITs etc) while at same time as sure it is "my change" that is being
>> tested on.
>> 
>> Resolver 2.0.0 had quite some changes:
>> * new modules (that started at buildNumber 1)
>> * module renames (transport http -> apache), similarly as above, apache
>> transport was 1, etc
>> 
>> Hence, referencing "I want a resolver reactor build that I know exactly
>> comes from this PR/branch/whatever" (for example from a PR) is impossible,
>> as "lock down" as explained on versions plugin becomes impossible, as
>> modules have different buildNumbers.
>> 
>> In this case, I "adjusted" the buildNo (basically ALIGNED them)
>> using MNG-8055 (mvn 3.9.7) [and other tricks before 3.9.7 was out], and
>> then I knew (as ASF CI deployed) which buildNo I really want, and then
>> created Maven PR with that _exact_ TS "locked down" snapshot version, and
>> was sure CI tested my change and my change only.
>> 
>> Thanks
>> T
>> 
>> 
>> On Fri, Jun 14, 2024 at 8:36 PM Tamás Cservenák 
>> wrote:
>> 
>>> Howdy,
>>> 
>>> If for example sake, we define "maven" as mvn CLI and "build end" as
>> "user
>>> got on console "BUILD SUCCESS/FAILED" output and CLI process exited, then
>>> at that point, this change would cause ZERO difference for SUCCESS
>> builds.
>>> 
>>> Where difference WILL happen, is in case of FAILED builds: nothing will
>> be
>>> installed to local repo and nothing will be deployed to remote repo.
>> Which
>>> is usually what we want, in reality.
>>> 
>>> Re install today:
>>> Let's assume that your project first "morning build fails in the middle"
>>> (at module N+1), hence the first N module ends up installed in your local
>>> repo, but second M modules (of some multi module build that has N+M
>> modules
>>> in total) are not. When you want to build some other project, that
>> depends
>>> on this project, the installed N JARs will be used that were built now
>>> (this morning) as they are "fresh", just installed, but other M will be
>>> pulled from remote (as last you installed yesterday, before you left the
>>> office). basically ending with JARs on classpath that may come even from
>>> different commits (depending what remote JARs, etc).
>>> 
>>> Re deploy today:
>>> Similarly, if you have a multi module build (N+M modules) and you deploy
>>> snapshots as today, and the build fails at module N+1 (CI or dev
>>> workstation, does not matter), after fixing the thing, and redeploy, all
>> is
>>> seemingly ok. But what happens is that due the first failure, the first N
>>> modules will have "build number" in their timestamped version +1 offset
>>> from those last M modules (basically as first N modules were deployed
>>> twice, while last M modules only once). Hence, if you would like to "lock
>>> down" or address whole reactor artifacts built together with a given TS
>>> snapshot number, you cannot. 

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

[Tamás Cservenák]

Howdy,

Everybody has "quirks", and your project "using the fact a previous module
was installed" is probably an exception.
For example no Maven project expects this (and we have circa 200 of them?).
Anyway, -DdeployAtEnd=false is your friend then (maybe best in
.mvn/maven.config).

Thanks
T

On Fri, Jun 14, 2024 at 9:21 PM Romain Manni-Bucau 
wrote:

> Hi
>
> I'm mixed about it since I have a lot of projects using the fact a previous
> module was installed in default repo.
> While I can understand the intent I also think both make sense so I don't
> think why we should break existing projects (when there are two values and
> both are needed I'd priviledge the backward compat one).
>
> Side note: indeed this does not work with split repo but this one has more
> issues for my cases so this will not be enabled like that so not a topic
> there.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 14 juin 2024 à 21:04, Tamás Cservenák  a
> écrit :
>
> > Just to clarify, the "snapshot lock down technique" as explained here:
> >
> >
> https://www.mojohaus.org/versions/versions-maven-plugin/examples/lock-snapshots.html
> >
> > It WORKS even today if dependency in question is one artifact. But, it
> > USUALLY becomes impossible, if you depend on some multi module build.
> >
> > Where I extensively use this technique is exactly with Maven and Maven
> > Resolver: I deploy "controlled" builds to ASF "snapshots" and then "lock
> it
> > down" in other (usually PR), and enjoy the benefit of full CI coverage
> and
> > all (ITs etc) while at same time as sure it is "my change" that is being
> > tested on.
> >
> > Resolver 2.0.0 had quite some changes:
> > * new modules (that started at buildNumber 1)
> > * module renames (transport http -> apache), similarly as above, apache
> > transport was 1, etc
> >
> > Hence, referencing "I want a resolver reactor build that I know exactly
> > comes from this PR/branch/whatever" (for example from a PR) is
> impossible,
> > as "lock down" as explained on versions plugin becomes impossible, as
> > modules have different buildNumbers.
> >
> > In this case, I "adjusted" the buildNo (basically ALIGNED them)
> > using MNG-8055 (mvn 3.9.7) [and other tricks before 3.9.7 was out], and
> > then I knew (as ASF CI deployed) which buildNo I really want, and then
> > created Maven PR with that _exact_ TS "locked down" snapshot version, and
> > was sure CI tested my change and my change only.
> >
> > Thanks
> > T
> >
> >
> > On Fri, Jun 14, 2024 at 8:36 PM Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > If for example sake, we define "maven" as mvn CLI and "build end" as
> > "user
> > > got on console "BUILD SUCCESS/FAILED" output and CLI process exited,
> then
> > > at that point, this change would cause ZERO difference for SUCCESS
> > builds.
> > >
> > > Where difference WILL happen, is in case of FAILED builds: nothing will
> > be
> > > installed to local repo and nothing will be deployed to remote repo.
> > Which
> > > is usually what we want, in reality.
> > >
> > > Re install today:
> > > Let's assume that your project first "morning build fails in the
> middle"
> > > (at module N+1), hence the first N module ends up installed in your
> local
> > > repo, but second M modules (of some multi module build that has N+M
> > modules
> > > in total) are not. When you want to build some other project, that
> > depends
> > > on this project, the installed N JARs will be used that were built now
> > > (this morning) as they are "fresh", just installed, but other M will be
> > > pulled from remote (as last you installed yesterday, before you left
> the
> > > office). basically ending with JARs on classpath that may come even
> from
> > > different commits (depending what remote JARs, etc).
> > >
> > > Re deploy today:
> > > Similarly, if you have a multi module build (N+M modules) and you
> deploy
> > > snapshots as today, and the build fails at module N+1 (CI or dev
> > > workstation, does not matter), after fixing the thing, and redeploy,
> all
> > is
> > > seemingly ok. But what happens is that due the first failure, the
> first N
> > > modules will have "build number" in their timestamped version +1 offset
> > > from those last M modules (basically as first N modules were deployed
> > > twice, while last M modules only once). Hence, if you would like to
> "lock
> > > down" or address whole reactor artifacts built together with a given TS
> > > snapshot number, you cannot. But the same happens in the following
> > > scenario: you have a multi module build of N modules, but this morning
> > you
> > > add one new module, hence you have N+1 modules. And you (or CI) deploy.
> > 

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

[Romain Manni-Bucau]

Hi

I'm mixed about it since I have a lot of projects using the fact a previous
module was installed in default repo.
While I can understand the intent I also think both make sense so I don't
think why we should break existing projects (when there are two values and
both are needed I'd priviledge the backward compat one).

Side note: indeed this does not work with split repo but this one has more
issues for my cases so this will not be enabled like that so not a topic
there.

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



Le ven. 14 juin 2024 à 21:04, Tamás Cservenák  a
écrit :

> Just to clarify, the "snapshot lock down technique" as explained here:
>
> https://www.mojohaus.org/versions/versions-maven-plugin/examples/lock-snapshots.html
>
> It WORKS even today if dependency in question is one artifact. But, it
> USUALLY becomes impossible, if you depend on some multi module build.
>
> Where I extensively use this technique is exactly with Maven and Maven
> Resolver: I deploy "controlled" builds to ASF "snapshots" and then "lock it
> down" in other (usually PR), and enjoy the benefit of full CI coverage and
> all (ITs etc) while at same time as sure it is "my change" that is being
> tested on.
>
> Resolver 2.0.0 had quite some changes:
> * new modules (that started at buildNumber 1)
> * module renames (transport http -> apache), similarly as above, apache
> transport was 1, etc
>
> Hence, referencing "I want a resolver reactor build that I know exactly
> comes from this PR/branch/whatever" (for example from a PR) is impossible,
> as "lock down" as explained on versions plugin becomes impossible, as
> modules have different buildNumbers.
>
> In this case, I "adjusted" the buildNo (basically ALIGNED them)
> using MNG-8055 (mvn 3.9.7) [and other tricks before 3.9.7 was out], and
> then I knew (as ASF CI deployed) which buildNo I really want, and then
> created Maven PR with that _exact_ TS "locked down" snapshot version, and
> was sure CI tested my change and my change only.
>
> Thanks
> T
>
>
> On Fri, Jun 14, 2024 at 8:36 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > If for example sake, we define "maven" as mvn CLI and "build end" as
> "user
> > got on console "BUILD SUCCESS/FAILED" output and CLI process exited, then
> > at that point, this change would cause ZERO difference for SUCCESS
> builds.
> >
> > Where difference WILL happen, is in case of FAILED builds: nothing will
> be
> > installed to local repo and nothing will be deployed to remote repo.
> Which
> > is usually what we want, in reality.
> >
> > Re install today:
> > Let's assume that your project first "morning build fails in the middle"
> > (at module N+1), hence the first N module ends up installed in your local
> > repo, but second M modules (of some multi module build that has N+M
> modules
> > in total) are not. When you want to build some other project, that
> depends
> > on this project, the installed N JARs will be used that were built now
> > (this morning) as they are "fresh", just installed, but other M will be
> > pulled from remote (as last you installed yesterday, before you left the
> > office). basically ending with JARs on classpath that may come even from
> > different commits (depending what remote JARs, etc).
> >
> > Re deploy today:
> > Similarly, if you have a multi module build (N+M modules) and you deploy
> > snapshots as today, and the build fails at module N+1 (CI or dev
> > workstation, does not matter), after fixing the thing, and redeploy, all
> is
> > seemingly ok. But what happens is that due the first failure, the first N
> > modules will have "build number" in their timestamped version +1 offset
> > from those last M modules (basically as first N modules were deployed
> > twice, while last M modules only once). Hence, if you would like to "lock
> > down" or address whole reactor artifacts built together with a given TS
> > snapshot number, you cannot. But the same happens in the following
> > scenario: you have a multi module build of N modules, but this morning
> you
> > add one new module, hence you have N+1 modules. And you (or CI) deploy.
> The
> > "new" module will have buildNumber 1 (as it was deployed the first time),
> > while all the others may have 50 or even 100. Again, you cannot address
> > (and be sure) you use all the artifacts that were built "together".
> > -SNAPSHOT versions are "moving targets", and kinda helps alleviate this,
> > but they still can suffer from spurious problems, like explained at the
> > beginning: if you depend on -SNAPSHOT version and your commit in question
> > introduced binary incompatibility between modules, your build may fail
> (as
> > -SNAPSHOT will use first N modules with 

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

[Tamás Cservenák]

Just to clarify, the "snapshot lock down technique" as explained here:
https://www.mojohaus.org/versions/versions-maven-plugin/examples/lock-snapshots.html

It WORKS even today if dependency in question is one artifact. But, it
USUALLY becomes impossible, if you depend on some multi module build.

Where I extensively use this technique is exactly with Maven and Maven
Resolver: I deploy "controlled" builds to ASF "snapshots" and then "lock it
down" in other (usually PR), and enjoy the benefit of full CI coverage and
all (ITs etc) while at same time as sure it is "my change" that is being
tested on.

Resolver 2.0.0 had quite some changes:
* new modules (that started at buildNumber 1)
* module renames (transport http -> apache), similarly as above, apache
transport was 1, etc

Hence, referencing "I want a resolver reactor build that I know exactly
comes from this PR/branch/whatever" (for example from a PR) is impossible,
as "lock down" as explained on versions plugin becomes impossible, as
modules have different buildNumbers.

In this case, I "adjusted" the buildNo (basically ALIGNED them)
using MNG-8055 (mvn 3.9.7) [and other tricks before 3.9.7 was out], and
then I knew (as ASF CI deployed) which buildNo I really want, and then
created Maven PR with that _exact_ TS "locked down" snapshot version, and
was sure CI tested my change and my change only.

Thanks
T


On Fri, Jun 14, 2024 at 8:36 PM Tamás Cservenák  wrote:

> Howdy,
>
> If for example sake, we define "maven" as mvn CLI and "build end" as "user
> got on console "BUILD SUCCESS/FAILED" output and CLI process exited, then
> at that point, this change would cause ZERO difference for SUCCESS builds.
>
> Where difference WILL happen, is in case of FAILED builds: nothing will be
> installed to local repo and nothing will be deployed to remote repo. Which
> is usually what we want, in reality.
>
> Re install today:
> Let's assume that your project first "morning build fails in the middle"
> (at module N+1), hence the first N module ends up installed in your local
> repo, but second M modules (of some multi module build that has N+M modules
> in total) are not. When you want to build some other project, that depends
> on this project, the installed N JARs will be used that were built now
> (this morning) as they are "fresh", just installed, but other M will be
> pulled from remote (as last you installed yesterday, before you left the
> office). basically ending with JARs on classpath that may come even from
> different commits (depending what remote JARs, etc).
>
> Re deploy today:
> Similarly, if you have a multi module build (N+M modules) and you deploy
> snapshots as today, and the build fails at module N+1 (CI or dev
> workstation, does not matter), after fixing the thing, and redeploy, all is
> seemingly ok. But what happens is that due the first failure, the first N
> modules will have "build number" in their timestamped version +1 offset
> from those last M modules (basically as first N modules were deployed
> twice, while last M modules only once). Hence, if you would like to "lock
> down" or address whole reactor artifacts built together with a given TS
> snapshot number, you cannot. But the same happens in the following
> scenario: you have a multi module build of N modules, but this morning you
> add one new module, hence you have N+1 modules. And you (or CI) deploy. The
> "new" module will have buildNumber 1 (as it was deployed the first time),
> while all the others may have 50 or even 100. Again, you cannot address
> (and be sure) you use all the artifacts that were built "together".
> -SNAPSHOT versions are "moving targets", and kinda helps alleviate this,
> but they still can suffer from spurious problems, like explained at the
> beginning: if you depend on -SNAPSHOT version and your commit in question
> introduced binary incompatibility between modules, your build may fail (as
> -SNAPSHOT will use first N modules with change, but "older" pre-commit M
> modules without change). Etc.
>
> In short:
> - in case of SUCCESS builds, at the moment CLI exits, the user
> experiences NO difference (everything is installed and/or deployed just
> like before)
> - in case of FAILED builds, the user can be sure no "partial" installs or
> deploys happened. This case is less important, as we tend to "fix" the
> failed builds anyway. Rinse and repeat.
>
> Thanks
> T
>
> On Fri, Jun 14, 2024 at 8:04 PM Maarten Mulders 
> wrote:
>
>> Would flipping the defaults make this a backward incompatible change? If
>> users are not aware of this change, it will change their build/deploy in
>> a significant way...
>>
>>
>> Maarten
>>
>> On 14/06/2024 19:49, Tamás Cservenák wrote:
>> > Howdy
>> >
>> > Yes, Martin is right: am talking about the two plugin *AtEnd parameters,
>> > and only about flipping their defaults.
>> >
>> > T
>> >
>> > On Fri, Jun 14, 2024, 18:29 Gary Gregory 
>> wrote:
>> >
>> >> Hi all,
>> >>
>> >> Install by default locally is probably OK for devs, 

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

[Tamás Cservenák]

Howdy,

If for example sake, we define "maven" as mvn CLI and "build end" as "user
got on console "BUILD SUCCESS/FAILED" output and CLI process exited, then
at that point, this change would cause ZERO difference for SUCCESS builds.

Where difference WILL happen, is in case of FAILED builds: nothing will be
installed to local repo and nothing will be deployed to remote repo. Which
is usually what we want, in reality.

Re install today:
Let's assume that your project first "morning build fails in the middle"
(at module N+1), hence the first N module ends up installed in your local
repo, but second M modules (of some multi module build that has N+M modules
in total) are not. When you want to build some other project, that depends
on this project, the installed N JARs will be used that were built now
(this morning) as they are "fresh", just installed, but other M will be
pulled from remote (as last you installed yesterday, before you left the
office). basically ending with JARs on classpath that may come even from
different commits (depending what remote JARs, etc).

Re deploy today:
Similarly, if you have a multi module build (N+M modules) and you deploy
snapshots as today, and the build fails at module N+1 (CI or dev
workstation, does not matter), after fixing the thing, and redeploy, all is
seemingly ok. But what happens is that due the first failure, the first N
modules will have "build number" in their timestamped version +1 offset
from those last M modules (basically as first N modules were deployed
twice, while last M modules only once). Hence, if you would like to "lock
down" or address whole reactor artifacts built together with a given TS
snapshot number, you cannot. But the same happens in the following
scenario: you have a multi module build of N modules, but this morning you
add one new module, hence you have N+1 modules. And you (or CI) deploy. The
"new" module will have buildNumber 1 (as it was deployed the first time),
while all the others may have 50 or even 100. Again, you cannot address
(and be sure) you use all the artifacts that were built "together".
-SNAPSHOT versions are "moving targets", and kinda helps alleviate this,
but they still can suffer from spurious problems, like explained at the
beginning: if you depend on -SNAPSHOT version and your commit in question
introduced binary incompatibility between modules, your build may fail (as
-SNAPSHOT will use first N modules with change, but "older" pre-commit M
modules without change). Etc.

In short:
- in case of SUCCESS builds, at the moment CLI exits, the user
experiences NO difference (everything is installed and/or deployed just
like before)
- in case of FAILED builds, the user can be sure no "partial" installs or
deploys happened. This case is less important, as we tend to "fix" the
failed builds anyway. Rinse and repeat.

Thanks
T

On Fri, Jun 14, 2024 at 8:04 PM Maarten Mulders 
wrote:

> Would flipping the defaults make this a backward incompatible change? If
> users are not aware of this change, it will change their build/deploy in
> a significant way...
>
>
> Maarten
>
> On 14/06/2024 19:49, Tamás Cservenák wrote:
> > Howdy
> >
> > Yes, Martin is right: am talking about the two plugin *AtEnd parameters,
> > and only about flipping their defaults.
> >
> > T
> >
> > On Fri, Jun 14, 2024, 18:29 Gary Gregory  wrote:
> >
> >> Hi all,
> >>
> >> Install by default locally is probably OK for devs, especially for
> >> multi-module projects, but deploy by default is a bad IMO: I often work
> in
> >> one repo and install, then switch to another repo and test the new
> snapshot
> >> jars. Round and round until my changes are fully baked. This usually
> means
> >> having 2 Eclipse instances open at the same time, we have some projects
> >> with lots of modules. Deploying by default adds time and inflicts my
> work
> >> in progress on everyone else. I'm sure I'd turn that off.
> >>
> >> I would turn off both for sure in GitHub CI builds, so hopefully that
> can
> >> be turned off on the command line so I don't have to make my POMs even
> more
> >> complicated ;-)
> >>
> >> An otherwise happy Maven user giving up
> >> 2c,
> >> Gary
> >>
> >> On Fri, Jun 14, 2024, 12:15 PM Tamás Cservenák 
> >> wrote:
> >>
> >>> Howdy,
> >>>
> >>> As history proved, the original "interleaved" install/deploy is just
> call
> >>> for problems, and causes in need for circumventions like
> >>> https://issues.apache.org/jira/browse/MNG-8054 to make classic
> "snapshot
> >>> TS
> >>> lock-down" possible on large(r) projects. Also, no wonder our users
> were
> >>> asking for this feature for a quite long time.
> >>>
> >>> Hence, I'd propose that in upcoming releases (ie 3.2.0 of them), in
> >> plugins
> >>> m-install-p and m-deploy-p simply "flip" the defaults: and make them
> >>> install/deploy At End by default, while keeping the ability to
> "reverse"
> >> if
> >>> someone really depends on per-module deploys.
> >>>
> >>> WDYT?
> >>>
> >>> Thanks
> >>> T
> >>>
> 

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

[Maarten Mulders]

Would flipping the defaults make this a backward incompatible change? If 
users are not aware of this change, it will change their build/deploy in 
a significant way...



Maarten

On 14/06/2024 19:49, Tamás Cservenák wrote:

Howdy

Yes, Martin is right: am talking about the two plugin *AtEnd parameters,
and only about flipping their defaults.

T

On Fri, Jun 14, 2024, 18:29 Gary Gregory  wrote:


Hi all,

Install by default locally is probably OK for devs, especially for
multi-module projects, but deploy by default is a bad IMO: I often work in
one repo and install, then switch to another repo and test the new snapshot
jars. Round and round until my changes are fully baked. This usually means
having 2 Eclipse instances open at the same time, we have some projects
with lots of modules. Deploying by default adds time and inflicts my work
in progress on everyone else. I'm sure I'd turn that off.

I would turn off both for sure in GitHub CI builds, so hopefully that can
be turned off on the command line so I don't have to make my POMs even more
complicated ;-)

An otherwise happy Maven user giving up
2c,
Gary

On Fri, Jun 14, 2024, 12:15 PM Tamás Cservenák 
wrote:


Howdy,

As history proved, the original "interleaved" install/deploy is just call
for problems, and causes in need for circumventions like
https://issues.apache.org/jira/browse/MNG-8054 to make classic "snapshot
TS
lock-down" possible on large(r) projects. Also, no wonder our users were
asking for this feature for a quite long time.

Hence, I'd propose that in upcoming releases (ie 3.2.0 of them), in

plugins

m-install-p and m-deploy-p simply "flip" the defaults: and make them
install/deploy At End by default, while keeping the ability to "reverse"

if

someone really depends on per-module deploys.

WDYT?

Thanks
T







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

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

[Tamás Cservenák]

And Jorge actually wrote down the two parameter names fully :) thanks, i
hope it is clear now.

T

On Fri, Jun 14, 2024, 19:25 Jorge Solórzano  wrote:

> +1 (nb) to make  installAtEnd and deployAtEnd properties true by default.
>
> BTW, there is a note of "experimental" on the install plugin.
>
>
> On Fri, Jun 14, 2024, 19:16 Martin Desruisseaux <
> martin.desruisse...@geomatys.com> wrote:
>
> > Le 2024-06-14 à 19 h 11, Gary Gregory a écrit :
> > >
> > > Thank you Martin for clarifying this! If I understand correctly: If I
> > > said 'mvn clean deploy foo bar' in a multi-module project, then 'mvn
> > > clean foo bar' happens first for all modules followed by 'mvn deploy'
> > > for all modules?
> > >
> > This is my understanding of Tamas's proposal (maybe more like "mvn
> > compile" for all modules followed by "mvn deploy" for all modules). But
> > I may be wrong, we will need his confirmation.
> >
> >  Martin
> >
> >
>

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

[Tamás Cservenák]

Howdy

Yes, Martin is right: am talking about the two plugin *AtEnd parameters,
and only about flipping their defaults.

T

On Fri, Jun 14, 2024, 18:29 Gary Gregory  wrote:

> Hi all,
>
> Install by default locally is probably OK for devs, especially for
> multi-module projects, but deploy by default is a bad IMO: I often work in
> one repo and install, then switch to another repo and test the new snapshot
> jars. Round and round until my changes are fully baked. This usually means
> having 2 Eclipse instances open at the same time, we have some projects
> with lots of modules. Deploying by default adds time and inflicts my work
> in progress on everyone else. I'm sure I'd turn that off.
>
> I would turn off both for sure in GitHub CI builds, so hopefully that can
> be turned off on the command line so I don't have to make my POMs even more
> complicated ;-)
>
> An otherwise happy Maven user giving up
> 2c,
> Gary
>
> On Fri, Jun 14, 2024, 12:15 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > As history proved, the original "interleaved" install/deploy is just call
> > for problems, and causes in need for circumventions like
> > https://issues.apache.org/jira/browse/MNG-8054 to make classic "snapshot
> > TS
> > lock-down" possible on large(r) projects. Also, no wonder our users were
> > asking for this feature for a quite long time.
> >
> > Hence, I'd propose that in upcoming releases (ie 3.2.0 of them), in
> plugins
> > m-install-p and m-deploy-p simply "flip" the defaults: and make them
> > install/deploy At End by default, while keeping the ability to "reverse"
> if
> > someone really depends on per-module deploys.
> >
> > WDYT?
> >
> > Thanks
> > T
> >
>

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

[Jorge Solórzano]

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

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


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

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

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

[Martin Desruisseaux]

Le 2024-06-14 à 19 h 19, Gary Gregory a écrit :

Yeah, we need clarification, I can't imagine test/verify would be skipped.


I should have said "mvn package for all modules, followed by mvn deploy 
for all modules". The package phase include tests if I remember right.


    Martin

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

[Gary Gregory]

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

Yeah, we need clarification, I can't imagine test/verify would be skipped.
:-)
Gary
>
>  Martin
>

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

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

[Martin Desruisseaux]

Le 2024-06-14 à 19 h 11, Gary Gregory a écrit :


Thank you Martin for clarifying this! If I understand correctly: If I 
said 'mvn clean deploy foo bar' in a multi-module project, then 'mvn 
clean foo bar' happens first for all modules followed by 'mvn deploy' 
for all modules?


This is my understanding of Tamas's proposal (maybe more like "mvn 
compile" for all modules followed by "mvn deploy" for all modules). But 
I may be wrong, we will need his confirmation.


    Martin

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

[Gary Gregory]

On Fri, Jun 14, 2024 at 1:08 PM Martin Desruisseaux
 wrote:
>
> Le 2024-06-14 à 18 h 28, Gary Gregory a écrit :
> >
> > Install by default locally is probably OK for devs, especially for
> > multi-module projects, but deploy by default is a bad IMO.
> >
> I believe that Tamas's proposal is not to deploy by default, but *if*
> users asked for deployment, then makes it happens after successful build
> of *all* modules instead of immediately after each module. Same would
> apply to install. My understanding of Tamas's email is that this feature
> was already available (I wasn't aware of that!) and would become the
> default.

Thank you Martin for clarifying this! If I understand correctly: If I
said 'mvn clean deploy foo bar' in a multi-module project, then 'mvn
clean foo bar' happens first for all modules followed by 'mvn deploy'
for all modules?

Gary

>
>  Martin
>
>
>
> -
> 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 should ALWAYS install/deploy at end

[Martin Desruisseaux]

Le 2024-06-14 à 18 h 28, Gary Gregory a écrit :


Install by default locally is probably OK for devs, especially for 
multi-module projects, but deploy by default is a bad IMO.


I believe that Tamas's proposal is not to deploy by default, but *if* 
users asked for deployment, then makes it happens after successful build 
of *all* modules instead of immediately after each module. Same would 
apply to install. My understanding of Tamas's email is that this feature 
was already available (I wasn't aware of that!) and would become the 
default.


    Martin



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

Re: [VOTE] Release Apache Maven mvnd 1.0.0

[Brian Demers]

+1 nb

Tested on a couple different projects without issue.

On Fri, Jun 14, 2024 at 12:02 PM Romain Manni-Bucau 
wrote:

> +1
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le ven. 14 juin 2024 à 16:28, Mateusz Gajewski <
> mateusz.gajew...@starburstdata.com> a écrit :
>
> > Tested with Trino locally: +1 nb.
> >
> > Thanks! This is gonna to be a great release   
> >
> >
> > On Fri, Jun 14, 2024 at 10:04 AM Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > Note: mvnd 1.x will from now on wrapping Maven 3.9.x and 2.x will wrap
> > > Maven 4.x.
> > >
> > > This release provides distribution on Apache Maven 3.9.8 (under vote,
> > > staged only).
> > >
> > > The release candidate is here:
> > > https://dist.apache.org/repos/dist/dev/maven/mvnd/1.0.0/
> > >
> > > Release notes: (visible to committers only as remains draft during the
> > > vote)
> > >
> > >
> >
> https://github.com/apache/maven-mvnd/releases/tag/untagged-65524f868c0424675d24
> > >
> > > Release notes (gist copy of that above for wider public):
> > > https://gist.github.com/cstamas/68ab0862a84b405c709307f46bb6
> > >
> > > SHA512(maven-mvnd-1.0.0-src.tar.gz)=
> > >
> > >
> >
> 0a44c56b8597049ff462f02e23e9063c592f5758334642701619f26881171c28441f6cf32f0ec018dae7a5f2d281db789723478cb01e1465cb19021741e37d79
> > >
> > > SHA512(maven-mvnd-1.0.0-src.zip)=
> > >
> > >
> >
> 243340dee95501a2e231b7d96fcaaf526e57cde61bbd4b24591ddd63e0cfd8c59adc971d12980938108ef6e5fc89f919bd8f48bb2c55854ac63b2a97d6e1aa16
> > >
> > > Vote open for 72h
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> >
>

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

[Gary Gregory]

Hi all,

Install by default locally is probably OK for devs, especially for
multi-module projects, but deploy by default is a bad IMO: I often work in
one repo and install, then switch to another repo and test the new snapshot
jars. Round and round until my changes are fully baked. This usually means
having 2 Eclipse instances open at the same time, we have some projects
with lots of modules. Deploying by default adds time and inflicts my work
in progress on everyone else. I'm sure I'd turn that off.

I would turn off both for sure in GitHub CI builds, so hopefully that can
be turned off on the command line so I don't have to make my POMs even more
complicated ;-)

An otherwise happy Maven user giving up
2c,
Gary

On Fri, Jun 14, 2024, 12:15 PM Tamás Cservenák  wrote:

> Howdy,
>
> As history proved, the original "interleaved" install/deploy is just call
> for problems, and causes in need for circumventions like
> https://issues.apache.org/jira/browse/MNG-8054 to make classic "snapshot
> TS
> lock-down" possible on large(r) projects. Also, no wonder our users were
> asking for this feature for a quite long time.
>
> Hence, I'd propose that in upcoming releases (ie 3.2.0 of them), in plugins
> m-install-p and m-deploy-p simply "flip" the defaults: and make them
> install/deploy At End by default, while keeping the ability to "reverse" if
> someone really depends on per-module deploys.
>
> WDYT?
>
> Thanks
> T
>

[RESULT] [VOTE] Release Maven Surefire version 3.3.0

[Michael Osipov]

Hi,

The vote has passed with the following result:

+1: Michael Osipov, Sylwester Lachiewicz, Romain Manni-Bucau, Slawomir 
Jaranowski, Karl Heinz Marbaise


PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

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

Re: [VOTE] Release Maven Release version 3.1.0

[Michael Osipov]

Am 2024-06-14 um 10:43 schrieb Michael Osipov:

Hi,

we solved 11 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317824=12354221

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MRELEASE/issues

Staging repo:
https://repository.apache.org/content/repositories/maven-2148/
https://repository.apache.org/content/repositories/maven-2148/org/apache/maven/release/maven-release/3.1.0/maven-release-3.1.0-source-release.zip

Source release checksum(s):
maven-release-3.1.0-source-release.zip
0883c76c2611fa74849038b2e133b0834c8498bdea494465c0f88324bab33af165d806ac0ee7c5e7b77b98dbf1e0e8bc9704605f7f10ae7e280bf0fa3878c6fe

Staging site:
https://maven.apache.org/maven-release-archives/maven-release-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.


+1


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

[DISCUSS] Maven should ALWAYS install/deploy at end

[Tamás Cservenák]

Howdy,

As history proved, the original "interleaved" install/deploy is just call
for problems, and causes in need for circumventions like
https://issues.apache.org/jira/browse/MNG-8054 to make classic "snapshot TS
lock-down" possible on large(r) projects. Also, no wonder our users were
asking for this feature for a quite long time.

Hence, I'd propose that in upcoming releases (ie 3.2.0 of them), in plugins
m-install-p and m-deploy-p simply "flip" the defaults: and make them
install/deploy At End by default, while keeping the ability to "reverse" if
someone really depends on per-module deploys.

WDYT?

Thanks
T

Re: [VOTE] Release Apache Maven mvnd 1.0.0

[Romain Manni-Bucau]

+1

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



Le ven. 14 juin 2024 à 16:28, Mateusz Gajewski <
mateusz.gajew...@starburstdata.com> a écrit :

> Tested with Trino locally: +1 nb.
>
> Thanks! This is gonna to be a great release   
>
>
> On Fri, Jun 14, 2024 at 10:04 AM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > Note: mvnd 1.x will from now on wrapping Maven 3.9.x and 2.x will wrap
> > Maven 4.x.
> >
> > This release provides distribution on Apache Maven 3.9.8 (under vote,
> > staged only).
> >
> > The release candidate is here:
> > https://dist.apache.org/repos/dist/dev/maven/mvnd/1.0.0/
> >
> > Release notes: (visible to committers only as remains draft during the
> > vote)
> >
> >
> https://github.com/apache/maven-mvnd/releases/tag/untagged-65524f868c0424675d24
> >
> > Release notes (gist copy of that above for wider public):
> > https://gist.github.com/cstamas/68ab0862a84b405c709307f46bb6
> >
> > SHA512(maven-mvnd-1.0.0-src.tar.gz)=
> >
> >
> 0a44c56b8597049ff462f02e23e9063c592f5758334642701619f26881171c28441f6cf32f0ec018dae7a5f2d281db789723478cb01e1465cb19021741e37d79
> >
> > SHA512(maven-mvnd-1.0.0-src.zip)=
> >
> >
> 243340dee95501a2e231b7d96fcaaf526e57cde61bbd4b24591ddd63e0cfd8c59adc971d12980938108ef6e5fc89f919bd8f48bb2c55854ac63b2a97d6e1aa16
> >
> > Vote open for 72h
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
>

Re: [VOTE] Release Apache Maven mvnd 1.0.0

[Mateusz Gajewski]

Tested with Trino locally: +1 nb.

Thanks! This is gonna to be a great release   


On Fri, Jun 14, 2024 at 10:04 AM Tamás Cservenák 
wrote:

> Howdy,
>
> Note: mvnd 1.x will from now on wrapping Maven 3.9.x and 2.x will wrap
> Maven 4.x.
>
> This release provides distribution on Apache Maven 3.9.8 (under vote,
> staged only).
>
> The release candidate is here:
> https://dist.apache.org/repos/dist/dev/maven/mvnd/1.0.0/
>
> Release notes: (visible to committers only as remains draft during the
> vote)
>
> https://github.com/apache/maven-mvnd/releases/tag/untagged-65524f868c0424675d24
>
> Release notes (gist copy of that above for wider public):
> https://gist.github.com/cstamas/68ab0862a84b405c709307f46bb6
>
> SHA512(maven-mvnd-1.0.0-src.tar.gz)=
>
> 0a44c56b8597049ff462f02e23e9063c592f5758334642701619f26881171c28441f6cf32f0ec018dae7a5f2d281db789723478cb01e1465cb19021741e37d79
>
> SHA512(maven-mvnd-1.0.0-src.zip)=
>
> 243340dee95501a2e231b7d96fcaaf526e57cde61bbd4b24591ddd63e0cfd8c59adc971d12980938108ef6e5fc89f919bd8f48bb2c55854ac63b2a97d6e1aa16
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: [VOTE] Release Apache Maven 3.9.8

[Sylwester Lachiewicz]

+1

pt., 14 cze 2024, 08:33 użytkownik Karl Heinz Marbaise
 napisał:

> Hi,
>
> +1 from me.
>
> Kind regards
> Karl Heinz Marbaise
> On 13.06.24 10:49, Tamás Cservenák wrote:
> > Howdy,
> >
> > We solved 16 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354748
> >
> > 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-2146
> >
> > Dev dist directory (binary bundles updated):
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.8/
> >
> > Source release checksums:
> > apache-maven-3.9.8-src.tar.gz.sha512
> >
> 624156967432be2e8805e5eace3c74b5f05d3ad74616e11733149cce5dda1b60443d6b5cba2f10744a9a71efc490108d2be373aa13760829ab62c6b73bdd6162
> >
> > apache-maven-3.9.8-src.zip.sha512
> >
> a55b7ee36639645f4034d47c4068e0a30927647e5d445d189188c053afd233fdb2362d459d98bff30ab979dce04e6262ce8449e6098f4f2b2485ab4318fcac74
> >
> > Staged site:
> > https://maven.apache.org/ref/3-LATEST/
> >
> > Draft for release notes:
> > https://github.com/apache/maven-site/pull/541
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72h
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Release version 3.1.0

[Sylwester Lachiewicz]

+1

pt., 14 cze 2024, 10:43 użytkownik Michael Osipov 
napisał:

> Hi,
>
> we solved 11 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317824=12354221
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MRELEASE/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2148/
>
> https://repository.apache.org/content/repositories/maven-2148/org/apache/maven/release/maven-release/3.1.0/maven-release-3.1.0-source-release.zip
>
> Source release checksum(s):
> maven-release-3.1.0-source-release.zip
>
> 0883c76c2611fa74849038b2e133b0834c8498bdea494465c0f88324bab33af165d806ac0ee7c5e7b77b98dbf1e0e8bc9704605f7f10ae7e280bf0fa3878c6fe
>
> Staging site:
> https://maven.apache.org/maven-release-archives/maven-release-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
>
>

[VOTE] Release Apache Maven mvnd 1.0.0

[Tamás Cservenák]

Howdy,

Note: mvnd 1.x will from now on wrapping Maven 3.9.x and 2.x will wrap
Maven 4.x.

This release provides distribution on Apache Maven 3.9.8 (under vote,
staged only).

The release candidate is here:
https://dist.apache.org/repos/dist/dev/maven/mvnd/1.0.0/

Release notes: (visible to committers only as remains draft during the vote)
https://github.com/apache/maven-mvnd/releases/tag/untagged-65524f868c0424675d24

Release notes (gist copy of that above for wider public):
https://gist.github.com/cstamas/68ab0862a84b405c709307f46bb6

SHA512(maven-mvnd-1.0.0-src.tar.gz)=
0a44c56b8597049ff462f02e23e9063c592f5758334642701619f26881171c28441f6cf32f0ec018dae7a5f2d281db789723478cb01e1465cb19021741e37d79

SHA512(maven-mvnd-1.0.0-src.zip)=
243340dee95501a2e231b7d96fcaaf526e57cde61bbd4b24591ddd63e0cfd8c59adc971d12980938108ef6e5fc89f919bd8f48bb2c55854ac63b2a97d6e1aa16

Vote open for 72h

[ ] +1
[ ] +0
[ ] -1

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.6.0

[Sylwester Lachiewicz]

+1

pt., 14 cze 2024, 09:48 użytkownik Slawomir Jaranowski <
s.jaranow...@gmail.com> napisał:

> +1
>
> czw., 13 cze 2024 o 18:49 Michael Osipov  napisał(a):
>
> > Hi,
> >
> > we solved 6 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821=12354774
> >
> > There are still a couple of issues left in JIRA:
> > https://issues.apache.org/jira/projects/MPIR/issues
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-2147/
> >
> >
> https://repository.apache.org/content/repositories/maven-2147/org/apache/maven/plugins/maven-project-info-reports-plugin/3.6.0/maven-project-info-reports-plugin-3.6.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-project-info-reports-plugin-3.6.0-source-release.zip
> > sha512:
> >
> >
> 72691f1affac507ccbaa908d1c03386accaf59384ec7b388c8b944389074861b334fd306af00d2b706a99401bd4c29f650f594dbc1cf22c3fecd1d3e7e7c140d
> >
> > Staging site:
> >
> >
> https://maven.apache.org/plugins-archives/maven-project-info-reports-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
>

[VOTE] Release Maven Release version 3.1.0

[Michael Osipov]

Hi,

we solved 11 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317824=12354221

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MRELEASE/issues

Staging repo:
https://repository.apache.org/content/repositories/maven-2148/
https://repository.apache.org/content/repositories/maven-2148/org/apache/maven/release/maven-release/3.1.0/maven-release-3.1.0-source-release.zip

Source release checksum(s):
maven-release-3.1.0-source-release.zip
0883c76c2611fa74849038b2e133b0834c8498bdea494465c0f88324bab33af165d806ac0ee7c5e7b77b98dbf1e0e8bc9704605f7f10ae7e280bf0fa3878c6fe

Staging site:
https://maven.apache.org/maven-release-archives/maven-release-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

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

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.6.0

[Slawomir Jaranowski]

+1

czw., 13 cze 2024 o 18:49 Michael Osipov  napisał(a):

> Hi,
>
> we solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821=12354774
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPIR/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2147/
>
> https://repository.apache.org/content/repositories/maven-2147/org/apache/maven/plugins/maven-project-info-reports-plugin/3.6.0/maven-project-info-reports-plugin-3.6.0-source-release.zip
>
> Source release checksum(s):
> maven-project-info-reports-plugin-3.6.0-source-release.zip
> sha512:
>
> 72691f1affac507ccbaa908d1c03386accaf59384ec7b388c8b944389074861b334fd306af00d2b706a99401bd4c29f650f594dbc1cf22c3fecd1d3e7e7c140d
>
> Staging site:
>
> https://maven.apache.org/plugins-archives/maven-project-info-reports-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: [VOTE] Release Maven Project Info Reports Plugin version 3.6.0

[Michael Osipov]

+1

On 2024/06/13 16:48:06 Michael Osipov wrote:
> Hi,
> 
> we solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821=12354774
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPIR/issues
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2147/
> https://repository.apache.org/content/repositories/maven-2147/org/apache/maven/plugins/maven-project-info-reports-plugin/3.6.0/maven-project-info-reports-plugin-3.6.0-source-release.zip
> 
> Source release checksum(s):
> maven-project-info-reports-plugin-3.6.0-source-release.zip
> sha512: 
> 72691f1affac507ccbaa908d1c03386accaf59384ec7b388c8b944389074861b334fd306af00d2b706a99401bd4c29f650f594dbc1cf22c3fecd1d3e7e7c140d
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 

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

Re: [VOTE] Release Apache Maven 3.9.8

[Karl Heinz Marbaise]

Hi,

+1 from me.

Kind regards
Karl Heinz Marbaise
On 13.06.24 10:49, Tamás Cservenák wrote:

Howdy,

We solved 16 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354748

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

Dev dist directory (binary bundles updated):
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.8/

Source release checksums:
apache-maven-3.9.8-src.tar.gz.sha512
624156967432be2e8805e5eace3c74b5f05d3ad74616e11733149cce5dda1b60443d6b5cba2f10744a9a71efc490108d2be373aa13760829ab62c6b73bdd6162

apache-maven-3.9.8-src.zip.sha512
a55b7ee36639645f4034d47c4068e0a30927647e5d445d189188c053afd233fdb2362d459d98bff30ab979dce04e6262ce8449e6098f4f2b2485ab4318fcac74

Staged site:
https://maven.apache.org/ref/3-LATEST/

Draft for release notes:
https://github.com/apache/maven-site/pull/541

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72h

[ ] +1
[ ] +0
[ ] -1



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

Re: [VOTE] Release Apache Maven 3.9.8

[Michael Bien]

+1 (non binding)

looks good! tests are green too

https://github.com/apache/netbeans/actions/runs/9507545238

best regards,
michael


On 13.06.24 10:49, Tamás Cservenák wrote:

Howdy,

We solved 16 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354748

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

Dev dist directory (binary bundles updated):
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.8/

Source release checksums:
apache-maven-3.9.8-src.tar.gz.sha512
624156967432be2e8805e5eace3c74b5f05d3ad74616e11733149cce5dda1b60443d6b5cba2f10744a9a71efc490108d2be373aa13760829ab62c6b73bdd6162

apache-maven-3.9.8-src.zip.sha512
a55b7ee36639645f4034d47c4068e0a30927647e5d445d189188c053afd233fdb2362d459d98bff30ab979dce04e6262ce8449e6098f4f2b2485ab4318fcac74

Staged site:
https://maven.apache.org/ref/3-LATEST/

Draft for release notes:
https://github.com/apache/maven-site/pull/541

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72h

[ ] +1
[ ] +0
[ ] -1




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

Re: [VOTE] Release Maven Project Info Reports Plugin version 3.6.0

[Gabriel Belingueres]

+1

Thanks!

El jue, 13 jun 2024 a la(s) 1:49 p.m., Michael Osipov (micha...@apache.org)
escribió:

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

Re: [VOTE] Release Apache Maven 3.9.8

[Olivier Lamy]

+1


On Thu, 13 Jun 2024 at 18:49, Tamás Cservenák  wrote:
>
> Howdy,
>
> We solved 16 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354748
>
> 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-2146
>
> Dev dist directory (binary bundles updated):
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.8/
>
> Source release checksums:
> apache-maven-3.9.8-src.tar.gz.sha512
> 624156967432be2e8805e5eace3c74b5f05d3ad74616e11733149cce5dda1b60443d6b5cba2f10744a9a71efc490108d2be373aa13760829ab62c6b73bdd6162
>
> apache-maven-3.9.8-src.zip.sha512
> a55b7ee36639645f4034d47c4068e0a30927647e5d445d189188c053afd233fdb2362d459d98bff30ab979dce04e6262ce8449e6098f4f2b2485ab4318fcac74
>
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/541
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1

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

Re: [VOTE] Release Apache Maven 3.9.8

[Mark Derricutt]

 +1 non-binding so far from me and our maven-tiles/osgi based project.

Mark

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 13 Jun 2024 at 8:49:07 PM, Tamás Cservenák  wrote:

> Howdy,
>
> We solved 16 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354748
>
> 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-2146
>
> Dev dist directory (binary bundles updated):
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.8/
>
> Source release checksums:
> apache-maven-3.9.8-src.tar.gz.sha512
>
> 624156967432be2e8805e5eace3c74b5f05d3ad74616e11733149cce5dda1b60443d6b5cba2f10744a9a71efc490108d2be373aa13760829ab62c6b73bdd6162
>
> apache-maven-3.9.8-src.zip.sha512
>
> a55b7ee36639645f4034d47c4068e0a30927647e5d445d189188c053afd233fdb2362d459d98bff30ab979dce04e6262ce8449e6098f4f2b2485ab4318fcac74
>
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/541
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>

Re: Apache Maven mvnd 1.0.0 "early access"

[Mateusz Gajewski]

Tested and works flawlessly! Thanks :)

Looking forward to the release!

On Thu, Jun 13, 2024 at 3:50 PM Tamás Cservenák  wrote:

> New builds w/ fixed deprecation warning about JAnsi will land here:
> https://github.com/apache/maven-mvnd/actions/runs/9505851154
>
> Thanks
> T
>
> On Thu, Jun 13, 2024 at 7:23 PM Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > Just wanted to mention that the upcoming Apache Maven mvnd
> > 1.0.0(-SNAPSHOT) integrated with latest Apache Maven 3.9.8 (currently
> under
> > vote, is in the process of release) is available for all supported
> > platforms from Github, Go grab one while hot!
> >
> > (and test and report back issues, please and thanks!)
> >
> > https://github.com/apache/maven-mvnd/actions/runs/950209
> >
> > Thanks
> > T
> >
>

Re: Apache Maven mvnd 1.0.0 "early access"

[Tamás Cservenák]

New builds w/ fixed deprecation warning about JAnsi will land here:
https://github.com/apache/maven-mvnd/actions/runs/9505851154

Thanks
T

On Thu, Jun 13, 2024 at 7:23 PM Tamás Cservenák  wrote:

> Howdy,
>
> Just wanted to mention that the upcoming Apache Maven mvnd
> 1.0.0(-SNAPSHOT) integrated with latest Apache Maven 3.9.8 (currently under
> vote, is in the process of release) is available for all supported
> platforms from Github, Go grab one while hot!
>
> (and test and report back issues, please and thanks!)
>
> https://github.com/apache/maven-mvnd/actions/runs/950209
>
> Thanks
> T
>

Re: [VOTE] Release Apache Maven 3.9.8

[Mateusz Gajewski]

Tested in Trino: https://github.com/trinodb/trino/pull/22382

+1 nb - works flawlessly (as the last couple of releases). Thanks!

On Thu, Jun 13, 2024 at 1:17 PM Tamás Cservenák  wrote:

> Ben,
> Thank to the whole team!
>
> I merely brought the schnaps to the party (for warm up) :)
>
> Thanks
> T
>
>
> On Thu, Jun 13, 2024, 19:11 Benjamin Marwell  wrote:
>
> > +1
> >
> > Thanks, Tamas! 
> >
> >
> >
> >
> > On Thu, 13 Jun 2024, 10:49 Tamás Cservenák,  wrote:
> >
> > > Howdy,
> > >
> > > We solved 16 issues:
> > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354748
> > >
> > > 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-2146
> > >
> > > Dev dist directory (binary bundles updated):
> > > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.8/
> > >
> > > Source release checksums:
> > > apache-maven-3.9.8-src.tar.gz.sha512
> > >
> > >
> >
> 624156967432be2e8805e5eace3c74b5f05d3ad74616e11733149cce5dda1b60443d6b5cba2f10744a9a71efc490108d2be373aa13760829ab62c6b73bdd6162
> > >
> > > apache-maven-3.9.8-src.zip.sha512
> > >
> > >
> >
> a55b7ee36639645f4034d47c4068e0a30927647e5d445d189188c053afd233fdb2362d459d98bff30ab979dce04e6262ce8449e6098f4f2b2485ab4318fcac74
> > >
> > > Staged site:
> > > https://maven.apache.org/ref/3-LATEST/
> > >
> > > Draft for release notes:
> > > https://github.com/apache/maven-site/pull/541
> > >
> > > Guide to testing staged releases:
> > > http://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for 72h
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> >
>

Apache Maven mvnd 1.0.0 "early access"

[Tamás Cservenák]

Howdy,

Just wanted to mention that the upcoming Apache Maven mvnd 1.0.0(-SNAPSHOT)
integrated with latest Apache Maven 3.9.8 (currently under vote, is in the
process of release) is available for all supported platforms from Github,
Go grab one while hot!

(and test and report back issues, please and thanks!)

https://github.com/apache/maven-mvnd/actions/runs/950209

Thanks
T

Re: [VOTE] Release Apache Maven 3.9.8

[Tamás Cservenák]

Ben,
Thank to the whole team!

I merely brought the schnaps to the party (for warm up) :)

Thanks
T


On Thu, Jun 13, 2024, 19:11 Benjamin Marwell  wrote:

> +1
>
> Thanks, Tamas! 
>
>
>
>
> On Thu, 13 Jun 2024, 10:49 Tamás Cservenák,  wrote:
>
> > Howdy,
> >
> > We solved 16 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354748
> >
> > 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-2146
> >
> > Dev dist directory (binary bundles updated):
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.8/
> >
> > Source release checksums:
> > apache-maven-3.9.8-src.tar.gz.sha512
> >
> >
> 624156967432be2e8805e5eace3c74b5f05d3ad74616e11733149cce5dda1b60443d6b5cba2f10744a9a71efc490108d2be373aa13760829ab62c6b73bdd6162
> >
> > apache-maven-3.9.8-src.zip.sha512
> >
> >
> a55b7ee36639645f4034d47c4068e0a30927647e5d445d189188c053afd233fdb2362d459d98bff30ab979dce04e6262ce8449e6098f4f2b2485ab4318fcac74
> >
> > Staged site:
> > https://maven.apache.org/ref/3-LATEST/
> >
> > Draft for release notes:
> > https://github.com/apache/maven-site/pull/541
> >
> > 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.8

[Benjamin Marwell]

+1

Thanks, Tamas! 




On Thu, 13 Jun 2024, 10:49 Tamás Cservenák,  wrote:

> Howdy,
>
> We solved 16 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354748
>
> 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-2146
>
> Dev dist directory (binary bundles updated):
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.8/
>
> Source release checksums:
> apache-maven-3.9.8-src.tar.gz.sha512
>
> 624156967432be2e8805e5eace3c74b5f05d3ad74616e11733149cce5dda1b60443d6b5cba2f10744a9a71efc490108d2be373aa13760829ab62c6b73bdd6162
>
> apache-maven-3.9.8-src.zip.sha512
>
> a55b7ee36639645f4034d47c4068e0a30927647e5d445d189188c053afd233fdb2362d459d98bff30ab979dce04e6262ce8449e6098f4f2b2485ab4318fcac74
>
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/541
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72h
>
> [ ] +1
> [ ] +0
> [ ] -1
>

[VOTE] Release Maven Project Info Reports Plugin version 3.6.0

[Michael Osipov]

Hi,

we solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317821=12354774

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MPIR/issues

Staging repo:
https://repository.apache.org/content/repositories/maven-2147/
https://repository.apache.org/content/repositories/maven-2147/org/apache/maven/plugins/maven-project-info-reports-plugin/3.6.0/maven-project-info-reports-plugin-3.6.0-source-release.zip

Source release checksum(s):
maven-project-info-reports-plugin-3.6.0-source-release.zip
sha512: 
72691f1affac507ccbaa908d1c03386accaf59384ec7b388c8b944389074861b334fd306af00d2b706a99401bd4c29f650f594dbc1cf22c3fecd1d3e7e7c140d


Staging site:
https://maven.apache.org/plugins-archives/maven-project-info-reports-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

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

Re: [VOTE] Release Apache Maven 3.9.8

[Michael Osipov]

Am 2024-06-13 um 10:49 schrieb Tamás Cservenák:

Howdy,

We solved 16 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354748

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

Dev dist directory (binary bundles updated):
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.8/

Source release checksums:
apache-maven-3.9.8-src.tar.gz.sha512
624156967432be2e8805e5eace3c74b5f05d3ad74616e11733149cce5dda1b60443d6b5cba2f10744a9a71efc490108d2be373aa13760829ab62c6b73bdd6162

apache-maven-3.9.8-src.zip.sha512
a55b7ee36639645f4034d47c4068e0a30927647e5d445d189188c053afd233fdb2362d459d98bff30ab979dce04e6262ce8449e6098f4f2b2485ab4318fcac74

Staged site:
https://maven.apache.org/ref/3-LATEST/

Draft for release notes:
https://github.com/apache/maven-site/pull/541

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72h


+1

Re: [VOTE] Release Apache Maven 3.9.8

[Romain Manni-Bucau]

+1

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



Le jeu. 13 juin 2024 à 17:40, Slawomir Jaranowski 
a écrit :

> +1
>
> czw., 13 cze 2024 o 10:49 Tamás Cservenák 
> napisał(a):
>
> > Howdy,
> >
> > We solved 16 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354748
> >
> > 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-2146
> >
> > Dev dist directory (binary bundles updated):
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.8/
> >
> > Source release checksums:
> > apache-maven-3.9.8-src.tar.gz.sha512
> >
> >
> 624156967432be2e8805e5eace3c74b5f05d3ad74616e11733149cce5dda1b60443d6b5cba2f10744a9a71efc490108d2be373aa13760829ab62c6b73bdd6162
> >
> > apache-maven-3.9.8-src.zip.sha512
> >
> >
> a55b7ee36639645f4034d47c4068e0a30927647e5d445d189188c053afd233fdb2362d459d98bff30ab979dce04e6262ce8449e6098f4f2b2485ab4318fcac74
> >
> > Staged site:
> > https://maven.apache.org/ref/3-LATEST/
> >
> > Draft for release notes:
> > https://github.com/apache/maven-site/pull/541
> >
> > 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.8

[Slawomir Jaranowski]

+1

czw., 13 cze 2024 o 10:49 Tamás Cservenák  napisał(a):

> Howdy,
>
> We solved 16 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354748
>
> 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-2146
>
> Dev dist directory (binary bundles updated):
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.8/
>
> Source release checksums:
> apache-maven-3.9.8-src.tar.gz.sha512
>
> 624156967432be2e8805e5eace3c74b5f05d3ad74616e11733149cce5dda1b60443d6b5cba2f10744a9a71efc490108d2be373aa13760829ab62c6b73bdd6162
>
> apache-maven-3.9.8-src.zip.sha512
>
> a55b7ee36639645f4034d47c4068e0a30927647e5d445d189188c053afd233fdb2362d459d98bff30ab979dce04e6262ce8449e6098f4f2b2485ab4318fcac74
>
> Staged site:
> https://maven.apache.org/ref/3-LATEST/
>
> Draft for release notes:
> https://github.com/apache/maven-site/pull/541
>
> 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

[VOTE] Release Apache Maven 3.9.8

[Tamás Cservenák]

Howdy,

We solved 16 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12354748

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

Dev dist directory (binary bundles updated):
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.9.8/

Source release checksums:
apache-maven-3.9.8-src.tar.gz.sha512
624156967432be2e8805e5eace3c74b5f05d3ad74616e11733149cce5dda1b60443d6b5cba2f10744a9a71efc490108d2be373aa13760829ab62c6b73bdd6162

apache-maven-3.9.8-src.zip.sha512
a55b7ee36639645f4034d47c4068e0a30927647e5d445d189188c053afd233fdb2362d459d98bff30ab979dce04e6262ce8449e6098f4f2b2485ab4318fcac74

Staged site:
https://maven.apache.org/ref/3-LATEST/

Draft for release notes:
https://github.com/apache/maven-site/pull/541

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 Maven Surefire version 3.3.0

[Sylwester Lachiewicz]

+1

czw., 13 cze 2024, 08:52 użytkownik Karl Heinz Marbaise
 napisał:

> Hi,
>
> +1 from me.
>
> Kind regards
> Karl Heinz Marbaise
> On 11.06.24 22:39, Michael Osipov wrote:
> > Hi,
> >
> > we solved 10 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12354462
> >
> > 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-2145/
> >
> https://repository.apache.org/content/repositories/maven-2145/org/apache/maven/surefire/surefire/3.3.0/surefire-3.3.0-source-release.zip
> >
> > Source release checksum(s):
> > surefire-3.3.0-source-release.zip
> > sha512:
> >
> d33978d38c0773a296f9fff438281cd4cfb69fe3082dfe908b7e0acd4f4eec40995c2df2616e17ffe4607fb7c6c9131ac58dcb96d41052b6ae244316a974152c
> >
> > 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
>
>

Re: [VOTE] Release Maven Surefire version 3.3.0

[Karl Heinz Marbaise]

Hi,

+1 from me.

Kind regards
Karl Heinz Marbaise
On 11.06.24 22:39, Michael Osipov wrote:

Hi,

we solved 10 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12354462

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-2145/
https://repository.apache.org/content/repositories/maven-2145/org/apache/maven/surefire/surefire/3.3.0/surefire-3.3.0-source-release.zip

Source release checksum(s):
surefire-3.3.0-source-release.zip
sha512:
d33978d38c0773a296f9fff438281cd4cfb69fe3082dfe908b7e0acd4f4eec40995c2df2616e17ffe4607fb7c6c9131ac58dcb96d41052b6ae244316a974152c

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

Re: [VOTE] Release Maven Surefire version 3.3.0

[Romain Manni-Bucau]

+1

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



Le jeu. 13 juin 2024 à 08:01, Slawomir Jaranowski 
a écrit :

> +1
>
> wt., 11 cze 2024 o 22:39 Michael Osipov  napisał(a):
> >
> > Hi,
> >
> > we solved 10 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12354462
> >
> > 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-2145/
> >
> https://repository.apache.org/content/repositories/maven-2145/org/apache/maven/surefire/surefire/3.3.0/surefire-3.3.0-source-release.zip
> >
> > Source release checksum(s):
> > surefire-3.3.0-source-release.zip
> > sha512:
> >
> d33978d38c0773a296f9fff438281cd4cfb69fe3082dfe908b7e0acd4f4eec40995c2df2616e17ffe4607fb7c6c9131ac58dcb96d41052b6ae244316a974152c
> >
> > 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
>
> -
> 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.3.0

[Slawomir Jaranowski]

+1

wt., 11 cze 2024 o 22:39 Michael Osipov  napisał(a):
>
> Hi,
>
> we solved 10 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12354462
>
> 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-2145/
> https://repository.apache.org/content/repositories/maven-2145/org/apache/maven/surefire/surefire/3.3.0/surefire-3.3.0-source-release.zip
>
> Source release checksum(s):
> surefire-3.3.0-source-release.zip
> sha512:
> d33978d38c0773a296f9fff438281cd4cfb69fe3082dfe908b7e0acd4f4eec40995c2df2616e17ffe4607fb7c6c9131ac58dcb96d41052b6ae244316a974152c
>
> 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

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

Upcoming Maven 3.9.8

[Tamás Cservenák]

Howdy,

The current status of Maven 3.9.8:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.8

I plan to release it soon. If anyone has anything to add, please let me
know.

Upcoming in the pipe:
- mvnd 1.x (former m39, mvnd that uses Maven 3.9.8) - did not check latest
issues/PRs, but I might release it along with Maven 3.9.8
- Resolver 2.0.0 (unsure do we want a beta out of it, as really almost all
the issues are done)

Thanks
T

Module: Inherit configuration from parent project

[Jochen Wiedmann]

Hi,

I have a plugin, which is basically controlled by a config file. So,
my plugin configuration looks like this:

  
 src/main/myPlugin/config.xml
  

In a module, it is desirable to reuse the parents configuration, so this becomes

 ../src/main/myPlugin/config.xml

or, if the module wishes to overwrite the parents configuration, it
might even be

 
../src/main/myPlugin/config.xml
 src/main/myPlugin/config.xml
  

Now my question; If parent, and module are in the same reactor (which
is usually the case), then is it possible, that the plugin detects the
presence of the parents configuration file automatically, without
explicit configuration. by looking into the parent project?

Thanks,

Jochen


-- 
The woman was born in a full-blown thunderstorm. She probably told it
to be quiet. It probably did. (Robert Jordan, Winter's heart)

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

[Michael Osipov]

+1

On 2024/06/11 20:39:53 Michael Osipov wrote:
> Hi,
> 
> we solved 10 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12354462
> 
> 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-2145/
> https://repository.apache.org/content/repositories/maven-2145/org/apache/maven/surefire/surefire/3.3.0/surefire-3.3.0-source-release.zip
> 
> Source release checksum(s):
> surefire-3.3.0-source-release.zip
> sha512: 
> d33978d38c0773a296f9fff438281cd4cfb69fe3082dfe908b7e0acd4f4eec40995c2df2616e17ffe4607fb7c6c9131ac58dcb96d41052b6ae244316a974152c
> 
> 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

[VOTE] Release Maven Surefire version 3.3.0

[Michael Osipov]

Hi,

we solved 10 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927=12354462

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-2145/
https://repository.apache.org/content/repositories/maven-2145/org/apache/maven/surefire/surefire/3.3.0/surefire-3.3.0-source-release.zip

Source release checksum(s):
surefire-3.3.0-source-release.zip
sha512: 
d33978d38c0773a296f9fff438281cd4cfb69fe3082dfe908b7e0acd4f4eec40995c2df2616e17ffe4607fb7c6c9131ac58dcb96d41052b6ae244316a974152c


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

[ANN] Release Maven Dependency Plugin 3.7.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Dependency Plugin version 3.7.0.


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

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


  org.apache.maven.plugins
  maven-dependency-plugin
  3.7.0



Release Notes - Maven Dependency Plugin - Version 3.7.0

** Bug
* [MDEP-835] - dependency:tree no longer shows optional flag
* [MDEP-838] - "Artifact has not been packaged yet" error message 
is not very helpful
* [MDEP-938] - 'mdep.overIfNewer' is misnamed from its usage of 
'mdep.overWriteIfNewer'


** New Feature
* [MDEP-317] - Add goal dependency:analyze-exclusions - check for 
invalid excludes
* [MDEP-799] - improve mvn dependency:tree - add optional JSON 
output of the results

* [MDEP-928] - Allow to exclude classes from dependency:analyze

** Improvement
* [MDEP-669] - Optimize the documentation of  of 
build-classpath-mojo

* [MDEP-893] - Get rid of commons-lang3
* [MDEP-894] - Use @Component instead of @Parameter for session/project
* [MDEP-896] - Removing unused code
* [MDEP-897] - Remove old style JavaDoc Plexus docs
* [MDEP-899] - Upgrade maven-plugin parent to 42
* [MDEP-917] - dependency:analyze-exclusions - use Resolver API 
instead of ProjectBuilder
* [MDEP-924] - Get rid of maven-artifact-transfer from list-classes 
goal

* [MDEP-925] - Require Maven 3.6.3
* [MDEP-939] - Lock down classifier in dependency:sources goal

** Test
* [MDEP-710] - reenable TestTreeMojo

** Task
* [MDEP-912] - Use version for plexus-utils/plexus-xml  from parent
* [MDEP-914] - collect goal description broken in documentation
* [MDEP-918] - Use standard updatePolicy for repositories in ITs
* [MDEP-923] - Code cleanups
* [MDEP-935] - Improvement ITs for dependency:tree
* [MDEP-941] - Deprecate dependency:sources in favor of 
dependency:resolve-sources


** Dependency upgrade
* [MDEP-911] - Bump org.codehaus.plexus:plexus-archiver from 4.8.0 
to 4.9.2

* [MDEP-915] - Upgrade commons-io:commons-io from 2.15.1 to 2.16.1
* [MDEP-920] - Bump org.assertj:assertj-core from 3.24.2 to 3.26.0
* [MDEP-921] - Bump org.apache.commons:commons-text from 1.11.0 to 
1.12.0
* [MDEP-922] - dependency:analyze-exclusions - should report issue 
only in current project
* [MDEP-929] - Bump 
org.apache.maven.shared:maven-dependency-analyzer from 1.13.2 to 1.14.1
* [MDEP-936] - Bump org.apache.maven.shared:maven-dependency-tree 
from 3.2.1 to 3.3.0



Enjoy,

-The Apache Maven team

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

[ANN] Apache Maven Shared Resources, version 6 Released

[Slawomir Jaranowski]

The Maven team is pleased to announce the release of the Apache Maven
Shared Resources, version 6

This is a collection of templates that are specific to the Maven project.

https://maven.apache.org/shared/maven-shared-resources/

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


 org.apache.maven.shared
 maven-shared-resources
 6


Release Notes - Maven Shared Components - Version maven-shared-resources-6

** New Feature
* [MSHARED-1171] - New IntelliJ code style formatter

** Improvement
* [MSHARED-1401] - Refresh checkstyle rules
* [MSHARED-1408] - Refresh IntelliJ formater
* [MSHARED-1409] - Fix site links

** Dependency upgrade
* [MSHARED-1170] - Upgrade Parent to 42
* [MSHARED-1353] - Upgrade parent POM to version 41

Enjoy,
-The Apache Maven team

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

[RESULT] [VOTE] Release Maven Dependency Plugin version 3.7.0

[Michael Osipov]

Hi,

The vote has passed with the following result:

+1: Sylwester Lachiewicz, Michael Osipov, Slawomir Jaranowski

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

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

[ANN] Maven PMD Plugin 3.23.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
PMD Plugin version 3.23.0.


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

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


  org.apache.maven.plugins
  maven-pmd-plugin
  3.23.0



Release Notes - Maven PMD Plugin - Version 3.23.0

** Bug
* [MPMD-395] - Build doesn't fail for invalid CPD format

** Dependency upgrade
* [MPMD-397] - Upgrade to Maven 3.6.3


Enjoy,

-The Apache Maven team

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

[RESULT] [VOTE] Release Apache Maven Shared Resources version 6

[Slawomir Jaranowski]

Hi,

The vote has passed with the following result:

+1: Michael Osipov, Sylwester Lachiewicz, Slawomir Jaranowski

PMC quorum: reached

I will promote the source release zip file to the Apache distribution
area and the artifacts to the central repo.

-- 
Sławomir Jaranowski

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

[RESULT] [VOTE] Release Maven PMD Plugin version 3.23.0

[Michael Osipov]

Hi,

The vote has passed with the following result:

+1: Sylwester Lachiewicz, Michael Osipov, Slawomir Jaranowski

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

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

Re: [VOTE] Release Apache Maven Shared Resources version 6

[Slawomir Jaranowski]

+1

sob., 8 cze 2024 o 11:46 Slawomir Jaranowski 
napisał(a):
>
> Hi,
>
> We solved 6 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12352642
>
> There is still a one issue left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-resources
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2142/
> https://repository.apache.org/content/repositories/maven-2142/org/apache/maven/shared/maven-shared-resources/6/maven-shared-resources-6-source-release.zip
>
> Source release checksum(s):
> maven-shared-resources-6-source-release.zip - SHA-512 :
> fbb52b0c29a5f624dd75dfc62d9ce3d1b91845558d447b9a9f1f25a96451765e25476740d5f5bd05225c54b3784824baf998a25935baf649dce143a9a91c3e99
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-shared-resources-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



-- 
Sławomir Jaranowski

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

Re: [VOTE] Release Maven Dependency Plugin version 3.7.0

[Michael Osipov]

+1

On 2024/06/09 11:08:27 Michael Osipov wrote:
> Hi,
> 
> we solved 30 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12353819
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MDEP/issues
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2144/
> https://repository.apache.org/content/repositories/maven-2144/org/apache/maven/plugins/maven-dependency-plugin/3.7.0/maven-dependency-plugin-3.7.0-source-release.zip
> 
> Source release checksum(s):
> maven-dependency-plugin-3.7.0-source-release.zip
> sha512: 
> 1f0ae13aa70809cc51b5ce8615302defb47ba20f82e1bb72f8a14104d915acf18a5cd62f33a7873e8475066c0b84ce8ec681619613bd96395b844cc82f10b05b
> 
> Staging site:
> https://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> 

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

Re: [VOTE] Release Maven Dependency Plugin version 3.7.0

[Sylwester Lachiewicz]

+1

niedz., 9 cze 2024, 13:08 użytkownik Michael Osipov 
napisał:

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

Re: [VOTE] Release Maven PMD Plugin version 3.23.0

[Sylwester Lachiewicz]

+1

sob., 8 cze 2024, 23:20 użytkownik Michael Osipov 
napisał:

> Am 2024-06-08 um 15:42 schrieb Michael Osipov:
> > Hi,
> >
> > we solved 2 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621=12354616
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPMD%20AND%20resolution%20%3D%20Unresolved
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-2143/
> >
> https://repository.apache.org/content/repositories/maven-2143/org/apache/maven/plugins/maven-pmd-plugin/3.23.0/maven-pmd-plugin-3.23.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-pmd-plugin-3.23.0-source-release.zip
> > sha512:
> >
> 5dd9c95f9f4774606d92e95139cb65f69fbf6fffe9fc59c3c6b28e982b8e2f607082227a6c54c25a8b54e2c14a883fb1b7fd00b90369019bb19cac16f265ebc8
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
>
> +1
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven PMD Plugin version 3.23.0

[Slawomir Jaranowski]

+1

sob., 8 cze 2024 o 15:43 Michael Osipov  napisał(a):
>
> Hi,
>
> we solved 2 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621=12354616
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPMD%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2143/
> https://repository.apache.org/content/repositories/maven-2143/org/apache/maven/plugins/maven-pmd-plugin/3.23.0/maven-pmd-plugin-3.23.0-source-release.zip
>
> Source release checksum(s):
> maven-pmd-plugin-3.23.0-source-release.zip
> sha512:
> 5dd9c95f9f4774606d92e95139cb65f69fbf6fffe9fc59c3c6b28e982b8e2f607082227a6c54c25a8b54e2c14a883fb1b7fd00b90369019bb19cac16f265ebc8
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-pmd-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

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

Re: [VOTE] Release Maven Dependency Plugin version 3.7.0

[Slawomir Jaranowski]

+1

niedz., 9 cze 2024 o 13:08 Michael Osipov  napisał(a):
>
> Hi,
>
> we solved 30 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12353819
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MDEP/issues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2144/
> https://repository.apache.org/content/repositories/maven-2144/org/apache/maven/plugins/maven-dependency-plugin/3.7.0/maven-dependency-plugin-3.7.0-source-release.zip
>
> Source release checksum(s):
> maven-dependency-plugin-3.7.0-source-release.zip
> sha512:
> 1f0ae13aa70809cc51b5ce8615302defb47ba20f82e1bb72f8a14104d915acf18a5cd62f33a7873e8475066c0b84ce8ec681619613bd96395b844cc82f10b05b
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Sławomir Jaranowski

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

JDK 23 Feature Freeze / New Loom EA builds

[David Delabassee]

Welcome to the latest OpenJDK Quality Outreach update!

JDK 23, scheduled for General Availability on September 17, 2024, is now in 
Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature set is 
frozen (see the final list of JEPs integrated into JDK 23 below) and only 
low-risk enhancements might still be considered. The coming weeks should be 
leveraged to identify and resolve as many issues as possible, i.e. before JDK 
23 enters the Release Candidates phase in early August [2]. We count on you to 
test your projects and help us make JDK 23 another solid release!

This time, we are covering several heads-up related to JDK 23 : Deprecate the 
Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation 
processing policy change. Also, make sure to check the new Loom early-access 
builds which have an improved Java monitors implementation to work better with 
virtual threads.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html
[2] https://openjdk.org/projects/jdk/23/


## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe 
for Removal

As mentioned in a previous communication [3], there’s a plan to ultimately 
remove the sun.misc.Unsafe memory-access methods as the platform offers safer 
alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe 
for Removal) [4] outlines in more detail this plan including the initial step 
which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access 
methods are now marked as deprecated for removal. This will cause, in JDK 23, 
compile-time deprecation warnings for code that refers to these methods, 
alerting library developers to their forthcoming removal. A new command-line 
option also enables application developers and users to receive runtime 
warnings when those methods are used.

Developers relying on those sun.misc.Unsafe APIs for access memory are strongly 
encouraged to start, if they haven't done so yet, the migration from the 
sun.misc.Unsafe APIs to supported replacements. For more details, make sure to 
read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for 
Removal).

[3] https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html
[4] https://openjdk.org/jeps/471


## Heads-Up - JDK 23: Changes Default Annotation Processing Policy

Annotation processing is a compile-time feature, where javac scans the 
to-be-compiled source files for annotations and then the class path for 
matching annotation processors, so they can generate source code. Up to JDK 22, 
this feature is enabled by default, which may have been reasonable when it was 
introduced in JDK 6 circa 2006, but from a current perspective, in the interest 
of making build output more robust against annotation processors being placed 
on the class path unintentionally, this is much less reasonable. Hence, 
starting with JDK 23, javac requires an additional command-line option to 
enable annotation processing.

### New `-proc` Value
To that end, the pre-existing option `-proc:$policy` was extended, where 
`$policy` can now have the following values:
- `none`: compilation _without_ annotation processing, this policy exists since 
JDK 6
- `only`: annotation processing _without_ compilation, this policy exists since 
JDK 6
- `full`: annotation processing followed by compilation, this policy is the 
default in JDK ≤22 but the value itself is new (see next section for versions 
that support it)

Up to and including JDK 22, code bases that require annotation processing 
before compilation could rely on javac's default behavior to process 
annotations but that is no longer the case. Starting with JDK 23, at least one 
annotation-processing command line option needs to be present. If neither 
`-processor`, `--processor-path`, now `--processor-module-path` is used, 
`-proc:only` or `-proc:full` has to be provided. In other words, absent other 
command line options, `-proc:none` is the default on JDK 23.

### Migration to `-proc:full`

Several measures were undertaken to help projects prepare for the switch to 
`-proc:full`:
- As of the April 2024 JDK security updates, support for `-proc:full` has been 
backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and OpenJDK 
distributions. Additionally, Oracle's 8u release (8u411) also supports 
`-proc:full`.
- Starting in JDK 21, javac prints an informative message if implicit usage of 
annotation processing under the default policy is detected.

With `-proc:full` backported, it is possible to configure a build that will 
work the same before and after the change in javac's default policy.

Additional details can be found in the original proposal [5].

[5] https://mail.openjdk.org/pipermail/jdk-dev/2024-May/009028.html


## Heads-up - Loom: New EA builds with improved Java monitors implementation to 
work better with virtual threads

Project Loom published new early-access builds [6]. These builds have an 
improved 

Re: Class MC UI trick?

[Gary Gregory]

Yep! TY Tamás!

Gary

On Sun, Jun 9, 2024, 2:14 PM Tamás Cservenák  wrote:

> Maybe
>
> https://search.maven.org/?eh=
>
> ?
>
> On Sun, Jun 9, 2024 at 4:44 PM Jeremy Landis 
> wrote:
>
> > Hey Gary,
> >
> > I agree the new UI is bad.  Its far slower than the old and for those of
> > us that are on there constantly, speed matters.  The new layout is too
> > confusing and trying to find the artifacts from what I've seen requires
> > going into different pages to see and the order sorting is a mess for
> some
> > things like tomcat that take far too long to find what versions.
> >
> > I think the new UI would be far better if it had some of the power usage
> > that the old did.
> >
> > Few observations, there are items that are new that don't show on the old
> > anymore and same goes on new that are showing on old instead.
> >
> > I know initially it gave you a chance to block the redirect.  I think
> that
> > might have gone away or is cached.  Now, I have no issues getting to
> > either.  You might want to try to clear your catch and then try '
> > search.maven.org' again to see if it stays or pops that popup that you
> > can get excluded on the redirect.
> >
> > Due to the mentioned issues, I ended up saving off both and go to either
> > or based on what I'm seeing in those limited cases where things do not
> give
> > well.  I've even opened some tickets at various projects where its messed
> > up but haven't heard any resolution.  Seems the back end data is
> > different...I have however mostly been using latest and just dealing with
> > it.
> >
> > Jeremy
> >
> > -Original Message-
> > From: Gary D. Gregory 
> > Sent: Sunday, June 9, 2024 9:31 AM
> > To: dev@maven.apache.org
> > Subject: Class MC UI trick?
> >
> > Do you have a trick to get the Classic UI for Maven Central?
> >
> > My go to search.maven.org flashes the old UI in Firefix and then
> > redirects to https://central.sonatype.com/?smo=true
> >
> > I really don't like the new UI :( It takes up way to much space for tool
> > little information.
> >
> > Sigh, progress,
> > Gary
> >
> > -
> > 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: Class MC UI trick?

[Tamás Cservenák]

Maybe

https://search.maven.org/?eh=

?

On Sun, Jun 9, 2024 at 4:44 PM Jeremy Landis 
wrote:

> Hey Gary,
>
> I agree the new UI is bad.  Its far slower than the old and for those of
> us that are on there constantly, speed matters.  The new layout is too
> confusing and trying to find the artifacts from what I've seen requires
> going into different pages to see and the order sorting is a mess for some
> things like tomcat that take far too long to find what versions.
>
> I think the new UI would be far better if it had some of the power usage
> that the old did.
>
> Few observations, there are items that are new that don't show on the old
> anymore and same goes on new that are showing on old instead.
>
> I know initially it gave you a chance to block the redirect.  I think that
> might have gone away or is cached.  Now, I have no issues getting to
> either.  You might want to try to clear your catch and then try '
> search.maven.org' again to see if it stays or pops that popup that you
> can get excluded on the redirect.
>
> Due to the mentioned issues, I ended up saving off both and go to either
> or based on what I'm seeing in those limited cases where things do not give
> well.  I've even opened some tickets at various projects where its messed
> up but haven't heard any resolution.  Seems the back end data is
> different...I have however mostly been using latest and just dealing with
> it.
>
> Jeremy
>
> -Original Message-
> From: Gary D. Gregory 
> Sent: Sunday, June 9, 2024 9:31 AM
> To: dev@maven.apache.org
> Subject: Class MC UI trick?
>
> Do you have a trick to get the Classic UI for Maven Central?
>
> My go to search.maven.org flashes the old UI in Firefix and then
> redirects to https://central.sonatype.com/?smo=true
>
> I really don't like the new UI :( It takes up way to much space for tool
> little information.
>
> Sigh, progress,
> Gary
>
> -
> 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: Class MC UI trick?

[Jeremy Landis]

Hey Gary,

I agree the new UI is bad.  Its far slower than the old and for those of us 
that are on there constantly, speed matters.  The new layout is too confusing 
and trying to find the artifacts from what I've seen requires going into 
different pages to see and the order sorting is a mess for some things like 
tomcat that take far too long to find what versions.

I think the new UI would be far better if it had some of the power usage that 
the old did.

Few observations, there are items that are new that don't show on the old 
anymore and same goes on new that are showing on old instead.

I know initially it gave you a chance to block the redirect.  I think that 
might have gone away or is cached.  Now, I have no issues getting to either.  
You might want to try to clear your catch and then try 'search.maven.org' again 
to see if it stays or pops that popup that you can get excluded on the redirect.

Due to the mentioned issues, I ended up saving off both and go to either or 
based on what I'm seeing in those limited cases where things do not give well.  
I've even opened some tickets at various projects where its messed up but 
haven't heard any resolution.  Seems the back end data is different...I have 
however mostly been using latest and just dealing with it.

Jeremy

-Original Message-
From: Gary D. Gregory 
Sent: Sunday, June 9, 2024 9:31 AM
To: dev@maven.apache.org
Subject: Class MC UI trick?

Do you have a trick to get the Classic UI for Maven Central?

My go to search.maven.org flashes the old UI in Firefix and then redirects to 
https://central.sonatype.com/?smo=true

I really don't like the new UI :( It takes up way to much space for tool little 
information.

Sigh, progress,
Gary

-
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

Class MC UI trick?

[Gary D. Gregory]

Do you have a trick to get the Classic UI for Maven Central?

My go to search.maven.org flashes the old UI in Firefix and then redirects to 
https://central.sonatype.com/?smo=true 

I really don't like the new UI :( It takes up way to much space for tool little 
information.

Sigh, progress,
Gary

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

[VOTE] Release Maven Dependency Plugin version 3.7.0

[Michael Osipov]

Hi,

we solved 30 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317227=12353819

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/projects/MDEP/issues

Staging repo:
https://repository.apache.org/content/repositories/maven-2144/
https://repository.apache.org/content/repositories/maven-2144/org/apache/maven/plugins/maven-dependency-plugin/3.7.0/maven-dependency-plugin-3.7.0-source-release.zip

Source release checksum(s):
maven-dependency-plugin-3.7.0-source-release.zip
sha512: 
1f0ae13aa70809cc51b5ce8615302defb47ba20f82e1bb72f8a14104d915acf18a5cd62f33a7873e8475066c0b84ce8ec681619613bd96395b844cc82f10b05b


Staging site:
https://maven.apache.org/plugins-archives/maven-dependency-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

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

Re: [VOTE] Release Maven PMD Plugin version 3.23.0

[Michael Osipov]

Am 2024-06-08 um 15:42 schrieb Michael Osipov:

Hi,

we solved 2 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621=12354616

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPMD%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-2143/
https://repository.apache.org/content/repositories/maven-2143/org/apache/maven/plugins/maven-pmd-plugin/3.23.0/maven-pmd-plugin-3.23.0-source-release.zip

Source release checksum(s):
maven-pmd-plugin-3.23.0-source-release.zip
sha512: 
5dd9c95f9f4774606d92e95139cb65f69fbf6fffe9fc59c3c6b28e982b8e2f607082227a6c54c25a8b54e2c14a883fb1b7fd00b90369019bb19cac16f265ebc8


Staging site:
https://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.


+1


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

Re: [VOTE] Release Apache Maven Shared Resources version 6

[Sylwester Lachiewicz]

+1

sob., 8 cze 2024, 15:30 użytkownik Michael Osipov 
napisał:

> Am 2024-06-08 um 11:46 schrieb Slawomir Jaranowski:
> > Hi,
> >
> > We solved 6 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12352642
> >
> > There is still a one issue left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-resources
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-2142/
> >
> https://repository.apache.org/content/repositories/maven-2142/org/apache/maven/shared/maven-shared-resources/6/maven-shared-resources-6-source-release.zip
> >
> > Source release checksum(s):
> > maven-shared-resources-6-source-release.zip - SHA-512 :
> >
> fbb52b0c29a5f624dd75dfc62d9ce3d1b91845558d447b9a9f1f25a96451765e25476740d5f5bd05225c54b3784824baf998a25935baf649dce143a9a91c3e99
> >
> > Staging site:
> > https://maven.apache.org/shared-archives/maven-shared-resources-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
>
> +1
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[VOTE] Release Maven PMD Plugin version 3.23.0

[Michael Osipov]

Hi,

we solved 2 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621=12354616

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPMD%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-2143/
https://repository.apache.org/content/repositories/maven-2143/org/apache/maven/plugins/maven-pmd-plugin/3.23.0/maven-pmd-plugin-3.23.0-source-release.zip

Source release checksum(s):
maven-pmd-plugin-3.23.0-source-release.zip
sha512: 
5dd9c95f9f4774606d92e95139cb65f69fbf6fffe9fc59c3c6b28e982b8e2f607082227a6c54c25a8b54e2c14a883fb1b7fd00b90369019bb19cac16f265ebc8


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

[ANN] Apache Maven Common Artifact Filters 3.4.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Common Artifact Filters version 3.4.0.


https://maven.apache.org/shared/maven-common-artifact-filters/


Release Notes - Maven Shared Components - Version 
maven-common-artifact-filters-3.4.0


** Bug
* [MSHARED-1300] - Order of dependencies is not always retained 
when filtering


** Improvement
* [MSHARED-1303] - Declare and undeclare used and unused dependencies

** Dependency upgrade
* [MSHARED-1301] - Upgrade to Parent 42 and Maven 3.6.3
* [MSHARED-1302] - commons-io to 2.13.0


Enjoy,

-The Apache Maven team

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

[RESULT] [VOTE] Release Apache Maven Common Artifact Filters version 3.4.0

[Michael Osipov]

Hi,

The vote has passed with the following result:

+1: Sylwester Lachiewicz, Tamás Cservenák, Michael Osipov, Slawomir 
Jaranowski


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 Apache Maven Shared Resources version 6

[Michael Osipov]

Am 2024-06-08 um 11:46 schrieb Slawomir Jaranowski:

Hi,

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

There is still a one issue left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-resources

Staging repo:
https://repository.apache.org/content/repositories/maven-2142/
https://repository.apache.org/content/repositories/maven-2142/org/apache/maven/shared/maven-shared-resources/6/maven-shared-resources-6-source-release.zip

Source release checksum(s):
maven-shared-resources-6-source-release.zip - SHA-512 :
fbb52b0c29a5f624dd75dfc62d9ce3d1b91845558d447b9a9f1f25a96451765e25476740d5f5bd05225c54b3784824baf998a25935baf649dce143a9a91c3e99

Staging site:
https://maven.apache.org/shared-archives/maven-shared-resources-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.


+1


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

[VOTE] Release Apache Maven Shared Resources version 6

[Slawomir Jaranowski]

Hi,

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

There is still a one issue left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-resources

Staging repo:
https://repository.apache.org/content/repositories/maven-2142/
https://repository.apache.org/content/repositories/maven-2142/org/apache/maven/shared/maven-shared-resources/6/maven-shared-resources-6-source-release.zip

Source release checksum(s):
maven-shared-resources-6-source-release.zip - SHA-512 :
fbb52b0c29a5f624dd75dfc62d9ce3d1b91845558d447b9a9f1f25a96451765e25476740d5f5bd05225c54b3784824baf998a25935baf649dce143a9a91c3e99

Staging site:
https://maven.apache.org/shared-archives/maven-shared-resources-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: [VOTE] Release Apache Maven Common Artifact Filters version 3.4.0

[Tamás Cservenák]

+1

On Wed, Jun 5, 2024, 16:48 Michael Osipov  wrote:

> Hi,
>
> we solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12352304
>
> There are no 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-common-artifact-filters
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2141/
>
> https://repository.apache.org/content/repositories/maven-2141/org/apache/maven/shared/maven-common-artifact-filters/3.4.0/maven-common-artifact-filters-3.4.0-source-release.zip
>
> Source release checksum(s):
> maven-common-artifact-filters-3.4.0-source-release.zip
> sha512:
>
> f036fda620f26397ab863ecf4ada93f2c314690bb4ee08efc3af6ab66e2a2bcebfb0c6655e317723375b754b202410d19ca9c015caaa068bc2ab07f9b858b14d
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-filtering-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Common Artifact Filters version 3.4.0

[Sylwester Lachiewicz]

+1

pt., 7 cze 2024, 10:53 użytkownik Slawomir Jaranowski <
s.jaranow...@gmail.com> napisał:

> +1
>
> śr., 5 cze 2024 o 16:48 Michael Osipov  napisał(a):
> >
> > Hi,
> >
> > we solved 3 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12352304
> >
> > There are no 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-common-artifact-filters
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-2141/
> >
> https://repository.apache.org/content/repositories/maven-2141/org/apache/maven/shared/maven-common-artifact-filters/3.4.0/maven-common-artifact-filters-3.4.0-source-release.zip
> >
> > Source release checksum(s):
> > maven-common-artifact-filters-3.4.0-source-release.zip
> > sha512:
> >
> f036fda620f26397ab863ecf4ada93f2c314690bb4ee08efc3af6ab66e2a2bcebfb0c6655e317723375b754b202410d19ca9c015caaa068bc2ab07f9b858b14d
> >
> > Staging site:
> > https://maven.apache.org/shared-archives/maven-filtering-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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Common Artifact Filters version 3.4.0

[Slawomir Jaranowski]

+1

śr., 5 cze 2024 o 16:48 Michael Osipov  napisał(a):
>
> Hi,
>
> we solved 3 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12352304
>
> There are no 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-common-artifact-filters
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-2141/
> https://repository.apache.org/content/repositories/maven-2141/org/apache/maven/shared/maven-common-artifact-filters/3.4.0/maven-common-artifact-filters-3.4.0-source-release.zip
>
> Source release checksum(s):
> maven-common-artifact-filters-3.4.0-source-release.zip
> sha512:
> f036fda620f26397ab863ecf4ada93f2c314690bb4ee08efc3af6ab66e2a2bcebfb0c6655e317723375b754b202410d19ca9c015caaa068bc2ab07f9b858b14d
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-filtering-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

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

Re: [VOTE] Release Apache Maven Common Artifact Filters version 3.4.0

[Michael Osipov]

Am 2024-06-05 um 16:47 schrieb Michael Osipov:

Hi,

we solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12352304

There are no 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-common-artifact-filters

Staging repo:
https://repository.apache.org/content/repositories/maven-2141/
https://repository.apache.org/content/repositories/maven-2141/org/apache/maven/shared/maven-common-artifact-filters/3.4.0/maven-common-artifact-filters-3.4.0-source-release.zip

Source release checksum(s):
maven-common-artifact-filters-3.4.0-source-release.zip
sha512: 
f036fda620f26397ab863ecf4ada93f2c314690bb4ee08efc3af6ab66e2a2bcebfb0c6655e317723375b754b202410d19ca9c015caaa068bc2ab07f9b858b14d


Staging site:
https://maven.apache.org/shared-archives/maven-filtering-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.


+1


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

[HEADS UP] Maven 3.9.8 is scheduled for release (mvnd m39 will wait for it)

[Tamás Cservenák]

Howdy,

Just a quick heads up:

Maven 3.9.8 release will happen soon(ish) with some important bug fixes and
improvements that were discovered since 3.9.7. See scheduled issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.8

Maven mvnd m39 was prepped with 3.9.7, but will wait for 3.9.8 to pick up
the latest Sisu and other fixes.

As usual, if anyone has anything to add, please let me know.

Thanks
T

[ANN] Release Maven Help Plugin 3.4.1 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Help Plugin version 3.4.1.


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

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


  org.apache.maven.plugins
  maven-help-plugin
  3.4.1



Release Notes - Maven Help Plugin - Version 3.4.1

** Test
* [MPH-207] - Exercise output of an expression returning a null object.

** Dependency upgrade
* [MPH-211] - Upgrade maven-plugin parent to 41
* [MPH-213] - Upgrade org.codehaus.plexus:plexus-interactivity-api 
from 1.3

* [MPH-214] - Upgrade to Parent 42


Enjoy,

-The Apache Maven team

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

[ANN] Maven Checkstyle Plugin 3.4.0 released

[Michael Osipov]

The Apache Maven team is pleased to announce the release of the Maven 
Checkstyle Plugin, version 3.4.0.


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

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


  org.apache.maven.plugins
  >maven-checkstyle-plugin
  3.4.0



Release Notes - Maven Checkstyle Plugin - Version 3.4.0

** Bug
* [MCHECKSTYLE-450] - Checkstyle rule link format results in 404

** New Feature
* [MCHECKSTYLE-449] - Add support for SARIF output format

** Dependency upgrade
* [MCHECKSTYLE-443] - Upgrade to Parent 41
* [MCHECKSTYLE-447] - Upgrade org.codehaus.plexus:plexus-resources 
to 1.3.0

* [MCHECKSTYLE-448] - Upgrade to Parent 42 and Maven 3.6.3


Enjoy,

-The Apache Maven team

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

[VOTE] Release Apache Maven Common Artifact Filters version 3.4.0

[Michael Osipov]

Hi,

we solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12352304

There are no 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-common-artifact-filters

Staging repo:
https://repository.apache.org/content/repositories/maven-2141/
https://repository.apache.org/content/repositories/maven-2141/org/apache/maven/shared/maven-common-artifact-filters/3.4.0/maven-common-artifact-filters-3.4.0-source-release.zip

Source release checksum(s):
maven-common-artifact-filters-3.4.0-source-release.zip
sha512: 
f036fda620f26397ab863ecf4ada93f2c314690bb4ee08efc3af6ab66e2a2bcebfb0c6655e317723375b754b202410d19ca9c015caaa068bc2ab07f9b858b14d


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

[RESULT] [VOTE] Release Maven Help Plugin version 3.4.1

[Michael Osipov]

Hi,

The vote has passed with the following result:

+1: Michael Osipov, Hervé Boutemy, Slawomir Jaranowski, Sylwester 
Lachiewicz, Olivier Lamy


PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

[RESULT] [VOTE] Release Maven Checkstyle Plugin version 3.4.0

[Michael Osipov]

Hi,

The vote has passed with the following result:

+1: Slawomir Jaranowski, Hervé Boutemy, Michael Osipov, Sylwester Lachiewicz

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP 
file

and add this release the board report.

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

Re: [VOTE] Release Maven Help Plugin version 3.4.1

[Michael Osipov]

Am 2024-06-02 um 17:56 schrieb Slawomir Jaranowski:

+1

We should categorize updating parents in the same way ... once we have
Improvement and once as Dependency upgrade


Right, for me personally, this is not necessarily an improvement, but 
upgrade deps because this is what happens. No funtionctional code change 
(in theory).



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

Re: [VOTE] Release Maven Help Plugin version 3.4.1

[Michael Osipov]

Am 2024-06-02 um 17:20 schrieb Michael Osipov:

Hi,

we solved 4 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317522=12353019

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPH%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-2140/
https://repository.apache.org/content/repositories/maven-2140/org/apache/maven/plugins/maven-help-plugin/3.4.1/maven-help-plugin-3.4.1-source-release.zip

Source release checksum(s):
maven-help-plugin-3.4.1-source-release.zip
sha512: 
a7d2f508086813e7104b3b49640e33897f48581991957727c86df82243e2cf1ad0d63021db9a8f948548db5dcabed1e2618604827a316ebb1122da1d55f0f766


Staging site:
https://maven.apache.org/plugins-archives/maven-help-plugin-LATEST/

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.


+1


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