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
+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
@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.
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
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.
Bac
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...@
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.
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 Fr
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 t
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.
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
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 param
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.
>
>
>
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 defau
+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
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
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
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 unders
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 d
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 happen
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 mea
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
22 matches
Mail list logo
