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