You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Tamás Cservenák <ta...@cservenak.net> on 2022/11/11 22:32:49 UTC
mvn install vs mvn verify
Howdy,
in relation to this PR (the reasoning behind it):
https://github.com/apache/maven-mvnd/pull/734
I never really understood people unconditionally forcing verify instead of
install.
For me, personally, the "final output" of the build was always what it
installs.
While we do call internally the target directory as "buildOutput", it is
more like "build temp", full of intermediate files, class files, temp
files, state files, and who knows what. To find the final output in target
you need to dig in, sift through files and/or directories (possibly needing
knowledge even how some plugin is configured, or worse, working).
In the local repository, it's all on coordinates: just check the POM GAV
you built, no need for any other knowledge (of plugin, of config or
whatever). Clear as it can be.
And ultimately, a Maven project's ultimate dream goal is to be deployed,
and what is installed, pretty much (most often) will be the same as will be
deployed. Again, win-win.
Finally, to me this feels like it is being pushed by people who "stick" to
their local repository a bit too much :) For them, there is a "split local
repository" feature, where installed and cached stuff is clearly separated
(and hence, easy to nuke).
Or in other words, I stick to the mantra "what is not in a (local or
remote) repo, does not exist (for Maven)". And most often you do want to
reuse (depend on) the project being built, hence "sharing" (installing for
local dev or deploy for remote dev) is wanted.
I see verify being better for trivial cases, like you work on a simple
(single or multi module) project, with a trivial (known to behave) set of
plugins. But in a moment when you work on two or more interconnected
projects, or non trivial projects, or just using some "nasty" plugin that
for some reason tries to resolve things and is unaware of the project, etc,
mvn verify quickly becomes a problem.
WDYT?
Thanks
T
Re: mvn install vs mvn verify
Posted by Delany <de...@gmail.com>.
You can miss a dep, but there's an enforcer rule to make sure you don't
https://maven.apache.org/enforcer/enforcer-rules/reactorModuleConvergence.html
My pain is having to always `clean install` because of an MCOMPILER bug
affecting just one module, and by extension all of them.
I wont mention which bug - suffice to say there are such edge cases.
Delany
On Thu, 17 Nov 2022 at 21:01, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le jeu. 17 nov. 2022 à 19:16, Arnaud Héritier <ah...@gmail.com> a
> écrit :
>
> > install is a source of issues if you are in a multi-module project, you
> > switch between branches and do not rebuild everything (because in general
> > you still have the same coordinates between branches).
> > In such case you can have binaries in m2 with one branch and rebuild some
> > others modules partially in your project using these artifacts in another
> > branch.
> > I don't know how frequent can be this kind of issue, I tried myself to
> stay
> > far from multi-modules as much as possible.
> >
>
> Isnt verify the same since in a multimodule you can't just build a
> submodule without missing a dep? Depends how you work on the project IMHO,
> but building from the root a multimodule is not the unique way to work with
> big projects (on very big project opening only submodule saves your time!)
> so guess both options have pro and cons and should be used as needed but
> enforce an understading of your commands as usual.
>
>
>
> >
> > On Thu, Nov 17, 2022 at 9:17 AM Tamás Cservenák <ta...@cservenak.net>
> > wrote:
> >
> > > Here it is described:
> > >
> > >
> >
> https://maven.apache.org/resolver-archives/resolver-LATEST/local-repository.html#use-cases
> > >
> > > Also, sorry for typo Guillaume ;)
> > >
> > > T
> > >
> > > On Thu, Nov 17, 2022 at 9:15 AM Tamás Cservenák <ta...@cservenak.net>
> > > wrote:
> > >
> > > > ...aaand this is where "workspace" feature of split repo comes in
> > play...
> > > > oh Guillable, you already said it :D
> > > >
> > > > T
> > > >
> > > > On Thu, Nov 17, 2022 at 9:01 AM Guillaume Nodet <gn...@apache.org>
> > > wrote:
> > > >
> > > >> That's specifically an area I've tried to improve over the past
> > months.
> > > >> Most plugins should avoid touching any output file if the content
> has
> > > not
> > > >> changed. Things have improved a bit, and with a bit of tuning, none
> > of
> > > >> the
> > > >> jars is actually touched during a rebuild.
> > > >> Also, the build cache extension will definitely help with those use
> > > cases.
> > > >>
> > > >> Anyway, one downside to the install is that if you're working on a
> > > custom
> > > >> branch, or even have checkout a tag, you kinda put in your local
> repo
> > > >> artifacts that you have no real control on.
> > > >> With the upcoming resolver new features, the separation of locally
> > built
> > > >> artifacts and artifacts from remote repositories will help cleaning
> > that
> > > >> stuff.
> > > >>
> > > >> Le jeu. 17 nov. 2022, 07:21, Olivier Lamy <ol...@apache.org> a
> écrit
> > :
> > > >>
> > > >> > Agree not sure why such "marketing buzz around this" as the idea
> is
> > to
> > > >> > share artifacts so they need to be installed or deployed.
> > > >> > The only issue I can see with install vs verify is the compilation
> > of
> > > >> > everything all the time.
> > > >> > because m-compiler-p detects a new artifact of a module in the
> > reactor
> > > >> > and so the m-compiler-p decides to recompile everything (because
> the
> > > >> > jar is newer than build start time).
> > > >> > I have some work locally but I still need to push the branch.
> > > >> > On very large projects (e.g lot of modules) it makes a significant
> > > >> > difference.
> > > >> > with install you will see "Changes detected - recompiling the
> > module!"
> > > >> > whereas it's totally wrong (nothing has changed)
> > > >> > Maven core is even worse as well because of modello re generation
> > even
> > > >> > if no changes.
> > > >> > it's definitely something here to improve (a sort of api where
> > plugins
> > > >> > can tell there is some changes or not)
> > > >> >
> > > >> > On Sat, 12 Nov 2022 at 08:33, Tamás Cservenák <
> tamas@cservenak.net>
> > > >> wrote:
> > > >> > >
> > > >> > > Howdy,
> > > >> > >
> > > >> > > in relation to this PR (the reasoning behind it):
> > > >> > > https://github.com/apache/maven-mvnd/pull/734
> > > >> > >
> > > >> > > I never really understood people unconditionally forcing verify
> > > >> instead
> > > >> > of
> > > >> > > install.
> > > >> > >
> > > >> > > For me, personally, the "final output" of the build was always
> > what
> > > it
> > > >> > > installs.
> > > >> > >
> > > >> > > While we do call internally the target directory as
> "buildOutput",
> > > it
> > > >> is
> > > >> > > more like "build temp", full of intermediate files, class files,
> > > temp
> > > >> > > files, state files, and who knows what. To find the final output
> > in
> > > >> > target
> > > >> > > you need to dig in, sift through files and/or directories
> > (possibly
> > > >> > needing
> > > >> > > knowledge even how some plugin is configured, or worse,
> working).
> > > >> > >
> > > >> > > In the local repository, it's all on coordinates: just check the
> > POM
> > > >> GAV
> > > >> > > you built, no need for any other knowledge (of plugin, of config
> > or
> > > >> > > whatever). Clear as it can be.
> > > >> > >
> > > >> > > And ultimately, a Maven project's ultimate dream goal is to be
> > > >> deployed,
> > > >> > > and what is installed, pretty much (most often) will be the same
> > as
> > > >> will
> > > >> > be
> > > >> > > deployed. Again, win-win.
> > > >> > >
> > > >> > > Finally, to me this feels like it is being pushed by people who
> > > >> "stick"
> > > >> > to
> > > >> > > their local repository a bit too much :) For them, there is a
> > "split
> > > >> > local
> > > >> > > repository" feature, where installed and cached stuff is clearly
> > > >> > separated
> > > >> > > (and hence, easy to nuke).
> > > >> > >
> > > >> > > Or in other words, I stick to the mantra "what is not in a
> (local
> > or
> > > >> > > remote) repo, does not exist (for Maven)". And most often you do
> > > want
> > > >> to
> > > >> > > reuse (depend on) the project being built, hence "sharing"
> > > (installing
> > > >> > for
> > > >> > > local dev or deploy for remote dev) is wanted.
> > > >> > >
> > > >> > > I see verify being better for trivial cases, like you work on a
> > > simple
> > > >> > > (single or multi module) project, with a trivial (known to
> behave)
> > > >> set of
> > > >> > > plugins. But in a moment when you work on two or more
> > interconnected
> > > >> > > projects, or non trivial projects, or just using some "nasty"
> > plugin
> > > >> that
> > > >> > > for some reason tries to resolve things and is unaware of the
> > > project,
> > > >> > etc,
> > > >> > > mvn verify quickly becomes a problem.
> > > >> > >
> > > >> > > WDYT?
> > > >> > >
> > > >> > > Thanks
> > > >> > > T
> > > >> >
> > > >> >
> > ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >> > For additional commands, e-mail: dev-help@maven.apache.org
> > > >> >
> > > >> >
> > > >>
> > > >
> > >
> >
> >
> > --
> > Arnaud Héritier
> > Twitter/GitHub/... : aheritier
> >
>
Re: mvn install vs mvn verify
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 17 nov. 2022 à 19:16, Arnaud Héritier <ah...@gmail.com> a
écrit :
> install is a source of issues if you are in a multi-module project, you
> switch between branches and do not rebuild everything (because in general
> you still have the same coordinates between branches).
> In such case you can have binaries in m2 with one branch and rebuild some
> others modules partially in your project using these artifacts in another
> branch.
> I don't know how frequent can be this kind of issue, I tried myself to stay
> far from multi-modules as much as possible.
>
Isnt verify the same since in a multimodule you can't just build a
submodule without missing a dep? Depends how you work on the project IMHO,
but building from the root a multimodule is not the unique way to work with
big projects (on very big project opening only submodule saves your time!)
so guess both options have pro and cons and should be used as needed but
enforce an understading of your commands as usual.
>
> On Thu, Nov 17, 2022 at 9:17 AM Tamás Cservenák <ta...@cservenak.net>
> wrote:
>
> > Here it is described:
> >
> >
> https://maven.apache.org/resolver-archives/resolver-LATEST/local-repository.html#use-cases
> >
> > Also, sorry for typo Guillaume ;)
> >
> > T
> >
> > On Thu, Nov 17, 2022 at 9:15 AM Tamás Cservenák <ta...@cservenak.net>
> > wrote:
> >
> > > ...aaand this is where "workspace" feature of split repo comes in
> play...
> > > oh Guillable, you already said it :D
> > >
> > > T
> > >
> > > On Thu, Nov 17, 2022 at 9:01 AM Guillaume Nodet <gn...@apache.org>
> > wrote:
> > >
> > >> That's specifically an area I've tried to improve over the past
> months.
> > >> Most plugins should avoid touching any output file if the content has
> > not
> > >> changed. Things have improved a bit, and with a bit of tuning, none
> of
> > >> the
> > >> jars is actually touched during a rebuild.
> > >> Also, the build cache extension will definitely help with those use
> > cases.
> > >>
> > >> Anyway, one downside to the install is that if you're working on a
> > custom
> > >> branch, or even have checkout a tag, you kinda put in your local repo
> > >> artifacts that you have no real control on.
> > >> With the upcoming resolver new features, the separation of locally
> built
> > >> artifacts and artifacts from remote repositories will help cleaning
> that
> > >> stuff.
> > >>
> > >> Le jeu. 17 nov. 2022, 07:21, Olivier Lamy <ol...@apache.org> a écrit
> :
> > >>
> > >> > Agree not sure why such "marketing buzz around this" as the idea is
> to
> > >> > share artifacts so they need to be installed or deployed.
> > >> > The only issue I can see with install vs verify is the compilation
> of
> > >> > everything all the time.
> > >> > because m-compiler-p detects a new artifact of a module in the
> reactor
> > >> > and so the m-compiler-p decides to recompile everything (because the
> > >> > jar is newer than build start time).
> > >> > I have some work locally but I still need to push the branch.
> > >> > On very large projects (e.g lot of modules) it makes a significant
> > >> > difference.
> > >> > with install you will see "Changes detected - recompiling the
> module!"
> > >> > whereas it's totally wrong (nothing has changed)
> > >> > Maven core is even worse as well because of modello re generation
> even
> > >> > if no changes.
> > >> > it's definitely something here to improve (a sort of api where
> plugins
> > >> > can tell there is some changes or not)
> > >> >
> > >> > On Sat, 12 Nov 2022 at 08:33, Tamás Cservenák <ta...@cservenak.net>
> > >> wrote:
> > >> > >
> > >> > > Howdy,
> > >> > >
> > >> > > in relation to this PR (the reasoning behind it):
> > >> > > https://github.com/apache/maven-mvnd/pull/734
> > >> > >
> > >> > > I never really understood people unconditionally forcing verify
> > >> instead
> > >> > of
> > >> > > install.
> > >> > >
> > >> > > For me, personally, the "final output" of the build was always
> what
> > it
> > >> > > installs.
> > >> > >
> > >> > > While we do call internally the target directory as "buildOutput",
> > it
> > >> is
> > >> > > more like "build temp", full of intermediate files, class files,
> > temp
> > >> > > files, state files, and who knows what. To find the final output
> in
> > >> > target
> > >> > > you need to dig in, sift through files and/or directories
> (possibly
> > >> > needing
> > >> > > knowledge even how some plugin is configured, or worse, working).
> > >> > >
> > >> > > In the local repository, it's all on coordinates: just check the
> POM
> > >> GAV
> > >> > > you built, no need for any other knowledge (of plugin, of config
> or
> > >> > > whatever). Clear as it can be.
> > >> > >
> > >> > > And ultimately, a Maven project's ultimate dream goal is to be
> > >> deployed,
> > >> > > and what is installed, pretty much (most often) will be the same
> as
> > >> will
> > >> > be
> > >> > > deployed. Again, win-win.
> > >> > >
> > >> > > Finally, to me this feels like it is being pushed by people who
> > >> "stick"
> > >> > to
> > >> > > their local repository a bit too much :) For them, there is a
> "split
> > >> > local
> > >> > > repository" feature, where installed and cached stuff is clearly
> > >> > separated
> > >> > > (and hence, easy to nuke).
> > >> > >
> > >> > > Or in other words, I stick to the mantra "what is not in a (local
> or
> > >> > > remote) repo, does not exist (for Maven)". And most often you do
> > want
> > >> to
> > >> > > reuse (depend on) the project being built, hence "sharing"
> > (installing
> > >> > for
> > >> > > local dev or deploy for remote dev) is wanted.
> > >> > >
> > >> > > I see verify being better for trivial cases, like you work on a
> > simple
> > >> > > (single or multi module) project, with a trivial (known to behave)
> > >> set of
> > >> > > plugins. But in a moment when you work on two or more
> interconnected
> > >> > > projects, or non trivial projects, or just using some "nasty"
> plugin
> > >> that
> > >> > > for some reason tries to resolve things and is unaware of the
> > project,
> > >> > etc,
> > >> > > mvn verify quickly becomes a problem.
> > >> > >
> > >> > > WDYT?
> > >> > >
> > >> > > Thanks
> > >> > > T
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> > For additional commands, e-mail: dev-help@maven.apache.org
> > >> >
> > >> >
> > >>
> > >
> >
>
>
> --
> Arnaud Héritier
> Twitter/GitHub/... : aheritier
>
Re: mvn install vs mvn verify
Posted by Arnaud Héritier <ah...@gmail.com>.
install is a source of issues if you are in a multi-module project, you
switch between branches and do not rebuild everything (because in general
you still have the same coordinates between branches).
In such case you can have binaries in m2 with one branch and rebuild some
others modules partially in your project using these artifacts in another
branch.
I don't know how frequent can be this kind of issue, I tried myself to stay
far from multi-modules as much as possible.
On Thu, Nov 17, 2022 at 9:17 AM Tamás Cservenák <ta...@cservenak.net> wrote:
> Here it is described:
>
> https://maven.apache.org/resolver-archives/resolver-LATEST/local-repository.html#use-cases
>
> Also, sorry for typo Guillaume ;)
>
> T
>
> On Thu, Nov 17, 2022 at 9:15 AM Tamás Cservenák <ta...@cservenak.net>
> wrote:
>
> > ...aaand this is where "workspace" feature of split repo comes in play...
> > oh Guillable, you already said it :D
> >
> > T
> >
> > On Thu, Nov 17, 2022 at 9:01 AM Guillaume Nodet <gn...@apache.org>
> wrote:
> >
> >> That's specifically an area I've tried to improve over the past months.
> >> Most plugins should avoid touching any output file if the content has
> not
> >> changed. Things have improved a bit, and with a bit of tuning, none of
> >> the
> >> jars is actually touched during a rebuild.
> >> Also, the build cache extension will definitely help with those use
> cases.
> >>
> >> Anyway, one downside to the install is that if you're working on a
> custom
> >> branch, or even have checkout a tag, you kinda put in your local repo
> >> artifacts that you have no real control on.
> >> With the upcoming resolver new features, the separation of locally built
> >> artifacts and artifacts from remote repositories will help cleaning that
> >> stuff.
> >>
> >> Le jeu. 17 nov. 2022, 07:21, Olivier Lamy <ol...@apache.org> a écrit :
> >>
> >> > Agree not sure why such "marketing buzz around this" as the idea is to
> >> > share artifacts so they need to be installed or deployed.
> >> > The only issue I can see with install vs verify is the compilation of
> >> > everything all the time.
> >> > because m-compiler-p detects a new artifact of a module in the reactor
> >> > and so the m-compiler-p decides to recompile everything (because the
> >> > jar is newer than build start time).
> >> > I have some work locally but I still need to push the branch.
> >> > On very large projects (e.g lot of modules) it makes a significant
> >> > difference.
> >> > with install you will see "Changes detected - recompiling the module!"
> >> > whereas it's totally wrong (nothing has changed)
> >> > Maven core is even worse as well because of modello re generation even
> >> > if no changes.
> >> > it's definitely something here to improve (a sort of api where plugins
> >> > can tell there is some changes or not)
> >> >
> >> > On Sat, 12 Nov 2022 at 08:33, Tamás Cservenák <ta...@cservenak.net>
> >> wrote:
> >> > >
> >> > > Howdy,
> >> > >
> >> > > in relation to this PR (the reasoning behind it):
> >> > > https://github.com/apache/maven-mvnd/pull/734
> >> > >
> >> > > I never really understood people unconditionally forcing verify
> >> instead
> >> > of
> >> > > install.
> >> > >
> >> > > For me, personally, the "final output" of the build was always what
> it
> >> > > installs.
> >> > >
> >> > > While we do call internally the target directory as "buildOutput",
> it
> >> is
> >> > > more like "build temp", full of intermediate files, class files,
> temp
> >> > > files, state files, and who knows what. To find the final output in
> >> > target
> >> > > you need to dig in, sift through files and/or directories (possibly
> >> > needing
> >> > > knowledge even how some plugin is configured, or worse, working).
> >> > >
> >> > > In the local repository, it's all on coordinates: just check the POM
> >> GAV
> >> > > you built, no need for any other knowledge (of plugin, of config or
> >> > > whatever). Clear as it can be.
> >> > >
> >> > > And ultimately, a Maven project's ultimate dream goal is to be
> >> deployed,
> >> > > and what is installed, pretty much (most often) will be the same as
> >> will
> >> > be
> >> > > deployed. Again, win-win.
> >> > >
> >> > > Finally, to me this feels like it is being pushed by people who
> >> "stick"
> >> > to
> >> > > their local repository a bit too much :) For them, there is a "split
> >> > local
> >> > > repository" feature, where installed and cached stuff is clearly
> >> > separated
> >> > > (and hence, easy to nuke).
> >> > >
> >> > > Or in other words, I stick to the mantra "what is not in a (local or
> >> > > remote) repo, does not exist (for Maven)". And most often you do
> want
> >> to
> >> > > reuse (depend on) the project being built, hence "sharing"
> (installing
> >> > for
> >> > > local dev or deploy for remote dev) is wanted.
> >> > >
> >> > > I see verify being better for trivial cases, like you work on a
> simple
> >> > > (single or multi module) project, with a trivial (known to behave)
> >> set of
> >> > > plugins. But in a moment when you work on two or more interconnected
> >> > > projects, or non trivial projects, or just using some "nasty" plugin
> >> that
> >> > > for some reason tries to resolve things and is unaware of the
> project,
> >> > etc,
> >> > > mvn verify quickly becomes a problem.
> >> > >
> >> > > WDYT?
> >> > >
> >> > > Thanks
> >> > > T
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >> >
> >>
> >
>
--
Arnaud Héritier
Twitter/GitHub/... : aheritier
Re: mvn install vs mvn verify
Posted by Tamás Cservenák <ta...@cservenak.net>.
Here it is described:
https://maven.apache.org/resolver-archives/resolver-LATEST/local-repository.html#use-cases
Also, sorry for typo Guillaume ;)
T
On Thu, Nov 17, 2022 at 9:15 AM Tamás Cservenák <ta...@cservenak.net> wrote:
> ...aaand this is where "workspace" feature of split repo comes in play...
> oh Guillable, you already said it :D
>
> T
>
> On Thu, Nov 17, 2022 at 9:01 AM Guillaume Nodet <gn...@apache.org> wrote:
>
>> That's specifically an area I've tried to improve over the past months.
>> Most plugins should avoid touching any output file if the content has not
>> changed. Things have improved a bit, and with a bit of tuning, none of
>> the
>> jars is actually touched during a rebuild.
>> Also, the build cache extension will definitely help with those use cases.
>>
>> Anyway, one downside to the install is that if you're working on a custom
>> branch, or even have checkout a tag, you kinda put in your local repo
>> artifacts that you have no real control on.
>> With the upcoming resolver new features, the separation of locally built
>> artifacts and artifacts from remote repositories will help cleaning that
>> stuff.
>>
>> Le jeu. 17 nov. 2022, 07:21, Olivier Lamy <ol...@apache.org> a écrit :
>>
>> > Agree not sure why such "marketing buzz around this" as the idea is to
>> > share artifacts so they need to be installed or deployed.
>> > The only issue I can see with install vs verify is the compilation of
>> > everything all the time.
>> > because m-compiler-p detects a new artifact of a module in the reactor
>> > and so the m-compiler-p decides to recompile everything (because the
>> > jar is newer than build start time).
>> > I have some work locally but I still need to push the branch.
>> > On very large projects (e.g lot of modules) it makes a significant
>> > difference.
>> > with install you will see "Changes detected - recompiling the module!"
>> > whereas it's totally wrong (nothing has changed)
>> > Maven core is even worse as well because of modello re generation even
>> > if no changes.
>> > it's definitely something here to improve (a sort of api where plugins
>> > can tell there is some changes or not)
>> >
>> > On Sat, 12 Nov 2022 at 08:33, Tamás Cservenák <ta...@cservenak.net>
>> wrote:
>> > >
>> > > Howdy,
>> > >
>> > > in relation to this PR (the reasoning behind it):
>> > > https://github.com/apache/maven-mvnd/pull/734
>> > >
>> > > I never really understood people unconditionally forcing verify
>> instead
>> > of
>> > > install.
>> > >
>> > > For me, personally, the "final output" of the build was always what it
>> > > installs.
>> > >
>> > > While we do call internally the target directory as "buildOutput", it
>> is
>> > > more like "build temp", full of intermediate files, class files, temp
>> > > files, state files, and who knows what. To find the final output in
>> > target
>> > > you need to dig in, sift through files and/or directories (possibly
>> > needing
>> > > knowledge even how some plugin is configured, or worse, working).
>> > >
>> > > In the local repository, it's all on coordinates: just check the POM
>> GAV
>> > > you built, no need for any other knowledge (of plugin, of config or
>> > > whatever). Clear as it can be.
>> > >
>> > > And ultimately, a Maven project's ultimate dream goal is to be
>> deployed,
>> > > and what is installed, pretty much (most often) will be the same as
>> will
>> > be
>> > > deployed. Again, win-win.
>> > >
>> > > Finally, to me this feels like it is being pushed by people who
>> "stick"
>> > to
>> > > their local repository a bit too much :) For them, there is a "split
>> > local
>> > > repository" feature, where installed and cached stuff is clearly
>> > separated
>> > > (and hence, easy to nuke).
>> > >
>> > > Or in other words, I stick to the mantra "what is not in a (local or
>> > > remote) repo, does not exist (for Maven)". And most often you do want
>> to
>> > > reuse (depend on) the project being built, hence "sharing" (installing
>> > for
>> > > local dev or deploy for remote dev) is wanted.
>> > >
>> > > I see verify being better for trivial cases, like you work on a simple
>> > > (single or multi module) project, with a trivial (known to behave)
>> set of
>> > > plugins. But in a moment when you work on two or more interconnected
>> > > projects, or non trivial projects, or just using some "nasty" plugin
>> that
>> > > for some reason tries to resolve things and is unaware of the project,
>> > etc,
>> > > mvn verify quickly becomes a problem.
>> > >
>> > > WDYT?
>> > >
>> > > Thanks
>> > > T
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>
Re: mvn install vs mvn verify
Posted by Tamás Cservenák <ta...@cservenak.net>.
...aaand this is where "workspace" feature of split repo comes in play...
oh Guillable, you already said it :D
T
On Thu, Nov 17, 2022 at 9:01 AM Guillaume Nodet <gn...@apache.org> wrote:
> That's specifically an area I've tried to improve over the past months.
> Most plugins should avoid touching any output file if the content has not
> changed. Things have improved a bit, and with a bit of tuning, none of the
> jars is actually touched during a rebuild.
> Also, the build cache extension will definitely help with those use cases.
>
> Anyway, one downside to the install is that if you're working on a custom
> branch, or even have checkout a tag, you kinda put in your local repo
> artifacts that you have no real control on.
> With the upcoming resolver new features, the separation of locally built
> artifacts and artifacts from remote repositories will help cleaning that
> stuff.
>
> Le jeu. 17 nov. 2022, 07:21, Olivier Lamy <ol...@apache.org> a écrit :
>
> > Agree not sure why such "marketing buzz around this" as the idea is to
> > share artifacts so they need to be installed or deployed.
> > The only issue I can see with install vs verify is the compilation of
> > everything all the time.
> > because m-compiler-p detects a new artifact of a module in the reactor
> > and so the m-compiler-p decides to recompile everything (because the
> > jar is newer than build start time).
> > I have some work locally but I still need to push the branch.
> > On very large projects (e.g lot of modules) it makes a significant
> > difference.
> > with install you will see "Changes detected - recompiling the module!"
> > whereas it's totally wrong (nothing has changed)
> > Maven core is even worse as well because of modello re generation even
> > if no changes.
> > it's definitely something here to improve (a sort of api where plugins
> > can tell there is some changes or not)
> >
> > On Sat, 12 Nov 2022 at 08:33, Tamás Cservenák <ta...@cservenak.net>
> wrote:
> > >
> > > Howdy,
> > >
> > > in relation to this PR (the reasoning behind it):
> > > https://github.com/apache/maven-mvnd/pull/734
> > >
> > > I never really understood people unconditionally forcing verify instead
> > of
> > > install.
> > >
> > > For me, personally, the "final output" of the build was always what it
> > > installs.
> > >
> > > While we do call internally the target directory as "buildOutput", it
> is
> > > more like "build temp", full of intermediate files, class files, temp
> > > files, state files, and who knows what. To find the final output in
> > target
> > > you need to dig in, sift through files and/or directories (possibly
> > needing
> > > knowledge even how some plugin is configured, or worse, working).
> > >
> > > In the local repository, it's all on coordinates: just check the POM
> GAV
> > > you built, no need for any other knowledge (of plugin, of config or
> > > whatever). Clear as it can be.
> > >
> > > And ultimately, a Maven project's ultimate dream goal is to be
> deployed,
> > > and what is installed, pretty much (most often) will be the same as
> will
> > be
> > > deployed. Again, win-win.
> > >
> > > Finally, to me this feels like it is being pushed by people who "stick"
> > to
> > > their local repository a bit too much :) For them, there is a "split
> > local
> > > repository" feature, where installed and cached stuff is clearly
> > separated
> > > (and hence, easy to nuke).
> > >
> > > Or in other words, I stick to the mantra "what is not in a (local or
> > > remote) repo, does not exist (for Maven)". And most often you do want
> to
> > > reuse (depend on) the project being built, hence "sharing" (installing
> > for
> > > local dev or deploy for remote dev) is wanted.
> > >
> > > I see verify being better for trivial cases, like you work on a simple
> > > (single or multi module) project, with a trivial (known to behave) set
> of
> > > plugins. But in a moment when you work on two or more interconnected
> > > projects, or non trivial projects, or just using some "nasty" plugin
> that
> > > for some reason tries to resolve things and is unaware of the project,
> > etc,
> > > mvn verify quickly becomes a problem.
> > >
> > > WDYT?
> > >
> > > Thanks
> > > T
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: mvn install vs mvn verify
Posted by Guillaume Nodet <gn...@apache.org>.
That's specifically an area I've tried to improve over the past months.
Most plugins should avoid touching any output file if the content has not
changed. Things have improved a bit, and with a bit of tuning, none of the
jars is actually touched during a rebuild.
Also, the build cache extension will definitely help with those use cases.
Anyway, one downside to the install is that if you're working on a custom
branch, or even have checkout a tag, you kinda put in your local repo
artifacts that you have no real control on.
With the upcoming resolver new features, the separation of locally built
artifacts and artifacts from remote repositories will help cleaning that
stuff.
Le jeu. 17 nov. 2022, 07:21, Olivier Lamy <ol...@apache.org> a écrit :
> Agree not sure why such "marketing buzz around this" as the idea is to
> share artifacts so they need to be installed or deployed.
> The only issue I can see with install vs verify is the compilation of
> everything all the time.
> because m-compiler-p detects a new artifact of a module in the reactor
> and so the m-compiler-p decides to recompile everything (because the
> jar is newer than build start time).
> I have some work locally but I still need to push the branch.
> On very large projects (e.g lot of modules) it makes a significant
> difference.
> with install you will see "Changes detected - recompiling the module!"
> whereas it's totally wrong (nothing has changed)
> Maven core is even worse as well because of modello re generation even
> if no changes.
> it's definitely something here to improve (a sort of api where plugins
> can tell there is some changes or not)
>
> On Sat, 12 Nov 2022 at 08:33, Tamás Cservenák <ta...@cservenak.net> wrote:
> >
> > Howdy,
> >
> > in relation to this PR (the reasoning behind it):
> > https://github.com/apache/maven-mvnd/pull/734
> >
> > I never really understood people unconditionally forcing verify instead
> of
> > install.
> >
> > For me, personally, the "final output" of the build was always what it
> > installs.
> >
> > While we do call internally the target directory as "buildOutput", it is
> > more like "build temp", full of intermediate files, class files, temp
> > files, state files, and who knows what. To find the final output in
> target
> > you need to dig in, sift through files and/or directories (possibly
> needing
> > knowledge even how some plugin is configured, or worse, working).
> >
> > In the local repository, it's all on coordinates: just check the POM GAV
> > you built, no need for any other knowledge (of plugin, of config or
> > whatever). Clear as it can be.
> >
> > And ultimately, a Maven project's ultimate dream goal is to be deployed,
> > and what is installed, pretty much (most often) will be the same as will
> be
> > deployed. Again, win-win.
> >
> > Finally, to me this feels like it is being pushed by people who "stick"
> to
> > their local repository a bit too much :) For them, there is a "split
> local
> > repository" feature, where installed and cached stuff is clearly
> separated
> > (and hence, easy to nuke).
> >
> > Or in other words, I stick to the mantra "what is not in a (local or
> > remote) repo, does not exist (for Maven)". And most often you do want to
> > reuse (depend on) the project being built, hence "sharing" (installing
> for
> > local dev or deploy for remote dev) is wanted.
> >
> > I see verify being better for trivial cases, like you work on a simple
> > (single or multi module) project, with a trivial (known to behave) set of
> > plugins. But in a moment when you work on two or more interconnected
> > projects, or non trivial projects, or just using some "nasty" plugin that
> > for some reason tries to resolve things and is unaware of the project,
> etc,
> > mvn verify quickly becomes a problem.
> >
> > WDYT?
> >
> > Thanks
> > T
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: mvn install vs mvn verify
Posted by Olivier Lamy <ol...@apache.org>.
Agree not sure why such "marketing buzz around this" as the idea is to
share artifacts so they need to be installed or deployed.
The only issue I can see with install vs verify is the compilation of
everything all the time.
because m-compiler-p detects a new artifact of a module in the reactor
and so the m-compiler-p decides to recompile everything (because the
jar is newer than build start time).
I have some work locally but I still need to push the branch.
On very large projects (e.g lot of modules) it makes a significant difference.
with install you will see "Changes detected - recompiling the module!"
whereas it's totally wrong (nothing has changed)
Maven core is even worse as well because of modello re generation even
if no changes.
it's definitely something here to improve (a sort of api where plugins
can tell there is some changes or not)
On Sat, 12 Nov 2022 at 08:33, Tamás Cservenák <ta...@cservenak.net> wrote:
>
> Howdy,
>
> in relation to this PR (the reasoning behind it):
> https://github.com/apache/maven-mvnd/pull/734
>
> I never really understood people unconditionally forcing verify instead of
> install.
>
> For me, personally, the "final output" of the build was always what it
> installs.
>
> While we do call internally the target directory as "buildOutput", it is
> more like "build temp", full of intermediate files, class files, temp
> files, state files, and who knows what. To find the final output in target
> you need to dig in, sift through files and/or directories (possibly needing
> knowledge even how some plugin is configured, or worse, working).
>
> In the local repository, it's all on coordinates: just check the POM GAV
> you built, no need for any other knowledge (of plugin, of config or
> whatever). Clear as it can be.
>
> And ultimately, a Maven project's ultimate dream goal is to be deployed,
> and what is installed, pretty much (most often) will be the same as will be
> deployed. Again, win-win.
>
> Finally, to me this feels like it is being pushed by people who "stick" to
> their local repository a bit too much :) For them, there is a "split local
> repository" feature, where installed and cached stuff is clearly separated
> (and hence, easy to nuke).
>
> Or in other words, I stick to the mantra "what is not in a (local or
> remote) repo, does not exist (for Maven)". And most often you do want to
> reuse (depend on) the project being built, hence "sharing" (installing for
> local dev or deploy for remote dev) is wanted.
>
> I see verify being better for trivial cases, like you work on a simple
> (single or multi module) project, with a trivial (known to behave) set of
> plugins. But in a moment when you work on two or more interconnected
> projects, or non trivial projects, or just using some "nasty" plugin that
> for some reason tries to resolve things and is unaware of the project, etc,
> mvn verify quickly becomes a problem.
>
> WDYT?
>
> Thanks
> T
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: mvn install vs mvn verify
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
Guess it depends the project.
Today, there are very few projects without custom plugin binding and all
tend to lead to package phase so package seems the natural one enabling to
bundle the deliverable with tests validation phase.
IT are a legacy phase where package was needed before tests so verify
sounds useless as of today for most projects - but our own projects abuse
of it so dont drop it yet ;).
Now a lot of plugins need install cause they resolve in m2 sometimes
without the resolver stack so guess install - as clean for a similar reason
- are the best defaults today.
Le ven. 11 nov. 2022 à 23:33, Tamás Cservenák <ta...@cservenak.net> a
écrit :
> Howdy,
>
> in relation to this PR (the reasoning behind it):
> https://github.com/apache/maven-mvnd/pull/734
>
> I never really understood people unconditionally forcing verify instead of
> install.
>
> For me, personally, the "final output" of the build was always what it
> installs.
>
> While we do call internally the target directory as "buildOutput", it is
> more like "build temp", full of intermediate files, class files, temp
> files, state files, and who knows what. To find the final output in target
> you need to dig in, sift through files and/or directories (possibly needing
> knowledge even how some plugin is configured, or worse, working).
>
> In the local repository, it's all on coordinates: just check the POM GAV
> you built, no need for any other knowledge (of plugin, of config or
> whatever). Clear as it can be.
>
> And ultimately, a Maven project's ultimate dream goal is to be deployed,
> and what is installed, pretty much (most often) will be the same as will be
> deployed. Again, win-win.
>
> Finally, to me this feels like it is being pushed by people who "stick" to
> their local repository a bit too much :) For them, there is a "split local
> repository" feature, where installed and cached stuff is clearly separated
> (and hence, easy to nuke).
>
> Or in other words, I stick to the mantra "what is not in a (local or
> remote) repo, does not exist (for Maven)". And most often you do want to
> reuse (depend on) the project being built, hence "sharing" (installing for
> local dev or deploy for remote dev) is wanted.
>
> I see verify being better for trivial cases, like you work on a simple
> (single or multi module) project, with a trivial (known to behave) set of
> plugins. But in a moment when you work on two or more interconnected
> projects, or non trivial projects, or just using some "nasty" plugin that
> for some reason tries to resolve things and is unaware of the project, etc,
> mvn verify quickly becomes a problem.
>
> WDYT?
>
> Thanks
> T
>
Re: mvn install vs mvn verify
Posted by Niels Basjes <Ni...@basjes.nl>.
Hi,
I rarely use the `resume from` case (mentioned in the issue).
In general I find myself doing `mvn verify` more often than the `mvn
install` while I'm developing stuff.
What I do have is that sometimes I want to try something out without
`damaging` the locally installed snapshot version: `mvn verify`
In cases where I need to update the installed snapshot version I usually
use a custom profile that disables all checks and tests and just builds and
installs my artifacts
https://github.com/nielsbasjes/yauaa/blob/b4b6be2be345f90135e5e72089e279f42a7b8eba/pom.xml#L304
I consider the development process and the release process to be separate
tasks.
Niels
On Fri, Nov 11, 2022 at 11:33 PM Tamás Cservenák <ta...@cservenak.net>
wrote:
> Howdy,
>
> in relation to this PR (the reasoning behind it):
> https://github.com/apache/maven-mvnd/pull/734
>
> I never really understood people unconditionally forcing verify instead of
> install.
>
> For me, personally, the "final output" of the build was always what it
> installs.
>
> While we do call internally the target directory as "buildOutput", it is
> more like "build temp", full of intermediate files, class files, temp
> files, state files, and who knows what. To find the final output in target
> you need to dig in, sift through files and/or directories (possibly needing
> knowledge even how some plugin is configured, or worse, working).
>
> In the local repository, it's all on coordinates: just check the POM GAV
> you built, no need for any other knowledge (of plugin, of config or
> whatever). Clear as it can be.
>
> And ultimately, a Maven project's ultimate dream goal is to be deployed,
> and what is installed, pretty much (most often) will be the same as will be
> deployed. Again, win-win.
>
> Finally, to me this feels like it is being pushed by people who "stick" to
> their local repository a bit too much :) For them, there is a "split local
> repository" feature, where installed and cached stuff is clearly separated
> (and hence, easy to nuke).
>
> Or in other words, I stick to the mantra "what is not in a (local or
> remote) repo, does not exist (for Maven)". And most often you do want to
> reuse (depend on) the project being built, hence "sharing" (installing for
> local dev or deploy for remote dev) is wanted.
>
> I see verify being better for trivial cases, like you work on a simple
> (single or multi module) project, with a trivial (known to behave) set of
> plugins. But in a moment when you work on two or more interconnected
> projects, or non trivial projects, or just using some "nasty" plugin that
> for some reason tries to resolve things and is unaware of the project, etc,
> mvn verify quickly becomes a problem.
>
> WDYT?
>
> Thanks
> T
>
--
Best regards / Met vriendelijke groeten,
Niels Basjes
Re: mvn install vs mvn verify
Posted by Mirko Friedenhagen <mf...@gmx.de>.
Hi,
late to the party here:
- We develop using merge requests and the default command we run there is `mvn verify` in CI.
- `install` should not be needed as the reactor should be sufficient in it.
- When a module does need an `install` it behaves strangely.
- I see that bigger multi-module projects *could* somehow benefit from `install` but for me the best proof is to execute just `mvn verify`.
Regards
Mirko
> Am 11.11.2022 um 23:32 schrieb Tamás Cservenák <ta...@cservenak.net>:
>
> Howdy,
>
> in relation to this PR (the reasoning behind it):
> https://github.com/apache/maven-mvnd/pull/734
>
> I never really understood people unconditionally forcing verify instead of
> install.
>
> For me, personally, the "final output" of the build was always what it
> installs.
>
> While we do call internally the target directory as "buildOutput", it is
> more like "build temp", full of intermediate files, class files, temp
> files, state files, and who knows what. To find the final output in target
> you need to dig in, sift through files and/or directories (possibly needing
> knowledge even how some plugin is configured, or worse, working).
>
> In the local repository, it's all on coordinates: just check the POM GAV
> you built, no need for any other knowledge (of plugin, of config or
> whatever). Clear as it can be.
>
> And ultimately, a Maven project's ultimate dream goal is to be deployed,
> and what is installed, pretty much (most often) will be the same as will be
> deployed. Again, win-win.
>
> Finally, to me this feels like it is being pushed by people who "stick" to
> their local repository a bit too much :) For them, there is a "split local
> repository" feature, where installed and cached stuff is clearly separated
> (and hence, easy to nuke).
>
> Or in other words, I stick to the mantra "what is not in a (local or
> remote) repo, does not exist (for Maven)". And most often you do want to
> reuse (depend on) the project being built, hence "sharing" (installing for
> local dev or deploy for remote dev) is wanted.
>
> I see verify being better for trivial cases, like you work on a simple
> (single or multi module) project, with a trivial (known to behave) set of
> plugins. But in a moment when you work on two or more interconnected
> projects, or non trivial projects, or just using some "nasty" plugin that
> for some reason tries to resolve things and is unaware of the project, etc,
> mvn verify quickly becomes a problem.
>
> WDYT?
>
> Thanks
> T
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org