The problem is in the library setup. Imagine you have a library and you want to
attach sources to it. Believe or not, there is a difference between attaching
sources as a "src" folder and attaching them as a zipped file. In the first
case, MDR takes the attached sources as the primary and the ONLY source of data
for the whole library (if the attached sources do not cover all classes in the
library, classes without sources are not visible to code completion, etc.). In
the later case, the primary sources of data are class files (so all the classes
in the library are visible to code completion, etc.).

Reassigning to javacore. Please consider changing this behavior (or at least
adding a notice to a documentation), since the current behavior is very confusing.

Easy workaround exists -> either zip the sources and attach the zip instead of a
folder to the library, or  attach complete sources. Agreed this should be
documented.
John, could this be added somewhere to the documentation? (release notes or help
for Library manager?)

Adding Talley to the cc, since he's documenting the core functionality. Talley,
looks like we need to add a note to some source editor pages (especially any
code completion pages) about how to get this to work. Contact Martin Matula if
you have any questions.

i added mention to the "Attaching Source Code to a JAR File" help topic
(debug_source.html) and the library manager's csh page (actually GW did this for me)

Blaha, can you, please, verify this issue? Thanks.

Doc was verified in build 20050719.

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

Sorry to say, but this should be considered a bug and fixed. How many people
read the docs to find a workaround ? Normally the docs are read when someone
doesn't known how to do something. Please consider to reopen this.

As this bug is still valid for 5.5, I think this should be fixed. 

An experienced NB user might actually find the correct solution for this. But a
new NB user might well be turn his back on NetBeans ("Not even code-completion
or auto-import is working correctly... I'll go back to Eclipse")

Simply imagine the situation where the full sources are not available at all. In
this case I have the choice between a non-working completion and auto-import or
not having at least the partial sources at all. Not very satisfying.

Would you reckon a message dialog or similar indications warning the
user of this conflicting situation would be a good workaround (at
least the user knows that code completion is not working properly
beforehand), before an attempt for a full fix is made?

---------------------

Yes a message dialog would far better then the current situation. Currently the
user does not have a clue what's going on. Especially as code-completion is
working for parts of the library, so the user's assumption would be that the
Library definition itself is correct at will assume it's a bug in NB.

Old TM, changing to TBD

We consider it for 6.0

reassigning to java core

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

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

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

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

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

I also think that this big problem. I for example use Velocity in my projet and 
it use commons-collections-3.1.jar and some other jars. For Velocity I have 
source code but for another jars doesn't. And Netbeans mark all import of 
"org.apache.commons.collections." netbeans mark it as error. But When i run it 
all works. I try add also "Library" with source code of commons-collections and 
NB still claim that org.apache.commons.collections. doesn't exist :-(

Fixed? Probably.

I had encountered this issue yesterday with 6.0M10. All my org.hibernate classes/packages where not visible in the import code completion suggestions 
and the annotations produced a red signal sign. I have defined a Library containing:
- jboss-seam.jar
- thirdparty-all.jar
- hibernate-all.jar
- jboss-seam-ui.jar
- jboss-commons.jar
- jboss-el.jar

and added it to my project (EJB).

I just removed the source and the issue is solved partly. I can now see parts of the classes in the package org.hibernate, but not all (The ones I use, I can 
not see - Length annotation). Unfortunately, the ant build does not complain and I can see the missing class if I expand the jar hibernate-all.jar in my 
projects Libraries folder.

For me, this is a serious bug. I can send you a small project if you like ...

Just a follow up to my previous post:

If I restart the IDE after removing the sources from the Library, I can see all classes in org.hibernate.xx and all warnings are gone. But if I only remove the 
sources from the library without restarting the IDE, I can see only parts of the org.hibernate.xxx package.

I don't understand why Netbeans prefer source code before jar/classes for autocomplete and error scan. If source code 
doesn't exists it use jar/classes, bur when I add source code it forget on it and use only sources. Why?

Checking in nbproject/project.xml;
/cvs/java/source/nbproject/project.xml,v  <--  project.xml
new revision: 1.25; previous revision: 1.24
done
Checking in src/org/netbeans/api/java/source/ClasspathInfo.java;
/cvs/java/source/src/org/netbeans/api/java/source/ClasspathInfo.java,v  <--  ClasspathInfo.java
new revision: 1.10; previous revision: 1.9
done
Checking in src/org/netbeans/modules/java/source/classpath/GlobalSourcePath.java;
/cvs/java/source/src/org/netbeans/modules/java/source/classpath/GlobalSourcePath.java,v  <--  GlobalSourcePath.java
new revision: 1.11; previous revision: 1.10
done

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