You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Manfred Moser <ma...@mosabuam.com> on 2013/11/07 18:04:50 UTC
Re: Why is "mvn validate compile" different from "mvn validate;
mvn compile"?
You should not use either call. The validate phase is automatically run
before the compile phase as part of the default lifecycle
Just use
mvn compile
In general it does not make sense to call multiple phases of the same
lifecycle since each phase invocation will run all phases up to and
including the phase mentioned.
manfred
> Hi.
>
> I have used mvn for a while, but am by no means an expert, so if I am
> asking an obvious question please pardon me and answer it anyway if you
> can. Thanks.
>
> I have bound some plugin executions to the validate phase because I need
> them to happen before compile. If I execute
>
> mvn validate
> mvn compile
>
> everything is fine. But if I call
>
> mvn validate compile
>
> Maven behaves differently. What I do during validate is download external,
> non-mavenised (as in unavailable on Central) dependencies and install them
> locally if they are not registered in my local repo yet. Those
> dependencies are used in the compile phase. Now if I seperate the two
> calls it works, but if I do it in one mvn call and rely on the order of
> phases, Maven breaks my build by checking for remote and local artifact
> availability *before* actually starting the validate stuff from my POM. If
> I run "mvn -X ..." I can clearly see the difference.
>
> Am I doing anything wrong? Can I force Maven to actually do what is
> described in the documentation, i.e. perform the whole validate phase with
> all executions bound to it in my POM *before* doing anything else related
> to the compile phase such as trying to download dependencies?
>
> Thank you
> --
> Alexander Kriegisch
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Posted by Vincent Latombe <vi...@gmail.com>.
Hi,
It doesn't work because in Maven, dependencies are resolved prior to any
plugin execution (for each module contained in the reactor). Which
dependencies (compile, runtime, test) are resolved depend on what is
required by the various plugins that are be called in the lifecycle
(depending on the phase you called)
That's why mvn validate works : it only execute the execution you defined,
and this desn't require any dependency resolution
Whilest mvn compile doesn't : compile phase has a maven-compiler-plugin
execution which requires dependency resolution for scope compile, and this
happens before any plugin execution.
Vincent
2013/11/7 Alexander Kriegisch <Al...@kriegisch.name>
> Only "mvn compile" yields the exact same result as "mvn validate compile",
> I just did it like this explicitly to make a point and show clearly what
> hapens. So again: Why, pray tell, does my two-phase build work if first I
> only do "mvn validate" and then "mvn compile", but not with only "mvn
> compile"? The question is still unanswered. Two people told me I made a
> mistake but did not explain which one and where the different behaviour
> comes from.
>
> If it helps I can send logs of "mvn -X ..." when I am back in office so
> you can see the difference if my explanation is not good enough. I thought
> it was. :-(
>
>
>
> > Am 07.11.2013 um 18:04 schrieb "Manfred Moser" <ma...@mosabuam.com>:
> >
> > You should not use either call. The validate phase is automatically run
> > before the compile phase as part of the default lifecycle
> >
> > Just use
> >
> > mvn compile
> >
> > In general it does not make sense to call multiple phases of the same
> > lifecycle since each phase invocation will run all phases up to and
> > including the phase mentioned.
> >
> > manfred
> >
> >> Hi.
> >>
> >> I have used mvn for a while, but am by no means an expert, so if I am
> >> asking an obvious question please pardon me and answer it anyway if you
> >> can. Thanks.
> >>
> >> I have bound some plugin executions to the validate phase because I need
> >> them to happen before compile. If I execute
> >>
> >> mvn validate
> >> mvn compile
> >>
> >> everything is fine. But if I call
> >>
> >> mvn validate compile
> >>
> >> Maven behaves differently. What I do during validate is download
> external,
> >> non-mavenised (as in unavailable on Central) dependencies and install
> them
> >> locally if they are not registered in my local repo yet. Those
> >> dependencies are used in the compile phase. Now if I seperate the two
> >> calls it works, but if I do it in one mvn call and rely on the order of
> >> phases, Maven breaks my build by checking for remote and local artifact
> >> availability *before* actually starting the validate stuff from my POM.
> If
> >> I run "mvn -X ..." I can clearly see the difference.
> >>
> >> Am I doing anything wrong? Can I force Maven to actually do what is
> >> described in the documentation, i.e. perform the whole validate phase
> with
> >> all executions bound to it in my POM *before* doing anything else
> related
> >> to the compile phase such as trying to download dependencies?
> >>
> >> Thank you
> >> --
> >> Alexander Kriegisch
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Posted by Barrie Treloar <ba...@gmail.com>.
On 8 November 2013 08:32, Alexander Kriegisch
> nexus for myself. But imagine a situation in which all I want to have as a precondition for building a tiny little OSS tool with external (non-Maven dependencies) is a working Maven installation and one command: mvn install. I do not want to put the burden on my users to create their own Nexus or manually download dependencies and install them to the local repo.
Who are your users?
If they are internal to you company then you solve that by using your
company's internal Maven Repository Manager.
If they are users on the internet then you solve that by getting your
dependencies into Central. Which is Solution #1.
What that post is missing is how to get your external jars into
Central, which is documented at
http://maven.apache.org/guides/mini/guide-central-repository-upload.html.
This requires your dependencies by open source. It does not rely on
the developers of that dependency to upload it to central. If they
are being recalcitrant then you can upload it for the benefit of
everyone else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Posted by Stephen Connolly <st...@gmail.com>.
On Thursday, 7 November 2013, Curtis Rueden wrote:
> Hi Alexander,
>
> > The non-maven-jar plugin was new to me, but unfortunately it also does
> > not do what I want because it expects the JAR to already exist in a
> > certain place and even have a custom Maven module for it.
There are plugins that will download files for you, and a maven rule is one
artifact per module
>
> Why not scratch your itch: fork the non-maven-jar-maven-plugin, add support
> for remote JAR locations, and submit a PR?
>
> -Curtis
>
>
> On Thu, Nov 7, 2013 at 4:13 PM, Alexander Kriegisch <
> Alexander@kriegisch.name> wrote:
>
> > Sorry, my finger slipped, sent too early...
> >
> >
> > > Am 07.11.2013 um 23:02 schrieb Alexander Kriegisch
> > <Al...@Kriegisch.name>:
> > >
> > > Thanks for all your answers, I know you want to help me, but you don't.
> > I know what Maven was designed to do, and I can set up an internal repo
> or
> > nexus for myself. But imagine a situation in which all I want to have as
> a
> > precondition for building a tiny little OSS tool with external (non-Maven
> > dependencies) is a working Maven installation and one command: mvn
> install.
> > I do not want to put the burden on my users to create their own Nexus or
> > manually download dependencies and install them to the local repo. I do
> not
> > want to execute ugly Ant tasks and not use system dependencies with fixed
> > paths. I have tried all this and got every variant working without much
> > fuss, but somehow all of this feels so unclean. I would much prefer to
> get
> > it working in a declarative Maven style. The non-maven
> >
> > The non-maven-jar plugin was new to me, but unfortunately it also does
> not
> > do what I want because it expects the JAR to already exist in a certain
> > place and even have a custom Maven module for it. Maybe I can somehow
> > combine it with the download plugin, but it seems awkward.
> >
> > Basically my solution with binding download and dynamic artifact
> > installation to a local repo to the validate phase works nicely as long
> as
> > I call the mvn validate separately for the very first time. Afterwards it
> > is absolutely transparent because the artifacts are first class maven
> > citizens after installation. The little bit of comfort missing is just a
> > trick to delay artifact resolution until after dynamic installation, for
> > which I hoped to get a magic Maven option or switch as a hint here on the
> > user group. Thanks for bearing with me, even thanks for lecturing me
> about
> > Maven basics I already knew by heart. I share your opinion that people
> not
> > maintaining their artifacts on Central & Co. are indeed "bad", but hey,
> it
> > is a real life situation I want to deal with and handle as gracefully as
> > possible with as few dirty tricks as possible.
> >
> > I might look into creating a custom lifecycle with an additional
> > pre-validate phase, if at all possible. I just fear that that hypothetic
> > lifecycle will also check dependencies before starting the hypothetic
> > pre-validate phase...
> >
> >
> > >
> > >
> > >> Am 07.11.2013 um 22:43 schrieb Curtis Rueden <ct...@wisc.edu>:
> > >>
> > >> Hi Alexander,
> > >>
> > >>> do you have any suggestion how to solve this problem in a clean,
> > >>> canonical Maven way, given a single condition: no private Nexus or
> > >>> external Maven repo is available and I want one-stop shopping and
> > >>> clean bootstrapping right from Maven.
> > >>
> > >> The blog post linked earlier answers exactly this question.
> > >>
> > >> The solutions it outlines to this problem are, in order of "best for
> the
> > >> Maven community to worst for the Maven community":
> > >>
> > >> 1.Get thee to Central
> > >> 2. Get the external jars into a public Maven repository
> > >> 3. Get the external jars into the internal Maven repository
> > >> 4. Use the reactor (and Stephen's non-maven-jar plugin)
> > >> 5. Use an ANT task
> > >> [Everything after this point is "Donny Don't".]
> > >> 6. The file:///${basedir} repository hack
> > >> 7. The system scope hack
> > >>
> > >> Options 1 & 2 require communication with the third party library
> > >> developers, which presumably is untenable for you. You have also
> > rejected
> > >> #3 ("I kinda dislike manually uploading external JARs there"), which
> > leaves
> > >> #4 as your next-best option.
> > >>
> > >> Regards,
> > >> Curtis
> > >>
> > >> P.S. I am intrigued by your current solution, since it doesn't even
> > appear
> > >> on Stephen's list, but I am guessing it would fall under the "Donny
> > Don't"
> > >> section. The non-maven-jar plugin is a more integrated way of doing
> what
> >
--
Sent from my phone
Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Alexander,
> The non-maven-jar plugin was new to me, but unfortunately it also does
> not do what I want because it expects the JAR to already exist in a
> certain place and even have a custom Maven module for it.
Why not scratch your itch: fork the non-maven-jar-maven-plugin, add support
for remote JAR locations, and submit a PR?
-Curtis
On Thu, Nov 7, 2013 at 4:13 PM, Alexander Kriegisch <
Alexander@kriegisch.name> wrote:
> Sorry, my finger slipped, sent too early...
>
>
> > Am 07.11.2013 um 23:02 schrieb Alexander Kriegisch
> <Al...@Kriegisch.name>:
> >
> > Thanks for all your answers, I know you want to help me, but you don't.
> I know what Maven was designed to do, and I can set up an internal repo or
> nexus for myself. But imagine a situation in which all I want to have as a
> precondition for building a tiny little OSS tool with external (non-Maven
> dependencies) is a working Maven installation and one command: mvn install.
> I do not want to put the burden on my users to create their own Nexus or
> manually download dependencies and install them to the local repo. I do not
> want to execute ugly Ant tasks and not use system dependencies with fixed
> paths. I have tried all this and got every variant working without much
> fuss, but somehow all of this feels so unclean. I would much prefer to get
> it working in a declarative Maven style. The non-maven
>
> The non-maven-jar plugin was new to me, but unfortunately it also does not
> do what I want because it expects the JAR to already exist in a certain
> place and even have a custom Maven module for it. Maybe I can somehow
> combine it with the download plugin, but it seems awkward.
>
> Basically my solution with binding download and dynamic artifact
> installation to a local repo to the validate phase works nicely as long as
> I call the mvn validate separately for the very first time. Afterwards it
> is absolutely transparent because the artifacts are first class maven
> citizens after installation. The little bit of comfort missing is just a
> trick to delay artifact resolution until after dynamic installation, for
> which I hoped to get a magic Maven option or switch as a hint here on the
> user group. Thanks for bearing with me, even thanks for lecturing me about
> Maven basics I already knew by heart. I share your opinion that people not
> maintaining their artifacts on Central & Co. are indeed "bad", but hey, it
> is a real life situation I want to deal with and handle as gracefully as
> possible with as few dirty tricks as possible.
>
> I might look into creating a custom lifecycle with an additional
> pre-validate phase, if at all possible. I just fear that that hypothetic
> lifecycle will also check dependencies before starting the hypothetic
> pre-validate phase...
>
>
> >
> >
> >> Am 07.11.2013 um 22:43 schrieb Curtis Rueden <ct...@wisc.edu>:
> >>
> >> Hi Alexander,
> >>
> >>> do you have any suggestion how to solve this problem in a clean,
> >>> canonical Maven way, given a single condition: no private Nexus or
> >>> external Maven repo is available and I want one-stop shopping and
> >>> clean bootstrapping right from Maven.
> >>
> >> The blog post linked earlier answers exactly this question.
> >>
> >> The solutions it outlines to this problem are, in order of "best for the
> >> Maven community to worst for the Maven community":
> >>
> >> 1.Get thee to Central
> >> 2. Get the external jars into a public Maven repository
> >> 3. Get the external jars into the internal Maven repository
> >> 4. Use the reactor (and Stephen's non-maven-jar plugin)
> >> 5. Use an ANT task
> >> [Everything after this point is "Donny Don't".]
> >> 6. The file:///${basedir} repository hack
> >> 7. The system scope hack
> >>
> >> Options 1 & 2 require communication with the third party library
> >> developers, which presumably is untenable for you. You have also
> rejected
> >> #3 ("I kinda dislike manually uploading external JARs there"), which
> leaves
> >> #4 as your next-best option.
> >>
> >> Regards,
> >> Curtis
> >>
> >> P.S. I am intrigued by your current solution, since it doesn't even
> appear
> >> on Stephen's list, but I am guessing it would fall under the "Donny
> Don't"
> >> section. The non-maven-jar plugin is a more integrated way of doing what
> >> you are trying to do.
> >>
> >>
> >> On Thu, Nov 7, 2013 at 3:29 PM, Alexander Kriegisch <
> >> Alexander@kriegisch.name> wrote:
> >>
> >>> I have never used Ant, so I do nkt have the urge to script my build. I
> >>> have also read the blog post you mentioned. The JARs I was trying to
> >>> dynamically download from. "non-Maven" URL are, as I said
> >>>
> >>> - not available on Central (I suggested it to the author, but he
> refused
> >>> and keeps committing all dependencies to his SCM)
> >>>
> >>> - not available on any other public Maven repo
> >>>
> >>> - not even built with Maven.
> >>>
> >>> Our company even has an internal Nexus, but
> >>>
> >>> - I kinda dislike manually uploading external JARs there
> >>>
> >>> - I was in a situation where I did not have access to that Nexus
> instance
> >>> and wondered if it was not somehow possible to bootstrap external
> >>> JARs directly with Maven. Thus, I ended up using the combination of
> >>> download-maven-plugin and maven-install-plugin, both tied to the
> first
> >>> phase available, named validate. This works nicely if I call validate
> >>> separately, but I wanted to do it Maven style in one call. I think it
> >>> is a
> >>> design flaw in Maven that it behaves differently for validate
> >>> depending on
> >>> which phase has been called. I think the principle of least surprise
> >>> makes
> >>> users expect a different (consistent) behaviour. I do not see any
> >>> problems
> >>> In an approach which executes validate before checking the downloads
> >>> needed for compile.
> >>>
> >>> Having said that and further explained my situation, do you have any
> >>> suggestion how to solve this problem in a clean, canonical Maven way,
> given
> >>> a single condition: no private Nexus or external Maven repo is
> available
> >>> and I want one-stop shopping and clean bootstrapping right from Maven.
> I
> >>> think this is a simple enough and understandable requirement. It is
> >>> actually what I have started using Maven for.
> >>>
> >>>
> >>>> Am 07.11.2013 um 21:23 schrieb Doug Douglass <douglass.doug@gmail.com
> >:
> >>>>
> >>>> On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
> >>>> Alexander@kriegisch.name> wrote:
> >>>>
> >>>>> Only "mvn compile" yields the exact same result as "mvn validate
> >>> compile",
> >>>>> I just did it like this explicitly to make a point and show clearly
> what
> >>>>> hapens. So again: Why, pray tell, does my two-phase build work if
> first
> >>> I
> >>>>> only do "mvn validate" and then "mvn compile", but not with only "mvn
> >>>>> compile"? The question is still unanswered. Two people told me I
> made a
> >>>>> mistake but did not explain which one and where the different
> behaviour
> >>>>> comes from.
> >>>> You're right, I didn't answer your original question. The different is
> >>>> because "mvn validate compile" and/or "mvn compile" is a single
> >>> invocation
> >>>> of maven and dependencies are resolved once (by default, w/o any other
> >>>> plugins/configuration). "mvn validate; mvn compile" are 2 separate
> >>>> invocations of maven; the first one does your "download external,
> >>>> non-mavenised" business, which makes those dependencies available for
> the
> >>>> second.
> >>>>
> >>>> I still suggest you read Steven's post as you're question/problem
> >>> indicates
> >>>> you're heading down the not-uncommon path of trying to script your
> build
> >>>> (like we all did in the Ant days) vs. giving into The Maven Way.
> There's
> >>>> lots of similar conversations in the list archives, the blog post is
> the
> >>>> result of many such "debates". I'll apologize in advance if this is
> not
> >>>> your case.
> >>>>
> >>>> Cheers,
> >>>> Doug
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Posted by Alexander Kriegisch <Al...@Kriegisch.name>.
Sorry, my finger slipped, sent too early...
> Am 07.11.2013 um 23:02 schrieb Alexander Kriegisch <Al...@Kriegisch.name>:
>
> Thanks for all your answers, I know you want to help me, but you don't. I know what Maven was designed to do, and I can set up an internal repo or nexus for myself. But imagine a situation in which all I want to have as a precondition for building a tiny little OSS tool with external (non-Maven dependencies) is a working Maven installation and one command: mvn install. I do not want to put the burden on my users to create their own Nexus or manually download dependencies and install them to the local repo. I do not want to execute ugly Ant tasks and not use system dependencies with fixed paths. I have tried all this and got every variant working without much fuss, but somehow all of this feels so unclean. I would much prefer to get it working in a declarative Maven style. The non-maven
The non-maven-jar plugin was new to me, but unfortunately it also does not do what I want because it expects the JAR to already exist in a certain place and even have a custom Maven module for it. Maybe I can somehow combine it with the download plugin, but it seems awkward.
Basically my solution with binding download and dynamic artifact installation to a local repo to the validate phase works nicely as long as I call the mvn validate separately for the very first time. Afterwards it is absolutely transparent because the artifacts are first class maven citizens after installation. The little bit of comfort missing is just a trick to delay artifact resolution until after dynamic installation, for which I hoped to get a magic Maven option or switch as a hint here on the user group. Thanks for bearing with me, even thanks for lecturing me about Maven basics I already knew by heart. I share your opinion that people not maintaining their artifacts on Central & Co. are indeed "bad", but hey, it is a real life situation I want to deal with and handle as gracefully as possible with as few dirty tricks as possible.
I might look into creating a custom lifecycle with an additional pre-validate phase, if at all possible. I just fear that that hypothetic lifecycle will also check dependencies before starting the hypothetic pre-validate phase...
>
>
>> Am 07.11.2013 um 22:43 schrieb Curtis Rueden <ct...@wisc.edu>:
>>
>> Hi Alexander,
>>
>>> do you have any suggestion how to solve this problem in a clean,
>>> canonical Maven way, given a single condition: no private Nexus or
>>> external Maven repo is available and I want one-stop shopping and
>>> clean bootstrapping right from Maven.
>>
>> The blog post linked earlier answers exactly this question.
>>
>> The solutions it outlines to this problem are, in order of "best for the
>> Maven community to worst for the Maven community":
>>
>> 1.Get thee to Central
>> 2. Get the external jars into a public Maven repository
>> 3. Get the external jars into the internal Maven repository
>> 4. Use the reactor (and Stephen's non-maven-jar plugin)
>> 5. Use an ANT task
>> [Everything after this point is "Donny Don't".]
>> 6. The file:///${basedir} repository hack
>> 7. The system scope hack
>>
>> Options 1 & 2 require communication with the third party library
>> developers, which presumably is untenable for you. You have also rejected
>> #3 ("I kinda dislike manually uploading external JARs there"), which leaves
>> #4 as your next-best option.
>>
>> Regards,
>> Curtis
>>
>> P.S. I am intrigued by your current solution, since it doesn't even appear
>> on Stephen's list, but I am guessing it would fall under the "Donny Don't"
>> section. The non-maven-jar plugin is a more integrated way of doing what
>> you are trying to do.
>>
>>
>> On Thu, Nov 7, 2013 at 3:29 PM, Alexander Kriegisch <
>> Alexander@kriegisch.name> wrote:
>>
>>> I have never used Ant, so I do nkt have the urge to script my build. I
>>> have also read the blog post you mentioned. The JARs I was trying to
>>> dynamically download from. "non-Maven" URL are, as I said
>>>
>>> - not available on Central (I suggested it to the author, but he refused
>>> and keeps committing all dependencies to his SCM)
>>>
>>> - not available on any other public Maven repo
>>>
>>> - not even built with Maven.
>>>
>>> Our company even has an internal Nexus, but
>>>
>>> - I kinda dislike manually uploading external JARs there
>>>
>>> - I was in a situation where I did not have access to that Nexus instance
>>> and wondered if it was not somehow possible to bootstrap external
>>> JARs directly with Maven. Thus, I ended up using the combination of
>>> download-maven-plugin and maven-install-plugin, both tied to the first
>>> phase available, named validate. This works nicely if I call validate
>>> separately, but I wanted to do it Maven style in one call. I think it
>>> is a
>>> design flaw in Maven that it behaves differently for validate
>>> depending on
>>> which phase has been called. I think the principle of least surprise
>>> makes
>>> users expect a different (consistent) behaviour. I do not see any
>>> problems
>>> In an approach which executes validate before checking the downloads
>>> needed for compile.
>>>
>>> Having said that and further explained my situation, do you have any
>>> suggestion how to solve this problem in a clean, canonical Maven way, given
>>> a single condition: no private Nexus or external Maven repo is available
>>> and I want one-stop shopping and clean bootstrapping right from Maven. I
>>> think this is a simple enough and understandable requirement. It is
>>> actually what I have started using Maven for.
>>>
>>>
>>>> Am 07.11.2013 um 21:23 schrieb Doug Douglass <do...@gmail.com>:
>>>>
>>>> On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
>>>> Alexander@kriegisch.name> wrote:
>>>>
>>>>> Only "mvn compile" yields the exact same result as "mvn validate
>>> compile",
>>>>> I just did it like this explicitly to make a point and show clearly what
>>>>> hapens. So again: Why, pray tell, does my two-phase build work if first
>>> I
>>>>> only do "mvn validate" and then "mvn compile", but not with only "mvn
>>>>> compile"? The question is still unanswered. Two people told me I made a
>>>>> mistake but did not explain which one and where the different behaviour
>>>>> comes from.
>>>> You're right, I didn't answer your original question. The different is
>>>> because "mvn validate compile" and/or "mvn compile" is a single
>>> invocation
>>>> of maven and dependencies are resolved once (by default, w/o any other
>>>> plugins/configuration). "mvn validate; mvn compile" are 2 separate
>>>> invocations of maven; the first one does your "download external,
>>>> non-mavenised" business, which makes those dependencies available for the
>>>> second.
>>>>
>>>> I still suggest you read Steven's post as you're question/problem
>>> indicates
>>>> you're heading down the not-uncommon path of trying to script your build
>>>> (like we all did in the Ant days) vs. giving into The Maven Way. There's
>>>> lots of similar conversations in the list archives, the blog post is the
>>>> result of many such "debates". I'll apologize in advance if this is not
>>>> your case.
>>>>
>>>> Cheers,
>>>> Doug
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Posted by Alexander Kriegisch <Al...@Kriegisch.name>.
Thanks for all your answers, I know you want to help me, but you don't. I know what Maven was designed to do, and I can set up an internal repo or nexus for myself. But imagine a situation in which all I want to have as a precondition for building a tiny little OSS tool with external (non-Maven dependencies) is a working Maven installation and one command: mvn install. I do not want to put the burden on my users to create their own Nexus or manually download dependencies and install them to the local repo. I do not want to execute ugly Ant tasks and not use system dependencies with fixed paths. I have tried all this and got every variant working without much fuss, but somehow all of this feels so unclean. I would much prefer to get it working in a declarative Maven style. The non-maven
> Am 07.11.2013 um 22:43 schrieb Curtis Rueden <ct...@wisc.edu>:
>
> Hi Alexander,
>
>> do you have any suggestion how to solve this problem in a clean,
>> canonical Maven way, given a single condition: no private Nexus or
>> external Maven repo is available and I want one-stop shopping and
>> clean bootstrapping right from Maven.
>
> The blog post linked earlier answers exactly this question.
>
> The solutions it outlines to this problem are, in order of "best for the
> Maven community to worst for the Maven community":
>
> 1.Get thee to Central
> 2. Get the external jars into a public Maven repository
> 3. Get the external jars into the internal Maven repository
> 4. Use the reactor (and Stephen's non-maven-jar plugin)
> 5. Use an ANT task
> [Everything after this point is "Donny Don't".]
> 6. The file:///${basedir} repository hack
> 7. The system scope hack
>
> Options 1 & 2 require communication with the third party library
> developers, which presumably is untenable for you. You have also rejected
> #3 ("I kinda dislike manually uploading external JARs there"), which leaves
> #4 as your next-best option.
>
> Regards,
> Curtis
>
> P.S. I am intrigued by your current solution, since it doesn't even appear
> on Stephen's list, but I am guessing it would fall under the "Donny Don't"
> section. The non-maven-jar plugin is a more integrated way of doing what
> you are trying to do.
>
>
> On Thu, Nov 7, 2013 at 3:29 PM, Alexander Kriegisch <
> Alexander@kriegisch.name> wrote:
>
>> I have never used Ant, so I do nkt have the urge to script my build. I
>> have also read the blog post you mentioned. The JARs I was trying to
>> dynamically download from. "non-Maven" URL are, as I said
>>
>> - not available on Central (I suggested it to the author, but he refused
>> and keeps committing all dependencies to his SCM)
>>
>> - not available on any other public Maven repo
>>
>> - not even built with Maven.
>>
>> Our company even has an internal Nexus, but
>>
>> - I kinda dislike manually uploading external JARs there
>>
>> - I was in a situation where I did not have access to that Nexus instance
>> and wondered if it was not somehow possible to bootstrap external
>> JARs directly with Maven. Thus, I ended up using the combination of
>> download-maven-plugin and maven-install-plugin, both tied to the first
>> phase available, named validate. This works nicely if I call validate
>> separately, but I wanted to do it Maven style in one call. I think it
>> is a
>> design flaw in Maven that it behaves differently for validate
>> depending on
>> which phase has been called. I think the principle of least surprise
>> makes
>> users expect a different (consistent) behaviour. I do not see any
>> problems
>> In an approach which executes validate before checking the downloads
>> needed for compile.
>>
>> Having said that and further explained my situation, do you have any
>> suggestion how to solve this problem in a clean, canonical Maven way, given
>> a single condition: no private Nexus or external Maven repo is available
>> and I want one-stop shopping and clean bootstrapping right from Maven. I
>> think this is a simple enough and understandable requirement. It is
>> actually what I have started using Maven for.
>>
>>
>>> Am 07.11.2013 um 21:23 schrieb Doug Douglass <do...@gmail.com>:
>>>
>>> On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
>>> Alexander@kriegisch.name> wrote:
>>>
>>>> Only "mvn compile" yields the exact same result as "mvn validate
>> compile",
>>>> I just did it like this explicitly to make a point and show clearly what
>>>> hapens. So again: Why, pray tell, does my two-phase build work if first
>> I
>>>> only do "mvn validate" and then "mvn compile", but not with only "mvn
>>>> compile"? The question is still unanswered. Two people told me I made a
>>>> mistake but did not explain which one and where the different behaviour
>>>> comes from.
>>> You're right, I didn't answer your original question. The different is
>>> because "mvn validate compile" and/or "mvn compile" is a single
>> invocation
>>> of maven and dependencies are resolved once (by default, w/o any other
>>> plugins/configuration). "mvn validate; mvn compile" are 2 separate
>>> invocations of maven; the first one does your "download external,
>>> non-mavenised" business, which makes those dependencies available for the
>>> second.
>>>
>>> I still suggest you read Steven's post as you're question/problem
>> indicates
>>> you're heading down the not-uncommon path of trying to script your build
>>> (like we all did in the Ant days) vs. giving into The Maven Way. There's
>>> lots of similar conversations in the list archives, the blog post is the
>>> result of many such "debates". I'll apologize in advance if this is not
>>> your case.
>>>
>>> Cheers,
>>> Doug
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Posted by Stephen Connolly <st...@gmail.com>.
On Thursday, 7 November 2013, Curtis Rueden wrote:
> Hi Alexander,
>
> > do you have any suggestion how to solve this problem in a clean,
> > canonical Maven way, given a single condition: no private Nexus or
> > external Maven repo is available and I want one-stop shopping and
> > clean bootstrapping right from Maven.
>
> The blog post linked earlier answers exactly this question.
>
> The solutions it outlines to this problem are, in order of "best for the
> Maven community to worst for the Maven community":
>
> 1.Get thee to Central
> 2. Get the external jars into a public Maven repository
> 3. Get the external jars into the internal Maven repository
> 4. Use the reactor (and Stephen's non-maven-jar plugin)
> 5. Use an ANT task
> [Everything after this point is "Donny Don't".]
> 6. The file:///${basedir} repository hack
> 7. The system scope hack
>
> Options 1 & 2 require communication with the third party library
> developers, which presumably is untenable for you. You have also rejected
> #3 ("I kinda dislike manually uploading external JARs there"), which leaves
> #4 as your next-best option.
>
> Regards,
> Curtis
>
> P.S. I am intrigued by your current solution, since it doesn't even appear
> on Stephen's list, but I am guessing it would fall under the "Donny Don't"
> section. The non-maven-jar plugin is a more integrated way of doing what
> you are trying to do.
I confined myself to solutions that actually work
;-)
>
>
> On Thu, Nov 7, 2013 at 3:29 PM, Alexander Kriegisch <
> Alexander@kriegisch.name <javascript:;>> wrote:
>
> > I have never used Ant, so I do nkt have the urge to script my build. I
> > have also read the blog post you mentioned. The JARs I was trying to
> > dynamically download from. "non-Maven" URL are, as I said
> >
> > - not available on Central (I suggested it to the author, but he
> refused
> > and keeps committing all dependencies to his SCM)
> >
> > - not available on any other public Maven repo
> >
> > - not even built with Maven.
> >
> > Our company even has an internal Nexus, but
> >
> > - I kinda dislike manually uploading external JARs there
> >
> > - I was in a situation where I did not have access to that Nexus
> instance
> > and wondered if it was not somehow possible to bootstrap external
> > JARs directly with Maven. Thus, I ended up using the combination of
> > download-maven-plugin and maven-install-plugin, both tied to the
> first
> > phase available, named validate. This works nicely if I call validate
> > separately, but I wanted to do it Maven style in one call. I think it
> > is a
> > design flaw in Maven that it behaves differently for validate
> > depending on
> > which phase has been called. I think the principle of least surprise
> > makes
> > users expect a different (consistent) behaviour. I do not see any
> > problems
> > In an approach which executes validate before checking the downloads
> > needed for compile.
> >
> > Having said that and further explained my situation, do you have any
> > suggestion how to solve this problem in a clean, canonical Maven way,
> given
> > a single condition: no private Nexus or external Maven repo is available
> > and I want one-stop shopping and clean bootstrapping right from Maven. I
> > think this is a simple enough and understandable requirement. It is
> > actually what I have started using Maven for.
> >
> >
> > > Am 07.11.2013 um 21:23 schrieb Doug Douglass <douglass.doug@gmail.com<javascript:;>
> >:
> > >
> > > On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
> > > Alexander@kriegisch.name <javascript:;>> wrote:
> > >
> > >> Only "mvn compile" yields the exact same result as "mvn validate
> > compile",
> > >> I just did it like this explicitly to make a point and show clearly
> what
> > >> hapens. So again: Why, pray tell, does my two-phase build work if
> first
> > I
> > >> only do "mvn validate" and then "mvn compile", but not with only "mvn
> > >> compile"? The question is still unanswered. Two people told me I made
> a
> > >> mistake but did not explain which one and where the different
> behaviour
> > >> comes from.
> > > You're right, I didn't answer your original question. The different is
> > > because "mvn validate compile" and/or "mvn compile" is a single
> > invocation
> > > of maven and dependencies are resolved once (by default, w/o any other
> > > plugins/configuration). "mvn validate; mvn compile" are 2 separate
> > > invocations of maven; the first one does your "download external,
> > > non-mavenised" business, which makes those dependencies available for
> the
> > > second.
> > >
> > > I still suggest you read Steven's post as you're question/problem
> > indicates
> > > you're heading down the not-uncommon path of trying to script your
> build
> > > (like we all did in the Ant days) vs. giving into The Maven Way.
> There's
> > > lots of similar conversations in the list archives, the blog post is
> the
> > > result of many such "debates". I'll apologize in advance if this is not
> > > your case.
> > >
> > > Cheers,
> > > Doug
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org<javascript:;>
> > For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
> >
> >
>
--
Sent from my phone
Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Alexander,
> do you have any suggestion how to solve this problem in a clean,
> canonical Maven way, given a single condition: no private Nexus or
> external Maven repo is available and I want one-stop shopping and
> clean bootstrapping right from Maven.
The blog post linked earlier answers exactly this question.
The solutions it outlines to this problem are, in order of "best for the
Maven community to worst for the Maven community":
1.Get thee to Central
2. Get the external jars into a public Maven repository
3. Get the external jars into the internal Maven repository
4. Use the reactor (and Stephen's non-maven-jar plugin)
5. Use an ANT task
[Everything after this point is "Donny Don't".]
6. The file:///${basedir} repository hack
7. The system scope hack
Options 1 & 2 require communication with the third party library
developers, which presumably is untenable for you. You have also rejected
#3 ("I kinda dislike manually uploading external JARs there"), which leaves
#4 as your next-best option.
Regards,
Curtis
P.S. I am intrigued by your current solution, since it doesn't even appear
on Stephen's list, but I am guessing it would fall under the "Donny Don't"
section. The non-maven-jar plugin is a more integrated way of doing what
you are trying to do.
On Thu, Nov 7, 2013 at 3:29 PM, Alexander Kriegisch <
Alexander@kriegisch.name> wrote:
> I have never used Ant, so I do nkt have the urge to script my build. I
> have also read the blog post you mentioned. The JARs I was trying to
> dynamically download from. "non-Maven" URL are, as I said
>
> - not available on Central (I suggested it to the author, but he refused
> and keeps committing all dependencies to his SCM)
>
> - not available on any other public Maven repo
>
> - not even built with Maven.
>
> Our company even has an internal Nexus, but
>
> - I kinda dislike manually uploading external JARs there
>
> - I was in a situation where I did not have access to that Nexus instance
> and wondered if it was not somehow possible to bootstrap external
> JARs directly with Maven. Thus, I ended up using the combination of
> download-maven-plugin and maven-install-plugin, both tied to the first
> phase available, named validate. This works nicely if I call validate
> separately, but I wanted to do it Maven style in one call. I think it
> is a
> design flaw in Maven that it behaves differently for validate
> depending on
> which phase has been called. I think the principle of least surprise
> makes
> users expect a different (consistent) behaviour. I do not see any
> problems
> In an approach which executes validate before checking the downloads
> needed for compile.
>
> Having said that and further explained my situation, do you have any
> suggestion how to solve this problem in a clean, canonical Maven way, given
> a single condition: no private Nexus or external Maven repo is available
> and I want one-stop shopping and clean bootstrapping right from Maven. I
> think this is a simple enough and understandable requirement. It is
> actually what I have started using Maven for.
>
>
> > Am 07.11.2013 um 21:23 schrieb Doug Douglass <do...@gmail.com>:
> >
> > On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
> > Alexander@kriegisch.name> wrote:
> >
> >> Only "mvn compile" yields the exact same result as "mvn validate
> compile",
> >> I just did it like this explicitly to make a point and show clearly what
> >> hapens. So again: Why, pray tell, does my two-phase build work if first
> I
> >> only do "mvn validate" and then "mvn compile", but not with only "mvn
> >> compile"? The question is still unanswered. Two people told me I made a
> >> mistake but did not explain which one and where the different behaviour
> >> comes from.
> > You're right, I didn't answer your original question. The different is
> > because "mvn validate compile" and/or "mvn compile" is a single
> invocation
> > of maven and dependencies are resolved once (by default, w/o any other
> > plugins/configuration). "mvn validate; mvn compile" are 2 separate
> > invocations of maven; the first one does your "download external,
> > non-mavenised" business, which makes those dependencies available for the
> > second.
> >
> > I still suggest you read Steven's post as you're question/problem
> indicates
> > you're heading down the not-uncommon path of trying to script your build
> > (like we all did in the Ant days) vs. giving into The Maven Way. There's
> > lots of similar conversations in the list archives, the blog post is the
> > result of many such "debates". I'll apologize in advance if this is not
> > your case.
> >
> > Cheers,
> > Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Why is "mvn validate compile" different from "mvn validate;
mvn compile"?
Posted by Manfred Moser <ma...@mosabuam.com>.
Ultimately Maven is designed to get components from a repo manager and
publish them back to the repo manager. Using it without a repository
managers is like saying you want to drive a car but it cant have an engine
or wheels.
manfred
> I have never used Ant, so I do nkt have the urge to script my build. I
> have also read the blog post you mentioned. The JARs I was trying to
> dynamically download from. "non-Maven" URL are, as I said
>
> - not available on Central (I suggested it to the author, but he refused
> and keeps committing all dependencies to his SCM)
>
> - not available on any other public Maven repo
>
> - not even built with Maven.
>
> Our company even has an internal Nexus, but
>
> - I kinda dislike manually uploading external JARs there
>
> - I was in a situation where I did not have access to that Nexus
> instance
> and wondered if it was not somehow possible to bootstrap external
> JARs directly with Maven. Thus, I ended up using the combination of
> download-maven-plugin and maven-install-plugin, both tied to the first
> phase available, named validate. This works nicely if I call validate
> separately, but I wanted to do it Maven style in one call. I think it
> is a
> design flaw in Maven that it behaves differently for validate
> depending on
> which phase has been called. I think the principle of least surprise
> makes
> users expect a different (consistent) behaviour. I do not see any
> problems
> In an approach which executes validate before checking the downloads
> needed for compile.
>
> Having said that and further explained my situation, do you have any
> suggestion how to solve this problem in a clean, canonical Maven way,
> given a single condition: no private Nexus or external Maven repo is
> available and I want one-stop shopping and clean bootstrapping right from
> Maven. I think this is a simple enough and understandable requirement. It
> is actually what I have started using Maven for.
>
>
>> Am 07.11.2013 um 21:23 schrieb Doug Douglass <do...@gmail.com>:
>>
>> On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
>> Alexander@kriegisch.name> wrote:
>>
>>> Only "mvn compile" yields the exact same result as "mvn validate
>>> compile",
>>> I just did it like this explicitly to make a point and show clearly
>>> what
>>> hapens. So again: Why, pray tell, does my two-phase build work if first
>>> I
>>> only do "mvn validate" and then "mvn compile", but not with only "mvn
>>> compile"? The question is still unanswered. Two people told me I made a
>>> mistake but did not explain which one and where the different behaviour
>>> comes from.
>> You're right, I didn't answer your original question. The different is
>> because "mvn validate compile" and/or "mvn compile" is a single
>> invocation
>> of maven and dependencies are resolved once (by default, w/o any other
>> plugins/configuration). "mvn validate; mvn compile" are 2 separate
>> invocations of maven; the first one does your "download external,
>> non-mavenised" business, which makes those dependencies available for
>> the
>> second.
>>
>> I still suggest you read Steven's post as you're question/problem
>> indicates
>> you're heading down the not-uncommon path of trying to script your build
>> (like we all did in the Ant days) vs. giving into The Maven Way. There's
>> lots of similar conversations in the list archives, the blog post is the
>> result of many such "debates". I'll apologize in advance if this is not
>> your case.
>>
>> Cheers,
>> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Posted by Doug Douglass <do...@gmail.com>.
On Thu, Nov 7, 2013 at 2:29 PM, Alexander Kriegisch <
Alexander@kriegisch.name> wrote:
> I have never used Ant, so I do nkt have the urge to script my build. I
> have also read the blog post you mentioned. The JARs I was trying to
> dynamically download from. "non-Maven" URL are, as I said
>
> - not available on Central (I suggested it to the author, but he refused
> and keeps committing all dependencies to his SCM)
>
> - not available on any other public Maven repo
>
> - not even built with Maven.
>
> Our company even has an internal Nexus, but
>
> - I kinda dislike manually uploading external JARs there
>
> - I was in a situation where I did not have access to that Nexus instance
> and wondered if it was not somehow possible to bootstrap external
> JARs directly with Maven. Thus, I ended up using the combination of
> download-maven-plugin and maven-install-plugin, both tied to the first
> phase available, named validate. This works nicely if I call validate
> separately, but I wanted to do it Maven style in one call. I think it
> is a
> design flaw in Maven that it behaves differently for validate
> depending on
> which phase has been called. I think the principle of least surprise
> makes
> users expect a different (consistent) behaviour. I do not see any
> problems
> In an approach which executes validate before checking the downloads
> needed for compile.
>
> Having said that and further explained my situation, do you have any
> suggestion how to solve this problem in a clean, canonical Maven way, given
> a single condition: no private Nexus or external Maven repo is available
> and I want one-stop shopping and clean bootstrapping right from Maven. I
> think this is a simple enough and understandable requirement. It is
> actually what I have started using Maven for.
>
>
I don't mean to sound rude, but all these excuses have been heard here
before and Steven's blog post is a direct and detailed response that
provides many solutions to your problem. Maven has a robust dependency
resolution and download mechanism, if you choose not to use it, you will be
continually fighting an uphill battle that will (already has) lead to
frustration.
That said, my pragmatic advice to your situation is Steven's solution #4.
Re: Why is "mvn validate compile" different from "mvn validate; mvn
compile"?
Posted by Robert Kuropkat <rk...@t-sciences.com>.
On 11/07/2013 04:29 PM, Alexander Kriegisch wrote:
<snip>
>
> Our company even has an internal Nexus, but
>
> - I kinda dislike manually uploading external JARs there
That's what an internal Maven repository (Nexus or Artifactory) is
actually for. You limit the surprises caused by relying on transient or
unreliable sources. It's no different than storing custom rpms in a
local yum repository so you don't lose those.
>
> - I was in a situation where I did not have access to that Nexus instance
I've seen, and done so myself, the idea of setting up yet another Nexus
repository on your development laptop. While it seems a little
outlandish, what it does do is cache everything you need locally so you
can work offline. Of course, if you have no network connection and
spring a new dependency onto the scene, you are stuck, but I would think
that a reasonable assumption under any circumstance. If needed, it also
gives you a way to vet any library upgrades locally before submitting
them to the corporate repository (Nexus). Depends on what your internal
processes are.
P.S. You can do this without a repository manager like Nexus by
injecting it directly into your .m2 cache, but at that point, I like the
management utility of Nexus to keep them and leave me the option of
blowing away my .m2 cache if something gets chunked up there...
<snip>
>
> Having said that and further explained my situation, do you have any suggestion how to solve this problem in a clean, canonical Maven way, given a single condition: no private Nexus or external Maven repo is available and I want one-stop shopping and clean bootstrapping right from Maven. I think this is a simple enough and understandable requirement. It is actually what I have started using Maven for.
>
>
>
Being new to Maven myself, I'll defer to better suggestions, but I would
say the most Maven-like solution is to submit the jars to your corporate
Nexus and then everything else just works like magic. You'll probably
want to create a custom "hosted" repo to store such things, one that is
separate from any repos you push snapshots and releases into and then
use a "Group" to make it all visible or some such...
<snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Posted by Alexander Kriegisch <Al...@Kriegisch.name>.
I have never used Ant, so I do nkt have the urge to script my build. I have also read the blog post you mentioned. The JARs I was trying to dynamically download from. "non-Maven" URL are, as I said
- not available on Central (I suggested it to the author, but he refused
and keeps committing all dependencies to his SCM)
- not available on any other public Maven repo
- not even built with Maven.
Our company even has an internal Nexus, but
- I kinda dislike manually uploading external JARs there
- I was in a situation where I did not have access to that Nexus instance
and wondered if it was not somehow possible to bootstrap external
JARs directly with Maven. Thus, I ended up using the combination of
download-maven-plugin and maven-install-plugin, both tied to the first
phase available, named validate. This works nicely if I call validate
separately, but I wanted to do it Maven style in one call. I think it is a
design flaw in Maven that it behaves differently for validate depending on
which phase has been called. I think the principle of least surprise makes
users expect a different (consistent) behaviour. I do not see any problems
In an approach which executes validate before checking the downloads
needed for compile.
Having said that and further explained my situation, do you have any suggestion how to solve this problem in a clean, canonical Maven way, given a single condition: no private Nexus or external Maven repo is available and I want one-stop shopping and clean bootstrapping right from Maven. I think this is a simple enough and understandable requirement. It is actually what I have started using Maven for.
> Am 07.11.2013 um 21:23 schrieb Doug Douglass <do...@gmail.com>:
>
> On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
> Alexander@kriegisch.name> wrote:
>
>> Only "mvn compile" yields the exact same result as "mvn validate compile",
>> I just did it like this explicitly to make a point and show clearly what
>> hapens. So again: Why, pray tell, does my two-phase build work if first I
>> only do "mvn validate" and then "mvn compile", but not with only "mvn
>> compile"? The question is still unanswered. Two people told me I made a
>> mistake but did not explain which one and where the different behaviour
>> comes from.
> You're right, I didn't answer your original question. The different is
> because "mvn validate compile" and/or "mvn compile" is a single invocation
> of maven and dependencies are resolved once (by default, w/o any other
> plugins/configuration). "mvn validate; mvn compile" are 2 separate
> invocations of maven; the first one does your "download external,
> non-mavenised" business, which makes those dependencies available for the
> second.
>
> I still suggest you read Steven's post as you're question/problem indicates
> you're heading down the not-uncommon path of trying to script your build
> (like we all did in the Ant days) vs. giving into The Maven Way. There's
> lots of similar conversations in the list archives, the blog post is the
> result of many such "debates". I'll apologize in advance if this is not
> your case.
>
> Cheers,
> Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Posted by Doug Douglass <do...@gmail.com>.
On Thu, Nov 7, 2013 at 12:41 PM, Alexander Kriegisch <
Alexander@kriegisch.name> wrote:
> Only "mvn compile" yields the exact same result as "mvn validate compile",
> I just did it like this explicitly to make a point and show clearly what
> hapens. So again: Why, pray tell, does my two-phase build work if first I
> only do "mvn validate" and then "mvn compile", but not with only "mvn
> compile"? The question is still unanswered. Two people told me I made a
> mistake but did not explain which one and where the different behaviour
> comes from.
>
>
You're right, I didn't answer your original question. The different is
because "mvn validate compile" and/or "mvn compile" is a single invocation
of maven and dependencies are resolved once (by default, w/o any other
plugins/configuration). "mvn validate; mvn compile" are 2 separate
invocations of maven; the first one does your "download external,
non-mavenised" business, which makes those dependencies available for the
second.
I still suggest you read Steven's post as you're question/problem indicates
you're heading down the not-uncommon path of trying to script your build
(like we all did in the Ant days) vs. giving into The Maven Way. There's
lots of similar conversations in the list archives, the blog post is the
result of many such "debates". I'll apologize in advance if this is not
your case.
Cheers,
Doug
Re: Why is "mvn validate compile" different from "mvn validate; mvn compile"?
Posted by Alexander Kriegisch <Al...@Kriegisch.name>.
Only "mvn compile" yields the exact same result as "mvn validate compile", I just did it like this explicitly to make a point and show clearly what hapens. So again: Why, pray tell, does my two-phase build work if first I only do "mvn validate" and then "mvn compile", but not with only "mvn compile"? The question is still unanswered. Two people told me I made a mistake but did not explain which one and where the different behaviour comes from.
If it helps I can send logs of "mvn -X ..." when I am back in office so you can see the difference if my explanation is not good enough. I thought it was. :-(
> Am 07.11.2013 um 18:04 schrieb "Manfred Moser" <ma...@mosabuam.com>:
>
> You should not use either call. The validate phase is automatically run
> before the compile phase as part of the default lifecycle
>
> Just use
>
> mvn compile
>
> In general it does not make sense to call multiple phases of the same
> lifecycle since each phase invocation will run all phases up to and
> including the phase mentioned.
>
> manfred
>
>> Hi.
>>
>> I have used mvn for a while, but am by no means an expert, so if I am
>> asking an obvious question please pardon me and answer it anyway if you
>> can. Thanks.
>>
>> I have bound some plugin executions to the validate phase because I need
>> them to happen before compile. If I execute
>>
>> mvn validate
>> mvn compile
>>
>> everything is fine. But if I call
>>
>> mvn validate compile
>>
>> Maven behaves differently. What I do during validate is download external,
>> non-mavenised (as in unavailable on Central) dependencies and install them
>> locally if they are not registered in my local repo yet. Those
>> dependencies are used in the compile phase. Now if I seperate the two
>> calls it works, but if I do it in one mvn call and rely on the order of
>> phases, Maven breaks my build by checking for remote and local artifact
>> availability *before* actually starting the validate stuff from my POM. If
>> I run "mvn -X ..." I can clearly see the difference.
>>
>> Am I doing anything wrong? Can I force Maven to actually do what is
>> described in the documentation, i.e. perform the whole validate phase with
>> all executions bound to it in my POM *before* doing anything else related
>> to the compile phase such as trying to download dependencies?
>>
>> Thank you
>> --
>> Alexander Kriegisch
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org