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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
