Thanks for the insight, it all makes sense and as a Maven user I fully support the principle of putting control of the cross-cutting in the hands of the user.
I'm still interested to know the answers to the following in the context of Maven 1.0: 1. Does maven.xml inheritance currently only happen when sub-projects run within the reactor? 2. Does project.properties and build.properties inheritance currently only happen when sub-projects are run within the reactor? If so, what's the reasoning behind this decision? Thanks, Matt. > -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: 01 July 2004 06:13 > To: Maven Users List > Subject: Re: Need to load common goals from sub-projects maven.xml > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
