On 6/1/10 11:24 AM, Ron Wheeler wrote: > The documentation is a bit light. > > Are there any particular things to watch out for in the release plug-in? 1) Know how to back out of a failed release. 2) Try not to have failed releases.
> Is it smart enough to fix the version of the parent pom in the project pom? If fix == update, then no, the release plugin won't do this by default. You can, however, add this by setting the preparation goals to include versions:update-parent and scm:checkin" > What about authentication to the SCM? Not sure what you mean here. > > > We have 60+ modules in a portlet application and it would be nice to > have a batch job that produced a release from a SNAPSHOT. The release plugin can be used in multi-module scenarios. Justin > > > Ron > > > On 01/06/2010 10:15 AM, Shan Syed wrote: >> I don't fully understand your scenario, but do you use the "release" >> plugin? >> http://maven.apache.org/plugins/maven-release-plugin/introduction.html >> >> if you maintain your pre-release code as "SNAPSHOT so-and-so", this >> plugin >> will help you make a release version out of it without having to edit >> POMs >> manually >> >> >> >> On Tue, Jun 1, 2010 at 10:09 AM, Andrew Close<acl...@gmail.com> wrote: >> >> >>> the organization that i currently work at is in the process of >>> updating our POM hierarchy. we're moving to a common company SuperPOM >>> which everyone will inherit from as opposed to the handful of >>> semi-SuperPOMs we have now. :) we currently have over 300 artifacts >>> that are downstream of this architecture and we'll be rolling this >>> model out in phases since it would be very difficult to schedule a >>> release with all of our artifacts at once. we're hoping to take >>> advantage of the common plugin management and dependency management to >>> keep our third party dependencies more manageable. this sounds good, >>> but i'm guessing we'll get halfway through the rollout and realize >>> that we need to make some changes to the SuperPOM, which entails a new >>> version, which means updating all the downstream artifacts so they >>> inherit from the new parent. this could become a very vicious cycle. >>> >>> so, the question i have is how do other large organizations with this >>> model handle versioning their SuperPOMs? do you actually update the >>> version and then go through all the artifacts and update their parent >>> block? or do you keep the SuperPOM at a static version (probably not >>> a very good idea) so all updates are handled dynamically? >>> is there a way to enforce which version of the SuperPOM should be >>> used? or at least warn the developer that there is a newer version of >>> the SuperPOM that they should be inheriting from? >>> >>> >>> -- >>> Andrew Close >>> >>> --------------------------------------------------------------------- >>> 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
