Bug 250402 - Import resolution breaks when outside source deletes eclipse-generated class files.
Summary: Import resolution breaks when outside source deletes eclipse-generated class ...
Status: VERIFIED NOT_ECLIPSE
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4.1   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.5 M3   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-10 05:31 EDT by Maarten Billemont CLA
Modified: 2009-04-24 06:59 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maarten Billemont CLA 2008-10-10 05:31:41 EDT
We're using Maven along with Eclipse in a rather large project.  Each time we fire up a ''clean install'' in maven, massive amounts of errors occur in Eclipse.  Eclipse is appearantly not smart enough to detect class files that disappeared and instead of rebuilding the files in question it acts like the import is unavailable.  Obviously, ctrl-clicking the import brings you to the right file.

The only way to fix this is by forcing a rebuild in eclipse by doing a global clean.

Moreover, these problems don't show up until you try editing a file.  Then that file you edited shows import resolution errors.  But no other files do; until you edit them (or force save them).  As such; it's impossible to tell the extent of the problem and the only safe way to fix it is doing a global clean operation which can take forever on large projects (even if you'd just done a ''mvn clean install'' on a single eclipse project/maven artifact).

I suggest the eclipse compiler check for missing class files, recursively, and rebuild them as necessary.
Comment 1 Jerome Lanneluc CLA 2008-10-14 04:49:32 EDT
I believe tampering with the .class files created by the Java builder is not supported.
Comment 2 Kent Johnson CLA 2008-10-14 12:14:12 EDT
Have you looked at the available options under Window -> Preferences -> Java -> Compiler -> Building -> Output Folder

1. You can turn off scrubbing output folders as part of a clean.

2. Or you can enable rebuilding .class files modified by others.



Your other option if your files are being compiled outside of Eclipse is to remove the Java Builder from your project.
Comment 3 Kent Johnson CLA 2008-10-17 12:44:19 EDT
Please reopen if none of the proposed options works for you.
Comment 4 David Audel CLA 2008-10-28 06:51:21 EDT
Verified for 3.5M3
Comment 5 Maarten Billemont CLA 2008-10-28 12:33:51 EDT
Note this issue is not caused by Maven overwriting Eclipse class files.

Maven puts its class files in {project}/target/classes.
We had set Eclipse up to use a bindir in {project}/target/eclipse.

This issue is caused due to the maven clean operation deleting everything under {project}/target, as such causing Eclipse's class files to disappear.
Comment 6 Kent Johnson CLA 2008-10-28 12:51:50 EDT
> This issue is caused due to the maven clean operation deleting everything
> under {project}/target, as such causing Eclipse's class files to disappear.

So how is this an Eclipse bug if Maven is deleting .class files it didn't create?


Did you enable this option ?

See Window -> Preferences -> Java -> Compiler -> Building -> Output Folder -> Rebuild .class files modified by others
Comment 7 Maarten Billemont CLA 2008-10-29 04:49:34 EDT
This is an Eclipse bug in the sense that Eclipse should notice its class files are no longer there and either give an error specific to that (instead of complaining about import resolution) or simply automatically recompiling any class files that do not exist (this can imo be done without the need for a special option to be set, since we're not actually overwriting any existing class files - which means, we don't risk breaking any other software).

I cannot test the option you gave me right now, simply because I've no access to my work setup right now.  But I think the option is not entirely relevant in this situation, even if it ends up being a work-around for the issue.
Comment 8 Philipe Mulet CLA 2008-10-29 06:31:21 EDT
Eclipse builders are required allow proper sequencing. For instance, the Java builder will output to its bin output, and allow a subsequent builder POST-PROC to do more work on these classfiles (possibly changing their contents).

This is an important scenario which we have to support by default. If you enable the option Kent mentionned, then it will tell the Java builder to undo all the work done by POST-PROC.

If you know the Java builder is at the end of the food chain for .class files, then you may flip the option in your current setup, but this is not something we can flip easily after 8 years and many builders on top of us.

As Kent observed, I would rather question Maven thinking it has the right to delete class files it doesn't own. If it does such and thinks it is the way to go, relying that others will compensate for this, then they can control JDT behavior. 

Closing as not an Eclipse bug.
Comment 9 Olivier Thomann CLA 2008-12-09 12:52:44 EST
Verified for 3.5M4 using I20081208-1800
Comment 10 Maarten Billemont CLA 2008-12-09 16:09:36 EST
I still don't see what rebuilding class files that eclipse relies upon when they disappear has to do with supporting external post-proc.

I'm not asking eclipse recompile any file that is modified since its previous eclipse compilation.

I'm asking that eclipse recreate any class files that have disappeared, for whatever reason, and whose existance the eclipse dependency (import) resolution relies upon.

This applies to class files that disappeared for *whatever* reason.  The fact that this issue is specifically to do with Maven deleting them is irrelevant.  If the class files disappeared because the user accidently deleted them, rm'ed the build dir in an attempt to force a rebuild, file system corruption occurred, or whatever other reason, eclipse should heal itself by rebuilding those.

Rebuilding missing class files is not detrimental to any class file food chain or post-proc.

Please re-evaluate the issue based on my thoughts on the matter and reopen the bug if you decide it is appropriate.
Comment 11 Kent Johnson CLA 2008-12-09 16:26:18 EST
Have you even tried the option that we told you about in comment 2 and comment 6 ?

Does it work for you ? If not , why not ?


You may want to read our responses.
Comment 12 Maarten Billemont CLA 2008-12-09 17:05:56 EST
I have read your responses carefully.  And if there is something I have missed out on, do point that out to me.

In mean while, please read my comments carefully in return, and take a moment to considder the real issue this ticket addresses.

I had tried the option of "rebuild class files modified by others" which has no effect.  And as I have stated earlier; even if it did - the effect would be classified a workaround to this issue rather than a fix.
Comment 13 Maarten Billemont CLA 2008-12-09 17:11:21 EST
Just to be clear (my appologies for not including this in my previous comment and causing a second email), here's the best manner to reproduce the problem:

 - Open eclipse, verify your project compiles well and there are no errors.
 - Manually, outside of eclipse, remove the bin directory, or remove a specific class file in it.
 - In eclipse, edit a file in your project (if you deleted only one class file in the previous step, edit a file that depends on the class file you deleted).  Simply adding a space or so is fine.
 - Save the file, triggering the eclipse compiler.
 - Errors will pop up on all your import statements for which you have deleted class files.

The previously suggested option (Window -> Preferences -> Java -> Compiler -> Building -> Output Folder ->
Rebuild .class files modified by others) does not have any effect on the course of this reproduction scenario.
Comment 14 Jerome Lanneluc CLA 2008-12-10 12:19:42 EST
(In reply to comment #13)
It looks like you didn't refresh the project after you deleted the .class file on disk. Without refreshing the project I'm able to reproduce the problem you're seeing. However if I refresh after deleting the .class file, the problem is gone.

To refresh, you can either select the project and hit Refresh (F5), or you can enable Prefererences > General > Workspace > Refresh Automatically.
Comment 15 Frederic Fusier CLA 2009-04-24 06:59:09 EDT
Verified for 3.5M3 as per comment 9