maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maczka Michal <>
Subject RE: [jira] Work started: (MNG-173) pom changes
Date Thu, 10 Mar 2005 11:02:42 GMT

> -----Original Message-----
> From: Brett Porter []
> Sent: Wednesday, March 09, 2005 8:12 PM
> To: Maven 2 Developers List
> Subject: Re: [jira] Work started: (MNG-173) pom changes
> Michal Maczka wrote:
> > I am thinking about cases like groovy. You should be able to define 
> > once and only once the place
> > where are located your groovy sources and  plugins like groovy 
> > compiler, groovy version of jxr, checkstyle, javadoc
> > etc should work out of the box. Obviously "default" layout  of 
> > directories for
> > projects using groovy  can be inherited so imo it make 
> sense to put it 
> > to pom
> We will add a script source root.


> >
> > In short I think that non standard settings which are crosscutting 
> > multiple plugins might be very helpful
> Examples, other than those I have already covered off?

How you are going to support aspectj and accompaing tools (e.g. aspectj's
javadoc like tool)

> > for limiting number of places where some value must be changed. 
> Anything that needs it should be stored and pipelined from the first 
> plugin through to further uses, like the source roots are.

Aren't you assuming that maven will be the only tool which is using poms and
that "magic" processing and computing of some properties
which is performed by plugins should be repeated by any other other tools?

> > For example now if you are going to use jdk 1.5
> > with maven1 you have to set way to many properties in your pom. 
> That's a flaw in the backwards compat of the JDK javac - a smarter 
> compiler plugin can avoid this. How is this relevant?

I don't understand what are you trying to say.
How is for example the javadoc plugin (and its maven.javadoc.source
property) related to compiler plugin and some settings of javac compiler?

> > We also have many plugins taking settings from other plugins.
> Poor design AFAICT, often necessitated by the lack of a defined 
> lifecycle (eg, resetting the test failure ignore property on the test 
> plugin).

> > And this is not very good thing as plugins should not use other 
> > plugins and their settings,
> > Both those problems can be solved in generic way if plugins 
> had access 
> > to non standard (means not having dedicated xml tag)
> > properties of pom.
> This isn't solving the problem, it's avoiding it.

What you are proposing can (probably) lead to the same thing but performed
dynamically (common settings will be  computed and then kept in sessions,
requests etc) but I don't see how this it is that fundamentally different
from having some static common settings kept in pom. 
The only difference is that I am assuming that it should relatively easy to
dig some information in the pom without the help of maven plugins. 
So more magic happens at the runtime - the harder it gets to write such
tools. Project inheritance, transitive dependencies, pom interpolation make
it already practically impossible to use pure "pom model" - this machinery
which is implemented in maven core is needed for assembling all those
dispersed pieces together. Now plugins and artifact handlers are going to be
added to that mix. This is actually quite cool thing. But every stick has
two ends.
More complicated this will get - the slower, harder and more fragile the
processing of transitive dependencies is going to be (as many files are
involved in that process). And nobody will be really able to reuse poms
without maven. So what I think is that that "dynamic" approach has some cost
and risks associated with it. 

One of the cool thing about the pom in m1 when project inheritance was not
yet used  was that pom represented in static way some common facts about the
project, which were shared by multiple plugins. Some of those settings are
standard hence they have corresponding XML elements. 
Some are not standard but this does not mean that they cannot be a part of
the pom and cannot be shared by the plugins 
The information sharing between tools an plugins  - this is for me the
primary function of pom. 
The fact that it contains the configuration of some particular maven plugins
is a secondary concern for me. I don't need pom for that. 
I can as well keep configuration settings of individual plugins in separte
files (like it happens in case of for example checkstyle).

I really want to see how you can solve the problem that JDK version is
needed for both (among others) apidoc and compiler plugin assuming that JDK
version not will be added to pom. And how you will be able to do something
like "maven javadoc" in m2 with  the correct version of maven.javadoc.source



View raw message