You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Hobson <ma...@gmail.com> on 2010/03/05 18:38:23 UTC
Re: annotations support in compiler mojo
Hi Milos,
Apologies for the delayed reply. See my responses inline:
On 25 February 2010 09:10, Milos Kleint <mk...@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
> 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
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
phase.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: annotations support in compiler mojo
Posted by Milos Kleint <mk...@gmail.com>.
to me, projects that have their own annotation processors are a bit
corner-case. We should have a documented approach for that situation for
sure. To me the workaround with resource:copy goal that copies the
META-INF/services/xxx entry *after* compilation sounds like the best
solution.
Milos
On Tue, Mar 30, 2010 at 11:03 AM, Mark Hobson <ma...@gmail.com> wrote:
> On 29 March 2010 10:35, Milos Kleint <mk...@gmail.com> wrote:
> > yes, one place when this issue arises is when your own project defines a
> > annotation processor of it's own. See
> > http://jira.codehaus.org/browse/MCOMPILER-97
>
> Hmm, maybe we'll have to split the compiler plugin up into two
> different executions for proc:none and proc:only. It'd be interesting
> to see what the actual performance hit is for this set up compared to
> a single invocation.
>
> > I'd like to do a 2.2 release sometimes later this month.
>
> Cool, I'll try it out soon.
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: annotations support in compiler mojo
Posted by Mark Hobson <ma...@gmail.com>.
On 29 March 2010 10:35, Milos Kleint <mk...@gmail.com> wrote:
> yes, one place when this issue arises is when your own project defines a
> annotation processor of it's own. See
> http://jira.codehaus.org/browse/MCOMPILER-97
Hmm, maybe we'll have to split the compiler plugin up into two
different executions for proc:none and proc:only. It'd be interesting
to see what the actual performance hit is for this set up compared to
a single invocation.
> I'd like to do a 2.2 release sometimes later this month.
Cool, I'll try it out soon.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: annotations support in compiler mojo
Posted by Milos Kleint <mk...@gmail.com>.
Hello Mark,
On Mon, Mar 29, 2010 at 10:39 AM, Mark Hobson <ma...@gmail.com> wrote:
<snip>
> >> 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?
> >
> > 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?
>
> Sounds good to me. I just wanted to highlight the fact that this
> circumnavigates Maven's traditional lifecycle phases.
>
yes, one place when this issue arises is when your own project defines a
annotation processor of it's own. See
http://jira.codehaus.org/browse/MCOMPILER-97
>
> Thanks for doing the work on this, I'll look forward to using it soon!
>
>
I'd like to do a 2.2 release sometimes later this month.
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: annotations support in compiler mojo
Posted by Mark Hobson <ma...@gmail.com>.
Hi Milos,
Sorry for the delay again, I've been away from code for a while.
On 6 March 2010 13:27, Milos Kleint <mk...@gmail.com> wrote:
> 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?
I agree that the compile classpath should be the default, as it is
with javac. Unless there's any other use case for specifying plugin
dependencies to the compiler plugin, I'd just use them as the
processor path if specified, avoiding the need to encode them.
> 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?
Yeah, the staleness checking is merely an optimisation. Like you say,
It isn't straightforward as you need to know how the processors
generate files. It can certainly be off by default, and it's more a
nice-to-have than absolutely necessary. I'm sure builds will be
quicker now if we're only invoking javac once, rather than javac and
then apt.
>> 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?
>
> 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?
Sounds good to me. I just wanted to highlight the fact that this
circumnavigates Maven's traditional lifecycle phases.
Thanks for doing the work on this, I'll look forward to using it soon!
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: annotations support in compiler mojo
Posted by Milos Kleint <mk...@gmail.com>.
On Fri, Mar 5, 2010 at 6:38 PM, Mark Hobson <ma...@gmail.com> wrote:
> Hi Milos,
>
> Apologies for the delayed reply. See my responses inline:
>
> On 25 February 2010 09:10, Milos Kleint <mk...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>