I've been thinking about this more, and I really think it's a bad
idea to scrap extensions completely. The more work I do on
conversions, etc. the more I see that there is a need to tweak Maven
here and there for certain projects. A great case-in-point here is
profile activators...without extensions, it would be impossible to
write a custom profile activator and have any hope of getting it
included in the Maven build environment.
I think that rather than conflating implementation problems with
design problems, we should be thinking about how to fix the
implementation and make it intuitive. I'd actually be much more in
favor of making the extension mechanism more rich, rather than
removing it, so we can support custom components in this component-
oriented system. There are legitimate cases where using the plugin as
a vector for bringing in extensions is simply inaccurate. Also, it's
not a great option to modify the Maven installation itself (I'm sure
we all cringed when I said that just now)...so extensions are all
that's left to us in many cases.
I'm definitely -1 for this, the more I think about it. If they don't
work for someone, we could probably look more closely at some sort of
policy enforcement that would prohibit the use of extensions...but
ironically, this would probably have to be carried out via an
extension of some sort (barring the enforcer-plugin, which would have
to have its own dedicated lifecycle phase to be absolutely sure
nothing executed in the build ahead of it).
-john
On Sep 20, 2007, at 3:40 AM, Milos Kleint wrote:
I might have another usecase in toolchains
(http://docs.codehaus.org/display/MAVEN/Toolchains)
A toolchain definition that is not part of the default set needs to be
added as extension to the build. It's accessed by multiple plugins and
therefore it's rather impractical to add it as dependency to each
plugin that uses it.
Milos
On 9/4/07, John Casey <[EMAIL PROTECTED]> wrote:
On Sep 4, 2007, at 5:34 AM, Jason van Zyl wrote:
The biggest offender are providers posing as extensions: wagon-
webdav is not an extension, it is a dependency required by the
deploy plugin. In the exact same way you would specify an SCM
provider as dependency of the release plugin if you needed, say,
ClearCase support. These are not general extensions they are
specifically required by certain plugins and should be defined as
such to scope their use. Dumping wagon-webdav into the core is not
very bright considering it's use is limited to the deploy plugin.
This is an oversimplification. Wagons are also used in resolving
artifacts, and while this is not a useful example WRT webdav, the ftp
or scp wagons could easily be required for resolving
dependencies...which is not a plugin task.
-john
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
