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

2024-06-15 Thread 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: [DISCUSS] Maven should ALWAYS install/deploy at end

2024-06-15 Thread 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 "toge

Re: [VOTE] Release Apache Maven mvnd 1.0.0

2024-06-15 Thread 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: [VOTE] Release Apache Maven 3.9.8

2024-06-15 Thread 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&version=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