On 29 Oct 07, at 9:35 PM 29 Oct 07, William Ferguson wrote:
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Yes, I know we discussed it briefly at the time, but I
wanted to look at the actual implications for 2.0.x users now.
There are none, they aren't using it. And it's only
implication is in conjunction with the release plugin and the
release plugin should not be tied to any information in the
super POM. That's just wrong.
If anyone expects the same
behavior that then can put that chunk of the POM in theirs.
As of right now there are zero people affected and the
release plugins is pretty much useless to anyone who is not
using subversion. It's useless for Clearcase users and
useless for Perforce users which is a large part of the
enterprise environment so overall the clean up is the right
thing to do as it simply should not be in the Super POM and I
really doubt anyone can rely on it for production use. It's
just too flaky.
Jason, I agree that the release-plugin shouldn't be tied to any
information in the super POM.
But I think you'll find that there are *lots* of teams using the
release
plugin in production environments.
I doubt that given my visitation of production environments. But that
said the portion from our own POM provides the same functionality, or
it would even be preferable in subsequent versions of the release
plugin to make these goals default. The problem therein is selecting
the right version. Ultimately any sane group of developers wants to
see this information in their face. What is being used to produce the
release and what version of any tools/plugins being used.
Its not perfect, the inability to
bind Mojos to its life-cycles is almost crippling, but it's the only
thing that remotely guarantees a consistent release process.
This will not change the way binaries are produced and released. The
sources/javadocs not being release would affect IDE usage, but easier
remedied with a snippet of our POM in the release plugin documentation.
So if this involves a large behaviour change for existing 2.0.x users
then there's going to need to be a suitable warning with an easy to
implement mitigation strategy.
William
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
