Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Message-ID: <9e3862d804070105335c78e6d0@mail.gmail.com>
Date: Thu, 1 Jul 2004 22:33:59 +1000
From: Brett Porter <brett.porter@gmail.com>
To: Maven Users List <users@maven.apache.org>
Subject: Re: Need to load common goals from sub-projects maven.xml
In-Reply-To: <4953851349197503280@unknownmsgid>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <4953851349197503280@unknownmsgid>

1) no, it matches project.xml inheritence
2) as for 1

On Thu, 1 Jul 2004 10:08:06 +0100, Matt Read <mread@spotd.co.uk> 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:jvanzyl@maven.org]
> > 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
> > <brett.porter@gmail.com> 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
> > jason@maven.org
> > 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org