2009/8/31 Lewis, Eric <eric.le...@ipi.ch> > > The whole point is to only remove -SNAPSHOT from dependencies > > _which have > > actually been released_ > > Yes, I know. However, our release build is a bit different, because we have > all the internal versions in one POM, and the build "masters" should release > that before the actual projects are released. It forces the developers to > use the released projects. >
Well I'm hoping to refactor v-m-p real soon now to split out the version checking stuff as an api .jar which would allow writing an m-enforcer-p rule to allow you to force projects to only release with the latest version of internal dependencies > > > > > If we remove -SNAPSHOT from dependencies which have not been > > released then > > we'd break your build. > > This is true... so you would suggest that for instance project A is > released, then the parent POM is adapted using versions:use-releases for > project A; then project B is released, and the same happens again? > In that case (as I was already thinking), the parent POM has to be replaced > in the repo every time a project is released. Which is kind of a hack, but I > don't see any other way... I wonder what "the Maven way" is for that. > I would suggest in such a case not to use a parent pom to force versions, or else to release everything in one go from the parent pom... or else accept that the parent pom (which is really an integration pom) will get a lot of churn. The "Maven Way" as I see it is to let projects define their dependencies. with the versions-m-p you now have reports to tell you when the project is not using the latest versions... and not using the latest version of something is not a crime... it might be more stable.... for example the latest version of Hudson is not always the most stable (though the new weekly release cycle is improving that) > > > > And versions:set is more magic than you think.... > > > > if you have the following structure > > > > /pom.xml > > foo/pom.xml > > bar/pom.xml > > manchu/pom.xml > > foo-manchu/pom.xml > > > > and foo-manchu depends on bar > > > > if you change directory into /foo/bar and run mvn versions:set > > -DnewVersion=2.0 > > > > then versions plugin will (by default or via a property, I > > forget) dance up > > the directory tree for as long as there are aggregator pom's until it > > reaches the top of the tree... then it will dance down looking for all > > projects that depend on bar:oldVersion and update them to the > > newVersion. > > This is a great feature, but we can't use it for two reasons: > - As I mentioned, we have a parent POM with all our versions, and no > project ever uses versions in its POM. > - We build project by project (using Hudson), we don't have a full reactor > build. > > > > > -Stephen > > > > 2009/8/31 Lewis, Eric <eric.le...@ipi.ch> > > > > > Sorry, I wasn't precise enough. > > > I mean to do this *only* with the dependencies in that POM, > > not with the > > > version of the POM's project. > > > > > > Best regards, > > > Eric > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > > > > Gesendet: Freitag, 28. August 2009 18:16 > > > > An: Maven Users List > > > > Betreff: Re: Force versions plugin to remove snapshots > > > > > > > > versions:set -DnewVersion=7.8.9 > > > > > > > > 2009/8/28 Lewis, Eric <eric.le...@ipi.ch> > > > > > > > > > Hi > > > > > > > > > > With our build, we have a top-down approach to our > > > > releases: We have a > > > > > hierarchy of POMs, and the one closest to the project > > > > contains all versions > > > > > of all our projects. > > > > > Now, to release that, we have to remove the -SNAPSHOT from > > > > the versions. I > > > > > wanted to do this with the versions plugin, but it insists > > > > on finding the > > > > > releases in the repository. > > > > > > > > > > Is there any other way I could achieve that? > > > > > > > > > > Best regards, > > > > > Eric > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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 > >
