Bug 111080 - Minimal Support for Annotation Processing related javac options
Minimal Support for Annotation Processing related javac options
Status: RESOLVED DUPLICATE of bug 111294
Product: java
Classification: Unclassified
Component: Project
All All
: P3 with 1 vote (vote)
: 6.x
Assigned To: Jan Jancura
Depends on:
Blocks: 111063
  Show dependency treegraph
Reported: 2007-07-26 10:50 UTC by brucechapman
Modified: 2010-03-02 07:27 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description brucechapman 2007-07-26 10:50:23 UTC
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.
Comment 1 _ wadechandler 2008-01-11 20:16:22 UTC
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:
(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.
Comment 2 brucechapman 2008-01-12 08:53:22 UTC
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
Comment 3 _ wadechandler 2008-01-12 14:02:43 UTC
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:
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
Comment 4 Jesse Glick 2010-03-02 07:27:07 UTC

*** This bug has been marked as a duplicate of bug 111294 ***

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo