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.
Summary: | Stale class cleanup broken by generated sources | ||
---|---|---|---|
Product: | apisupport | Reporter: | Jan Lahoda <jlahoda> |
Component: | Harness | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ibeaumont |
Priority: | P3 | ||
Version: | 7.0 | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Jan Lahoda
2011-01-27 22:14:06 UTC
Bundle.java is in build/classes-generated. When CustomJavac.cleanUpStaleClasses() asks for the sourcepath, only src/ is included, not this dir. I think that is because compile() sets up generatedClassesDir _after_ cleanUpStaleClasses is called. core-main #e69eddab943f Integrated into 'main-golden', will be available in build *201101290000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/e69eddab943f User: Jesse Glick <jglick@netbeans.org> Log: #194789: Stale class cleanup broken by generated sources I have a module suite that always gives me this warning and recomplies everything in one module all the time. I've recently moved to a new computer and got all the new sources again hoping it would go away, but no joy. Having lived with it for years, I would now really like to find the cause/solution as it then recompiles 900 source files for no reason. Any hints on how to track it down or what additional information I could provide if I log a new defect? (I'm on 7.2.1 and still the problem persists). ibeaumont: the known bug here was fixed for NB 7.0. If you are still seeing similar symptoms you may have encountered an unrelated bug, or a corner case in this one, etc. Figure out how to reproduce the problem from scratch, then file it. Is there no logging or anything I could turn on to try to help figure out why it thinks the class is stale? Well, ant -v may give some useful information, but in general the most brainless way to proceed is to make sure you have a reproducible test case of some kind, then use bisection to narrow it down to a minimal test case that omits any proprietary information and will often make the cause (and fix) obvious. Just before I go further and waste too much time in creating a test case, can I check it isn't supposed to do this... I have Module 1 containing classes A,B,C. Module 2 has classes X, Y. Module 2 has a dependency on Module 1, and class X imports class A. Now, if I change any line of code in any class in Module 1 - then class X in Module 2 is marked out of date and recompiled when I build the project. IIRC this is normal as the dependency check is done by JAR rather than by *.class entry. |