Bug 121950 - Wrong error badges umbrella
Wrong error badges umbrella
Status: RESOLVED FIXED
Product: ide
Classification: Unclassified
Component: Code
6.x
All All
: P2 with 5 votes (vote)
: 6.x
Assigned To: issues@ide
issues@ide
issue_reviewed
: UMBRELLA
: 135520 136432 141931 (view as bug list)
Depends on: 165446 170190 193183 195587 102290 104665 109900 114446 115412 117055 118341 118348 118784 118879 118936 119429 119669 120600 120765 120837 121561 121890 122774 123181 124137 128614 129938 134805 135023 135894 136522 136834 137861 139274 140911 141244 142485 143849 145880 146272 147000 147168 149356 149770 150559 150667 150766 151297 151635 152085 152789 153158 158414 160109 161980 163278 163347 163530 164475 164511 164716 165712 165946 167213 168568 171616 173802 175048 179924 182121 183364 188323 194474
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-14 23:17 UTC by Jiri Prox
Modified: 2011-10-26 16:16 UTC (History)
11 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
nbproject files for fop (1.22 KB, application/x-gzip)
2008-03-15 12:34 UTC, pbw
Details
xmlunit-1.1 jar file (84.23 KB, application/octet-stream)
2008-03-15 12:39 UTC, pbw
Details
Log file at time of resolution of error badges (52.12 KB, text/plain)
2008-04-17 01:09 UTC, pbw
Details
Basic structure of project (11.41 KB, image/png)
2008-04-17 01:10 UTC, pbw
Details
First image (9.09 KB, image/png)
2008-05-23 13:01 UTC, pbw
Details
2nd image (14.20 KB, image/png)
2008-05-23 13:02 UTC, pbw
Details
3rd image (19.32 KB, text/plain)
2008-05-23 13:04 UTC, pbw
Details
Fourth image (19.56 KB, image/png)
2008-05-23 13:06 UTC, pbw
Details
Fifth image (14.14 KB, image/png)
2008-05-23 13:09 UTC, pbw
Details
Apache XML-Sec 1st image (16.98 KB, image/png)
2008-10-31 06:14 UTC, pbw
Details
Apache XML-Sec 2nd image (28.71 KB, image/png)
2008-10-31 06:15 UTC, pbw
Details
Apache XML-Sec 3rd image (18.96 KB, image/png)
2008-10-31 06:17 UTC, pbw
Details
Apache XML-Sec 4th image (17.67 KB, image/png)
2008-10-31 06:18 UTC, pbw
Details
nbproject directory tar.gz (1017 bytes, application/x-gzip)
2008-10-31 06:20 UTC, pbw
Details
captured IDE log when the problem happened (305.79 KB, text/plain)
2009-02-23 16:56 UTC, yweng
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Prox 2007-11-14 23:17:59 UTC
This is umbrella issue for wrong error badges
Comment 1 pbw 2008-01-17 01:57:35 UTC
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
Comment 2 pbw 2008-01-17 04:39:56 UTC
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.
Comment 3 pbw 2008-03-15 12:31:57 UTC
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.


Comment 4 pbw 2008-03-15 12:34:56 UTC
Created attachment 58428 [details]
nbproject files for fop
Comment 5 pbw 2008-03-15 12:39:30 UTC
Created attachment 58429 [details]
xmlunit-1.1 jar file
Comment 6 pbw 2008-04-17 01:05:16 UTC
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.
Comment 7 pbw 2008-04-17 01:09:21 UTC
Created attachment 60316 [details]
Log file at time of resolution of error badges
Comment 8 pbw 2008-04-17 01:10:18 UTC
Created attachment 60317 [details]
Basic structure of project
Comment 9 Jiri Prox 2008-04-17 09:15:54 UTC
pbw: the error badges are probably wrong because of the exception after changing configuration. It's reported as
separate issue 130687
Comment 10 pbw 2008-04-17 10:19:18 UTC
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.)
Comment 11 giorgio42 2008-05-01 20:31:40 UTC
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
Comment 12 Jiri Prox 2008-05-03 14:24:10 UTC
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)?
Comment 13 pbw 2008-05-23 11:17:28 UTC
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.
Comment 14 pbw 2008-05-23 13:01:14 UTC
Created attachment 61825 [details]
First image
Comment 15 pbw 2008-05-23 13:02:09 UTC
Created attachment 61826 [details]
2nd image
Comment 16 pbw 2008-05-23 13:04:43 UTC
Created attachment 61827 [details]
3rd image
Comment 17 pbw 2008-05-23 13:06:53 UTC
Created attachment 61829 [details]
Fourth image
Comment 18 pbw 2008-05-23 13:09:15 UTC
Created attachment 61830 [details]
Fifth image
Comment 19 Jan Becicka 2008-06-06 11:35:09 UTC
*** Issue 135520 has been marked as a duplicate of this issue. ***
Comment 20 Jan Becicka 2008-07-25 10:10:17 UTC
*** Issue 136432 has been marked as a duplicate of this issue. ***
Comment 21 Jan Becicka 2008-07-29 10:33:16 UTC
*** Issue 141931 has been marked as a duplicate of this issue. ***
Comment 22 giorgio42 2008-08-26 13:12:23 UTC

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).
Comment 23 pbw 2008-10-31 06:04:04 UTC
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.


Comment 24 pbw 2008-10-31 06:14:12 UTC
Created attachment 72957 [details]
Apache XML-Sec 1st image
Comment 25 pbw 2008-10-31 06:15:04 UTC
Created attachment 72958 [details]
Apache XML-Sec 2nd image
Comment 26 pbw 2008-10-31 06:17:41 UTC
Created attachment 72959 [details]
Apache XML-Sec 3rd image
Comment 27 pbw 2008-10-31 06:18:19 UTC
Created attachment 72960 [details]
Apache XML-Sec 4th image
Comment 28 pbw 2008-10-31 06:20:36 UTC
Created attachment 72961 [details]
nbproject directory tar.gz
Comment 29 yweng 2009-02-23 16:56:28 UTC
Created attachment 77253 [details]
captured IDE log when the problem happened
Comment 30 David Strupl 2009-11-09 14:08:35 UTC
I guess this one can be closed now.
Comment 31 Jan Becicka 2009-11-10 01:12:38 UTC
great job guys!
Comment 32 Jiri Prox 2009-11-10 02:06:27 UTC
All issues in this umbrella are fixed -> closing

thanks


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo