You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Aslak Hellesøy <as...@netcom.no> on 2003/06/04 11:47:18 UTC
smart reactor proposal
Sorry if this has been brought up before, but I have an idea about how
to make the reactor smarter/quicker.
I have a project with lots of subprojects that are built with reactor. I
want to reduce the build time by making the reactor smarter.
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.
I'm planning to implement this feature, but before I do, I'd like to
hear some opinions.
Cheers,
Aslak
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: smart reactor proposal
Posted by Rafal Krzewski <Ra...@caltha.pl>.
Mark H. Wilkinson wrote:
> I'm wondering if there's a fundamental reason why we couldn't change
> maven to build a dependency graph of files with scripts attached to the
> arcs, just like make used to do. Statements and scripts would need a way
> to expose the lists of source files and target files to the maven core
> to build the dependency graph, but that doesn't seem like an
> insurmountable problem. The reactor would become a way to stitch
> dependency graphs together, saying that when one project runs the
> jar:install script to bring $MAVEN_REPO/group/jar/foo-1.0.jar
> up-to-date, this is the same artifact that another project has declared
> in its project.xml. But the result would be the ability to work out the
> minimum set of scripts that need to be run across a large reactor build
> purely by checking timestamps on files and without going through the
> process of running every step in the process.
I think there is no such fundametal reason. Maven is just following Ant
design in this regard, but I don't see why all of the current
functionality could't be provided within the framework you are
describing. The piece missing from the picture above are 'phony
targets', make targets that don't correspond to a physical file.
Maven would provide many such targets, in fact all of the 'goals'
that the plugins have exactly this nature. In essence Maven (and Ant)
can be though of like make that supports phony targets only.
Once Maven is able to build dependency graph that includes not only
'goals' but also source files, intermediate build products and final
artifacts, a further optimisation available would be using special
timestamp files corresponding to phony targets. It makes sense only
if at least one phony target depends on a real physical source file
of course.
This is definetely a very interesting idea. I hope we can work on
implementing this after 1.0 is out.
R.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: smart reactor proposal
Posted by "Mark H. Wilkinson" <mh...@kremvax.net>.
On Wed, 2003-07-02 at 12:18, Jason van Zyl wrote:
> On Wed, 2003-06-04 at 05:47, Aslak Hellesøy wrote:
> > I think this can be implemented quite simply by doing some date
> > comparisons between java sources and classes in each project.
>
> Did you ever make any progress on this because I was going to add some
> stuff to JIRA about uptodate checks in general for docs. There are some
> checking utilities in CruiseControl and there is some stuff in DVSL
> itself so I'm going to steal something and make a general tool.
Hrrm; I started writing up my thoughts on this yesterday to save for
after 1.0 was out, but I guess I should air them now. Basically, I think
that the problem is that neither ant nor maven currently do dependency
checking in the way make used to, and I think that this hurts maven more
than ant because maven's plugin system leads to larger graphs that
describe the build system. The following is quite long, but hopefully it
explains the problem. (Well, what *I* think is a problem, anyway. I'm
sure others will likely disagree with my opinions... :-)
In a nutshell, make builds a dependency graph where the nodes are files,
arcs are dependencies and arcs are annotated with commands that can be
used to bring files up to date if their timestamps indicate that
something is out of date.
Ant builds a dependency graph where the nodes are scripts and the arcs
describe the order in which the scripts ought to be run.
When you run make you tell it which file you want it to build, and it
works out the minimum set of commands that need to be run to make sure
that file is up to date.
When you run ant you tell it which script you want it to run, and it
works out all the scripts which are required to be run before it. It
then runs every single script, whether needed or not. Some scripts
include statements that take a bit of time to execute, so those
statements make local decisions about what they need to do based on
timestamps, but there's no overall mechanism for file timestamp
dependency checking in build.xml because the dependency graph just
doesn't model that kind of thing.
Maven at the moment is kind-of like ant, with a bunch of plugins that
build a similar dependency graph to describe an idealised build system.
So you get a nice complete build system without having to write a 500
line build.xml. But it's still just a dependency graph that connects
scripts (goals) together.
The reactor resolves dependencies at a different level - where ant (and
normal maven execution) satisfies dependencies between scripts, reactor
satisfies dependencies between artifacts required by one project.xml and
those built by another project.xml. It presumably builds a dependency
graph between Projects based on artifact ids, and then works out an
ordering over those projects.
So the reactor takes multiple script-dependency graphs and works out an
ordering for running named scripts in every project. Not surprisingly
this can lead to maven spending lots of time just running scripts, even
if those scripts don't need to be executed.
One solution to this would be to make more of the individual statements
check timestamps before they run, but this is not easy. It needs logic
adding to every piece of processing that can take a significant amount
of time. It's harder for things that are written in jelly because
there's currently no mechanism for checking timestamps (I think - and I
guess this might be the kind of solution that Jason's alluding to
above).
But having done this, maven would still need to run the entire script
chain so that each statement can confirm that nothing needs to be done.
Another solution is to try to short-circuit the reactor, with some kind
of check to decide on a project-by-project basis whether a build needs
to be done or not. I think this is what Aslak's suggesting.
I'm wondering if there's a fundamental reason why we couldn't change
maven to build a dependency graph of files with scripts attached to the
arcs, just like make used to do. Statements and scripts would need a way
to expose the lists of source files and target files to the maven core
to build the dependency graph, but that doesn't seem like an
insurmountable problem. The reactor would become a way to stitch
dependency graphs together, saying that when one project runs the
jar:install script to bring $MAVEN_REPO/group/jar/foo-1.0.jar
up-to-date, this is the same artifact that another project has declared
in its project.xml. But the result would be the ability to work out the
minimum set of scripts that need to be run across a large reactor build
purely by checking timestamps on files and without going through the
process of running every step in the process.
You probably now see why I was leaving this until after 1.0 was out!
Thoughts?
-Mark.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: smart reactor proposal
Posted by Brett Porter <bp...@f2network.com.au>.
> I'm not sure I can glean the use case from what you're describing. What
> is it you're trying to do?
We have a project which is all one unit, and currently use reactor to
build all the subprojects, some of which are dependant on each other.
Some are JARs and some are WARs.
At the moment, you either build just one, or build them all. The thought
I had was that if you build just one, based on a flag it could also
build its dependencies, so you get a complete build for that one
component, without building other subprojects that you aren't working on
(even if they haven't changed, the reactor takes some time to check that).
eg.
finserv-webapp depends on portfolios and markets
portfolios depends on retriever
markets depends on retriever
So building war:webapp inside finserv-webapp should build portfolios,
markets, retriever via the reactor first.
Just building portfolios.jar though would build only portfolios and
retriever.
Does that make sense? Can you think of an alternative structure that
would alleviate the need to do this?
Cheers,
Brett
--
Web Developer
f2 network ~ everything essential
02 8596 4437
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: smart reactor proposal
Posted by Jason van Zyl <ja...@zenplex.com>.
On Tue, 2003-07-01 at 19:21, Brett Porter wrote:
> Can this also tie in with the aggregator stuff dIon was working on?
Sure, once we have a little tool I'm sure it can be reused.
> I
> think he was specifically looking at docs, but other plugins like EAR
> and Eclipse could certainly make use of it. I'm thinking of some sort of
> generalised "buildable project" dependency infrastructure.
>
> I'm also looking at having my build plugin go through the dependency
> list and use the reactor to rebuild dependencies with the same groupId.
> Is that worth including here?
I'm not sure I can glean the use case from what you're describing. What
is it you're trying to do?
> - Brett
>
> Jason van Zyl wrote:
> > On Wed, 2003-06-04 at 05:47, Aslak Hellesøy wrote:
> >
> >
> > Aslak,
> >
> > Did you ever make any progress on this because I was going to add some
> > stuff to JIRA about uptodate checks in general for docs. There are some
> > checking utilities in CruiseControl and there is some stuff in DVSL
> > itself so I'm going to steal something and make a general tool.
> >
> >
> >>Cheers,
> >>Aslak
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: smart reactor proposal
Posted by Brett Porter <bp...@f2network.com.au>.
ok, I'll keep it in mind and see how this pans out. I'm not sure which
goal I'd want to attach it to or to which plugin it should belong at
this point. We have our own plugin for these sorts of requirements.
- Brett
dion@multitask.com.au wrote:
> Yep, it's all worth including!
> --
> dIon Gillard, Multitask Consulting
> Blog: http://blogs.codehaus.org/people/dion/
> Work: http://www.multitask.com.au
>
>
--
Web Developer
f2 network ~ everything essential
02 8596 4437
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: smart reactor proposal
Posted by di...@multitask.com.au.
Yep, it's all worth including!
--
dIon Gillard, Multitask Consulting
Blog: http://blogs.codehaus.org/people/dion/
Work: http://www.multitask.com.au
Brett Porter <bp...@f2network.com.au> wrote on 02/07/2003 09:21:56 AM:
> Can this also tie in with the aggregator stuff dIon was working on? I
> think he was specifically looking at docs, but other plugins like EAR
> and Eclipse could certainly make use of it. I'm thinking of some sort of
> generalised "buildable project" dependency infrastructure.
>
> I'm also looking at having my build plugin go through the dependency
> list and use the reactor to rebuild dependencies with the same groupId.
> Is that worth including here?
>
> - Brett
>
> Jason van Zyl wrote:
> > On Wed, 2003-06-04 at 05:47, Aslak Hellesøy wrote:
> >
> >
> > Aslak,
> >
> > Did you ever make any progress on this because I was going to add some
> > stuff to JIRA about uptodate checks in general for docs. There are
some
> > checking utilities in CruiseControl and there is some stuff in DVSL
> > itself so I'm going to steal something and make a general tool.
> >
> >
> >>Cheers,
> >>Aslak
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>For additional commands, e-mail: dev-help@maven.apache.org
>
> --
> Web Developer
> f2 network ~ everything essential
> 02 8596 4437
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Re: smart reactor proposal
Posted by Brett Porter <bp...@f2network.com.au>.
Can this also tie in with the aggregator stuff dIon was working on? I
think he was specifically looking at docs, but other plugins like EAR
and Eclipse could certainly make use of it. I'm thinking of some sort of
generalised "buildable project" dependency infrastructure.
I'm also looking at having my build plugin go through the dependency
list and use the reactor to rebuild dependencies with the same groupId.
Is that worth including here?
- Brett
Jason van Zyl wrote:
> On Wed, 2003-06-04 at 05:47, Aslak Hellesøy wrote:
>
>
> Aslak,
>
> Did you ever make any progress on this because I was going to add some
> stuff to JIRA about uptodate checks in general for docs. There are some
> checking utilities in CruiseControl and there is some stuff in DVSL
> itself so I'm going to steal something and make a general tool.
>
>
>>Cheers,
>>Aslak
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>For additional commands, e-mail: dev-help@maven.apache.org
--
Web Developer
f2 network ~ everything essential
02 8596 4437
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: smart reactor proposal
Posted by Aslak Hellesøy <as...@thoughtworks.net>.
Jason van Zyl wrote:
>On Wed, 2003-06-04 at 05:47, Aslak Hellesøy wrote:
>
>
>>Sorry if this has been brought up before, but I have an idea about how
>>to make the reactor smarter/quicker.
>>
>>I have a project with lots of subprojects that are built with reactor. I
>>want to reduce the build time by making the reactor smarter.
>>
>>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.
>>
>>I'm planning to implement this feature, but before I do, I'd like to
>>hear some opinions.
>>
>>
>
>Aslak,
>
>Did you ever make any progress on this because I was going to add some
>stuff to JIRA about uptodate checks in general for docs. There are some
>checking utilities in CruiseControl and there is some stuff in DVSL
>itself so I'm going to steal something and make a general tool.
>
>
Yes I've made some progress on this. It's a little different than my
initial proposal though. It uses Ant's checksum task(+) to update
version numbers (!) Here is how it works:
All versions, i.e. /project/currentVersion and
/project/dependencies/dependency/version are MD5 checksums. And they are
automaitcally calculated and updated by a "preprocessor" to the smart
reactor, using speciaal PomTransformers. There are three steps involved
in the whole process:
1) For each subproject sp, compute a checksum c for all files under
${basedir}/src. Set sp's /project/currentVersion = the value of c. (*)
2) For each subproject sp, update the
/project/dependencies/dependency/version values to use the ones computed
under 1) (*)
3) Run the smart reactor. It will only build projects that have a
project.xml that's newer than the corresponding jar file in the local
repository. Or if the jar doesn't exist.
(*) The project.xml files are only re-written if there was a change in
either /project/currentVersion or /project/dependencies/dependency/version
(+) Relies on a recent Ant patch that is applied in Ant's CVS, and not
yet released (will be in Ant 1.6).
http://issues.apache.org/bugzilla/show_bug.cgi?id=20767
This seems to work very well and captures my requirements. We have close
to 100 subprojects and we're reducing build time A LOT with this. Let me
know if this sounds like a generally useful thing, and I'll wrap it up,
document it and give it back to Maven.
Cheers,
Aslak
>
>
>>Cheers,
>>Aslak
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: smart reactor proposal
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-06-04 at 05:47, Aslak Hellesøy wrote:
> Sorry if this has been brought up before, but I have an idea about how
> to make the reactor smarter/quicker.
>
> I have a project with lots of subprojects that are built with reactor. I
> want to reduce the build time by making the reactor smarter.
>
> 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.
>
> I'm planning to implement this feature, but before I do, I'd like to
> hear some opinions.
Aslak,
Did you ever make any progress on this because I was going to add some
stuff to JIRA about uptodate checks in general for docs. There are some
checking utilities in CruiseControl and there is some stuff in DVSL
itself so I'm going to steal something and make a general tool.
> Cheers,
> Aslak
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: smart reactor proposal
Posted by Aslak Hellesøy <as...@thoughtworks.net>.
> Don't forget that in general case there are not only java sources
> but other types of source files (for example, ANTLR grammars).
>
Sure, I know. But at first I'll DTSTTCPW.
I think it would be nice to have something similar to Ant's uptodate task in the pom, so that Maven can figure out whether a rebuild is needed at all.
Thoughts?
Aslak
> Best regards,
> Alexey
> ---
> Alexey Demakov, ISP RAS
> www: http://redverst.ispras.ru
> e-mail: demakov@ispras.ru
> ICQ 740187
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: smart reactor proposal
Posted by Alexey Demakov <de...@ispras.ru>.
Don't forget that in general case there are not only java sources
but other types of source files (for example, ANTLR grammars).
Best regards,
Alexey
---
Alexey Demakov, ISP RAS
www: http://redverst.ispras.ru
e-mail: demakov@ispras.ru
ICQ 740187
----- Original Message -----
From: "Aslak Hellesøy" <as...@netcom.no>
To: <de...@maven.apache.org>
Sent: Wednesday, June 04, 2003 1:47 PM
Subject: smart reactor proposal
> Sorry if this has been brought up before, but I have an idea about how
> to make the reactor smarter/quicker.
>
> I have a project with lots of subprojects that are built with reactor. I
> want to reduce the build time by making the reactor smarter.
>
> 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.
>
> I'm planning to implement this feature, but before I do, I'd like to
> hear some opinions.
>
> Cheers,
> Aslak
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: smart reactor proposal
Posted by Brian Ewins <Br...@i-documentsystems.com>.
There are a lot more sources in a project than just its java source. For
example, any project with snapshot dependencies may change if its
snapshot jars have changed. You won't know this without actually doing a
build.
Secondly, the reactor takes a list of goals. One of those goals - or
indeed an invocation from a custom goal - could be 'clean'. (maven-new's
maven.xml contains an example of this)
Thirdly, you need to keep track not only of whether the project changed,
but whether the build environment changed. What you describe won't
notice if I change MAVEN_HOME, maven.repo.local, JAVA_HOME, the -o flag,
etc etc. Admittedly neither will javac, of course.
In short: the idea is of dubious value. Individual goals (like
java:compile) can make better decisions about what to do and what not to
do because they are much more focussed, but shortcutting builds at the
reactor level is error prone.
Having said all that, if this was an optional feature, or a different
goal, I'd be happy with it.
-Baz
Aslak Hellesøy wrote:
> Sorry if this has been brought up before, but I have an idea about how
> to make the reactor smarter/quicker.
>
> I have a project with lots of subprojects that are built with reactor. I>
want to reduce the build time by making the reactor smarter.
>
> 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.
>
> I'm planning to implement this feature, but before I do, I'd like to
> hear some opinions.
>
> Cheers,
> Aslak
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Privacy and Confidentiality Notice
------------------------------------------------
The information contained in this E-Mail message is intended only for the person or persons to whom it is addressed. Such information is confidential and privileged and no mistake in transmission is intended to waive or compromise such privilege. If you have received it in error, please destroy it and notify us on the telephone number printed above. If you do not receive complete and legible copies, please telephone us immediately. Any opinions expressed herein including attachments are those of the author only. i-documentsystems Ltd. does not accept responsibility for the accuracy or completeness of the information provided or for any changes to this Email, however made, after it was sent. (Please note that it is your responsibility to scan this message for viruses).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: smart reactor proposal
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-06-04 at 05:47, Aslak Hellesøy wrote:
> Sorry if this has been brought up before, but I have an idea about how
> to make the reactor smarter/quicker.
>
> I have a project with lots of subprojects that are built with reactor. I
> want to reduce the build time by making the reactor smarter.
>
> 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.
This is not really within the domain of the reactor to decide. This is
probably something that could be implemented as a separate goal that
might do a check before attaining goals pertinent to building.
You could use the task in cruisecontrol that check a whole set of
sources to see if there have been any changes. This would include any
changes to POM. You might also want to look at SNAPSHOTS eventually.
But I don't think this belongs in the reactor per se.
> I think this can be implemented quite simply by doing some date
> comparisons between java sources and classes in each project.
Yup, I think there's something like this in cruisecontrol as mentioned
before.
> I'm planning to implement this feature, but before I do, I'd like to
> hear some opinions.
I think something like:
<goal name="compile-with-uptodate-check">
<j:if test="$!{sourcesUptodate}">
<attainGoal name="compile"/>
</j:if>
</goal>
Where you do whatever you like to get a value for the up-to-date test.
> Cheers,
> Aslak
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: smart reactor proposal
Posted by Rafal Krzewski <Ra...@caltha.pl>.
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