versions-maven-plugin looks like something that could fit my needs. Since I'm new to maven I haven't understood everythingh you wrote but I'l give it closer look as soon as I find time. Thanks for the help!
2009/3/6 Stephen Connolly <[email protected]> > 2009/3/6 Martin Eigenbrodt <[email protected]> > > > > > > > The release plugin *is* clever enough to ask you if you want to > > > replace SNAPSHOT versions in your dependencies with real release > > > versions. Once it's gotten the necessary information from you, it > > > makes the edits on your behalf. A good feature, that. > > > > > > But that means I have to (manually?) build a release version for each > > dependency used > > . > > > > > > > > > > > The problem with "always picking the latest build" is that you won't > > > know anymore which that was when you check out a two-month old tag > > > form source control and try to repeat the build. I > > > > > > That is exactly my Point. I dont wan't to have "pick latest version" in > the > > tag, just in the trunk. > > > > I'll try to explain again what I'd wish to have. The pom in the Trunk of > > Project B should contain: > > <dependency> > > <groupId>MyId</groupId> > > <artifactId>A</artifactId> > > <version>PICK THE LATEST</version> > > </dependency> > > > > If I release this today the tag created in source control should look > like: > > > > <dependency> > > <groupId>MyId</groupId> > > <artifactId>A</artifactId> > > <version>2.4</version> > > </dependency> > > > > Releasing the same trunk tomorrow without any changes might lead to > > > > <dependency> > > <groupId>MyId</groupId> > > <artifactId>A</artifactId> > > <version>2.5</version> > > </dependency> > > > *BUT* trunk should never have a non -SNAPSHOT version... the only place > where you should have non-SNAPSHOT versions are in tags > > I think you probably want to use something like > versions-maven-plugin:update-properties to manage this for you... you might > be able to get away with a preparation goal that was a little smarter... > > for example if your aggregator pom from which you are rolling the release > has a preparationGoal of > > versions:update-properties invoker:run > > and you have configured invoker:run to invoke maven on the current project > with the goals of "clean verify" > > Then you will automatically get the versions of artifacts linked by > versions-maven-plugin updated, and as invoker is re-parsing the pom, "clean > verify" will be run on the modified pom. > > The release plugin will then check in the modified pom with the versions > updated providing that "clean verify" worked > > Hmmmm... note to self... should try this > > > > > > > > > If A has changed in the meantime. The tag version from today would still > be > > pointing to "2.4". > > > > > > > too have projects > > > where I want my dependencies to always go to the latest build. I just > > > go through the drudgery of updating users when such a library has a > > > new release. > > > > > > Since i want the projects to pick up the latest build I would have to go > > through the drudgery after > > every commit. I mean this is what CI is all about: Every commit in > Project > > A > > does not only trigger > > a build of Project A but does build all downstream Projects with the new > > version of A to show > > any integration problems. > > > > You might wan't to look at ivys deliver task ant the replacedynamicref > > attribute: > > http://ant.apache.org/ivy/history/latest-release/use/deliver.html > > > > Martin > > > > > > > > > > Speaking of releases, I read something in Sonatype's Maven book about > > > using RELEASE as the version for a dependency. Supposedly this will > > > always take the newest released version (SNAPSHOTs are not > > > considered). It hasn't worked for me (mvn 2.0.9), I assume this > > > feature will come along in the next version. > > > > > > // ben > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > >
