maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hobson <>
Subject Re: annotations support in compiler mojo
Date Fri, 05 Mar 2010 17:38:23 GMT
Hi Milos,

Apologies for the delayed reply.  See my responses inline:

On 25 February 2010 09:10, Milos Kleint <> 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:

> 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

> 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
> (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:

Obviously this is complicated if we're also compiling too.

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



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message