Dev build. Created a new Ant-based module suite. Added module m1 to it. Copied a random *.png to the m1 package; also create a class m1.C so project customizer would let me mark it as public. Under API Versioning, marked package m1 as public. Added module m2. Added Always Enabled action to m2. Edited @ActionRegistration to include iconBase="m1/iconname.png". Editor claims icon cannot be found, as expected - there is no dep. Added module dependency m2 -> m1. Now F9 on the new action class works, but the editor reports the icon as missing, even after a restart. NetBeans Module Metadata Inspector plugin confirms compile classpath of action includes build/cluster/modules/m1.jar ~ m1/src. If I run 'JAVA_HOME=/space/jdk7 ant -f test197553/build.xml clean build' compilation succeeds if and only if I have not mistyped the name of the icon, as expected. So sounds like an issue with the editor, maybe another manifestation of bug #197104?

Is Jesse saying: "worksforme"?

Not at all. There is definitely a bug, I am just not yet sure in which component.

I've just managed to compile a patch that uses wrong iconBase with completely missing icon (bug 198318 comment #1). It works on JDK1.6. No error appeared.

Test case from comment #1 still reproducible in a dev build.

CachingFileManager.findFile searches through a classpath consisting of FolderArchive entries. $userdir/var/cache/index/s3/java/14/classes/ contains just m1/C.sig, so of course findFile returns null.

Interestingly, if you specify iconBase="m1/C.class", you also get an error badge. But iconBase="m1/C.sig" removes the error badge! In other words, the IDE's implementation of Filer.getResource is quite useless when applied to a FolderArchive (as opposed to a CachingArchive as in bug #197104).

The issue has nothing in common with difference among Caching and Folder archive. The FolderArchive works fine when it's applied to a non project folder. The CachingArchive represents a FileManager source for zip file content on classpath. The zip file content contains all needed files, class files + resources. If the classpath contains a folder the FolderArchive is used and it works as well as the CachingArchive. The problem is when project artifact is on classpath. In this case the source for FileManager is he NB internal cache maintained by the JavaCustomIndexer. Unlike the plain folder or jar it does not contain resources and this is the reason why they cannot be found. The FileManager cannot use the build artifact itself as it may not exist. It should not use cache + build artifact (the icon will be available only for non cleaned project). This will cause even worse behavior. You start with a project depending on another built project. You clean the lib project and open some file from main project having the AR annotation. But there is a new error which will be detected by IncorrectErrrorBadges task. The task will fire a rescan of project. You will end with file with error + additional scan. The same happens after build.
Unfortunately event the COSSynchronizing index cannot be used as it's created only for web projects.
Probably the only possibility is to lookup these resources in the source root with java files excluded.

Needs big changes in classpath mappings.

Fixed jet-main 12decab4469b

Integrated into 'main-golden', will be available in build *201105200400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/12decab4469b
User: Tomas Zezula <tzezula@netbeans.org>
Log: #197553:ActionRegistration's iconBase does not work with icons located outside

(In reply to comment #9)
> Fixed jet-main 12decab4469b

I do not think this is quite correct. What if there are two source roots contributing to the binary root? In particular, what if the owner of the icon is a Maven project and the icon is in src/main/resources?

>I do not think this is quite correct. What if there are two source roots
>contributing to the binary root? 
See my comment #17.
The problem was that the processor looks a resource which is not available because the cache contains only classes. As I've explained in the comment #17 binary roots cannot be used at all it will make the situation even worse (reparse after each build, clean). The patch does not use binary to source mapping as you think about it (SFBQ). It uses cache to source mapping. The cache to source is 1 : 1 mapping, each source root has a cache root.

>In particular, what if the owner of the icon
>is a Maven project and the icon is in src/main/resources?
It's up to maven if the compile classpath contains the src/main/resources it should work fine.

(In reply to comment #12)
>> In particular, what if the owner of the icon
>> is a Maven project and the icon is in src/main/resources?
>
> It's up to maven if the compile classpath contains the src/main/resources it
> should work fine.

A Maven project will have src/main/java + src/main/resources in the SOURCE cp, is that what you meant?

Why is this NO701? It was reproducible in 7.0 builds and it seems the fix was put in for 7.1.

As it was not verified by QE.
But I can put it into 7.0.1, no problem.

My understanding was that NO701 referred to issues which (despite the Version field) do not actually apply to 7.0.1. Whether or not you plan to backport a fix to 7.0.1 is unrelated.

Transplanted into 701:
http://hg.netbeans.org/releases/rev/06f4c629e20e

I guess you meant to change the Target Milestone, not the Version.

Integrated into 'releases'
Changeset: http://hg.netbeans.org/releases/rev/06f4c629e20e
User: Tomas Zezula <tzezula@netbeans.org>
Log: #197553:ActionRegistration's iconBase does not work with icons located outside

I can still reproduce this bug on the 7.0.1 release AND the 7.1 dev build in a maven project.

The module containing the @ActionRegistration does not have a direct dependency on the module containing the icon. The icon is located in the branding module so different branding could have different icons.

It makes sense for branding modules to override existing resources instead of add additional resources.

Putting the issue back on fixed, apologies for the inconvenience.

While evaluating the issue I've found another problem.
The error is not shown is some case when it should be shown (it's caused by some strange BOOT CP content) causing IllegalArgumentException.
So I created a new issue #202001

Created attachment 110657 [details]
Screenshot bug reproduction in maven

Moved some icons from the branding module to another module.
Have reproduced the bug with the following scenario:

- maven rcp project with Modules A and B
- Module A contains the icon in src/main/resources
- Module B contains a direct dependency on Module A and has a @ActionRegistration with a reference to the icon.

Rebuild both modules and the entire application, but annotation still marks the icon as missing.

Reopened issue as it is not solved for maven projects.

Works fine for Ant based NB projects.
Seems as Maven specific issue.

The message "...with no leading slash" is obviously bogus in this case and is not the same as the "cannot find..." error that this bug dealt with.

With bug #202001 fixed, e.g.

diff --git a/java.source/src/org/netbeans/modules/java/source/parsing/FolderArchive.java b/java.source/src/org/netbeans/modules/java/source/parsing/FolderArchive.java
--- a/java.source/src/org/netbeans/modules/java/source/parsing/FolderArchive.java
+++ b/java.source/src/org/netbeans/modules/java/source/parsing/FolderArchive.java
@@ -154,7 +154,7 @@
         }
         try {
             final URL srcRoot = getBaseSourceRoot(this.root.toURI().toURL());
-            if (srcRoot != null) {
+            if (srcRoot != null && "file".equals(srcRoot.getProtocol())) {
                 final File folder = new File(srcRoot.toURI());
                 file = new File (folder,path);
                 if (file.exists()) {

the annotation is correctly displayed with an error mark iff the path does not exist in the other project. Command-line compilation (mvn install) works as well. Tested against RELEASE701; the processor code is different in 7.1 (bug #196452).