This is umbrella issue for wrong error badges
Although I can't use the code I'm working on, here are some more details of a problem I'm finding.
I have built metro 1.1 from the source bundle, and I have created a library from the generated jars, the sources and the
I create a new web service from a wsdl, and deploy it.
I create a new java app, and then a new web service client within the app, as per the tutorials. Wsimport generates the
appropriate java and class files. Into the app, I copy some java files from an existing application. These files
reference classes in the metro 1.1 webservices jars, and wsimport-generated files. There are read marks against both
sets of references, and the project cannot build.
I add the metro library to the Libraries. I can now build the project. However, there are still red marks against at
least the metor references.
I make a separate copy of the metro 1.1 files. I "add a jar" webservices-rt.jar from this location to the Libraries for
the project, after the metro library. The red marks disappear. I remove the jar from the project Libraries. The red
marks re-appear for both the 1.1 references and the references to generated files. I restore the alternative
webservices-rt.jar to the project, and all of the error marks disappear.
I'm running 6.0.1 Build 200801140000 on Java 1.6 update 4, so there are no webservices jars in jre/lib, and there is no
All of the distributed JAXB and JAX-WS jars are still in java1/modules/ext/jaxws21 and java1/modules/ext/jaxws21/api.
I'm running glassfish V2 UR1, with the metro 1.1 jars installed, and the endorsed jar removed.
Some more details.
I deleted the project and sources, and started again. Note that I'm working from pre-existing sources, but I want to
create a NetBeans project from a wsdl. I have already created the web service in a similar manner.
I create a new java application. Then I create a new web service client from a wsdl; in this case, I get it from my
deployed web service. This is a different sequence from my previous attempt. I'll come back to that.
I refactor-copy java files into the package from existing sources. I paste text as required from the existing main class
into the newly generated one, and fix what imports I can.
I build and find problems accessing the metro 1.1 classes. I add the metro library to the project libraries. Red badges
remain. I build successfully.
I add to the project the webservices-rt.jar from the same location as the metro library files. The red badges remain. I
delete the jar, and add a copy of webservices-rt.jar from a different location. The badges disappear.
The difference in behaviour from my previous attempt is that at no stage do I get badges on the references to the
classes generated by wsimport. The difference in the sequence of events is that last time I copied the non-generated
java sources in before creating the web service client; that is, before the wsimport files had been generated.
This difference meant that, until I added the independent copy of webservices-rt.jar to the project libraries, I would
have badges on the metro references, and the references to the generated files. When I added the jar, all badges
cleared. When I removed it again, all badges would reappear, even though there is no connection between the metro
references and the wsimport-generated file references.
Here are a couple of examples from open source projects.
Download apache-fop via anonymous subversion from http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk
If you don't have Jimi support in your installation, remove the file
I have JAI support in my Java installation, so I can't readily say what to remove to circumvent errors in that case.
Add ant.jar, junit.jar (3.*), and xmlunit-1.1.jar to lib. (I'll add a copy here.) Put the nbproject dir that I will
post, as a sibling of src. One of the source roots of this project is a directory of generated sources. Build the
project by running the jar-main target.
I see error badges on src/java-1.4, and in src/java at org.apache.fop.fonts, o.a.f.fonts.type1, o.a.f.pdf, o.a.f.render.apf.
The source root at build/gensrc does not appear as a source root. When I close and re-open the project, build/gensrc
appears, but the error badges (some of which are related to files in build/gensrc) remain. Generally, opening all of the
files in turn will clear the errors.
Created attachment 58428 [details]
nbproject files for fop
Created attachment 58429 [details]
xmlunit-1.1 jar file
Another aspect of this problem. Using 6.1RC1 or a daily build of 6.1, I had problems with a small free-form project that
built a web app for GF V2UR2, and built a client to access the service. Both sides were using wsimport to build sources
from a wsdl. Therefore, on both sides there were temporary sources. Client and server sides had their own build.xml, and
there was an overall build.xml.
Initially, I made a single FF project at the top level, and specified the source roots:
I specified the output for the server side as
and for the client side as
because the temporary sources compiled into the respective classes directories, with server/src and client/src depending
on the compiled temporary classes in their respective classes directories.
The client side dependencies were located OK, but the server side could not resolve the references to the generated
source and class files.
The classpaths for each of the four roots were specified individually - none for the generated files, and the classes
directories for the non-generated files. It's the sort of structure that occurs time and time again.
None of the usual tactics would resolve the server dependencies in the generate files.
I deleted the project and started again, with separate projects for each side, and an overall project with noj source
roots. This time neither the server nor the client side could resolve dependencies. Red flags everywhere.
Finally, I went into the properties of each project, and in 'Java sources classpath' unticked the 'Separate classpath
for each source package folder' button. presto, all of the errors resolved, throwing an exception in the process. I will
attach the extract from the log file.
Created attachment 60316 [details]
Log file at time of resolution of error badges
Created attachment 60317 [details]
Basic structure of project
pbw: the error badges are probably wrong because of the exception after changing configuration. It's reported as
separate issue 130687
Yes, the CoModEx is issue 130687. However, that seems to be incidental. Switching to a common classpath fixed my error
badges problem. It's the only thing that did. Before the exeption, I had error badges. After switching off individual
classpaths and getting the exception, the error badges disappeared. (I noticed the exception marker in the status bar at
the left coming on for a few seconds, which is why I looked for the exception in the log.)
I have installed NB6.1 FCS and opened 15 projects. To test something else I closed NB, deleted the var directory and
restarted it. Now 10 of the 15 projects show red error badges.
In some cases the error badges go away if I open the file and just wait for some time. Sometimes I have to make a minor
change and save and sometimes nothing helps.
giorgio42: please describe you project configuration. Are there dependency among the project? What type of project do
you use? Are all classes names matching the file names (class living elsewhere problem)?
More feedback on the Apache FOP codebase. I had a persistent problem with my installation, so I did a fresh checkout,
and copied my nbproject directory and project.xml across. When I opened the second project I had the situation shown in
the first and second images.
My original project was showing a persistent flag in the build/gensrc tree on CodepointMapping.java. As I recall, the
problem was a reference to a class in the src/java tree. I say, "as I recall", because I foolishly neglected to take
snapshots of the editor panes, thinking that the problem would persist. Ho ho.
Note that in the new (lower) project, build/gensrc is ok, but there are errors on src/java and src/codegen/java.
I started the process of opening errored files, having NB discover that there was nothing wrong, and clear the error
when I opened the next file. This process has improved, because all of the errors cleared without my having to open each
I was expecting to see the error flag pop up on build/gensrc, because that was exactly the experience I had on the
original project. However, all of the errors cleared without generating any in build/gensrc. I left NB running
overnight, and when I opened CodepointMapping.java in the original project, the error cleared.
This error had been particularly persistent. I believe that I had deleted the cache and re-opened NB in an attempt to
clear it, without success, but this time it cleared.
Created attachment 61825 [details]
Created attachment 61826 [details]
Created attachment 61827 [details]
Created attachment 61829 [details]
Created attachment 61830 [details]
*** Issue 135520 has been marked as a duplicate of this issue. ***
*** Issue 136432 has been marked as a duplicate of this issue. ***
*** Issue 141931 has been marked as a duplicate of this issue. ***
What is the state of this issue in the current 6.5 dailies? I still have this 20080824xxx.
I have the same project on my PC and on my laptop. On the PC I have error badges for all projects that use JFreeChart,
but not on the laptop (same NB version).
The usual measures to get rid of the wrong error badges on the PC do not work (closing NB, deleting the var folder and
restart, opening the wrongly badged Java files, just nothing helps except probably starting with a new userdir, but
firstly scrapping the userdir sucks, and secondly, I want this thing to get fixed, and maybe my current situation - same
environment, same project, but different result - could serve as a guinea pig... ).
Can you please give me an advice on how to track down the differences between the two boxes (logging flags to pass on
Running 6.5 daily build NetBeans IDE Dev (Build 200810301401).
The codebase is the Apache XML-Security project source for release 1.4.2.
The project is open. When I fire up 6.5, it and my other open projects show up,as expected. Apache XML Security has an
error badge. Opening the project tree shows the first attached image. All the errors are in org.jcp.xml.dsig.internal.dom.
Opening that package shows the second attached image. There are numerous files in error. I open some badges files. The
typical result is as show in the third attachment. No internal error. As I open a badged file, the status bar shows
Scanning projects, and during this process, the error badges redistribute over the files in the package. Some of the
error badges stay on the same file; in other cases, the file loses it error badge; in other cases a file gains an error
badge it didn't have before. When the scanning process finishes, the error badge distribution goes back to what it was
I open *all* of the files in the package, and then close them in reverse order, as quickly as I can. By the end of this
process, all the error badges have cleared. See the fourth attachment.
Created attachment 72957 [details]
Apache XML-Sec 1st image
Created attachment 72958 [details]
Apache XML-Sec 2nd image
Created attachment 72959 [details]
Apache XML-Sec 3rd image
Created attachment 72960 [details]
Apache XML-Sec 4th image
Created attachment 72961 [details]
nbproject directory tar.gz
Created attachment 77253 [details]
captured IDE log when the problem happened
I guess this one can be closed now.
great job guys!
All issues in this umbrella are fixed -> closing