1) no, it matches project.xml inheritence 2) as for 1 On Thu, 1 Jul 2004 10:08:06 +0100, Matt Read <[EMAIL PROTECTED]> wrote: > > 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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
