Re: Maven unattended build process ---?
try maven-scm-plugin 1.5.1-SNAPSHOT still in svn. svn co https://svn.apache.org/repos/asf/maven/maven-1/plugins/trunk then goto trunk/scm and do maven install -D On 8/18/05, Sanjay Choudhary [EMAIL PROTECTED] wrote: Hi Dan, This makes perfect sense. Thanks for your help. In one of your steps you said tag the entire source source. How do you tag it? Do you use ant rtag or someother mechanism? Thanks, Sanjay On 8/18/05, dan tran [EMAIL PROTECTED] wrote: Sanjay, you and I have the same build requirements ( tag daily build) but I dont use multiproejct:prepare-release. This is the different. In my case, I have a single version property defined at the root pom, and all subproject's version and dependency's version, except the thirdpary ones, reuse that property. For each build, i do: - fetch the root property file - increment the build - check it in - tag the entire source tree - fetch the entire source tree using the tag - build and deploy all built artifacts All those steps can be done by a bootstrap project that is not part of your source tree. In your CI, like a watch dog build, your can keep scm:update or scm:checkout the source and build WITHOUT deploy so that when it fails you can notify developer. hope it helps!!! -D On 8/18/05, Sanjay Choudhary [EMAIL PROTECTED] wrote: Hi Dan, thanks for your comments and I tried it but it fails First Build 1. Bootstrap code for release 1.0.1 2. multiproject:prepare-release will Tag in CVS and project.xml gets updated with version 1.0.1 3. maven goal-name Second build 1. Bootstrap code. 2. mulitproject:prepare-release will Tag in CVS and project.xml gets updated with version 1.0.2 3. maven goal-name --- Build fails Third build 1. Bootstrap code 2. multiproject:prepare-release - at time of tagging and updating POM's maven will check for the dependecies. My local repository and remote repository doesn't have dependencies for version 1.0.2. Hence, this fails. 3. Even build fails for the same reason. You said If your have a night build fail. You should increment the build number and tag it again for the next build. But how is this possible? Please help me understand with details. Appreciate your time. -sanjay On 8/18/05, dan tran [EMAIL PROTECTED] wrote: Sanjay, beside from CI as Thomas suggested. If your have a night build fail. You should increment the build number and tag it again for the next build. However even with simple cron job to do scm:update and build every hour would reduce your chance of failed nightly build big time. It works great for me. -Dan On 8/18/05, Thomas Van de Velde [EMAIL PROTECTED] wrote: Sanjay, You might want to look at continuous integration engines like CruiseControl, Anthill or Luntbuild, which take care of the tagging and are ideal for nightly builds. Maven would then just be used for build and packaging. CVS operations are handled by the build server. However, for application releases (meaning a software release to production), I would use Maven to tag and assign a version number. These type of releases are not part of a continuous build and are often refered to as push-button operations. Maven could go a bit further with the automation of releases. Right now a lot of it still manual (e.g. assigning a version number, etc.). I've written a plugin that automates all of that by automatically incrementing the last digit of an application's version upon release. Cheers, Thomas On 8/18/05, Sanjay Choudhary [EMAIL PROTECTED] wrote: We currently use Maven 1.0.2 only for building a J2EE application. *Developers aren't using it as yet.* :-( Our current process is described below. We run this process everynight to create EAR and deploy them in Sandbox. I will appreciate everyone's suggestions and comments to improve the process. 1. Bootstrap all projects from CVS. Get latest from head or branch. (We have maven.xml in the our bootstrap project that does check outs for all the projects from CVS). 2. Perform release - We use multiproject:goal with -Dgoal=performrelease. In this task we tag our code in CVS and update project.xml's with the new version. 3. Use maven and build EAR. 4. Deploy EAR in sandbox - This is done using Jackal scripts. we have a unix shell script that runs(from cron job) the above mentioned process. Value of CVS tag and version numbers are determined using perl and passed to maven. Issues with this process. == For some reason, if step 3 fails to build the EAR file. (For
Re: Maven unattended build process ---?
Sanjay, You might want to look at continuous integration engines like CruiseControl, Anthill or Luntbuild, which take care of the tagging and are ideal for nightly builds. Maven would then just be used for build and packaging. CVS operations are handled by the build server. However, for application releases (meaning a software release to production), I would use Maven to tag and assign a version number. These type of releases are not part of a continuous build and are often refered to as push-button operations. Maven could go a bit further with the automation of releases. Right now a lot of it still manual (e.g. assigning a version number, etc.). I've written a plugin that automates all of that by automatically incrementing the last digit of an application's version upon release. Cheers, Thomas On 8/18/05, Sanjay Choudhary [EMAIL PROTECTED] wrote: We currently use Maven 1.0.2 only for building a J2EE application. *Developers aren't using it as yet.* :-( Our current process is described below. We run this process everynight to create EAR and deploy them in Sandbox. I will appreciate everyone's suggestions and comments to improve the process. 1. Bootstrap all projects from CVS. Get latest from head or branch. (We have maven.xml in the our bootstrap project that does check outs for all the projects from CVS). 2. Perform release - We use multiproject:goal with -Dgoal=performrelease. In this task we tag our code in CVS and update project.xml's with the new version. 3. Use maven and build EAR. 4. Deploy EAR in sandbox - This is done using Jackal scripts. we have a unix shell script that runs(from cron job) the above mentioned process. Value of CVS tag and version numbers are determined using perl and passed to maven. Issues with this process. == For some reason, if step 3 fails to build the EAR file. (For reasons like compilation errors etc) Getting build process back in line is lot of work. For example, if my last successfull build was 1.0.1 and now I am trying to build 1.0.2. 1. Bootstrap works ok 2. Prepare release will tag the cvs and update the project.xml for current version to be 1.0.2 3. BUILD FAILS. Developer fixes the bug and now when we will try to do release 1. Bootstrap new code. 2. Attempt Prepare Release - it fails when it tries to find the depencies for version 1.0.2. Since this is a J2EE application, there are dependencies of EJB's , WAR project on Java projects.Also some Java projects are dependent on other java projects. I am not sure if we are following the right process to build. Our goal is to tag code in CVS and build everynight ( and may be multiple times in a day in future). Also if build fails, email out the notifications. I will appreciate any comments, suggestions and any experience. Thanks, Sanjay
Re: Maven unattended build process ---?
Hi Tom, Is your plug-in public or private? If its public, whats the name of your plug-in? On 8/18/05, Thomas Van de Velde [EMAIL PROTECTED] wrote: Sanjay, You might want to look at continuous integration engines like CruiseControl, Anthill or Luntbuild, which take care of the tagging and are ideal for nightly builds. Maven would then just be used for build and packaging. CVS operations are handled by the build server. However, for application releases (meaning a software release to production), I would use Maven to tag and assign a version number. These type of releases are not part of a continuous build and are often refered to as push-button operations. Maven could go a bit further with the automation of releases. Right now a lot of it still manual (e.g. assigning a version number, etc.). I've written a plugin that automates all of that by automatically incrementing the last digit of an application's version upon release. Cheers, Thomas On 8/18/05, Sanjay Choudhary [EMAIL PROTECTED] wrote: We currently use Maven 1.0.2 only for building a J2EE application. *Developers aren't using it as yet.* :-( Our current process is described below. We run this process everynight to create EAR and deploy them in Sandbox. I will appreciate everyone's suggestions and comments to improve the process. 1. Bootstrap all projects from CVS. Get latest from head or branch. (We have maven.xml in the our bootstrap project that does check outs for all the projects from CVS). 2. Perform release - We use multiproject:goal with -Dgoal=performrelease. In this task we tag our code in CVS and update project.xml's with the new version. 3. Use maven and build EAR. 4. Deploy EAR in sandbox - This is done using Jackal scripts. we have a unix shell script that runs(from cron job) the above mentioned process. Value of CVS tag and version numbers are determined using perl and passed to maven. Issues with this process. == For some reason, if step 3 fails to build the EAR file. (For reasons like compilation errors etc) Getting build process back in line is lot of work. For example, if my last successfull build was 1.0.1 and now I am trying to build 1.0.2. 1. Bootstrap works ok 2. Prepare release will tag the cvs and update the project.xml for current version to be 1.0.2 3. BUILD FAILS. Developer fixes the bug and now when we will try to do release 1. Bootstrap new code. 2. Attempt Prepare Release - it fails when it tries to find the depencies for version 1.0.2. Since this is a J2EE application, there are dependencies of EJB's , WAR project on Java projects.Also some Java projects are dependent on other java projects. I am not sure if we are following the right process to build. Our goal is to tag code in CVS and build everynight ( and may be multiple times in a day in future). Also if build fails, email out the notifications. I will appreciate any comments, suggestions and any experience. Thanks, Sanjay
Re: Maven unattended build process ---?
Sanjay, beside from CI as Thomas suggested. If your have a night build fail. You should increment the build number and tag it again for the next build. However even with simple cron job to do scm:update and build every hour would reduce your chance of failed nightly build big time. It works great for me. -Dan On 8/18/05, Thomas Van de Velde [EMAIL PROTECTED] wrote: Sanjay, You might want to look at continuous integration engines like CruiseControl, Anthill or Luntbuild, which take care of the tagging and are ideal for nightly builds. Maven would then just be used for build and packaging. CVS operations are handled by the build server. However, for application releases (meaning a software release to production), I would use Maven to tag and assign a version number. These type of releases are not part of a continuous build and are often refered to as push-button operations. Maven could go a bit further with the automation of releases. Right now a lot of it still manual (e.g. assigning a version number, etc.). I've written a plugin that automates all of that by automatically incrementing the last digit of an application's version upon release. Cheers, Thomas On 8/18/05, Sanjay Choudhary [EMAIL PROTECTED] wrote: We currently use Maven 1.0.2 only for building a J2EE application. *Developers aren't using it as yet.* :-( Our current process is described below. We run this process everynight to create EAR and deploy them in Sandbox. I will appreciate everyone's suggestions and comments to improve the process. 1. Bootstrap all projects from CVS. Get latest from head or branch. (We have maven.xml in the our bootstrap project that does check outs for all the projects from CVS). 2. Perform release - We use multiproject:goal with -Dgoal=performrelease. In this task we tag our code in CVS and update project.xml's with the new version. 3. Use maven and build EAR. 4. Deploy EAR in sandbox - This is done using Jackal scripts. we have a unix shell script that runs(from cron job) the above mentioned process. Value of CVS tag and version numbers are determined using perl and passed to maven. Issues with this process. == For some reason, if step 3 fails to build the EAR file. (For reasons like compilation errors etc) Getting build process back in line is lot of work. For example, if my last successfull build was 1.0.1 and now I am trying to build 1.0.2. 1. Bootstrap works ok 2. Prepare release will tag the cvs and update the project.xml for current version to be 1.0.2 3. BUILD FAILS. Developer fixes the bug and now when we will try to do release 1. Bootstrap new code. 2. Attempt Prepare Release - it fails when it tries to find the depencies for version 1.0.2. Since this is a J2EE application, there are dependencies of EJB's , WAR project on Java projects.Also some Java projects are dependent on other java projects. I am not sure if we are following the right process to build. Our goal is to tag code in CVS and build everynight ( and may be multiple times in a day in future). Also if build fails, email out the notifications. I will appreciate any comments, suggestions and any experience. Thanks, Sanjay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven unattended build process ---?
Hi Dan, thanks for your comments and I tried it but it fails First Build 1. Bootstrap code for release 1.0.1 2. multiproject:prepare-release will Tag in CVS and project.xml gets updated with version 1.0.1 3. maven goal-name Second build 1. Bootstrap code. 2. mulitproject:prepare-release will Tag in CVS and project.xml gets updated with version 1.0.2 3. maven goal-name --- Build fails Third build 1. Bootstrap code 2. multiproject:prepare-release - at time of tagging and updating POM's maven will check for the dependecies. My local repository and remote repository doesn't have dependencies for version 1.0.2. Hence, this fails. 3. Even build fails for the same reason. You said If your have a night build fail. You should increment the build number and tag it again for the next build. But how is this possible? Please help me understand with details. Appreciate your time. -sanjay On 8/18/05, dan tran [EMAIL PROTECTED] wrote: Sanjay, beside from CI as Thomas suggested. If your have a night build fail. You should increment the build number and tag it again for the next build. However even with simple cron job to do scm:update and build every hour would reduce your chance of failed nightly build big time. It works great for me. -Dan On 8/18/05, Thomas Van de Velde [EMAIL PROTECTED] wrote: Sanjay, You might want to look at continuous integration engines like CruiseControl, Anthill or Luntbuild, which take care of the tagging and are ideal for nightly builds. Maven would then just be used for build and packaging. CVS operations are handled by the build server. However, for application releases (meaning a software release to production), I would use Maven to tag and assign a version number. These type of releases are not part of a continuous build and are often refered to as push-button operations. Maven could go a bit further with the automation of releases. Right now a lot of it still manual (e.g. assigning a version number, etc.). I've written a plugin that automates all of that by automatically incrementing the last digit of an application's version upon release. Cheers, Thomas On 8/18/05, Sanjay Choudhary [EMAIL PROTECTED] wrote: We currently use Maven 1.0.2 only for building a J2EE application. *Developers aren't using it as yet.* :-( Our current process is described below. We run this process everynight to create EAR and deploy them in Sandbox. I will appreciate everyone's suggestions and comments to improve the process. 1. Bootstrap all projects from CVS. Get latest from head or branch. (We have maven.xml in the our bootstrap project that does check outs for all the projects from CVS). 2. Perform release - We use multiproject:goal with -Dgoal=performrelease. In this task we tag our code in CVS and update project.xml's with the new version. 3. Use maven and build EAR. 4. Deploy EAR in sandbox - This is done using Jackal scripts. we have a unix shell script that runs(from cron job) the above mentioned process. Value of CVS tag and version numbers are determined using perl and passed to maven. Issues with this process. == For some reason, if step 3 fails to build the EAR file. (For reasons like compilation errors etc) Getting build process back in line is lot of work. For example, if my last successfull build was 1.0.1 and now I am trying to build 1.0.2. 1. Bootstrap works ok 2. Prepare release will tag the cvs and update the project.xml for current version to be 1.0.2 3. BUILD FAILS. Developer fixes the bug and now when we will try to do release 1. Bootstrap new code. 2. Attempt Prepare Release - it fails when it tries to find the depencies for version 1.0.2. Since this is a J2EE application, there are dependencies of EJB's , WAR project on Java projects.Also some Java projects are dependent on other java projects. I am not sure if we are following the right process to build. Our goal is to tag code in CVS and build everynight ( and may be multiple times in a day in future). Also if build fails, email out the notifications. I will appreciate any comments, suggestions and any experience. Thanks, Sanjay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven unattended build process ---?
Sanjay, you and I have the same build requirements ( tag daily build) but I dont use multiproejct:prepare-release. This is the different. In my case, I have a single version property defined at the root pom, and all subproject's version and dependency's version, except the thirdpary ones, reuse that property. For each build, i do: - fetch the root property file - increment the build - check it in - tag the entire source tree - fetch the entire source tree using the tag - build and deploy all built artifacts All those steps can be done by a bootstrap project that is not part of your source tree. In your CI, like a watch dog build, your can keep scm:update or scm:checkout the source and build WITHOUT deploy so that when it fails you can notify developer. hope it helps!!! -D On 8/18/05, Sanjay Choudhary [EMAIL PROTECTED] wrote: Hi Dan, thanks for your comments and I tried it but it fails First Build 1. Bootstrap code for release 1.0.1 2. multiproject:prepare-release will Tag in CVS and project.xml gets updated with version 1.0.1 3. maven goal-name Second build 1. Bootstrap code. 2. mulitproject:prepare-release will Tag in CVS and project.xml gets updated with version 1.0.2 3. maven goal-name --- Build fails Third build 1. Bootstrap code 2. multiproject:prepare-release - at time of tagging and updating POM's maven will check for the dependecies. My local repository and remote repository doesn't have dependencies for version 1.0.2. Hence, this fails. 3. Even build fails for the same reason. You said If your have a night build fail. You should increment the build number and tag it again for the next build. But how is this possible? Please help me understand with details. Appreciate your time. -sanjay On 8/18/05, dan tran [EMAIL PROTECTED] wrote: Sanjay, beside from CI as Thomas suggested. If your have a night build fail. You should increment the build number and tag it again for the next build. However even with simple cron job to do scm:update and build every hour would reduce your chance of failed nightly build big time. It works great for me. -Dan On 8/18/05, Thomas Van de Velde [EMAIL PROTECTED] wrote: Sanjay, You might want to look at continuous integration engines like CruiseControl, Anthill or Luntbuild, which take care of the tagging and are ideal for nightly builds. Maven would then just be used for build and packaging. CVS operations are handled by the build server. However, for application releases (meaning a software release to production), I would use Maven to tag and assign a version number. These type of releases are not part of a continuous build and are often refered to as push-button operations. Maven could go a bit further with the automation of releases. Right now a lot of it still manual (e.g. assigning a version number, etc.). I've written a plugin that automates all of that by automatically incrementing the last digit of an application's version upon release. Cheers, Thomas On 8/18/05, Sanjay Choudhary [EMAIL PROTECTED] wrote: We currently use Maven 1.0.2 only for building a J2EE application. *Developers aren't using it as yet.* :-( Our current process is described below. We run this process everynight to create EAR and deploy them in Sandbox. I will appreciate everyone's suggestions and comments to improve the process. 1. Bootstrap all projects from CVS. Get latest from head or branch. (We have maven.xml in the our bootstrap project that does check outs for all the projects from CVS). 2. Perform release - We use multiproject:goal with -Dgoal=performrelease. In this task we tag our code in CVS and update project.xml's with the new version. 3. Use maven and build EAR. 4. Deploy EAR in sandbox - This is done using Jackal scripts. we have a unix shell script that runs(from cron job) the above mentioned process. Value of CVS tag and version numbers are determined using perl and passed to maven. Issues with this process. == For some reason, if step 3 fails to build the EAR file. (For reasons like compilation errors etc) Getting build process back in line is lot of work. For example, if my last successfull build was 1.0.1 and now I am trying to build 1.0.2. 1. Bootstrap works ok 2. Prepare release will tag the cvs and update the project.xml for current version to be 1.0.2 3. BUILD FAILS. Developer fixes the bug and now when we will try to do release 1. Bootstrap new code. 2. Attempt Prepare Release - it fails when it tries to find the depencies for version 1.0.2. Since this is a J2EE application, there are dependencies of EJB's , WAR project on Java projects.Also some Java projects are dependent on other java projects. I am not sure
Re: Maven unattended build process ---?
Hi Dan, This makes perfect sense. Thanks for your help. In one of your steps you said tag the entire source source. How do you tag it? Do you use ant rtag or someother mechanism? Thanks, Sanjay On 8/18/05, dan tran [EMAIL PROTECTED] wrote: Sanjay, you and I have the same build requirements ( tag daily build) but I dont use multiproejct:prepare-release. This is the different. In my case, I have a single version property defined at the root pom, and all subproject's version and dependency's version, except the thirdpary ones, reuse that property. For each build, i do: - fetch the root property file - increment the build - check it in - tag the entire source tree - fetch the entire source tree using the tag - build and deploy all built artifacts All those steps can be done by a bootstrap project that is not part of your source tree. In your CI, like a watch dog build, your can keep scm:update or scm:checkout the source and build WITHOUT deploy so that when it fails you can notify developer. hope it helps!!! -D On 8/18/05, Sanjay Choudhary [EMAIL PROTECTED] wrote: Hi Dan, thanks for your comments and I tried it but it fails First Build 1. Bootstrap code for release 1.0.1 2. multiproject:prepare-release will Tag in CVS and project.xml gets updated with version 1.0.1 3. maven goal-name Second build 1. Bootstrap code. 2. mulitproject:prepare-release will Tag in CVS and project.xml gets updated with version 1.0.2 3. maven goal-name --- Build fails Third build 1. Bootstrap code 2. multiproject:prepare-release - at time of tagging and updating POM's maven will check for the dependecies. My local repository and remote repository doesn't have dependencies for version 1.0.2. Hence, this fails. 3. Even build fails for the same reason. You said If your have a night build fail. You should increment the build number and tag it again for the next build. But how is this possible? Please help me understand with details. Appreciate your time. -sanjay On 8/18/05, dan tran [EMAIL PROTECTED] wrote: Sanjay, beside from CI as Thomas suggested. If your have a night build fail. You should increment the build number and tag it again for the next build. However even with simple cron job to do scm:update and build every hour would reduce your chance of failed nightly build big time. It works great for me. -Dan On 8/18/05, Thomas Van de Velde [EMAIL PROTECTED] wrote: Sanjay, You might want to look at continuous integration engines like CruiseControl, Anthill or Luntbuild, which take care of the tagging and are ideal for nightly builds. Maven would then just be used for build and packaging. CVS operations are handled by the build server. However, for application releases (meaning a software release to production), I would use Maven to tag and assign a version number. These type of releases are not part of a continuous build and are often refered to as push-button operations. Maven could go a bit further with the automation of releases. Right now a lot of it still manual (e.g. assigning a version number, etc.). I've written a plugin that automates all of that by automatically incrementing the last digit of an application's version upon release. Cheers, Thomas On 8/18/05, Sanjay Choudhary [EMAIL PROTECTED] wrote: We currently use Maven 1.0.2 only for building a J2EE application. *Developers aren't using it as yet.* :-( Our current process is described below. We run this process everynight to create EAR and deploy them in Sandbox. I will appreciate everyone's suggestions and comments to improve the process. 1. Bootstrap all projects from CVS. Get latest from head or branch. (We have maven.xml in the our bootstrap project that does check outs for all the projects from CVS). 2. Perform release - We use multiproject:goal with -Dgoal=performrelease. In this task we tag our code in CVS and update project.xml's with the new version. 3. Use maven and build EAR. 4. Deploy EAR in sandbox - This is done using Jackal scripts. we have a unix shell script that runs(from cron job) the above mentioned process. Value of CVS tag and version numbers are determined using perl and passed to maven. Issues with this process. == For some reason, if step 3 fails to build the EAR file. (For reasons like compilation errors etc) Getting build process back in line is lot of work. For example, if my last successfull build was 1.0.1 and now I am trying to build 1.0.2. 1. Bootstrap works ok 2. Prepare release will tag the cvs and update the project.xml for current version to be 1.0.2 3.
