This *may* be related to the fact that this output jar is outside the project directory.

Why this should make any difference, I don't know, but see issue #57656 for another case where this clearly makes a
difference -- for no clear reason.

Others have claimed that this works fine if this is a directory rather than a jar and under the project directory tree.
 Which made the difference is unclear.  Unfortunately, that will not work for me -- only the jar is complete and it must
be outside the project directory tree.

Oddly out of dozens of projects all in this situation it seems NetBeans 6 works alright for 1 or 2 of them.  Oddly I
stopped NetBeans, deleted all caches, and a different 1 or 2 projects worked!

Also note that NetBeans 6 started producing NullPointerExceptions (I filed one or two auto-reports on this earlier
today).  I'm pretty sure I wasn't getting these prior to adding the output jar to the classpaths -- but not entirely sure...

I *probably* know what happens here, and I am afraid we cannot generally solve this (and sorry I did not notice sooner).

We (Java infrastructure) are actually doing some magic when processing the classpath. We go through all elements of the
classpath and we try to find sources for the classpath element. If we find the sources, we remove the classpath element
from the classpath and put the found sources into the classpath (actually, the process is a bit more complicated, but
this is good enough approximation, I think).

This translation is necessary. The reason is that the inter-project dependencies in NB are expressed only through jars
(project artifacts). For example:
Project P1, with source root S1 and output jar D1.jar
Project P2, with source root S2 and output jar D2.jar

If S2 depends on S1, the compile classpath for S2 contains D1.jar, not S1. And D1.jar may not exist at the time we are
parsing a file from S2. So we need to modify the CP to reference S1 instead of D1.jar.

Also, in vast majority of cases I am aware of, this works OK (there were some problems with libraries+sources, which we
fixed, but these are unrelated to this problem).

In your case, if we kept the jar on the CP altogether with the sources, the problem should be (more or less) solved.
But, we cannot do this generally, IMO, as we would break many things. What we could do is to do a command line option,
which would ensure that we keep the jar on the classpath altogether with the sources (including some disadvantages, like
if you would remove class from the sources, the IDE would still see it, until you rebuild the project). I will try to
prototype this and attach a binary patch, so you can try it.

Created attachment 49645 [details]
Change to add the jar to cp (diff)

I've added the diff. Honzo should I commit it into the CVS or will you create a special build with it?

Created attachment 49649 [details]
Refined patch.

Created attachment 49650 [details]
Binary patch.

Thanks Tomas for (both online and offline) help. I have attached a slightly refined patch. Jess, could you please
download the binary patch, place it into:
${nbinstalldir}/java1/modules/patches/org-netbeans-modules-java-source/
directory (${nbinstalldir}/java1/modules/ should already exist, patches/org-netbeans-modules-java-source/ needs to be
created) and try if it works in your setup? To remove the patch, deleting the 116208a.jar file should be enough.

Thanks.

Ooops, I forgot, it is necessary to start the IDE with this command line option:
-J-DCacheClassPath.keepJars=true
You can append it eg. to the "netbeans_default_options" variable in ${nbinstalldir}/etc/netbeans.conf

Thanks.

I'm sorry I didn't get back to this sooner, but I was on vacation.

At any rate, the patch provided does the trick.

I'm wondering if the best solution is a -J switch as provided or something in project.xml to denote particular project
output jars as being not fully represented by the project's Java sources.  This issue is general to any project whose
output jars' classes are not fully covered by that project's Java sources.  In essence any class file produced by a
means other than a Java source file in the project is an issue.  This would seem to be specific to either free-form
projects or standard projects with custom build steps.  In any event this situation requires someone to do some
low-level-ish tinkering and if they had a specific low-level means to denote particular jars as falling into this
category that might be better than a global switch.  Just a thought anyway.

If you add such a project.xml flag, please add that information to this issue, so I can incorporate it in my automatic
project.xml generation scripts.

Also it would seem that these jars could and should always be "last searched" items in that the majority of references
encountered by the parser are still covered by project sources and other contributing projects, rather than such
sourceless class files.

As noted in previous comments, the patch noted does work (or did on the given daily build).  Also as noted there are
other ways to go about fixing this.  This issue *should* be addressed in *some* manner (the -J fix is okay) in NB 6,
however, given the strong impact of not addressing this to all those in my situation.  I've conversed with others on the
user lists that are doing some really ugly workarounds instead.

Also note that the fix to 57656 ended up being a new, special <build-file> element for project.xml, so it would seem
that changes in this area are still allowable.

