Bug 25962 - Output classes is scrubbed due to error in compiling a source.
Summary: Output classes is scrubbed due to error in compiling a source.
Status: RESOLVED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0.1   Edit
Hardware: PC Windows NT
: P2 major (vote)
Target Milestone: 2.1 M4   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-11-11 05:06 EST by Søren Troest CLA
Modified: 2002-11-18 16:38 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Søren Troest CLA 2002-11-11 05:06:36 EST
Hey,

I've experienced that my .class's is scrubbed due to a compiling error in an 
another java source.

I've a class B which references a class X which is part of project's classpath 
eg. in a jar file.

Class X implements HttpSessionBindingListener which is not part of the 
project's classpath, this results in a compilation error in class B, with the 
following error : This compilation unit indirectly references the missing type 
javax.servlet.http.HttpSessionBindingListener (typically some required class 
file is referencing a type outside the classpath)

This compilation error is correct, but by altering the code in class B eg. 
adding a space or like wise, and compiling the class B, all my .class files in 
packages that exits after the packages in which class B exits, will be scrub, 
and not recompiled ?????

My SetUP:

TestProject
 |
 |_ dk.test1
 |          |_ A.class
 |
 |_ dk.test2
 |          |_ B.class (This Class contains the error, after altering the 
 |                      code, Class B + C will not exits - even though Class C
 |                      does not contian any errors).
 |_ dk.test3
            |_ C.class
 
I run WSAD 5.0 on NT, I've tried getting the lastet version of the eclipse eg. 
eclipse-SDK-I20021018-win32.zip, eclipse-SDK-I20021018-win32.zip but the 
problem still exits.

Best regards, Søren Troest
Comment 1 Sonia Dimitrov CLA 2002-11-11 09:10:28 EST
Moving to JDT Core for comment.
Comment 2 Kent Johnson CLA 2002-11-11 17:44:47 EST
This is expected behaviour when your classpath is incomplete. Missing .class 
files on your classpath are major errors which abort the build before it is 
finished.

The compiler/builder is aborting the build when it cannot find a .class file 
which is referenced from another .class file.

There should be another error on the project telling you that the build 
failed... is it not there?
Comment 3 Søren Troest CLA 2002-11-12 02:57:19 EST
The error message telling me that the classpath is incomplete is present, I 
just didn't see it.
Due to message filtering.

But why does the build scrub my exiting .class files, only on the second try to 
compile ?

The first time I compile my class, I get these two messages, telling me that 
the classpath is incorrect, and that my class indirectly references something 
that is missing, but all my .class's is still present.

If I alter my code and compile again, all my .class files (that exits is the 
hierarchy after the compiled class) are scrubbed, but "normal" java syntaxs 
errors, does not apply this functionality.

In my specific situation, I've developed some plugins for our java developers, 
these plugins are capable of autogenerating DAO's (Data Access Objects )from 
exitsing DTO's (Data Transfer Objects).

The new autogenerated class is written to the workspace via 
packageFragment.createCompilationUnit(..), but if the error above occurs all 
the .class's in the project is scrubbed, which is very unfortunate.

I know that in this case, it would be possible to out comment the errors, and 
rebuild but this operation could be time consuming.
Both finding the error, and rebuilding.

Best regards, Søren Troest
Comment 4 Kent Johnson CLA 2002-11-12 14:14:50 EST
The first time your class is compiled, an incremental build is performed (which 
fails because of the classpath problem).

The second time a full build is performed because of the previous build failure 
& so the output folder is wiped clean before the build begins... it doesn't 
finish because of the classpath problem... so you're left with only some of 
your .class files.

The 2 errors are generated to inform you that there are serious problems with 
your project that need to be addressed before fixing other minor problems.

What filter did you have set that meant you didn't see the 2 errors?
Comment 5 Søren Troest CLA 2002-11-13 02:27:34 EST
Hey,

What I meant about filtering is that I'd set my task filtering to 'On selected 
resources and it's children', and the message concerning incomplete classpath 
is reported on Project basic, which offcours results in that I didn't see the 
message.

Thank you for your answers, I fully understand them, but still find it 
unfortunate that the builder stops due to problems with my classpath, I would 
have expected that only the .class's which were directly involved in the error 
would have been affected eg. scrubbed.

It would have been ok, that the builder would stop building one .class if it 
contained a error, and continue with the next .class.

Can you see my developers faces whenever they have been using one of my 
Wizards, just as they think that one class have been added to the project, xxx 
classes is missing instead... (-:

Perhaps I could post it as a feature request, that the builder should try to 
build as many classes in a project as possible.

Best regards, Søren Troest

Comment 6 Kent Johnson CLA 2002-11-13 10:11:52 EST
I accept that in your case only a single source file is affected... but in most 
cases we see Object.class cannot be found because an entire jar file is missing.

We decided to abort the build so the user gets only 2 errors instead of one per 
source file. We have found that numerous errors in the task list make it very 
difficult for users to figure out what went wrong.

Our current behaviour is the best compromise we have found.
Comment 7 Kent Johnson CLA 2002-11-18 16:38:08 EST
Current behaviour is the best compromise we have found.