maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark H. Wilkinson" <mhw-m2-...@kremvax.net>
Subject Re: #1 thoughts on the goal chain
Date Tue, 11 Jan 2005 10:21:17 GMT
On Tue, 2005-01-11 at 20:20 +1100, Brett Porter wrote:
> I'm all for plugins acting appropriately on the correct set of files, 
> and for correctly defining their inputs and outputs. But what about the 
> following situations:
> - a plugin doesn't actually affect any files (scm, deployment, ...)

This is typically handled (in Unix make) by using virtual (or 'phony')
targets: targets that exist in the dependency graph, but which don't map
to real files in the file system. They are always assumed to be out of
date with respect to their dependents, so they will always be built when
the user asks for them to be built. So, jar:deploy would be a virtual
target that depends on jar:jar; the action to bring jar:deploy 'up to
date' would be to deploy the jar file to the remote repository.

Effectively this gets the user to do the decision making about when
virtual targets should be built.

> - the timestamp of the file is not relevant to when a file needs to be 
> processed - for instance configuration has changed that is within the 
> scope of the plugin, not the file itself.

There are two possible ways to handle this that I'm aware of:
     1. The configuration information is held in a file somewhere, so
        include that file (or files) in the dependency graph. At the
        worst, touching ~/build.properties will cause everything to
        rebuild.
     2. Ignore configuration information held in files. Make the users
        aware that changing configuration will normally require a build
        from clean afterwards.
I've seen both approaches used in Unix make build systems. The first
approach tends to work better for more complex builds, and is used by
the GNU automake program. It can be confusing in that environment
because the generation of the Makefile (i.e. the dependency graph) is
included in the Makefile, which is somewhat circular. I don't imagine
that this would be a problem for maven as I'm not suggesting that a
representation of the dependency graph become part of the project source
tree.

> I also don't think that targetting individual artifacts for a build is 
> very easy to use.

For the end users? I would expect that the standard plugins would
include a number of convenience virtual targets. In the example in my
previous email I included a 'jar:jar' virtual target that depended on
the project's artifact being up to date. Normal operation for the end
user will likely use the short names they are using today.

> >      * The user can create any intermediate target. For example, you can
> >        'm2 target/surefire-reports/org.codehaus.plexus.PlexusTestCaseTest.txt'

> I'm not sure this is entirely useful, sorry.

Our experiences must differ then - I've often wanted to regenerate a
single report in the generated site over and over again (e.g. getting
the checkstyle errors out of a source tree).

> >An addition is that the user could explicitly force a plugin to be
> >loaded by referring to one of its targets on the command line. Hence 'm2
> >antlr:translate jar:jar' would force the antrl plugin to load and its
> >dependencies to be added to the dependency graph.
> >
> That's not autonomous enough. A user should be able to pick up any 
> source tree and run "m2 jar:jar" and get a complete jar.
> If antlr:translate were required - they'd get compile errors and 
> confusion first up. The need for antlr must be defined somewhere in the POM.

Agreed - if antrl were required for the build it should be included in
the POM. Perhaps that was a bad example. There are some other use cases
where being able to just name a plugin on the command line would be
useful:
      * When you have no source tree checked out. For example, building
        new project templates, checking out source trees and so on.
      * When you want to apply a tool to a project without integrating
        it into the build. For example, you might download a project and
        run 'm2 clover:report' to have clover do its stuff just that one
        time. If things work out you might then include it in the pom,
        but being able to trigger things from the command line allows
        experimentation.
      * Limiting the amount of work that m2 has to do. I guess most
        maven projects currently have two main goal chains: build the
        jar file and build the web site. If the user says 'm2 jar:jar'
        we don't need to load the site generation plugin, so we don't
        need to process all the extra dependency information.
        Conversely, 'm2 site:generate' would force the site plugin to
        load, pulling in the extra dependencies that it defines.

-Mark.


Mime
View raw message