I don't think this information is what Niranjan is really looking for. He appears to have some workflow that he is used to with some other build tool, and is trying to use Maven to reproduce that same workflow. But my guess is that it isn't a workflow that maven is designed to implement, hence the confusion.
Nirijan, why don't you try and describe what you are trying to do with Maven then people can perhaps help you. For example, are you using this to do daily builds for the use of an internal dev team, or are you releasing to customers? Are these artefacts that you are trying to create just temporary or do they need to be available a year from now? What version control system are you using, and what changes do you want to happen in it when you do whatever it is you are trying to do? Normally, for the purposes of internal development on a large project you should set up a "snapshot" repository on some central computer. Then periodically you deploy a snapshot to this repository. By default, two copies are uploaded: one named "foo-SNAPSHOT.jar", and one named "foo-SNAPSHOT-20080601100533.jar". Other people's poms can either add a dependency on the "-SNAPSHOT" or "-SNAPSHOT-20080601100533" one. If they use the first form, then as soon as someone publishes a new snapshot, their computer will download it. That's good because they will pick up bugfixes and see API changes. But it's bad because it might break their build when they don't want to, so people who want some more stability can depend on the dated version instead. Note that the pom <version> tag does NOT need to get changed when deploying a new snapshot to the snapshot repository. And so a new version of pom.xml does not get checked in. But you should not release any code to customers that has a SNAPSHOT dependency, because there is no way you can recreate that build. The jarfile remains in the repo, but you can't be sure exactly what version of the code it was built from. So before a real release, you update the pom to be a non-snapshot version, check it in, tag it, build a jarfile and deploy it to a non-snapshot repository, then update the pom again to have a -SNAPSHOT version. If any of this is confusing, then please read the maven books that are available on-line (see the maven website). Regards, Simon Andreas Christoforides schrieb: > Niranjan, > > The maven release plugin allows performing a dry run of the prepare goal [1]. > > mvn release:prepare -DdryRun=true > > The dry run performs all the local file changes but without executing any SCM > operations (commits and tagging). > > To revert the file changes from the dry run you can also use the clean goal: > > mvn release:clean > > Andreas > > [1] http://maven.apache.org/plugins/maven-release-plugin/usage.html > > On Wednesday 04 June 2008 11:49:34 pm Niranjan Deshpande wrote: > >> Hi Chris, >> >> So you meant to say that SNAPSHOT will be repaced by a timestamp at the run >> time? >> also, can we avoid the chekin of the pom and tagging of the project that >> happens after mvn release:prepare? i am rather experimenting on things >> and dnt want to invite the wrath of other developers if ther repository is >> contaminated ;) >> >> On 6/5/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >>> Mark Struberg <[EMAIL PROTECTED]> wrote on 04/06/2008 22:53:35: >>> >>>> Maybe i missed the point, or you did. >>>> >>>> The usual behaviour is to always have a SNAPSHOT version in your SCM >>>> e.g. <version>1.4-SNAPSHOT</version> >>>> >>>> If you make a build, you simply use the maven-release-plugin >>>> >>>> $>mvn release:prepare >>>> this will >>>> .) ask you the release-version which will default to 1.4 and the next- >>>> version which defaults to 1.5-SNAPSHOT >>>> .) does some usefull checks >>>> .) checkin pom with the 1.4 into SCM and tag the project >>>> .) set the next version in the pom to 1.5-SNAPSHOT or whatever you >>>> provided in step 1 >>>> >>>> after this, do a >>>> $>mvn release:perform >>>> to build the project with the freshly tagged build version >>>> >>>> So there is usually no need to set versions in the pom manually. >>>> >>> So long as maven supports your scm... >>> >>> -Chris >>> >>> >>> ********************************************************************** >>> CAUTION - This message is intended for the addressee named above. It may >>> contain privileged or confidential information. >>> >>> If you are not the intended recipient of this message you must: >>> - Not use, copy, distribute or disclose it to anyone other than the >>> addressee; >>> - Notify the sender via return email; and >>> - Delete the message (and any related attachments) from your computer >>> immediately. >>> >>> Internet emails are not necessarily secure. Australian Associated Motors >>> Insurers Limited ABN 92 004 791 744 (AAMI), and its related entities, do >>> not accept responsibility for changes made to this message after it was >>> sent. >>> >>> Unless otherwise stated, views expressed within this email are the >>> author's own and do not represent those of AAMI. >>> ********************************************************************** >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >> -- >> Regards, >> Niranjan Deshpande >> >> "Shut yourself from the world and create the reality you want" >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