I have applied the patch, so you shouldn't need the binary patch with future builds anymore. Could you please verify?

I was thinking about this, but did not come with anything better, sorry. Would be interesting to know more exactly do
you build the projects (do you generate some class file directly into the jar, without writing them first to a directory?).

Checking in parsing/CachingFileManager.java;
/cvs/java/source/src/org/netbeans/modules/java/source/parsing/CachingFileManager.java,v  <--  CachingFileManager.java
new revision: 1.9; previous revision: 1.8
done
Checking in parsing/CachingArchiveProvider.java;
/cvs/java/source/src/org/netbeans/modules/java/source/parsing/CachingArchiveProvider.java,v  <-- 
CachingArchiveProvider.java
new revision: 1.5; previous revision: 1.4
done
Checking in classpath/CacheClassPath.java;
/cvs/java/source/src/org/netbeans/modules/java/source/classpath/CacheClassPath.java,v  <--  CacheClassPath.java
new revision: 1.11; previous revision: 1.10
done

Thanks.  I'll download a daily later today or early tomorrow and verify that the -J switch works therein.

As for how and why this build generation is being done, yes, I can tell you more than you want to know.

First off, the reason for the generation is the unfortunate circumstances of ResourceBundles.  ListResourceBundle is
most efficient in that ResourceBundle is defined to always look for these first, which means PropertyResourceBundle can
be seriously non-performant in an applet on a WAN.  Also one can create and use compile-time constants in a
ListResourceBundle to avoid typos in ResourceBundle keys.  On the other hand, ListResourceBundle's are very hard for
localizers to work with as compared to properties files -- especially since ListResourceBundle allows developers to do
all sorts of open-ended stuff therein.

This situation pushed us into creating our own resource bundle file format (.rbInfo) for use by localizers from which we
generate ListResourceBundle classes -- replete with compile-time constants for use as keys.  This has some downsides in
that it does not interact well with Matisse or any other IDE tooling for that matter, but only with Java 6's improved
ResourceBundle APIs can we begin to consider PropertyResourceBundle again (as we can then look these up while explicitly
not looking for ListResourceBundle's).  This still leaves the lack of compile-time constants looming...

We have our own IDE-independent Ant scripts -- hence our use of free-form projects to integrate with these.  For a given
module, these scripts build ListResourceBundle classes for all our .rbInfo files into a per-module codebase directory. 
The module's Java files are then built against the module's classpath which includes the per-module codebase directory
-- and the resulting class files are also sent to the per-module codebase directory.  The codebase directory is then
jarred up to form a jar for the given module.

We actually have an 'apt' phase as well that comes before both of these and generates .rbInfo files in cases, but we
check those results into source control so that this operation becomes a no-op in integration (but not in NetBeans).

Since all of this is our own code we have flexibility to change things to be more amenable to NetBeans.  That said,
NetBeans users are in the minority here and any time consuming change would simply be a reason for the minority to be
forced to stop using NetBeans.  Also developers really should not have to build all our modules in NetBeans prior to
getting appropriate results from the editor's parser -- as we normally work with full source *and* a full set of module
jars pre-built in integration and installed as part of an instance of our product which we work against (which explains
why we're so severely impacted by issue #57656 as well).  As it stands your fix seems great in that: (1) it does not
require any changes on our part beyond project.xml [where we have to include the module's own jar in the module's
classpath] and (2) the parser gives correct results immediately without having to build anything in NetBeans.  I just
hope this does not cause other unfortunate side-effects -- especially since this is a special -J switch rather than the
default (and thus fully tested) mode of operation...

One further comment:

Since many developers will be impacted by this it would be easier for me to change something in how I auto-generate
project.xml's for modules for all developers than for me to tell and remind developers to add a -J switch to
netbeans.conf.  Even if the switch is at a per-project rather than per-jar level, it would be better (and seemingly more
correct...) to have this information travel with the project than on a global level in netbeans.conf.

That's not to knock the fix as is -- I'm grateful.  It just seems that this is really a per-project situation and thus a
given project should tell the IDE if it needs special treatment in this regard.

FWIW, I have a fairly large complicated project and using this method (the -J-D...=true) worked for me as well.

In my situation we have about 400 java classes and many jar file dependencies. I would get a red exclamation point on
several files even though they compiled just fine.  As soon as I added this switch, all that went away.

*** Issue 120210 has been marked as a duplicate of this issue. ***

*** Issue 120210 has been marked as a duplicate of this issue. ***