--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
A man enjoys hsi work when he understands the whole and when he
is responsible for the quality of the whole
-- Christopher Alexander, A Pattern Language
--- Begin Message ---
Daniel Kulp wrote:
Jason,
That's not exactly true. The fact that the plugin created a new version
of a file is an irreversible change in many (most) SCM's. Yes, you can
alway checkout an older version of the file to restore it, but the fact
is, in the the history, you now have another version. Also, various
SCM reporting tools, etc... will now report that version/file as changed,
cruisecontrol/continuum will trigger a build, etc....
That said, going through and "restoring" a bunch of pom.xml files can take
time which is something that we usually don't have around release time.
All those things are true, they are annoying, and can be time consuming
but not irreparable.
Definitely good advice. When I make another pass at the release plug-in
I'll add some notices until the release plug-in is production quality.
I think it's widely known that the release plug-in is not production
quality yet but we usually warn people in back channels. It should be
more up-front with the release plug-ins capabilities.
Agreed. The release plugin guide doesn't really mention that it isn't
completely production ready. My boss was glad I was experimenting with
it in our test repository and not the production one.
It's clearly marked as a beta. It's never had a full release.
Cause of that, we're going to be writing some perl
scripts or something to do something similar.
Why not try to help improve the release plug-in?
I wish I could, just no time. It's very easy to do a perl
search/replace for the version string and run a "svn cp trunk tags/TAG"
type of thing. It doesn't do everything the release plugin would do
(verify snapshot usage, etc...), but "good enough" for us for now.
I've heard that before :-) People try to redo small plug-ins all the way
up to trying to replace Maven and it generally results in spending more
time overall but in the short term, sure it's good enough.
A dry run mode would certainly be valuable. If that's not in JIRA I'll
add that.
dry run.... That's the phrase I was searching for. I was going nuts
this morning trying to think of that. I must be losing my mind... :-(
Thanks!
No problem.
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more examples
you look at, the more general your framework will be.
-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
--- End Message ---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
