Re: annotations support in compiler mojo
On 29 March 2010 10:35, Milos Kleint mkle...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: annotations support in compiler mojo
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 markhob...@gmail.com wrote: On 29 March 2010 10:35, Milos Kleint mkle...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: annotations support in compiler mojo
Hi Milos, Sorry for the delay again, I've been away from code for a while. On 6 March 2010 13:27, Milos Kleint mkle...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: annotations support in compiler mojo
Hello Mark, On Mon, Mar 29, 2010 at 10:39 AM, Mark Hobson markhob...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: annotations support in compiler mojo
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
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 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 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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: annotations support in compiler mojo
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 bri...@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 mkle...@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 mkle...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: annotations support in compiler mojo
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 markhob...@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 nicolas.del...@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 bri...@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 mkle...@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 mkle...@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
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 mkle...@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 mkle...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: annotations support in compiler mojo
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 bri...@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 mkle...@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 mkle...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: annotations support in compiler mojo
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 nicolas.del...@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 bri...@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 mkle...@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 mkle...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: annotations support in compiler mojo
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 mkle...@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.
