But there are even worst cases when pipelining is useless.
E.g. consider following use case
1) First run of Maven : I start XDoclet it creates some classes and updates java path for the rest of plugins (e.g. javac)
2) Second/Third etc.. run of Maven I don't want to regenerate one more time XDoclet stuff .. but I want to have the source previously generated visible in my path.
That would be handled exactly as it is now, I'm not sure I see your point? i.e., each plugin in a pipeline invokes its dependents, which end up doing nothing because their output already exists? The pipeline is not passing the file contents (I guess this might be what you're thinking?), only data structures (eg FileSets) which allow you to get access to the files.
The only way it can be handled properly is to make it on plugin level. So plugins like XDoclet should be equipped with some hooks for making such things and hide some details into which directories they will put their sources.
All I am suggesting is that saying 'goal A depends on goal B' generally means 'goal A depends on the /output of/ goal B'. At the moment, B knows where its output went, but A is just guessing. So we require A to have knowledge of how B works in order to get hold of B's data. That hides /less/ about which directories B uses than my suggestion.
The 'official' way to deal with code generators is to chuck their output into the 'global list of sources'. Are we suggesting global variables are a good thing? Also, this mechanism only deals with .java files - there is no equivalent fat pipe for documentation etc AFAIK. (BTW this can also be seen as inverting the problem in the previous para - now B knows how A works and is pushing its data at A)
There also seems to be a clash with the Inversion of Control principle[1] here: either A is pulling data from B, or B is pushing data at A (or equivalently, A pulls from a global, B pushes to a global). It should be the framework telling A what files to process, which happens to include the output of B because the current 'flow' declares that dependency.
To some extent I'm echoing Bob McWhirter here, and suggesting that "everything is workflow"[2] - including maven.
-Baz
[1] http://avalon.apache.org/framework/guide-patterns-ioc.html [2] http://blogs.werken.com/people/bob/archives/000160.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
