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 <[EMAIL PROTECTED]> 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 <[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] > >
