Bug 181439

core-main #a331e263c813

Integrated into 'main-golden', will be available in build *201003030200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/a331e263c813
User: Jesse Glick <jglick@netbeans.org>
Log: #181439: minimal AP query impl.

Really this should be in a http://www.netbeans.org/ns/freeform-project-java/3 schema (together with 1.6/1.7 source levels and possibly other changes), but doing a schema upgrade is significant work and we are generally not doing development on the freeform project type going forward. Be advised that a project using mode="processor" cannot be opened in NB 6.8.

"not doing development on the freeform project type going forward"????

That's the only thing that keeps us using NetBeans.

Without this we'd have gone to Eclipse quite some time ago.

If you can't add a few nuggets to the project.xml schema along the lines you indicated and route their data to the appropriate places, then I guess that's a sign to give up on NetBeans.

I am now on vacation but after it I will do a /3 schema.
Jesse, if you have any other things we want to add (except of cp type and source level) please add them into this issue.

(In reply to comment #5)
> I am now on vacation but after it I will do a /3 schema.

Go ahead if you have time. Note that feature freeze is the end of this week. There is some fairly complicated code to decide whether to use a /1 or /2 schema which would need to be adapted to also work with /3, if something from the GUI wants to store new information - which would be true if you e.g. included 1.6 and 1.7 as options in the Source Level dropdown.

I know about the upgrade code, it's similar o UpdateHelper, and this was the reason why I didn't add the 1.6, 1.7 yet.
I will definitely not do it before feature freeze but as a bug fix after it.

Created attachment 95536 [details]
freeform-project-java/3 diff

Typo in comment:

...
         // First check whether we need /2 data.
+        boolean need3 = false;
...


Can remove 'processor' from permitted CP types in /2 schema.


Otherwise looks good to me. Don't forget to publish new schema in old CVS under www/www/ns/ (or ask me to do so after you have committed to Hg).

The typo is fixed.
"Processor" is removed from /2.
I will commit the new schema into the cvs.netbeans.org, unfortunately the server is now down. I've created a new issue #182574

Integrated into jet-main 1c95fe60e70c.
To jessholle: If you are using processor path, you will need to upgrade the schema to /3.

When will this be available to try out?  The next 6.9 nightly or...?

Not sure, as it needs to merge from our team repository into the golden.
The merge should add the message into this issue, something like:
Integrated into 'main-golden', will be available in build *????????????????* on....

Integrated into 'main-golden', will be available in build *201003240200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/1c95fe60e70c
User: Tomas Zezula <tzezula@netbeans.org>
Log: #181439:Minimal AnnotationProcessingQueryImplementation for freeform projects

I finally got time to try this in the latest nightly of NB 6.9.

I get innumerable log messages stating:

INFO [com.sun.tools.javac.processing.JavacProcessingEnvironment]: Annotation processing error:
java.lang.IllegalArgumentException: Argument is not a primitive type or a string; it has class com.ptc.windchill.annotations.metadata.SupportedAPI.

This same annotation processor does not produce such output when run with javac from the command line.  I'm left wondering if the SupportedAPI class (which is an enum) is not being seen by the annotation processor, though its jar is in the processorpath along with the annotation processor implementation.

When invoked from the command line we also provide -s and several -A arguments which the freeform project XML currently does not allow me to provide, but I suspect this is not the issue.

Should I re-open this or file a new issue?

Created attachment 97451 [details]
annotation processing error message and traceback

Attaching the annotation processing error message and stack trace.

What exactly passes
at com.ptc.windchill.annotations.processors.SupportedAPIWrapper.<init>(SupportedAPIWrapper.java:23)

to Elements.getConstantExpression? Thanks.

The Elements.getConstantExpression() javadoc:
Returns the text of a constant expression representing a primitive value or a string.

I didn't even notice our code in the stack trace -- sorry for the sloppiness!

At any rate the interesting bit of the line in question is:

  env.getElementUtils().getConstantExpression(SupportedAPI.PRIVATE)

where SupportedAPI.PRIVATE is a value of the SupportedAPI enum, of course.

Given that this appears to be working fine outside NetBeans (or as an Ant task launched within the same NetBeans project), something seems amiss in NetBeans here.

So we're just getting away with this when this is invoked via javac?

(In reply to comment #20)
> So we're just getting away with this when this is invoked via javac?

Yes, as far as I can tell. There was a bug in javac that this was not enforced:
http://bugs.sun.com/view_bug.do?bug_id=6517779
The fix was pulled to the NetBeans' version of javac together with other fixes. The very same exception is thrown when javac from JDK7 (I tested b85) is used.

Having gotten past the constants vs. enums spec bit, we're now seeing two new exceptions over and over again, an IllegalArgumentException and a new NullPointerException.  Any ideas?  [Again, this works fine from the command line javac.]

Created attachment 97609 [details]
Two new exceptions occurring during code scanning/parsing

Two new exceptions occurring during code scanning/parsing.  Again, these do not occur with our annotation processor when used from javac from Ant from the command line.

(In reply to comment #23)
> Two new exceptions occurring during code scanning/parsing.  Again, these do not
> occur with our annotation processor when used from javac from Ant from the
> command line.

Such things would be better filed as separate issues in java/source since they are likely not specific to freeform projects.

Okay, I can certainly file this as one or more separate issues against java/source -- I had little/no way of knowing what to file this against or even if there was some spec subtlety we'd missed once again.

I filed issue 184503 in regards to the exceptions.  If this should be split into 2 issues, that can be done later -- I didn't want to jump to the conclusion that the exceptions were unrelated, though.