Hi Simon, Thanks a lot for that reply. Yes, I have a workflow in ANT (with CVS), which asks the user whether he wants a timestamp or a version build. With that as a mindset, I was looking on Maven. You have identified it right that Maven has its own stuff when it comes to versioning the builds.
We are trying to migrate from ANT-CVS to Maven-SVN. :), and as far as possible, retain the workflow that's in place with ANT system, so that the people taking builds o maven, will feel at home ;). I think the release plugin already has everything for the versioning/tagging. Any comments? On 6/5/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > 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] > > -- Regards, Niranjan Deshpande "Shut yourself from the world and create the reality you want"
