On 15 October 2010 12:57, Leon Rosenberg <rosenberg.l...@gmail.com> wrote: > On Fri, Oct 15, 2010 at 10:31 AM, Stephen Connolly > <stephen.alan.conno...@gmail.com> wrote: >> On 15 October 2010 07:28, Leon Rosenberg <rosenberg.l...@gmail.com> wrote: >>> Hello, >>> >>> following situation: >>> >>> I have like 20 projects which are libs of different level. They are >>> all built as jars. They are partially dependent on each other (not >>> circularly). >>> For example project A provides very basic utils. Project B is more >>> specialized and depends on A. Project C depends on A, project D on A >>> and C. >>> >>> I have two requirements: >>> >>> First: I want them to depend on a released version of each other, not >>> necessary last release, but preferred. >>> This work if I declare the dependency as RELEASE >> >> STOP right there! >> >> NEVER EVER USE <version>RELEASE</version> >> >> the tag is depricated and relies on correct metadata to work.... and >> it does not work the way you think it works. The metadata for RELEASE >> is the last (in time) version that was not a -SNAPSHOT and that was >> deployed. so if you deploy in order 1.0, 2.0, 1.0.1, 2.1, 1.0.2 then >> RELEASE will be equivalent to 1.0.2 and not 2.1 > > Good to know, thanx! > >> >>> or a version number like 1.0.2 >> >> That is the correct way to work >> >>> >>> Second: >>> I want to be able to build automatically each night to check whether >>> the last svn committed changes of the projects break the dependent >>> projects. >>> This works if I declare dependencies as SNAPSHOT, like 1.0.2-SNAPSHOT. >>> >>> The problem with SNAPSHOT is that If I release 1.0.1 of project B it >>> upgrades the dependency of A from 1.0.1-SNAPSHOT to 1.0.2 SNAPSHOT (if >>> I previously released an 1.0.1 of project A). >> >> Sounds like a bug in either your project structure, or the maven >> release plugin. can you post the poms of A and B and a diagram of >> their layout in SVN, e.g. >> >> / >> + A >> + trunk >> + tags >> + branches >> + B >> + trunk >> + tags >> + branches >> >>> As a result I am not able to release 1.0.2 of project B until I have >>> released 1.0.2 of A, even I had no changes in A. >>> >>> Therefore the question, how can I teach maven that project depend on >>> RELEASEd versions of each other for release process and dependency >>> management on the one side, and on svn snapshots for CI purposes on >>> the other? >> >> another trick is to have your CI build run one of the >> versions-maven-plugin goals before running the build. >> >> but you will actually want two CI builds, one which builds SVN exactly >> as it is, the other which uses v-m-p to update to the bleeding edge >> and build things... one of the goals like >> http://mojo.codehaus.org/versions-maven-plugin/use-latest-versions-mojo.html >> should help > > Ok, from what I understood I should use > versions:use-latest-snapshots from the vmp to replace all > 1.0.something to 1.0.somethingelsesnapshot, build with it and tell > whether its still working. > If I execute mvn install on each commit I should be able to detect > errors early. > > Is this correct? > > Do you know by chance whether hudson will be able to recognize that > builds as dependency builds and trigger the build of dependent > projects automatically? > > thanx > regards > Leon > >> >>> >>> The only thing I can come up with right now is to have two different >>> poms for each project, with different dependencies. But this sounds >>> like a mess to maintain :-(. >> >> if you use v-m-p it should not be >> >>> >>> I have done this before with ant+ivy by simple declaring a file based >>> 'local repository'. This local repository existed only in the context >>> of a job. I than had a hudson job that checked out all 20 projects and >>> published them one after each other into the local repository. If some >>> versions would not compile, the job would fail and send an alert. This >>> hasn't affected already released versions. Is something similar >>> possible with maven? >>>
I use freestyle projects and if you are using v-m-p you will need to use them too. I just set up a big fat aggrigator for each of the "test everything together" projects that I want to run CI over. I use svn:externals to check everything out and then two maven builders, first to update the aggregator and all child modules to link them together and the second to run "verify". That way I never pollute the local repo... and these types of build run less frequently (hourly), so the slower build is less of an issue. -Stephen >>> regards >>> Leon >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
