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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
