You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brian Fox <br...@infinity.nu> on 2010/02/10 15:52:42 UTC
Re: annotations support in compiler mojo
Does it make sense to create a plugin specifically for annotation processing?
On Sat, Jan 30, 2010 at 3:06 AM, Milos Kleint <mk...@gmail.com> wrote:
> can I read silence as lazy consensus to add annotation processing to the
> compiler plugin?
>
> Milos
>
> On Mon, Jan 25, 2010 at 2:48 PM, Milos Kleint <mk...@gmail.com> wrote:
>
>> Hello,
>>
>> I'd like to start a discussion about how annotations are supported in maven
>> builds. I'm currently trying to use some NetBeans Platform based annotations
>> in maven projects and I'm encountering some problems.
>>
>> 1. http://jira.codehaus.org/browse/MCOMPILER-98 - -sourcepath needs to be
>> always set to have the annotations processed. fixed in latest plexus
>> compiler sources..
>> 2. some annotation processors require resources to be present on the
>> sourcepath eg. one that generates java beans from schema or another one that
>> checks for property bundle key presence. I'm not sure how to make this
>> generally available to the processor. resources themselves (in
>> src/main/resources) are not to be referenced I guess (as they could be on
>> wrong <targetPath> or not filtered). So the only other option is to include
>> the target/classes folder somehow with the correctly processed resources.
>> Any other idea?
>> 3. Some annotation processors generate xml files or META-INF/services
>> content, some generate java files. the default output location for the
>> processor is target/classes, which is fine for xml files, but it's
>> inconvenient to generate java files there as they end up in the jar file
>> then. I've tried to configure the compiler to use
>> target/generated-sources/annotations as the output folder for sources (via
>> -s <dir> switch). Unfortunately there are problems associated with that
>> approach.
>> a. the folder needs to exist up front or the compiler chokes on it.
>> Doable with some ant-run scripting, but ugly.
>> b. what to do with the resources there that need to be copied to the
>> target/classes folder? Doable with resources:copy-resources but again ugly.
>> 4. reporting from the annotations processors is broken -
>> http://jira.codehaus.org/browse/MCOMPILER-66
>>
>>
>> Issue http://jira.codehaus.org/browse/MCOMPILER-75 seems to be dedicated
>> to annotation support. Is anyone actively working on it? I'm volunteering to
>> add some of the required switches as prameters for the compiler mojo, but
>> I'm unsure how to proceed. Is it ok just to add the required stuff as mojo
>> params, even if it will be unused by some of the other compilers? and even
>> by the non 1.6 javac compilers? or have some new ways fo configuring the
>> mojo (as pointed out in http://jira.codehaus.org/browse/MCOMPILER-14)?
>>
>> Thanks for any comments.
>>
>> Milos
>>
>> PS: I can provide a sample project with the above mentioned annotations
>> being used if there is interest.
>>
>>
>>
>>
>>
>>
>>
>
---------------------------------------------------------------------
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
>
>
Re: annotations support in compiler mojo
Posted by Mark Hobson <ma...@gmail.com>.
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>.
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..
2. -implicit - i'm entirely clueless what this is supposed to do..
3. -Akey=value parameters for annotation processors. could be left for
configuration via the generic compileArguments parameter I guess..
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.
Anything else that could be described as dealbreaker for anyone?
Milos
On Wed, Feb 10, 2010 at 5:53 PM, Mark Hobson <ma...@gmail.com> wrote:
> Late reply on this one, but I'm certainly interested in seeing apt
> support added to maven-compiler-plugin.
>
> There is already a separate plugin for apt over at Mojo,
> apt-maven-plugin [1]. I worked on this a while back to get it into
> shape and am currently using it in production. I'd be happy to see
> this superseded by the compiler plugin if it incorporates all of the
> existing functionality.
>
> Cheers,
>
> Mark
>
> [1] http://mojo.codehaus.org/apt-maven-plugin/
>
> On 10 February 2010 15:21, nicolas de loof <ni...@gmail.com>
> wrote:
> > Would such a dedicated plugin only apply annotation processing or replace
> > compiler plugin ? This may implies duplicate configuration for compiler +
> > annotation-processing plugins. Also consider slower build process as
> javac
> > will need to parse source code 2 times.
> >
> > (late) +1 for annotations support in maven-compiler-plugin
> > Nicolas
> >
> > 2010/2/10 Brian Fox <br...@infinity.nu>
> >
> >> Does it make sense to create a plugin specifically for annotation
> >> processing?
> >>
> >> On Sat, Jan 30, 2010 at 3:06 AM, Milos Kleint <mk...@gmail.com>
> wrote:
> >> > can I read silence as lazy consensus to add annotation processing to
> the
> >> > compiler plugin?
> >> >
> >> > Milos
> >> >
> >> > On Mon, Jan 25, 2010 at 2:48 PM, Milos Kleint <mk...@gmail.com>
> wrote:
> >> >
> >> >> Hello,
> >> >>
> >> >> I'd like to start a discussion about how annotations are supported in
> >> maven
> >> >> builds. I'm currently trying to use some NetBeans Platform based
> >> annotations
> >> >> in maven projects and I'm encountering some problems.
> >> >>
> >> >> 1. http://jira.codehaus.org/browse/MCOMPILER-98 - -sourcepath needs
> to
> >> be
> >> >> always set to have the annotations processed. fixed in latest plexus
> >> >> compiler sources..
> >> >> 2. some annotation processors require resources to be present on the
> >> >> sourcepath eg. one that generates java beans from schema or another
> one
> >> that
> >> >> checks for property bundle key presence. I'm not sure how to make
> this
> >> >> generally available to the processor. resources themselves (in
> >> >> src/main/resources) are not to be referenced I guess (as they could
> be
> >> on
> >> >> wrong <targetPath> or not filtered). So the only other option is to
> >> include
> >> >> the target/classes folder somehow with the correctly processed
> >> resources.
> >> >> Any other idea?
> >> >> 3. Some annotation processors generate xml files or META-INF/services
> >> >> content, some generate java files. the default output location for
> the
> >> >> processor is target/classes, which is fine for xml files, but it's
> >> >> inconvenient to generate java files there as they end up in the jar
> file
> >> >> then. I've tried to configure the compiler to use
> >> >> target/generated-sources/annotations as the output folder for sources
> >> (via
> >> >> -s <dir> switch). Unfortunately there are problems associated with
> that
> >> >> approach.
> >> >> a. the folder needs to exist up front or the compiler chokes on
> it.
> >> >> Doable with some ant-run scripting, but ugly.
> >> >> b. what to do with the resources there that need to be copied to
> the
> >> >> target/classes folder? Doable with resources:copy-resources but again
> >> ugly.
> >> >> 4. reporting from the annotations processors is broken -
> >> >> http://jira.codehaus.org/browse/MCOMPILER-66
> >> >>
> >> >>
> >> >> Issue http://jira.codehaus.org/browse/MCOMPILER-75 seems to be
> >> dedicated
> >> >> to annotation support. Is anyone actively working on it? I'm
> >> volunteering to
> >> >> add some of the required switches as prameters for the compiler mojo,
> >> but
> >> >> I'm unsure how to proceed. Is it ok just to add the required stuff as
> >> mojo
> >> >> params, even if it will be unused by some of the other compilers? and
> >> even
> >> >> by the non 1.6 javac compilers? or have some new ways fo configuring
> the
> >> >> mojo (as pointed out in http://jira.codehaus.org/browse/MCOMPILER-14
> )?
> >> >>
> >> >> Thanks for any comments.
> >> >>
> >> >> Milos
> >> >>
> >> >> PS: I can provide a sample project with the above mentioned
> annotations
> >> >> being used if there is interest.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> 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>.
Late reply on this one, but I'm certainly interested in seeing apt
support added to maven-compiler-plugin.
There is already a separate plugin for apt over at Mojo,
apt-maven-plugin [1]. I worked on this a while back to get it into
shape and am currently using it in production. I'd be happy to see
this superseded by the compiler plugin if it incorporates all of the
existing functionality.
Cheers,
Mark
[1] http://mojo.codehaus.org/apt-maven-plugin/
On 10 February 2010 15:21, nicolas de loof <ni...@gmail.com> wrote:
> Would such a dedicated plugin only apply annotation processing or replace
> compiler plugin ? This may implies duplicate configuration for compiler +
> annotation-processing plugins. Also consider slower build process as javac
> will need to parse source code 2 times.
>
> (late) +1 for annotations support in maven-compiler-plugin
> Nicolas
>
> 2010/2/10 Brian Fox <br...@infinity.nu>
>
>> Does it make sense to create a plugin specifically for annotation
>> processing?
>>
>> On Sat, Jan 30, 2010 at 3:06 AM, Milos Kleint <mk...@gmail.com> wrote:
>> > can I read silence as lazy consensus to add annotation processing to the
>> > compiler plugin?
>> >
>> > Milos
>> >
>> > On Mon, Jan 25, 2010 at 2:48 PM, Milos Kleint <mk...@gmail.com> wrote:
>> >
>> >> Hello,
>> >>
>> >> I'd like to start a discussion about how annotations are supported in
>> maven
>> >> builds. I'm currently trying to use some NetBeans Platform based
>> annotations
>> >> in maven projects and I'm encountering some problems.
>> >>
>> >> 1. http://jira.codehaus.org/browse/MCOMPILER-98 - -sourcepath needs to
>> be
>> >> always set to have the annotations processed. fixed in latest plexus
>> >> compiler sources..
>> >> 2. some annotation processors require resources to be present on the
>> >> sourcepath eg. one that generates java beans from schema or another one
>> that
>> >> checks for property bundle key presence. I'm not sure how to make this
>> >> generally available to the processor. resources themselves (in
>> >> src/main/resources) are not to be referenced I guess (as they could be
>> on
>> >> wrong <targetPath> or not filtered). So the only other option is to
>> include
>> >> the target/classes folder somehow with the correctly processed
>> resources.
>> >> Any other idea?
>> >> 3. Some annotation processors generate xml files or META-INF/services
>> >> content, some generate java files. the default output location for the
>> >> processor is target/classes, which is fine for xml files, but it's
>> >> inconvenient to generate java files there as they end up in the jar file
>> >> then. I've tried to configure the compiler to use
>> >> target/generated-sources/annotations as the output folder for sources
>> (via
>> >> -s <dir> switch). Unfortunately there are problems associated with that
>> >> approach.
>> >> a. the folder needs to exist up front or the compiler chokes on it.
>> >> Doable with some ant-run scripting, but ugly.
>> >> b. what to do with the resources there that need to be copied to the
>> >> target/classes folder? Doable with resources:copy-resources but again
>> ugly.
>> >> 4. reporting from the annotations processors is broken -
>> >> http://jira.codehaus.org/browse/MCOMPILER-66
>> >>
>> >>
>> >> Issue http://jira.codehaus.org/browse/MCOMPILER-75 seems to be
>> dedicated
>> >> to annotation support. Is anyone actively working on it? I'm
>> volunteering to
>> >> add some of the required switches as prameters for the compiler mojo,
>> but
>> >> I'm unsure how to proceed. Is it ok just to add the required stuff as
>> mojo
>> >> params, even if it will be unused by some of the other compilers? and
>> even
>> >> by the non 1.6 javac compilers? or have some new ways fo configuring the
>> >> mojo (as pointed out in http://jira.codehaus.org/browse/MCOMPILER-14)?
>> >>
>> >> Thanks for any comments.
>> >>
>> >> Milos
>> >>
>> >> PS: I can provide a sample project with the above mentioned annotations
>> >> being used if there is interest.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
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 nicolas de loof <ni...@gmail.com>.
Would such a dedicated plugin only apply annotation processing or replace
compiler plugin ? This may implies duplicate configuration for compiler +
annotation-processing plugins. Also consider slower build process as javac
will need to parse source code 2 times.
(late) +1 for annotations support in maven-compiler-plugin
Nicolas
2010/2/10 Brian Fox <br...@infinity.nu>
> Does it make sense to create a plugin specifically for annotation
> processing?
>
> On Sat, Jan 30, 2010 at 3:06 AM, Milos Kleint <mk...@gmail.com> wrote:
> > can I read silence as lazy consensus to add annotation processing to the
> > compiler plugin?
> >
> > Milos
> >
> > On Mon, Jan 25, 2010 at 2:48 PM, Milos Kleint <mk...@gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I'd like to start a discussion about how annotations are supported in
> maven
> >> builds. I'm currently trying to use some NetBeans Platform based
> annotations
> >> in maven projects and I'm encountering some problems.
> >>
> >> 1. http://jira.codehaus.org/browse/MCOMPILER-98 - -sourcepath needs to
> be
> >> always set to have the annotations processed. fixed in latest plexus
> >> compiler sources..
> >> 2. some annotation processors require resources to be present on the
> >> sourcepath eg. one that generates java beans from schema or another one
> that
> >> checks for property bundle key presence. I'm not sure how to make this
> >> generally available to the processor. resources themselves (in
> >> src/main/resources) are not to be referenced I guess (as they could be
> on
> >> wrong <targetPath> or not filtered). So the only other option is to
> include
> >> the target/classes folder somehow with the correctly processed
> resources.
> >> Any other idea?
> >> 3. Some annotation processors generate xml files or META-INF/services
> >> content, some generate java files. the default output location for the
> >> processor is target/classes, which is fine for xml files, but it's
> >> inconvenient to generate java files there as they end up in the jar file
> >> then. I've tried to configure the compiler to use
> >> target/generated-sources/annotations as the output folder for sources
> (via
> >> -s <dir> switch). Unfortunately there are problems associated with that
> >> approach.
> >> a. the folder needs to exist up front or the compiler chokes on it.
> >> Doable with some ant-run scripting, but ugly.
> >> b. what to do with the resources there that need to be copied to the
> >> target/classes folder? Doable with resources:copy-resources but again
> ugly.
> >> 4. reporting from the annotations processors is broken -
> >> http://jira.codehaus.org/browse/MCOMPILER-66
> >>
> >>
> >> Issue http://jira.codehaus.org/browse/MCOMPILER-75 seems to be
> dedicated
> >> to annotation support. Is anyone actively working on it? I'm
> volunteering to
> >> add some of the required switches as prameters for the compiler mojo,
> but
> >> I'm unsure how to proceed. Is it ok just to add the required stuff as
> mojo
> >> params, even if it will be unused by some of the other compilers? and
> even
> >> by the non 1.6 javac compilers? or have some new ways fo configuring the
> >> mojo (as pointed out in http://jira.codehaus.org/browse/MCOMPILER-14)?
> >>
> >> Thanks for any comments.
> >>
> >> Milos
> >>
> >> PS: I can provide a sample project with the above mentioned annotations
> >> being used if there is interest.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> 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>.
Well, the javac executable is caapable of doing both jobs (compile and
process annotations) simultaneously. And with reasonable defaults we can
make the annotation processing work out of the box for majority of people.
Having a special plugin for it, with comfiguration etc would make it more
complicated to setup and maintain.
Milos
On Wed, Feb 10, 2010 at 3:52 PM, Brian Fox <br...@infinity.nu> wrote:
> Does it make sense to create a plugin specifically for annotation
> processing?
>
> On Sat, Jan 30, 2010 at 3:06 AM, Milos Kleint <mk...@gmail.com> wrote:
> > can I read silence as lazy consensus to add annotation processing to the
> > compiler plugin?
> >
> > Milos
> >
> > On Mon, Jan 25, 2010 at 2:48 PM, Milos Kleint <mk...@gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I'd like to start a discussion about how annotations are supported in
> maven
> >> builds. I'm currently trying to use some NetBeans Platform based
> annotations
> >> in maven projects and I'm encountering some problems.
> >>
> >> 1. http://jira.codehaus.org/browse/MCOMPILER-98 - -sourcepath needs to
> be
> >> always set to have the annotations processed. fixed in latest plexus
> >> compiler sources..
> >> 2. some annotation processors require resources to be present on the
> >> sourcepath eg. one that generates java beans from schema or another one
> that
> >> checks for property bundle key presence. I'm not sure how to make this
> >> generally available to the processor. resources themselves (in
> >> src/main/resources) are not to be referenced I guess (as they could be
> on
> >> wrong <targetPath> or not filtered). So the only other option is to
> include
> >> the target/classes folder somehow with the correctly processed
> resources.
> >> Any other idea?
> >> 3. Some annotation processors generate xml files or META-INF/services
> >> content, some generate java files. the default output location for the
> >> processor is target/classes, which is fine for xml files, but it's
> >> inconvenient to generate java files there as they end up in the jar file
> >> then. I've tried to configure the compiler to use
> >> target/generated-sources/annotations as the output folder for sources
> (via
> >> -s <dir> switch). Unfortunately there are problems associated with that
> >> approach.
> >> a. the folder needs to exist up front or the compiler chokes on it.
> >> Doable with some ant-run scripting, but ugly.
> >> b. what to do with the resources there that need to be copied to the
> >> target/classes folder? Doable with resources:copy-resources but again
> ugly.
> >> 4. reporting from the annotations processors is broken -
> >> http://jira.codehaus.org/browse/MCOMPILER-66
> >>
> >>
> >> Issue http://jira.codehaus.org/browse/MCOMPILER-75 seems to be
> dedicated
> >> to annotation support. Is anyone actively working on it? I'm
> volunteering to
> >> add some of the required switches as prameters for the compiler mojo,
> but
> >> I'm unsure how to proceed. Is it ok just to add the required stuff as
> mojo
> >> params, even if it will be unused by some of the other compilers? and
> even
> >> by the non 1.6 javac compilers? or have some new ways fo configuring the
> >> mojo (as pointed out in http://jira.codehaus.org/browse/MCOMPILER-14)?
> >>
> >> Thanks for any comments.
> >>
> >> Milos
> >>
> >> PS: I can provide a sample project with the above mentioned annotations
> >> being used if there is interest.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>