@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 <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:45, Tamás Cservenák <ta...@cservenak.net> 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 <ta...@cservenak.net>:
> > >
> > > 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 <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
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>
> > >> GF Kemal Soysal
> > >>
> > >> __________________________
> > >> Kemal Soysal
> > >> LS IT-Solutions GmbH
> > >> kemal.soy...@ls-it-solutions.de
> > >> Mobil: +49 1512 404 55 66
> > >> Thomas-Mann-Str.21
> > >> 44141 Dortmund
> > >>
> > >>
> >
> > GF Kemal Soysal
> >
> > __________________________
> > Kemal Soysal
> > LS IT-Solutions GmbH
> > kemal.soy...@ls-it-solutions.de
> > Mobil: +49 1512 404 55 66
> > Thomas-Mann-Str.21
> > 44141 Dortmund
> >
> >
>
