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 <rmannibu...@gmail.com>
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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <
https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<
https://www.packtpub.com/application-development/java-ee-8-high-performance
Le ven. 14 juin 2024 à 21:04, Tamás Cservenák <ta...@cservenak.net> 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 <ta...@cservenak.net>
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 <mthmuld...@apache.org
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 <garydgreg...@gmail.com>
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 <
ta...@cservenak.net>
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
