Brian Ewins wrote:
> 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)
Instead of 'global' think about 'valid during a session'. Suppose you
have Maven embedded in an IDE, with your project loaded and all goal
dependency information in place. You click a toolbar icon that invokes
a pre-configured goal on the current project. This starts a new Maven
session for your project. Maven uses the loaded goal dependency
information to build of a graph of goals that need to be attained to
achieve the goal you requested. Then the order in which the goals will
be attained is computed (with the possible outcome of cirular dependency
error message). At this point we have a pipeline formed. The goals that
run at the beginning of the pipeline are usually producers of ... well,
let's call'em 'interim artifacts'. For example, 'java:init' goal would
check for existence of ${basedir}/src/java, and if it's present, would
create a FileSet interim artifact named 'java.source.set' and pass it
down the pipeline. How would that be done? The object would be injected
into the Maven session context. How further elements of the pipeline
know where to look for that interim artifact? The key in the session
context is a part of public API of the plugin that produces it.
I think that most, if not all of the infrastructure needed to implement
that kind of pipelining operation is already present in Maven. All we
need is defining that this is how things should be done, and documenting
the contracts of all plugins -- what 'interim artifacts' they produce
and consume.
> 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.
I'm no expert at the theory behind frameworks, but what I've described
above seems reasonably well strucured to me. A and B need to agree on
a contract (names of the passed artifacts) and the framework does the
storage/lookup for them.
R.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
