This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Use maven web project to reproduce issue 187653.
Trying to find out how to configure annotation processors compiler parameters, found next topic http://jira.codehaus.org/browse/MCOMPILER-135 Petr, Do we have all these patches and functionality in nb maven plugin already, what maven version should be supported (for external one)?
Not sure if I understand the question; we currently use maven-compiler-plugin version 2.3.2, which is the latest released. And from I understand bug MCOMPILER-135 is NOT fixed in this version. I am cc'ing Jesse, as he is the most knowledgeable about this area.
Don't know what the question is. A project using whatever version of the compiler plugin it is configured to use.
It's because I'm not familiar with maven area, what is maven version and what is affected by version, if it's just enough to specify latest compiler plugin version when new project is created it seems good.
(In reply to comment #4) > to specify latest compiler plugin version when new project is created The IDE does not specify anything. The archetype (~ project template), hosted on mojo.codehaus.org, specifies the complete project POM incl. plugin versions. For a Java EE 6 WAR, the currently released archetype (version 1.3) specifies maven-compiler-plugin 2.3.2.
ok, may be it doesn't matter, but regarding "You should start by defining the appropriate parameters to maven-compiler-plugin in the POM. Then file an RFE in projects/maven blocking bug #184952 for MavenAnnotationProcessingQueryImpl to interpret them." it's likely need to be done in reverse order as I need to find out first if parameter is already specified or not and it require "interpretation" part first in my opinion. Also if there is another parameter and there seems to be number of approaches to specify parameters new one is good to specify the same way as existent.
Jesse, is there any api to set a property in pom? I see only PluginPropertyUtils but there are getters only, also there is no compile options in project properties as possible starting point to investigate how it may work.
I have found POMModel, Plugin, COnfiguration classes which may help (used in source level update, but may not be good for more complex cases, need to try first) but to use these classes dependencies between maven modules should be extended.
(In reply to comment #8) > I have found POMModel, Plugin, COnfiguration Yes, these would be used to modify compiler plugin params. > to use these classes dependencies between maven modules should be extended. To whom? maven.model is already a friend of maven.j2ee and maven.jaxws. If maven.persistence is where your code resides, just add a friend declaration. (To be safe for Auto Update, you must also incr the spec version of maven.model, and ensure that maven.persistence requests that new version.)
yes, maven.persistence, thanks for version update reminder
I'm going to use <plugin> ... <configuration> .... <annotationProcessorArguments> <Aeclipselink.canonicalmodel.use_static_factory>false</Aeclipselink.canonicalmodel.use_static_factory> </annotationProcessorArguments> </configuration> </plugin> Even it's not supported by maven(may be yet) It looks like maven do not support ap arguments well anyway and also there is no need for now to have this arguments passed to javac in clean&build, the issue require to pass these arguments to internal nb javac only and it can be done this way. Any cons?
Mix of one compilerArguments and compilerArgument seems to work (yet I test it with some simple arguments), but in my opinion it's unsafe to use it for ap parameters as anyway can't specify multiple parameters and also if user use it already I can't modify it to support additional arguments because if issues. So would like to use unsupported "annotationProcessorArguments" instead to pass ap parameters to AnnotationProcessorQuery, tried to add it to pom and it cause no visible issues.
(In reply to comment #11) > Even it's not supported by maven (may be yet) Do _not_ set any config in the POM that does not actually work today. Until the maven-compiler-plugin issues are resolved and a new release of the plugin is made there is no way to know for sure what the final syntax will be. A short-term workaround in the IDE may be to define an AnnotationProcessingQueryImplementation (position < 100) which detects src/main/java for Maven projects affected by this issue, loads the default APQI from the project's lookup, and delegates to it except for adding the desired processor flags.
> A short-term workaround in the IDE may be... Actually, could not this be the permanent solution? Because we don't really need this property in the pom file for command line use, we only need it for the internal Java parsing infrastructure.
http://hg.netbeans.org/web-main/rev/cf6b7f2a7584 fix, parameter for eclipselink is always provided by ide. http://hg.netbeans.org/web-main/rev/0586e260f3ef this part can be used if ap parameters support will be enhanced
Integrated into 'main-golden', will be available in build *201011260001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/cf6b7f2a7584 User: Sergey B. Petrov <sj-nb@netbeans.org> Log: fix #192101 necessary parameter is hardcoded in annotation query impl
oom is fixed, but there is possible P3-P4 (in my opinion) with extra warning see issue 192105
(In reply to comment #14) > could not this be the permanent solution? Perhaps. I don't understand well enough what the parameter does, or what the original bug was. Sounds to me like there is a bug in the processor itself that we are just working around. Eclipse #322921 seems like they just added the ability to work around what is clearly a bad design in the processor; not quite sure I understand why there are using a static field, but perhaps they just want to use a WeakHashMap<ProcessingEnv,MetadataMirrorFactory> like we use in LayerGeneratingProcessor? 0586e260f3ef can probably be backed out as it seems the commented-out code will never be wanted.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/f7e669c7eea5 User: Jesse Glick <jglick@netbeans.org> Log: Backing out 0586e260f3ef from #192101; might work with 2.4 compiler plugin (MCOMPILER-135) but unlikely to be wanted. The in-IDE query automatically sets this property as a workaround for the buggy processor; setting for command-line Maven builds is uncomfortable.