On 8/31/06, Wayne Fay <[EMAIL PROTECTED]> wrote:
Download the code for the plugin(s) from SVN/CVS.
Increment the version number to a fixed/released number, build,
install locally and deploy to your corporate repo (if you have one) or
provide it to your coworkers some other way.
Update your pom to reflect the new plugin version number.
Generally I would suggest you incorporate a timestamp into the build
number ie maven-war-plugin 2.1.20060830 just to keep it clear that
this is not necessarily a real release.
Make sure you understand the artifact version system before picking a
build number, or else you could easily end up with a situation where
the "official" plugin releases a new version but your internal plugin
is still considered "newer" ie if a plugin last released 2.0.5 and is
currently releasing 2.1-SNAPSHOT, you might want to tag yours as 2.0.6
or 2.0.5.1 -- if you tag it as 2.1, then you won't get the "real" 2.1
release when it is final. (Of course, if the plugin release 2.0.6 then
you'll get a collision there too...)
I wrote this up here
http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins
It's what I used to release our team's code which needed snaphot
plugins + patches.
The wiki docs assume the next release is going to match the -SNAPSHOT
version being developed and that a younger release won't sneak in for
some critical reason.
Of course, the docs do warn you that when a release is made that you
need to double check it includes any patches that you manually
applied, as you may need to re-apply them.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
