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] > > > > >
