On 07/01/2010, at 1:16 AM, Kristian Rosenvold wrote: > On Wed, 2010-01-06 at 13:41 +0000, Stephen Connolly wrote: >> however you might have to wait for "install" as the attached artifact >> can be replaced in the reactor, e.g. maven-shade-plugin could be >> replacing the artifact with its shaded version >> >> you only know by the time you hit install (or the last phase in the >> invoked lifecycle, whichever comes first) that the attached artifacts >> are the final attached artifacts for consumption by dependent modules >> > > This is really interesting, because it probably has the same solution > as the antrun problem. > >> From a 10000 foot perspective, what my patch really does is augment the > ProjectDependencyGraph with Scheduling information, effectively > constructing a much richer dependency graph.
Is the way this is designed something that's potentially reusable outside of Maven in an embedded scenario? Continuum currently builds Maven projects module by module, with some crude parallelism and the old project sorter. The availability of this and the Maven embedder would be smoking for CI :) > > The "Schedule" that is added to the ExecutionPlanItem describes the > relationship to upstream plugins/phases. So when a given plugin has a > specific requirement (i.e. "I require a jar file") it expresses a > dependency upon the install plugin. This is all behind the scenes? I usually raise a flag hearing "expressing a dependency on the install plugin", as its one of the anti-patterns of maven 1 that we keep trying to avoid (where you couldn't switch in other plugins because of hard dependencies). But if I understand correctly, you're just figuring out that it is the install plugin at runtime because install was run, and it produced the relevant copy of the artifact that now needs to be used. Along the lines of what Stephen mentioned - the use cases I'd expect to still work is proper ordering when running "mvn package", cases like the shade plugin that replace the main artifact, or the creation of attached artifacts. This sounds a lot like the need for something like this in 3.1: http://jira.codehaus.org/browse/MNG-193 :) Thanks for continuing to give us insight into how this is working! Cheers, Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
