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.
Build: NetBeans IDE Dev (Build 090928) VM: Java HotSpot(TM) Client VM, 14.1-b02, Java(TM) SE Runtime Environment, 1.6.0_15-b03 OS: Linux, 2.6.28-15-generic, i386 User Comments: jglick: Java Ext Editor enabled. Looking at a source file using @ProjectServiceProvider in a suite built atop NB 6.7. Stacktrace: java.lang.ClassNotFoundException: org.openide.filesystems.annotations.LayerGeneratingProcessor at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(AccessController.java:0) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
Created attachment 88444 [details] stacktrace
Part of the problem is that pelmel uses ClassPath.COMPILE to find and run annotation processors, but apisupport defines a specific -processpath during build. Would be more precise to have a special ClassPath.PROCESSOR classpath type (which would be equal to run classpath for apisupport.project), and fallback to CP.COMPILE is CP.PROCESSOR is not defined. Any idea where to put such a constant? ClassPath class itself does not seem like a good place, as that is not Java specific anymore. Another part of the problem is that pelmel should be able to tolerate even broken setups.
Right, ClassPath is not the right place. We can create a new constant class in the org.netbeans.api.java (the old classpath module which contains the java specific APIS). Something like JavaProjectConstants in java/project.
Agreed that a new constant ClassPath.PROCESSOR in api.java would be sensible. Fast-track API review I guess. A short-term workaround could be for pelmel to look in EXECUTE instead of CLASSPATH, or as a fallback in case a processor cannot be loaded from EXECUTE. This would be pretty specific to apisupport.project of course.
Pelmel uses "classpath/processor" (=PROCESSOR_PATH) if available: http://kenai.com/projects/pelmel/sources/main/revision/91 Also, pelmel should not throw exceptions if it cannot find an annotation processor: http://kenai.com/projects/pelmel/sources/main/revision/85 (contains two fixes, which were fixed later). Patch for issue #174202 (integrated to jet-main) contains also changes to apisupport.project. The patch does not change behavior for extra compilation units - these will still use CP.COMPILE to look for annotation processors. Given that the users need to compile the ECU manually in their build scripts, it is not clear what is the correct CP for annotation processors for ECUs. What would be the most correct behavior?
The apisupport.project schema defines no way of specifying a processor path for an ECU for now. I doubt it is necessary, since these source roots are unlikely to need APs.