On 01/06/2010 12:37 PM, Justin Edelson wrote:
On 6/1/10 12:02 PM, Ron Wheeler wrote:
On 01/06/2010 11:30 AM, Justin Edelson wrote:
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.
Any hints about how we get to know this?
Know what your release process does and know how to reverse it. For
example, the release plugin will create a tag in SCM. Some organizations
disallow the removal of tags by regular users, so if a release fails, an
admin may need to remove the tag OR a new tag name must be used.
Ok.
2) Try not to have failed releases.
We do what we can!
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"
OK. Will look up how to do this.
What about authentication to the SCM?
Not sure what you mean here.
Our subversion requires usernames and passwords for each person.
If the credentials in the Subversion credentials cache are wrong, then
the release preparation will fail.
We always use Eclipse to access our svn so I guess that I will have to
do some digging here to see where Maven expects to find the credentials..
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.
Sounds like a real time-saver.
It is, but as someone else noted, it does require testing. Your first
release should NOT be 60 projects.
You mean we can't apply our "No guts - no glory" guidelines.
Thanks for your help Ron
Justin
Thanks
Ron
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
---------------------------------------------------------------------
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
