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.
JDK6's javac has several new options in support in JSR-269 Anotationprocessors. This issue addresses a minimal subset of those in order for builds to behave correctly in the presence of annotation processors. javac's -s option ----------------- This specifies a directory in which to place generated source files. Some project tools ought to treat such files in the same manner as project source files, while other tools need to treat them in a similar manner to other imtermediate build artifacts (e.g. .class files). Therefore they need to have their own location in the project directory structure. /build/generated is an appropriate location. Specific operation support clean: this directory should be cleaned, BUT because the editor might write into this directory prior to the pject's compile tasks being run, the directory itself should always be present (clean should erase the contents but ensure the directory exists). compile: should pass this directory as javac's -s option (for JDK6+) debug: this directory should be made available as a source location for the debugger javadoc: (uncertain) but probably this directory should be made available as a location of source files. this means that javadoc task depends on compile (to trigger generation of those *.java files), but that could be done in such a way as to short circuit some of the compilation via java'c -proc:only option somehow. profiling/code coverage: this directory should be treated as a source location. (though that is maybe debatable for static analysis tools since the project owner has no control over the form of the generated code unless they happen to "own" the annotation processor as well. static analysis tools: should probably ignore this directory. (except when the project is for the annotation processor code itself, in which case that might be useful to analyse the generated code). Source Control (CVS/ SVN etc): should ignore this directory. (Suspect no change required since under /build) Other javac options ------------------- Existing projects can support these via the javac.compilerargs property - no change necessary.
The only issue I can think of with existing projects is that the properties in the property file are not proper location Ant properties, so the full path is not expanded. For instance: javac.compilerargs= -s gensrc will crash the compiler. The compiler will be running the in the src directory when compiling these files (its working directory differs from Ant that is), so one currently has to do: javac.compilerargs= -s ${basedir}/gensrc It also seems that javac, differing from the JDK documentation at: http://java.sun.com/javase/6/docs/technotes/tools/windows/javac.html#searching (you'll have to scroll up a bit to see the section "Annotation Processing", doesn't support META-INF services seamlessly, and one actually has to use: javac.compilerargs=-processor <javac processor class name list> -s ${basedir}/gensrc where as supposedly according to the JDK javadocs it should support META_INF/services/javax.annotation.processing.Processor files with instances of that interface inside it. This apparently doesn't work. I've used SPIs before, and checked it many many ways, and even ran javac from the command line and could not get it to pick up the processors at compile time without manually supplying the processor list. So, either javac doesn't do this automatically, or the docs give the wrong class name.
Annotation Processor discovery via META-INF/services works just fine in javac. I have used it both with jar files, and also with a directory on the classpath containing both the META-INF... directories and class file directory tree. I note that you say META_INF when it is actually META-INF (hyphen not underscore) for the SPI mechanism. Anyway, that would be the cause of your problems if you put the file under META_INF rather than META-INF
META_INF was a typo here, my folder name is META-INF in my project, but I found the source of my stinking problem. This is what one gets doing things late. Oh, I had checked it alright, but what I did was create a file named services and stuck the stinking lines such as this: javax.annotation.processing.Processor=org.netbeans.beans.annotations.api.AnnotationProcessor in the file instead of a file named after the class and lines of processors. Heh heh, I am using SPI all over the NB RCP libraries, but some how when I did this one night it never clicked I guess because I had the ...=... so logically I guess when looking at it I would just go...OK. Anyways, so now the only issue seems to be -s ${basedir}/gensrc
*** This bug has been marked as a duplicate of bug 111294 ***