On Thu, 2004-07-01 at 00:22, Dion Gillard wrote: > On Thu, 1 Jul 2004 13:16:02 +1000, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > It's a bad thing inside plugins though as you have these things > > sneaking into your build process. > > If they do nothing when not needed, as most of these do, then where's the harm.
The complexity involved in managing the dependencies among the plugins. Brett is the only person besides myself that understands the clusterfuck of code required to manage goal decoration amongst plugins. It was removed as an option in m2 for clarity: goal decoration is only within the purview of the user. This pattern is used in many of the plugins we have in maven1 but it's not enforced. Plugins like the antlr plugin do some magic with pregoals and it's not clear at all what's going on. Plugins of the form that Vincent tends to use are clear because it is soley up to the user to perform the goal decoration in order to harness the functionality of a plugin. Allowing plugins to decorate goals from other plugins can lead to undeterministic behaviour, especially when it is so easy in maven1 to frob the context wherever you like, affect parent contexts and access variables from other plugins. A user explicity stating what is to happen in a build prevents unwanted side effects from plugins being added to the system. Right now in maven1 I could right a plugin that could adversely affect every build. A case in point being the old AspectJ plugin which decorated the standard compile goals which caused the AspectJ jars to be downloaded. This is all easily avoided by putting the control in the hands of the user where it belongs. The code required to manage goal decoration amonst plugins in maven1 is nothing short of a ratfuck. Purely unmanageable and requires some pretty funky contortions to make it work. The harm is potentially vast. > > In m2 the model is more along the lines of registration into the build > > process at defined points (like how xdoc/site does the reports) > > That sounds awfully like pre/post goals to me. So plugins would > 'register' to be invoked as part of the process? No, the plugins would not 'register' anything. The whole point of the change is to make explicit from the user's end how the plugins interact. How Vincent tends to use the plugins is how things should work in maven1 where the functionality is provided in the plugin but it is the responsibility of the user to decorate any desired goals to invoke the plugin in question. Plugins should be entirely indifferent to the process. How they are combined should be explicity controlled by the user for the sake of clarity, ease of use, and ease of maintenance. -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
