You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Dhruva Reddy <dr...@sapient.com> on 2008/02/07 22:50:16 UTC
Maven Concepts
I know this seems like a silly thing to post on here, but...
What exactly is a goal and what is a phase? I can't find a good answer in the documentation and there's a lot of seemingly conflicting information out there.
My current understanding is that a phase is a part of a lifecycle (process-resources, compile, etc). A goal is somewhat analogous to an ANT-task, but with a focus on what should happen, rather than how it is done.
Can someone clear this up for me, giving examples?
Thanks,
Dhruva
Re: Maven Concepts
Posted by Stephen Connolly <st...@gmail.com>.
Redeploying a non-SNAPSHOT version is a _bad thing_ as Maven will not
re-download it.
This is why -SNAPSHOT versions are needed (because Maven knows to check for
updates).
But another reason why the update may not have occurred is if the artifact
was copied into the remote repository and not deployed using one of:
- mvn deploy:deploy
- mvn deploy:deploy-file
- maven ant tasks (which are a set of tasks that can be used from ant
build scripts to download artifacts from maven repositories or deploy files
to maven repositories)
These three methods of deploying to the remote repository will ensure that
the repository metadata is updated.
If you "just copy the file" then maven can be unaware of this version as it
checks the metadata first
-Stephen
On Feb 8, 2008 7:37 AM, Sahoo <Sa...@sun.com> wrote:
> I am no maven expert. AFAIK, only if it is SNAPSHOT (the one that ends
> with -SNAPSHOT) version then maven checks the timestamp etc. against the
> remote repository. Otherwise Maven always prefers the one in the local
> repository if one is available there. In your case, the artifact version
> looks to be 1.0 which means once the artifact is available in your local
> repo, maven won't go to remote repo for that one. Question why did the
> owner of the artifact chose to update the artifact, but did not bother
> to change the version number?
>
> Someone can correct me if need be.
>
> Thanks,
> Sahoo
> amit kumar wrote:
> > Continuing on this thread I would also like to put a
> doubt(misconception)-
> > Until yesterday I used to think that if I have an artifact on local
> > repository + remote repository with same groupId-artifactId-version. The
> > maven will take the one which is built at a later time or some system
> > property attached to it which maven uses to differentiate.
> >
> > The origin for this assumption was no matter if the artifact is present
> in
> > my local repository maven shows
> >
> > Downloading \\remoteRepository\org\apache\x\x-1.0.pom
> > Downloading http:\\repo1.maven.org\org\apache\x\x-1.0.pom
> > .
> > .
> > .
> > .
> > .
> > What I assumed of this was that it compares where the latest of the
> artifact
> > is available even with same groupId+artifactId+version.
> >
> > But yesterday when I cross checked even at the remote repository had a
> > artifact newly deployed (though with same groupId+artifactId+versionId)
> what
> > I was seeing in the classpath was the one from local repository.
> >
> > Am I right in what I am concluding? Or again missing somewhere.
> >
> > If what I have concluded upon is right, is there a way to make maven
> pick up
> > the one from remote repository(in case it is build and deployed later? )
> >
> >
> > Thanks and regards,
> > Amit
> >
> >
> > On Feb 8, 2008 4:55 AM, Graham Leggett <mi...@sharp.fm> wrote:
> >
> >
> >> Dhruva Reddy wrote:
> >>
> >>
> >>> What exactly is a goal and what is a phase?
> >>>
> >> In maven 1, there were only goals, and goals were specific targets that
> >> were embedded in specific maven plugins, a bit like an ant target.
> >>
> >> So the jar plugin would have the jar goal which when run, would jar up
> >> some classes.
> >>
> >> It soon became apparent that this leaves too much up to the end user:
> >> what if the artifact you are producing isn't a jar, but an ear instead?
> >> Or a war file? Why should the user have to know or care that they must
> >> run the ear:ear goal instead of the jar:jar goal?
> >>
> >> Enter the phases of the lifecycle in maven 2.
> >>
> >> Plugins attach various goals to the various phases in the lifecycles,
> >> and depending on which phase of the lifecycle you've asked maven to
> >> complete, all the relevant goals attached to that lifecycle will be run
> >> up to that phase.
> >>
> >> So if you run "mvn install" (or "run all goals in all phases up until
> >> the 'install' phase"), maven figures out for itself that the
> >> compile:compile goal must run, and the ear:ear goal (because the
> >> artifact is an ear file), the user no longer needs to care.
> >>
> >> So to sum up:
> >>
> >> The lifecycle contains a list of phases, and each phase has a goal or
> >> goals attached to that phase. So running a phase is a convenient way of
> >> saying "run all goals I need to run to make this artifact up to this
> >> phase, and don't tell me what those goals are, I don't care".
> >>
> >> Regards,
> >> Graham
> >> --
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Maven Concepts
Posted by Sahoo <Sa...@Sun.COM>.
I am no maven expert. AFAIK, only if it is SNAPSHOT (the one that ends
with -SNAPSHOT) version then maven checks the timestamp etc. against the
remote repository. Otherwise Maven always prefers the one in the local
repository if one is available there. In your case, the artifact version
looks to be 1.0 which means once the artifact is available in your local
repo, maven won't go to remote repo for that one. Question why did the
owner of the artifact chose to update the artifact, but did not bother
to change the version number?
Someone can correct me if need be.
Thanks,
Sahoo
amit kumar wrote:
> Continuing on this thread I would also like to put a doubt(misconception)-
> Until yesterday I used to think that if I have an artifact on local
> repository + remote repository with same groupId-artifactId-version. The
> maven will take the one which is built at a later time or some system
> property attached to it which maven uses to differentiate.
>
> The origin for this assumption was no matter if the artifact is present in
> my local repository maven shows
>
> Downloading \\remoteRepository\org\apache\x\x-1.0.pom
> Downloading http:\\repo1.maven.org\org\apache\x\x-1.0.pom
> .
> .
> .
> .
> .
> What I assumed of this was that it compares where the latest of the artifact
> is available even with same groupId+artifactId+version.
>
> But yesterday when I cross checked even at the remote repository had a
> artifact newly deployed (though with same groupId+artifactId+versionId) what
> I was seeing in the classpath was the one from local repository.
>
> Am I right in what I am concluding? Or again missing somewhere.
>
> If what I have concluded upon is right, is there a way to make maven pick up
> the one from remote repository(in case it is build and deployed later? )
>
>
> Thanks and regards,
> Amit
>
>
> On Feb 8, 2008 4:55 AM, Graham Leggett <mi...@sharp.fm> wrote:
>
>
>> Dhruva Reddy wrote:
>>
>>
>>> What exactly is a goal and what is a phase?
>>>
>> In maven 1, there were only goals, and goals were specific targets that
>> were embedded in specific maven plugins, a bit like an ant target.
>>
>> So the jar plugin would have the jar goal which when run, would jar up
>> some classes.
>>
>> It soon became apparent that this leaves too much up to the end user:
>> what if the artifact you are producing isn't a jar, but an ear instead?
>> Or a war file? Why should the user have to know or care that they must
>> run the ear:ear goal instead of the jar:jar goal?
>>
>> Enter the phases of the lifecycle in maven 2.
>>
>> Plugins attach various goals to the various phases in the lifecycles,
>> and depending on which phase of the lifecycle you've asked maven to
>> complete, all the relevant goals attached to that lifecycle will be run
>> up to that phase.
>>
>> So if you run "mvn install" (or "run all goals in all phases up until
>> the 'install' phase"), maven figures out for itself that the
>> compile:compile goal must run, and the ear:ear goal (because the
>> artifact is an ear file), the user no longer needs to care.
>>
>> So to sum up:
>>
>> The lifecycle contains a list of phases, and each phase has a goal or
>> goals attached to that phase. So running a phase is a convenient way of
>> saying "run all goals I need to run to make this artifact up to this
>> phase, and don't tell me what those goals are, I don't care".
>>
>> Regards,
>> Graham
>> --
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Concepts
Posted by amit kumar <am...@gmail.com>.
Continuing on this thread I would also like to put a doubt(misconception)-
Until yesterday I used to think that if I have an artifact on local
repository + remote repository with same groupId-artifactId-version. The
maven will take the one which is built at a later time or some system
property attached to it which maven uses to differentiate.
The origin for this assumption was no matter if the artifact is present in
my local repository maven shows
Downloading \\remoteRepository\org\apache\x\x-1.0.pom
Downloading http:\\repo1.maven.org\org\apache\x\x-1.0.pom
.
.
.
.
.
What I assumed of this was that it compares where the latest of the artifact
is available even with same groupId+artifactId+version.
But yesterday when I cross checked even at the remote repository had a
artifact newly deployed (though with same groupId+artifactId+versionId) what
I was seeing in the classpath was the one from local repository.
Am I right in what I am concluding? Or again missing somewhere.
If what I have concluded upon is right, is there a way to make maven pick up
the one from remote repository(in case it is build and deployed later? )
Thanks and regards,
Amit
On Feb 8, 2008 4:55 AM, Graham Leggett <mi...@sharp.fm> wrote:
> Dhruva Reddy wrote:
>
> > What exactly is a goal and what is a phase?
>
> In maven 1, there were only goals, and goals were specific targets that
> were embedded in specific maven plugins, a bit like an ant target.
>
> So the jar plugin would have the jar goal which when run, would jar up
> some classes.
>
> It soon became apparent that this leaves too much up to the end user:
> what if the artifact you are producing isn't a jar, but an ear instead?
> Or a war file? Why should the user have to know or care that they must
> run the ear:ear goal instead of the jar:jar goal?
>
> Enter the phases of the lifecycle in maven 2.
>
> Plugins attach various goals to the various phases in the lifecycles,
> and depending on which phase of the lifecycle you've asked maven to
> complete, all the relevant goals attached to that lifecycle will be run
> up to that phase.
>
> So if you run "mvn install" (or "run all goals in all phases up until
> the 'install' phase"), maven figures out for itself that the
> compile:compile goal must run, and the ear:ear goal (because the
> artifact is an ear file), the user no longer needs to care.
>
> So to sum up:
>
> The lifecycle contains a list of phases, and each phase has a goal or
> goals attached to that phase. So running a phase is a convenient way of
> saying "run all goals I need to run to make this artifact up to this
> phase, and don't tell me what those goals are, I don't care".
>
> Regards,
> Graham
> --
>
Re: Maven Concepts
Posted by Graham Leggett <mi...@sharp.fm>.
Dhruva Reddy wrote:
> What exactly is a goal and what is a phase?
In maven 1, there were only goals, and goals were specific targets that
were embedded in specific maven plugins, a bit like an ant target.
So the jar plugin would have the jar goal which when run, would jar up
some classes.
It soon became apparent that this leaves too much up to the end user:
what if the artifact you are producing isn't a jar, but an ear instead?
Or a war file? Why should the user have to know or care that they must
run the ear:ear goal instead of the jar:jar goal?
Enter the phases of the lifecycle in maven 2.
Plugins attach various goals to the various phases in the lifecycles,
and depending on which phase of the lifecycle you've asked maven to
complete, all the relevant goals attached to that lifecycle will be run
up to that phase.
So if you run "mvn install" (or "run all goals in all phases up until
the 'install' phase"), maven figures out for itself that the
compile:compile goal must run, and the ear:ear goal (because the
artifact is an ear file), the user no longer needs to care.
So to sum up:
The lifecycle contains a list of phases, and each phase has a goal or
goals attached to that phase. So running a phase is a convenient way of
saying "run all goals I need to run to make this artifact up to this
phase, and don't tell me what those goals are, I don't care".
Regards,
Graham
--
Re: Maven Concepts
Posted by Mark Howard <mh...@tildemh.com>.
Hi,
This is an excellent explanation, thanks for posting.
How do executions fit into this?
Is it that the pom can define many executions of a plugin, each with
different configuration and phases (and potentially goals).
How do you 'run' a single execution of a plugin, in a similar way to
calling mvn plugin:goal to run a goal?
Thanks for any explanations,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Concepts
Posted by Rahul Thakur <ra...@gmail.com>.
You'd use dependencyManagement to baseline dependencies and their
versions across various inheriting modules, while a dependency is, well,
a dependency :-)
Once specified in the dependencyManagement, you don't need to provider
versions for those dependencies in child module's pom.
HTH,
Rahul
amit kumar wrote:
> what is the difference between dependency and dependencyManagement? I mean
> when do we use dependency and when do we use dependencyManagement?
>
> On Feb 8, 2008 10:26 PM, amit kumar <am...@gmail.com> wrote:
>
>
>> That makes two of us Dhruva. Seriously guys thanks a lot. Great help.
>>
>>
>> On Feb 8, 2008 9:46 PM, Dhruva Reddy <dr...@sapient.com> wrote:
>>
>>
>>> This really clears things up--many thanks!
>>>
>>>
>>> --
>>> Dhruva B. Reddy
>>> Senior Associate of Technology, Level 2 | Sapient
>>>
>>> 25 1st Street
>>> Cambridge, MA, 02141, USA
>>> desk: +1 617 452 1900
>>> fax: +1 617 621 1300
>>>
>>> www.sapient.com
>>>
>>> -----Original Message-----
>>> From: John Casey [mailto:jdcasey@commonjava.org]
>>> Sent: Thursday, 07 February 2008 17:01
>>> To: Maven Users List
>>> Subject: Re: Maven Concepts
>>>
>>> You've got it exactly right.
>>>
>>> Maven builds are usually oriented around the concept of a lifecycle,
>>> which consists of phases in a specific order. Each phase has zero or
>>> more mojos (usually called goals) bound to it. Each phase in the
>>> lifecycle implies all of the phases that come before it. This allows
>>> users to bind (or configure) different goals to different phases of
>>> the build, then the standard phase names to run the build. The
>>> default goals for a given type of project are also bound to the
>>> lifecycle in this way, but behind the scenes, such that the user can
>>> supplement these default goals using configurations in the pom.xml.
>>>
>>> So, if you have a jar project (<packaging>jar</packaging>), you might
>>> have something like this:
>>>
>>> Phase Goals
>>> -------- -----------
>>>
>>> validate (none)
>>> initialize (none)
>>> ...
>>> compile org.apache.maven.plugins:maven-compiler-
>>> plugin:compile
>>> ...
>>> test org.apache.maven.plugins:maven-surefire-
>>> plugin:test
>>> ...
>>> package org.apache.maven.plugins:maven-jar-plugin:jar
>>> ...
>>> install org.apache.maven.plugins:maven-install-
>>> plugin:install
>>> ...
>>> etc.
>>>
>>> Now, if you just want to compile your project, you simply call the
>>> 'compile' phase, like this:
>>>
>>> mvn compile
>>>
>>> If you want to run the unit tests, call this:
>>>
>>> mvn test
>>>
>>> Note that in order to run unit tests, you must have compiled your
>>> project's main sources. That's handled here, since the test phase is
>>> later in the lifecycle than the compile phase...'test' implies
>>> 'compile' and all the other phases (in order) that come before 'test'.
>>>
>>> On the other hand, Maven also supports certain one-off goals that are
>>> usually meant to help manage the project build in certain special
>>> cases, or give information about the build. One such example gives
>>> you a glimpse of the POM after all inheritance and profile injection
>>> has been completed:
>>>
>>> mvn help:effective-pom
>>>
>>> which is shorthand for:
>>>
>>> mvn org.apache.maven.plugins:maven-help-plugin:effective-pom
>>>
>>>
>>> Hope that helps,
>>>
>>> -john
>>>
>>> On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote:
>>>
>>>
>>>> I know this seems like a silly thing to post on here, but...
>>>>
>>>> What exactly is a goal and what is a phase? I can't find a good
>>>> answer in the documentation and there's a lot of seemingly
>>>> conflicting information out there.
>>>>
>>>> My current understanding is that a phase is a part of a lifecycle
>>>> (process-resources, compile, etc). A goal is somewhat analogous to
>>>> an ANT-task, but with a focus on what should happen, rather than
>>>> how it is done.
>>>>
>>>> Can someone clear this up for me, giving examples?
>>>>
>>>> Thanks,
>>>> Dhruva
>>>>
>>> ---
>>> John Casey
>>> Committer and PMC Member, Apache Maven
>>> mail: jdcasey at commonjava dot org
>>> blog: http://www.ejlife.net/blogs/john
>>> rss: http://feeds.feedburner.com/ejlife/john
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Maven Concepts
Posted by Alexander Sack <pi...@gmail.com>.
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
-aps
On Feb 9, 2008 3:25 AM, amit kumar <am...@gmail.com> wrote:
> what is the difference between dependency and dependencyManagement? I mean
> when do we use dependency and when do we use dependencyManagement?
>
> On Feb 8, 2008 10:26 PM, amit kumar <am...@gmail.com> wrote:
>
> > That makes two of us Dhruva. Seriously guys thanks a lot. Great help.
> >
> >
> > On Feb 8, 2008 9:46 PM, Dhruva Reddy <dr...@sapient.com> wrote:
> >
> > > This really clears things up--many thanks!
> > >
> > >
> > > --
> > > Dhruva B. Reddy
> > > Senior Associate of Technology, Level 2 | Sapient
> > >
> > > 25 1st Street
> > > Cambridge, MA, 02141, USA
> > > desk: +1 617 452 1900
> > > fax: +1 617 621 1300
> > >
> > > www.sapient.com
> > >
> > > -----Original Message-----
> > > From: John Casey [mailto:jdcasey@commonjava.org]
> > > Sent: Thursday, 07 February 2008 17:01
> > > To: Maven Users List
> > > Subject: Re: Maven Concepts
> > >
> > > You've got it exactly right.
> > >
> > > Maven builds are usually oriented around the concept of a lifecycle,
> > > which consists of phases in a specific order. Each phase has zero or
> > > more mojos (usually called goals) bound to it. Each phase in the
> > > lifecycle implies all of the phases that come before it. This allows
> > > users to bind (or configure) different goals to different phases of
> > > the build, then the standard phase names to run the build. The
> > > default goals for a given type of project are also bound to the
> > > lifecycle in this way, but behind the scenes, such that the user can
> > > supplement these default goals using configurations in the pom.xml.
> > >
> > > So, if you have a jar project (<packaging>jar</packaging>), you might
> > > have something like this:
> > >
> > > Phase Goals
> > > -------- -----------
> > >
> > > validate (none)
> > > initialize (none)
> > > ...
> > > compile org.apache.maven.plugins:maven-compiler-
> > > plugin:compile
> > > ...
> > > test org.apache.maven.plugins:maven-surefire-
> > > plugin:test
> > > ...
> > > package org.apache.maven.plugins:maven-jar-plugin:jar
> > > ...
> > > install org.apache.maven.plugins:maven-install-
> > > plugin:install
> > > ...
> > > etc.
> > >
> > > Now, if you just want to compile your project, you simply call the
> > > 'compile' phase, like this:
> > >
> > > mvn compile
> > >
> > > If you want to run the unit tests, call this:
> > >
> > > mvn test
> > >
> > > Note that in order to run unit tests, you must have compiled your
> > > project's main sources. That's handled here, since the test phase is
> > > later in the lifecycle than the compile phase...'test' implies
> > > 'compile' and all the other phases (in order) that come before 'test'.
> > >
> > > On the other hand, Maven also supports certain one-off goals that are
> > > usually meant to help manage the project build in certain special
> > > cases, or give information about the build. One such example gives
> > > you a glimpse of the POM after all inheritance and profile injection
> > > has been completed:
> > >
> > > mvn help:effective-pom
> > >
> > > which is shorthand for:
> > >
> > > mvn org.apache.maven.plugins:maven-help-plugin:effective-pom
> > >
> > >
> > > Hope that helps,
> > >
> > > -john
> > >
> > > On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote:
> > >
> > > > I know this seems like a silly thing to post on here, but...
> > > >
> > > > What exactly is a goal and what is a phase? I can't find a good
> > > > answer in the documentation and there's a lot of seemingly
> > > > conflicting information out there.
> > > >
> > > > My current understanding is that a phase is a part of a lifecycle
> > > > (process-resources, compile, etc). A goal is somewhat analogous to
> > > > an ANT-task, but with a focus on what should happen, rather than
> > > > how it is done.
> > > >
> > > > Can someone clear this up for me, giving examples?
> > > >
> > > > Thanks,
> > > > Dhruva
> > >
> > > ---
> > > John Casey
> > > Committer and PMC Member, Apache Maven
> > > mail: jdcasey at commonjava dot org
> > > blog: http://www.ejlife.net/blogs/john
> > > rss: http://feeds.feedburner.com/ejlife/john
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson
Re: Maven Concepts
Posted by amit kumar <am...@gmail.com>.
what is the difference between dependency and dependencyManagement? I mean
when do we use dependency and when do we use dependencyManagement?
On Feb 8, 2008 10:26 PM, amit kumar <am...@gmail.com> wrote:
> That makes two of us Dhruva. Seriously guys thanks a lot. Great help.
>
>
> On Feb 8, 2008 9:46 PM, Dhruva Reddy <dr...@sapient.com> wrote:
>
> > This really clears things up--many thanks!
> >
> >
> > --
> > Dhruva B. Reddy
> > Senior Associate of Technology, Level 2 | Sapient
> >
> > 25 1st Street
> > Cambridge, MA, 02141, USA
> > desk: +1 617 452 1900
> > fax: +1 617 621 1300
> >
> > www.sapient.com
> >
> > -----Original Message-----
> > From: John Casey [mailto:jdcasey@commonjava.org]
> > Sent: Thursday, 07 February 2008 17:01
> > To: Maven Users List
> > Subject: Re: Maven Concepts
> >
> > You've got it exactly right.
> >
> > Maven builds are usually oriented around the concept of a lifecycle,
> > which consists of phases in a specific order. Each phase has zero or
> > more mojos (usually called goals) bound to it. Each phase in the
> > lifecycle implies all of the phases that come before it. This allows
> > users to bind (or configure) different goals to different phases of
> > the build, then the standard phase names to run the build. The
> > default goals for a given type of project are also bound to the
> > lifecycle in this way, but behind the scenes, such that the user can
> > supplement these default goals using configurations in the pom.xml.
> >
> > So, if you have a jar project (<packaging>jar</packaging>), you might
> > have something like this:
> >
> > Phase Goals
> > -------- -----------
> >
> > validate (none)
> > initialize (none)
> > ...
> > compile org.apache.maven.plugins:maven-compiler-
> > plugin:compile
> > ...
> > test org.apache.maven.plugins:maven-surefire-
> > plugin:test
> > ...
> > package org.apache.maven.plugins:maven-jar-plugin:jar
> > ...
> > install org.apache.maven.plugins:maven-install-
> > plugin:install
> > ...
> > etc.
> >
> > Now, if you just want to compile your project, you simply call the
> > 'compile' phase, like this:
> >
> > mvn compile
> >
> > If you want to run the unit tests, call this:
> >
> > mvn test
> >
> > Note that in order to run unit tests, you must have compiled your
> > project's main sources. That's handled here, since the test phase is
> > later in the lifecycle than the compile phase...'test' implies
> > 'compile' and all the other phases (in order) that come before 'test'.
> >
> > On the other hand, Maven also supports certain one-off goals that are
> > usually meant to help manage the project build in certain special
> > cases, or give information about the build. One such example gives
> > you a glimpse of the POM after all inheritance and profile injection
> > has been completed:
> >
> > mvn help:effective-pom
> >
> > which is shorthand for:
> >
> > mvn org.apache.maven.plugins:maven-help-plugin:effective-pom
> >
> >
> > Hope that helps,
> >
> > -john
> >
> > On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote:
> >
> > > I know this seems like a silly thing to post on here, but...
> > >
> > > What exactly is a goal and what is a phase? I can't find a good
> > > answer in the documentation and there's a lot of seemingly
> > > conflicting information out there.
> > >
> > > My current understanding is that a phase is a part of a lifecycle
> > > (process-resources, compile, etc). A goal is somewhat analogous to
> > > an ANT-task, but with a focus on what should happen, rather than
> > > how it is done.
> > >
> > > Can someone clear this up for me, giving examples?
> > >
> > > Thanks,
> > > Dhruva
> >
> > ---
> > John Casey
> > Committer and PMC Member, Apache Maven
> > mail: jdcasey at commonjava dot org
> > blog: http://www.ejlife.net/blogs/john
> > rss: http://feeds.feedburner.com/ejlife/john
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: Maven Concepts
Posted by amit kumar <am...@gmail.com>.
That makes two of us Dhruva. Seriously guys thanks a lot. Great help.
On Feb 8, 2008 9:46 PM, Dhruva Reddy <dr...@sapient.com> wrote:
> This really clears things up--many thanks!
>
>
> --
> Dhruva B. Reddy
> Senior Associate of Technology, Level 2 | Sapient
>
> 25 1st Street
> Cambridge, MA, 02141, USA
> desk: +1 617 452 1900
> fax: +1 617 621 1300
>
> www.sapient.com
>
> -----Original Message-----
> From: John Casey [mailto:jdcasey@commonjava.org]
> Sent: Thursday, 07 February 2008 17:01
> To: Maven Users List
> Subject: Re: Maven Concepts
>
> You've got it exactly right.
>
> Maven builds are usually oriented around the concept of a lifecycle,
> which consists of phases in a specific order. Each phase has zero or
> more mojos (usually called goals) bound to it. Each phase in the
> lifecycle implies all of the phases that come before it. This allows
> users to bind (or configure) different goals to different phases of
> the build, then the standard phase names to run the build. The
> default goals for a given type of project are also bound to the
> lifecycle in this way, but behind the scenes, such that the user can
> supplement these default goals using configurations in the pom.xml.
>
> So, if you have a jar project (<packaging>jar</packaging>), you might
> have something like this:
>
> Phase Goals
> -------- -----------
>
> validate (none)
> initialize (none)
> ...
> compile org.apache.maven.plugins:maven-compiler-
> plugin:compile
> ...
> test org.apache.maven.plugins:maven-surefire-
> plugin:test
> ...
> package org.apache.maven.plugins:maven-jar-plugin:jar
> ...
> install org.apache.maven.plugins:maven-install-
> plugin:install
> ...
> etc.
>
> Now, if you just want to compile your project, you simply call the
> 'compile' phase, like this:
>
> mvn compile
>
> If you want to run the unit tests, call this:
>
> mvn test
>
> Note that in order to run unit tests, you must have compiled your
> project's main sources. That's handled here, since the test phase is
> later in the lifecycle than the compile phase...'test' implies
> 'compile' and all the other phases (in order) that come before 'test'.
>
> On the other hand, Maven also supports certain one-off goals that are
> usually meant to help manage the project build in certain special
> cases, or give information about the build. One such example gives
> you a glimpse of the POM after all inheritance and profile injection
> has been completed:
>
> mvn help:effective-pom
>
> which is shorthand for:
>
> mvn org.apache.maven.plugins:maven-help-plugin:effective-pom
>
>
> Hope that helps,
>
> -john
>
> On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote:
>
> > I know this seems like a silly thing to post on here, but...
> >
> > What exactly is a goal and what is a phase? I can't find a good
> > answer in the documentation and there's a lot of seemingly
> > conflicting information out there.
> >
> > My current understanding is that a phase is a part of a lifecycle
> > (process-resources, compile, etc). A goal is somewhat analogous to
> > an ANT-task, but with a focus on what should happen, rather than
> > how it is done.
> >
> > Can someone clear this up for me, giving examples?
> >
> > Thanks,
> > Dhruva
>
> ---
> John Casey
> Committer and PMC Member, Apache Maven
> mail: jdcasey at commonjava dot org
> blog: http://www.ejlife.net/blogs/john
> rss: http://feeds.feedburner.com/ejlife/john
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Maven Concepts
Posted by Dhruva Reddy <dr...@sapient.com>.
This really clears things up--many thanks!
--
Dhruva B. Reddy
Senior Associate of Technology, Level 2 | Sapient
25 1st Street
Cambridge, MA, 02141, USA
desk: +1 617 452 1900
fax: +1 617 621 1300
www.sapient.com
-----Original Message-----
From: John Casey [mailto:jdcasey@commonjava.org]
Sent: Thursday, 07 February 2008 17:01
To: Maven Users List
Subject: Re: Maven Concepts
You've got it exactly right.
Maven builds are usually oriented around the concept of a lifecycle,
which consists of phases in a specific order. Each phase has zero or
more mojos (usually called goals) bound to it. Each phase in the
lifecycle implies all of the phases that come before it. This allows
users to bind (or configure) different goals to different phases of
the build, then the standard phase names to run the build. The
default goals for a given type of project are also bound to the
lifecycle in this way, but behind the scenes, such that the user can
supplement these default goals using configurations in the pom.xml.
So, if you have a jar project (<packaging>jar</packaging>), you might
have something like this:
Phase Goals
-------- -----------
validate (none)
initialize (none)
...
compile org.apache.maven.plugins:maven-compiler-
plugin:compile
...
test org.apache.maven.plugins:maven-surefire-
plugin:test
...
package org.apache.maven.plugins:maven-jar-plugin:jar
...
install org.apache.maven.plugins:maven-install-
plugin:install
...
etc.
Now, if you just want to compile your project, you simply call the
'compile' phase, like this:
mvn compile
If you want to run the unit tests, call this:
mvn test
Note that in order to run unit tests, you must have compiled your
project's main sources. That's handled here, since the test phase is
later in the lifecycle than the compile phase...'test' implies
'compile' and all the other phases (in order) that come before 'test'.
On the other hand, Maven also supports certain one-off goals that are
usually meant to help manage the project build in certain special
cases, or give information about the build. One such example gives
you a glimpse of the POM after all inheritance and profile injection
has been completed:
mvn help:effective-pom
which is shorthand for:
mvn org.apache.maven.plugins:maven-help-plugin:effective-pom
Hope that helps,
-john
On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote:
> I know this seems like a silly thing to post on here, but...
>
> What exactly is a goal and what is a phase? I can't find a good
> answer in the documentation and there's a lot of seemingly
> conflicting information out there.
>
> My current understanding is that a phase is a part of a lifecycle
> (process-resources, compile, etc). A goal is somewhat analogous to
> an ANT-task, but with a focus on what should happen, rather than
> how it is done.
>
> Can someone clear this up for me, giving examples?
>
> Thanks,
> Dhruva
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Concepts
Posted by John Casey <jd...@commonjava.org>.
You've got it exactly right.
Maven builds are usually oriented around the concept of a lifecycle,
which consists of phases in a specific order. Each phase has zero or
more mojos (usually called goals) bound to it. Each phase in the
lifecycle implies all of the phases that come before it. This allows
users to bind (or configure) different goals to different phases of
the build, then the standard phase names to run the build. The
default goals for a given type of project are also bound to the
lifecycle in this way, but behind the scenes, such that the user can
supplement these default goals using configurations in the pom.xml.
So, if you have a jar project (<packaging>jar</packaging>), you might
have something like this:
Phase Goals
-------- -----------
validate (none)
initialize (none)
...
compile org.apache.maven.plugins:maven-compiler-
plugin:compile
...
test org.apache.maven.plugins:maven-surefire-
plugin:test
...
package org.apache.maven.plugins:maven-jar-plugin:jar
...
install org.apache.maven.plugins:maven-install-
plugin:install
...
etc.
Now, if you just want to compile your project, you simply call the
'compile' phase, like this:
mvn compile
If you want to run the unit tests, call this:
mvn test
Note that in order to run unit tests, you must have compiled your
project's main sources. That's handled here, since the test phase is
later in the lifecycle than the compile phase...'test' implies
'compile' and all the other phases (in order) that come before 'test'.
On the other hand, Maven also supports certain one-off goals that are
usually meant to help manage the project build in certain special
cases, or give information about the build. One such example gives
you a glimpse of the POM after all inheritance and profile injection
has been completed:
mvn help:effective-pom
which is shorthand for:
mvn org.apache.maven.plugins:maven-help-plugin:effective-pom
Hope that helps,
-john
On Feb 7, 2008, at 4:50 PM, Dhruva Reddy wrote:
> I know this seems like a silly thing to post on here, but...
>
> What exactly is a goal and what is a phase? I can't find a good
> answer in the documentation and there's a lot of seemingly
> conflicting information out there.
>
> My current understanding is that a phase is a part of a lifecycle
> (process-resources, compile, etc). A goal is somewhat analogous to
> an ANT-task, but with a focus on what should happen, rather than
> how it is done.
>
> Can someone clear this up for me, giving examples?
>
> Thanks,
> Dhruva
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john