Re: Need to load common goals from sub-projects maven.xml

[Dion Gillard <di...@gmail.com>]

On Wed, 30 Jun 2004 16:28:18 +0100, Matt Read <mr...@spotd.co.uk> wrote:
> 
> > From: Maczka Michal [mailto:michal.maczka@imtf.ch]
> > 
> > No! preGoals should not be used by plugins.
> 
> Ok, so these aren't behaving themselves?
> 
> cache\maven-antlr-plugin-1.2\plugin.jelly(59): <preGoal name="java:compile">
> cache\maven-antlr-plugin-1.2\plugin.jelly(63): </preGoal>
> cache\maven-html2xdoc-plugin-1.3\plugin.jelly(102): <preGoal
> name="xdoc:jelly-transform">
> cache\maven-html2xdoc-plugin-1.3\plugin.jelly(108): </preGoal>
> cache\maven-latex-plugin-1.2\plugin.jelly(82): <preGoal name="xdoc">
> cache\maven-latex-plugin-1.2\plugin.jelly(86): </preGoal>

Nope, they're doing exactly what they should do. That's what preGoals are for.

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

RE: Need to load common goals from sub-projects maven.xml

[Matt Read <mr...@spotd.co.uk>]

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 
> <br...@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

Re: Need to load common goals from sub-projects maven.xml

[Jason van Zyl <jv...@maven.org>]

On Thu, 2004-07-01 at 00:22, Dion Gillard wrote:
> On Thu, 1 Jul 2004 13:16:02 +1000, Brett Porter <br...@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

Re: Need to load common goals from sub-projects maven.xml

[Dion Gillard <di...@gmail.com>]

On Thu, 1 Jul 2004 13:16:02 +1000, Brett Porter <br...@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.

> 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? A rose by any other
name...

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

Re: Need to load common goals from sub-projects maven.xml

[Brett Porter <br...@gmail.com>]

It's a bad thing inside plugins though as you have these things
sneaking into your build process.

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)

- Brett

On Thu, 1 Jul 2004 08:33:59 +1000, Dion Gillard <di...@gmail.com> wrote:
> 
> On Wed, 30 Jun 2004 16:28:18 +0100, Matt Read <mr...@spotd.co.uk> wrote:
> >
> > > From: Maczka Michal [mailto:michal.maczka@imtf.ch]
> > >
> > > No! preGoals should not be used by plugins.
> >
> > Ok, so these aren't behaving themselves?
> >
> > cache\maven-antlr-plugin-1.2\plugin.jelly(59): <preGoal name="java:compile">
> > cache\maven-antlr-plugin-1.2\plugin.jelly(63): </preGoal>
> > cache\maven-html2xdoc-plugin-1.3\plugin.jelly(102): <preGoal
> > name="xdoc:jelly-transform">
> > cache\maven-html2xdoc-plugin-1.3\plugin.jelly(108): </preGoal>
> > cache\maven-latex-plugin-1.2\plugin.jelly(82): <preGoal name="xdoc">
> > cache\maven-latex-plugin-1.2\plugin.jelly(86): </preGoal>
> 
> Nope, they're doing exactly what they should do. That's what preGoals are for.
> 
> 
> 
> ---------------------------------------------------------------------
> 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