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.

Bug 173202

Summary: ClassNotFoundException: org.openide.filesystems.annotations.LayerGeneratingProcessor
Product: java Reporter: Jesse Glick <jglick>
Component: SourceAssignee: Jan Lahoda <jlahoda>
Severity: blocker CC: rmichalsky, tzezula
Priority: P3    
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter: 159187
Bug Depends on: 174202    
Bug Blocks:    
Attachments: stacktrace

Description Jesse Glick 2009-09-28 18:27:29 UTC
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.

java.lang.ClassNotFoundException: org.openide.filesystems.annotations.LayerGeneratingProcessor
        at java.lang.ClassLoader.loadClass(
        at java.lang.ClassLoader.loadClass(
        at java.lang.ClassLoader.loadClassInternal(
Comment 1 Jesse Glick 2009-09-28 18:27:34 UTC
Created attachment 88444 [details]
Comment 2 Jan Lahoda 2009-10-02 09:18:36 UTC
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

Another part of the problem is that pelmel should be able to tolerate even broken setups.
Comment 3 Tomas Zezula 2009-10-02 09:38:57 UTC
Right, ClassPath is not the right place.
We can create a new constant class in the (the old classpath module which contains the java specific APIS). Something like 
JavaProjectConstants in java/project.
Comment 4 Jesse Glick 2009-10-02 17:22:16 UTC
Agreed that a new constant ClassPath.PROCESSOR in 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.
Comment 5 Jan Lahoda 2009-10-19 08:33:36 UTC
Pelmel uses "classpath/processor" (=PROCESSOR_PATH) if available:
Also, pelmel should not throw exceptions if it cannot find an annotation processor:
(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?
Comment 6 Jesse Glick 2009-10-20 18:17:12 UTC
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.