maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafal Krzewski <Rafal.Krzew...@caltha.pl>
Subject Re: smart reactor proposal
Date Wed, 04 Jun 2003 11:23:24 GMT
Aslak Helles√ły wrote:

> Imagine I have 3 sub projects a,b and c with the following dependencies:
> a<-b<-c.
> 
> The 1st time I run reactor everything is built. Then I modify b and run
> reactor again. a doesn't depend on b and therefore shouldn't be rebuilt.
> The reactor should now only build b and c.
> 
> I think this can be implemented quite simply by doing some date
> comparisons between java sources and classes in each project.

Do you happen to know unix utility called 'make'? :-D I hope that at
some point Maven will be able to take advantage of 30 years of
experience of the make community.

The problem is that determinig weather the project is 'up to date' is
not so simple anymore. Suppose you have your project 'b' that depends on
project 'a'. You are asking maven to rebuild project 'b', so maven tries
to determine if project's dependencies are up to date. Now. Most of the
dependencies are binary only, downloaded from remote repo, some of the
dependencies however are available in the users' workspace (think
Eclipse) in the source form. Maven would have to keep some sort of
registry in the users' MAVEN_LOCAL_HOME that would associate artifacts
from the repository with projects in the users' workspace (in Eclipse
sense, or just on the local file system). Using this registry maven
would be able to detect that it should check if project 'a' in the
users's workspace is up-to-date before proceeding with building project
'b'.
How could maven determine if the artifact from project 'a' sitting in
the repository is up to date? I guess it should start by determing
what plugin is responsible for generating and deploying that particular
artifact type. Then it should somehow discover the chain of plugins
that ineroperate to provide the artifact-generating plugin with it's
input. And then it should go over the plugin chain bottom to top and ask
each plugin if it's output files seem to be newer than it's input files.
In a simple scenario java plugin would be consulted, and then jar
plugin. The chain might be much longer, and possibly branched, for more
complicated setups involving aspects, grammars, xdoclet, stub/tie
generators and the like. If any of the plugins detects new/modified
source files it should perform a rebuild of it's piece of work, and all
plugins down the chain (or branch, to be more specific) should perform
an unconditional rebuild. As a result, we expect an updated version
of the project's 'a' artifact being deployed to the local repository,
if any of the project's a source files changed.

As you see this is rather complicated process... Luckily Maven-new will
allow us to define more strict plugin contracts, including optional
contracts like the ability to participate in artifact processing
pipelines and incremenatal/partial rebuilds.

R.


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


Mime
View raw message