Steve, why do you think this is a bug in core?  I think java module
should have to do its analysis first.

Will check; still let me share sincere doubts that P1 is appropriate
for this issue (even if it is a regression), if you consider this
feature's impact on the user and rest of the system.

I'll make this P2.  In QA we get a little confused because it is often
said all regressions are P1.  I'll seek some clarification from my mgmt for my own
information.  Also feel free to re-assign to a better module.  Since I see this both in Explorer
and Source Editor I didn't really know where to start it...not too familiar with how Java Module
fits in...I'll try to learn about this.

Could you write us step-by-step instructions 
to reproduce it?
Something like: 
Using internal compiler build this folder, 
then clean this and compile this.
Thanks

Sorry we cannot reproduce it in current dev builds. Please provide
exact reproduction steps.
Things, which may be involved:
1. the compiler compiles to another directory (Target property is set)
2. the file in question is not compiled directly (e.g. invoking
Compile on it or its parent folder), but rather indirectly through
dependencies. E.g. when you have Foo.java and Bar.java, Foo class
references Bar and you start compilation with only Foo selected, Bar
will be compiled as well.
3. 2 + the indirectly compiled file resides in another directory than
the directly compiled one(s)

I will ask Honza to have his engineers work with you.
I see this on EE build 030203_2, but this is on a Q build that
is a couple weeks old.  Our latest Q build is bad so I'd like to
keep this open until we see a fix has happened.
If it's fixed in the new Q build I will close.
I would guess it has been fixed, especially if Honza's folks
can't reproduce...sound good?

Confirmed. I can easily reproduce the problem with both NB dev build
#200302060100 and S1S build #030205_4 on WinNT 4 SP 6, Sun JDK 1.4.1_01.

Steps to reproduce:

1. Start with a clean userdir.
2. Open examples/colorpicker/ColorPreview in the Editor.
3. Make some editing changes and delete them.
   -> the icon is changed to the 'needs compile' status.
4. Re-compile the source (F9).
5. Watch the icon, the status badge never changes and the 'needs
compile' flag stays on forever.

Please investigate.

Ok, I shall look at it.

I believe this regression was caused by integration of issue 29002. David, Jesse can you check it. 
RCS file: /cvs/openide/src/org/openide/loaders/MultiDataObject.java,v
Working file: MultiDataObject.java
head: 1.74
branch:
locks: strict
access list:
keyword substitution: kv
total revisions: 92;    selected revisions: 92
description:
[...]
----------------------------
revision 1.72
date: 2003/01/13 13:33:26;  author: dstrupl;  state: Exp;  lines: +13 -2
#29002: Jesse's code to eliminate unnecessary firing of PROP_FILES
----------------------------

Reassigning to Jesse for investigation. The fix of issue 29002 is incorrect. PROP_FILES has to be fired for newly created MultiDataObject with secondary entries.

"PROP_FILES has to be fired for newly created MultiDataObject with
secondary entries" - why? Where in the docs does it say anything of
the sort? Why should a property change be fired for a property which
has not changed?

For now, will assume that JavaDataObject is simply not listening
aggressively enough. For example, after DataObject.modified has
changed, or after a compiler has been created for a JDO,
lissenToClasses() could be called.

AFAIK MultiDataObject.files() returns an incomplete set initially
(before folder recognition is finished), which is arguably a bug; if
you agree that this is the real problem, assign back to datasystems.
IMHO it should block until all files in the folder have been
recognized by some loader (not necessary for the DataObject's to be
constructed, just for the file -> primary file mapping to be known).

If you allow to create MultiDataObject with just primary file and add secondary entries later, that at the beginning there were no secondary file. After secondary files are recognized, there _ARE_ secondary files. So this property was changed. So PROP_FILES was fired before and must be fired now. 

I still suggest fixing the behavior of files() to be accurate from the
start, rather than firing PROP_FILES during folder recognition. It is
likely to be simpler and faster. Creating a MDO, which is by
definition a collection of related files, incl. running subclass
initialization code, before all of its files are even known, strikes
me as bizarre at best. David can comment.

Nonetheless short-term workarounds in JavaDataObject should be
straightforward if they are needed, and have less impact than
org.openide.loaders.* changes.

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

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

30434 has more info I think worth reviewing.

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

Created attachment 9077 [details]
First draft of a patch for MultiDataObject

I have attached patch for MultiDataObject that does following:
1. does not fire before the MDO is constructed
2. fires at most twice (for each MDO)

I agree that 2. is not very nice but I did not find better solution
that would stay correct without a race condition. The current tests in
openide pass with the patch. Also Tomas agrees that for JavaDataObject
it works. So should I apply this patch or are there any improvements
possible? If there are no objections I will apply this patch.

Patch applied (after small change)
to
MultiDataObject.java 1.75.

Sounds like a workaround not a fix, but probably a proper fix can wait
until New Datasystems.

[20030325350] verified. 

Not sure, If I should reopen this issue or some of its duplicates, but
compile badges still does work.
Steps to reproduce:
1. Mount a new filesystem and set it as a target folder for External
Compilation
2. Select "examples" folder and do Build All
3. Select "colorpicker" folder and do Clean All -> compile status
badges do not update its state! 
4. Do refresh folder on colorpicker folder -> badges will update

Please evaluate

Honza you have right. If the target pacgage is not explorord in
explorer the status of files is not updated. 

We decided to close this issue and reopen issue 30860

verified