On 7/20/05, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
> On Wed, 20 Jul 2005, John Fallows wrote:
>
> > On 7/20/05, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> > It seems that classification of these sources into main, test, site,
> > itest, etc, would already be well-defined for checked in sources under
> > ${basedir}/src, and the fact that they are generated does not change
> > the classification.
> >
> > IMHO, it makes sense to replicate the ${basedir}/src subdirectory
> > structure under ${basedir}/target/generated-src because all these
> > files would be checked in under ${basedir}/src if they were not being
> > generated.
>
> The problem here is that there is no direct relation between the sources
> that produce generated-sources and those generated-sources. Mostly
> a plugin specific configuration file is used in src/main/XXX/,
> or even configuration in the POM. It could also be that those sources
> are generated from the main sources (xdoclet) or the test sources,
> in which case the source dir to use is probably specified in the plugin
> configuration.
>
> Separation isn't always necessary, but throwing everything on one heap
> doesn't enable one to later get a list of the (re-)sources generated
> by a certain plugin, maybe for use in another mojo (from the same
> plugin) at a later lifecycle phase. Currently only (re-)source roots
> and test (re-)source roots can be added, because the main plugins need
> those. There's no other way to pass such information to other phases
> (other plugin mojo's) without adding them to some path, except
> for the separate directories. Currently the only implemented use cases
> are generation of sources/resources that are added to those paths
> because the steps to process them don't care if they're all in one heap.
>
> But is this always the case?
Clearly, it would not be possible to get a separate list of generated
(re)sources, but I humbly question the need for (and desirability of)
such a design.
Let's take your example of chaining Mojo's together. Why should the
Mojo care whether or not the (re)sources are generated?
Since it is good practice to have all generated (re)sources under
"target", and all versioned (re)sources under "src", it would seem to
be best practice to write Mojo's that are expecting two possible
(re)source locations, one for versioned and one for generated.
If such a directory layout is standardized, this leads to reduced
configuration - in the default scenario - for users of the plugins in
pom.xml.
Imagine that a javacc plugin and an xdoclet plugin both just generate
.java sources to target/generated-src/main/java for "main" sources
living in target/src/main/javacc and target/src/main/xdoclet.
Now suppose that another plugin needs to generate javacc or xdoclet
files for main. Where should that output go? I would suggest it goes
to target/generated-src/main/javacc and
target/generated-src/main/xdoclet.
Since the "best practice" javacc and xdoclet plugins are written to
obtain (re)sources from two standard locations, one for versioned
(re)sources and one for generated (re)sources, no configuration is
required to make this work.
Compare this to the approach of having separate generated (re)source
directories per plugin. Further pom.xml configuration is required to
tie the pipeline together so that (re)sources can be located by the
various plugins in the pipeline.
IMHO, a transparent plugin pipeline is defeated by not having standard
output locations for generated (re)sources, and by not writing plugins
to read from two standard input locations, one each for generated and
versioned (re)sources.
Kind Regards,
John Fallows.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
