Hi Martin, As far as I understand our approach is fundamentally different than what "mvn release:prepare" does. We treat all build as a potential release build. After the binary artifacts are built from the source and the build number is stored in the SCM as a tag, we do not rebuild the binary artifacts anymore. Ivy stores the status of an artifact in the artifact repository and not in the SCM. The advantage of this for us: - we can trace the "snapshot like" artifacts (if a secondary test fails, we know the build numbers of the unstable dependencies), - it allows us a finer control over the "stability" of the used dependencies (we don't want to test fully all builds, but we want to integrate as frequently as possible), - we also don't have to rebuild the artifacts if we decided to release a specific build (for us it takes 3-5 hours to build everything).
I don't know whether it is better or not, but it suites better for us (it is huge code base in which several modules released together as a single product). Regards, Gabor On Sun, Jan 6, 2013 at 2:59 PM, Martin Gainty <[email protected]> wrote: > > Gabor How is Ivy better suited to specifying promotion/staging tags than > implementing <tag> with mvn > release:prepare?http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html > Martin > ______________________________________________ > Jogi és Bizalmassági kinyilatkoztatás Ez az > üzenet bizalmas. Ha nem ön az akinek szánva volt, akkor kérjük, hogy > jelentse azt nekünk vissza. Semmiféle továbbítása vagy másolatának > készítése nem megengedett. Ez az üzenet csak ismeret cserét szolgál és > semmiféle jogi alkalmazhatósága sincs. Mivel az electronikus üzenetek > könnyen megváltoztathatóak, ezért minket semmi felelöség nem terhelhet > ezen üzenet tartalma miatt. > > Date: Sun, 6 Jan 2013 10:18:18 +0100 >> Subject: Re: Is there any on-going work to implement standard build >> promotion/staging mechanism? >> From: [email protected] >> To: [email protected] >> >> Hi Hervé, >> >> > can you explain the ant/ivy build pipeline implementing promotion you did >> > with >> > the help of my team mates? >> Context: we have several modules which are built on top of each other. >> The build pipeline: >> - developer commits his/her changes to the SVN >> - the Jenkins server checks out from SVN, compiles and runs the unit >> tests; finally, the jar artifacts are created and published with >> "integration" status >> - a Jenkins job retrieves this artifact from an Ivy repository and >> checks out secondary tests from the SVN; runs the secondary tests; if >> all tests pass, the description of the artifact is re-published with >> "milestone" status >> - other jobs grab only the artifact if it has least "milestone" status >> - on the end of the pipeline "milestone" artifacts can be promoted >> manually to "release" if the manual tests are successful >> - other loosely coupled projects reference only to artifacts with >> "release" status >> >> Promotion is handled completely by the apache-ivy. It allows you not >> only to reference snapshot as maven do, but you can specify >> "latest.integration" or "latest.release" as version. We use standard >> Ivy statuses, but custom statuses can be defined too. >> >> Regards, Gabor >> >> > (notice I won't be here for 1 week, so won't be able to continue the >> > discussion for the moment, but the topic is worth more discussion) >> > >> > Regards, >> > >> > Hervé >> > >> > Le jeudi 20 décembre 2012 12:12:22 Gábor Guta a écrit : >> >> Yes, I want to start the build of other projects if new version of the >> >> promoted artifact is available. >> >> >> >> Imagine a larger project in which 15-50 modules exists. Top level >> >> module build is triggered by the available new modules with a specific >> >> status i.e. performance tests run when new version of the dependencies >> >> with integration status available, but installer generation needs new >> >> artifact with milestone quality. Developers also prefer to work with >> >> milestone artifacts as they need something which is more stable than >> >> snapshot, but newer than the latest release. I hope this helped to >> >> clarify the role of module statuses. >> >> >> >> Regards, Gabor >> >> >> >> On Thu, Dec 20, 2012 at 8:35 AM, Hervé BOUTEMY <[email protected]> >> > wrote: >> >> > ok, I see the workflow for single artifact promotion >> >> > >> >> > Once this artifact is promoted, you want to update another project's >> >> > dependency to rebuild using this (now promoted) artifact? >> >> > Or your wish is about not rebuilding the other project but promoting its >> >> > built result and modifying dependency to let think it was built with the >> >> > promoted artifact? >> >> > >> >> > >> >> > (notice I'm going to my day work: I won't be able to continue this >> >> > discussion before the end of the day...) >> >> > >> >> > Regards, >> >> > >> >> > Hervé >> >> > >> >> > Le jeudi 20 décembre 2012 07:51:08 Gábor Guta a écrit : >> >> >> We make the promotion of the already built artifact and we update the >> >> >> metadata. e.g.: if the corresponding integration tests are fine, the >> >> >> status of the artifact change to milestone. >> >> >> >> >> >> Regards, Gabor. >> >> >> >> >> >> On Thu, Dec 20, 2012 at 7:17 AM, Hervé BOUTEMY <[email protected]> >> >> > >> >> > wrote: >> >> >> > in your ideas, do you intend to rebuild the artifact at each >> >> >> > promotion, >> >> >> > or >> >> >> > make promotion of the already built artifact (then without rebuilding >> >> >> > it), >> >> >> > only changing its status metatada? >> >> >> > >> >> >> > Regards, >> >> >> > >> >> >> > Hervé >> >> >> > >> >> >> > Le mercredi 19 décembre 2012 15:37:18 Gábor Guta a écrit : >> >> >> >> Can you give me feedback feedback / recommendation about how can I >> >> >> >> write extensions for Maven to support a build pipeline and artifact >> >> >> >> promotion in a "standard" way. As far as understand these issues are >> >> >> >> common problems, because I have found many blogs describing hacks >> >> >> >> and >> >> >> >> workarounds. I also have to mention that nexus and artifactory >> >> >> >> provide >> >> >> >> custom fixes for these problems, but I would prefer not to be locked >> >> >> >> to a specific vendor. I built an ant/ivy build pipeline implementing >> >> >> >> promotion with the help of my team mates. My primary motivation is >> >> >> >> to >> >> >> >> enable the mixing of artifacts from ant and maven builds through a >> >> >> >> central maven repository. >> >> >> >> >> >> >> >> I have two main issues with the current Maven model: >> >> >> >> - no standard way to handle traceable snapshot i.e. snapshots are >> >> >> >> temporary and I can't push them through on the testing pipeline by >> >> >> >> referencing to them by a unique id (build number); >> >> >> >> - no standard way to reference to staged/promoted artifact in the >> >> >> >> dynamic version number i.e. I can't specify in a standard way that I >> >> >> >> want the latest artifact which passed the integration test and has >> >> >> >> version from a specific branch. >> >> >> >> >> >> >> >> Proposal for promotion model: >> >> >> >> - store status information in a POM property (introducing standard >> >> >> >> meta data in the POM would be much nicer) e.g. integration, >> >> >> >> milestone >> >> >> >> - write an extension which can interpret and resolve "3.3.? >> >> >> >> latest.milestone" like notation in the version number >> >> >> >> >> >> >> >> Proposal for staging model: >> >> >> >> - status information is identified by the repository location, so I >> >> >> >> have to be able to add multiple repositories with meta data about >> >> >> >> the >> >> >> >> status of the stored artifacts >> >> >> >> - write an extension which can interpret and resolve "3.3.?, >> >> >> >> latest.milestone" like notation in the version number >> >> >> >> >> >> >> >> >> >> >> >> Gabor >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> >> 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] >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> 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] >> >> >> >> --------------------------------------------------------------------- >> >> 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] >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
