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.
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 javadocs. 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 jre/lib/endorsed. 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. Peter
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 src/java/org/apache/fop/image/JimiImage.java 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: server/src server/tmp/src client/src client/tmp/src I specified the output for the server side as server/classes and for the client side as client/classes 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. Georg
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 one. Congratulations! 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] First image
Created attachment 61826 [details] 2nd image
Created attachment 61827 [details] 3rd image
Created attachment 61829 [details] Fourth image
Created attachment 61830 [details] Fifth image
*** 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 startup etc.)? [WinXPSP2,1.6.0_10rc).
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 previously. 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 thanks