Hi Bernd, Thanks for the reply, see below:
On 02/04/2008, Bernd Bohmann <[EMAIL PROTECTED]> wrote: > > I've also just removed any Java compliation support from the plugin > > since I couldn't see any advantage of duplicating this with the > > maven-compiler-plugin. Can you see any problems with that? > > I don't use this parameter, but this would break backwards compatibility. I'm not too concerned about backwards compatibility since the Codehaus plugin is currently in the sandbox and hence has no releases. If you're aware of any other users of the Tobago plugin then this may need considering if the Tobago version is removed for the Codehaus version. > > 1) Do you use extra source roots? I'm tempted to remove this > > parameter since it tends to go against the standard of using the > > project's current source roots. > > Yes, I need this parameter. We unpack a source artifact and process the > containing source code too. But the extra source root should not > included in the compile. Right, whereabouts is this in the build? Normally source roots are contributed to the build via plugins, for example the maven-compiler-plugin cannot be configured to use extra source roots but allows other plugins to add them during the lifecycle. > > 2) Do you use the resource target path parameter? I'd have thought > > that the apt factory should control this. > > Yes, I think the apt processor should only generate files and the > resource plugin should copy the resources. Cool, I've removed this one. > > 3) Do you use the target files parameter? I wouldn't have thought > > you'd need such fine-grained control of source files to process when > > using Maven. > > Yes, we did see 4 > > > 4) Do you use staleness checking? I'm not too convinced by this > > implementation since it checks source files against class files to > > determine staleness. This is a problem when using -nocompile as the > > class file timestamp has no correlation with the staleness of > > generated resources. Auto-compiling IDEs then also pose a further > > problem since they never let a class file become stale, hence > > resources are never generated with apt. > > Yes, with the target file parameter the apt plugin is only called if the > source code has changed. I see, I think misread the staleness implementation here. I've updated the Codehaus plugin to compute staleness using either: - suffixes of the processor-generated files (for one-to-one apt factories) - paths of the processor-generated files (for many-to-one apt factories) Your TLD factory falls into the latter category. This means that when at least one source file has a last modified timestamp beyond the generated file's last modified timestamp, then apt is run with *all* the source files. I believe this is the correct behaviour since with a many-to-one apt factory the generated resource is typically the amalgamation of all source files. Whereas for one-to-one apt factories, only stale source files are passed to apt. Can you see any problems with this logic? > You can look at > http://svn.apache.org/repos/asf/myfaces/tobago/trunk/core/pom.xml for > some usages of the tobago apt plugin > > The old apt plugin from codehaus provides a 'generateToBuildDir' > property. I think this parameter is useless. What do you think? I believe this placed the generated resources in the src directory or something daft? Nah, I don't think we need this either and it's gone in the current version. Cheers, Mark
