On Fri, Mar 5, 2010 at 6:38 PM, Mark Hobson <markhob...@gmail.com> wrote:
> Hi Milos, > > Apologies for the delayed reply. See my responses inline: > > On 25 February 2010 09:10, Milos Kleint <mkle...@gmail.com> wrote: > > Hello Mark, > > > > what are the required feaures you are after? From the glimpse at the apt > > plugin, I got the impression that it has quite a lot of configuration, > some > > I didn't completely understand.. > > here's what already implemented in code > > -proc parameter to turn aannotation processing off, or enable it > exclusively > > without compilation. default is process+compile. > > -s <path> with reasonable path for generated source fles - > > target/generated/sources/annotations (or test-annotation when executed > from > > test-compile mojo) > > -processor parameter with optional list of processor classes > > All these switches are only applied to javac when the source/compiler > level > > is 1.6+. It can already be tested with the latest snapshot of > > maven-compiler-plugin in apache snapshot repository. > > > > What is missing? > > 1. -processorpath handling. Not sure how many projects have different > > processor path from compile path, but probably useful to have. I'm not > sure > > how to represent it in terms of mojo parameters. Any hints, precedents > > welcome.. > > I certainly use this, since processors are only required at build time > I like to keep them out of the runtime dependencies. See the second > example here for how apt-maven-plugin configures this: > > > http://mojo.codehaus.org/apt-maven-plugin/examples/configuring-a-factory.html > > I see. I think the regular compilation classpath shall be the default though. The question is how to encode this special processor path? is there a way to encode <dependency> elements inside the <configuration>? or shall we just have a simple boolean parameter that would take plugin's classpath/dependencies instead of the project compilation cp and encode the processor path as <dependency> of the plugin? > > 2. -implicit - i'm entirely clueless what this is supposed to do.. > > I'm not too familiar with this either, will need to read more. > > > 3. -Akey=value parameters for annotation processors. could be left for > > configuration via the generic compileArguments parameter I guess.. > > Yeah, this is currently achieved with an options mojo parameter, but I > agree the compileArguments parameters would be better in > maven-compiler-plugin. > > > 4. currently we put just java source root on the -sourcepath. At least in > > netbeans codebase we have cases where the sourcepath is supposed to > contain > > resources accessed by the annotation processors. Bundle properties files > get > > checked for presence of keys at compile time etc. I've experimented with > > adding either target/classes or src/main/resources of source path, but > > neither worked now due to a bug in javac - jglick filed it under > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929404 (might take a > few > > days to appear). There is an ugly workaround, to define the resources in > > src/main/java. I expect we add the relevant portion to the compiler > plugin > > only after at least one jdk release includes the fix. > > I see, nasty, I haven't encountered such a setup yet. > > > Anything else that could be described as dealbreaker for anyone? > > I'd like to see support for the apt staleness checking that currently > exists: > > > http://mojo.codehaus.org/apt-maven-plugin/examples/configuring-staleness-checking.html what is the purpose of the staleness checking? to avoid regenerating resources all over again? The various rules assume you always know what the given annotation generates, which might not be applicable to everyone (and requires additional mandatory configuration?) If we add it can it be "off" be default? So that only those caring enough get to configure it? > > > Obviously this is complicated if we're also compiling too. > Yes, you would have to somehow recognize this upfront and pass -proc:none to avoid processing? but how do you figure? > > Another thought I had was that the lifecycle phases are going to get > muddied somewhat by the compiler goal also running apt. For example, > resources may be generated during the compile phase rather than at the > generate-resources phase. I wonder what we want to be the default > behaviour? Either to split out the compiler mojo into two separate > executions, thus being slower, or to combine them for speed. Even > with the former, we don't know in advance whether apt is generating > sources or resources, so it still could be executing in the wrong > phase. > the current netbeans annotations do generate resources (layer.xml files and META-INF/services content) and also java/class files. If you generate class files, you cannot probably do just annotation processing (in process-resources) without compiling as well. Or we would have to add the generated sources root to the project? OTOH when resources get generated in compile phase, it probably only matters if you want to do filtering of these resources? but that assumes your annotations do generated filterable content. Hmm. I suppose this setup can be configured in the pom, additional execution with -proc:only and the default compile execution with -proc:none So I would go with doing annotation processing along with compiling, it's going to be faster and is actually the default javac behaviour as well. The other scenarios seem to be configurable then as well using the current parameters, right? Regards Milos > Cheers, > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
