Currently the behaviour when there are errors seems to be overly cautious. The following happens to me quite frequently:
1) I run JIDL over all our projects IDL files to generate Java sources. 2) I go into IDEA and hit build. 3) All the idl .class files get deleted (because they are now out of date) 4) All the idl files compile successfully but there are errors in another file because of changes in the idl. 5) I fix an error in one of the other files and press build again 6) All the idl .class files are deleted again 7) Everything compiles successfully The problem I have is with step 6. All the IDL files were successfully compiled and don't depend in any way on the file that failed to compile so I'm not sure why they get deleted. I suspect that any error in a build prevents the states of any of the files from getting updated. -- Mark -----Original Message----- From: Eugene Zhuravlev [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 27, 2002 12:05p To: [EMAIL PROTECTED] Subject: Re: [Eap-list] Bug in dependency checker (or compiler?) (#611) > Or perhaps it works off the byte-code. In which > case, until the class has byte-code generated for it, you can't do the dependency checking. Exactly :-). This is the way it is done now mostly because of efficiency concerns. The dependency compilation is done in 2 steps: first the modified files are recompiled and then, if there were no errors, after analysing changes and dependencies between classes, the set of dependent files that should be compiled is determined. In this particular case the error is flagged on the first step and because of this our dependency analyser is not even started. > I was thinking of a source-level dependency hierarchy, not one based on the byte code.. We are thinking about the efficient source-level implementation and if we come to any satisfactory solution, we'll update the make's functionality accordingly. Best regards, Eugene Zhuravlev JetBrains, Inc / IntelliJ Software, http://www.intellij.com/ "Develop with pleasure!" ----- Original Message ----- From: "Michael Kirby" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, March 27, 2002 21:11 Subject: Re: [Eap-list] Bug in dependency checker (or compiler?) (#611) > I would have thought that the IDEA dependency checker would prioritize the set of classes > based on the dependency. If an interface to a class changes, then all classes that > implement the interface should be recompiled before classes that extend those classes. > > I don't see why IDEA would invoke the compiler on the concrete class until after it had > recompiled ALL classes that implement Foo? Perhaps I don't understand? Shouldn't > intellij's dependency checker be run first? Or perhaps it works off the byte-code. In which > case, until the class has byte-code generated for it, you can't do the dependency checking. > > I was thinking of a source-level dependency hierarchy, not one based on the byte code.. > > Mike > > > On 27 Mar 2002 at 19:45, Eugene Zhuravlev wrote: > > > Hi Jonas, > > > > Yes, this is a known issue. The problem is that in this particular > > case the dependency is checked by the javac. IDEA's dependency checker > > is not even started because of the errors reported by javac. Currently > > we have no ideas how to solve this problem efficiently. But IMHO this > > problems is a minor one - anyway you get some errors reported instead > > of silently "compiling" and reporting that everything is ok. > > > > Best regards, > > Eugene Zhuravlev > > JetBrains, Inc / IntelliJ Software, http://www.intellij.com/ > > "Develop with pleasure!" > > > > > > ----- Original Message ----- > > From: "Jonas Kvarnstr�m" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, March 27, 2002 17:26 > > Subject: [Eap-list] Bug in dependency checker (or compiler?) (#611) > > > > > > > Consider the following classes and interfaces: > > > > > > public interface Foo { > > > public void method(); > > > } > > > public abstract class AbstractFoo implements Foo { } > > > public class SomeFoo extends AbstractFoo { > > > public void method() {} > > > } > > > > > > Compile this. Then change SomeFoo: > > > > > > public class SomeFoo extends AbstractFoo { > > > public void method() throws Exception {} > > > } > > > > > > You'll get a compiler error since Foo.method() doesn't throw > > > Exception. > > > Change Foo: > > > > > > public interface Foo { > > > public void method() throws Exception; > > > } > > > > > > Information about the abstract methods inherited from Foo is > > > apparently stored in AbstractFoo, so AbstractFoo now needs to be > > > recompiled -- but IDEA doesn't realize this so ctrl-f9 will just > > > give you the same compiler error again and again until you rebuild > > > the entire project or realize there's an abstract intermediate class > > > and recompile it manually. > > > > > > > > > > > > _______________________________________________ > > > Eap-list mailing list > > > [EMAIL PROTECTED] > > > http://www.intellij.com/mailman/listinfo/eap-list > > > > > > _______________________________________________ > > Eap-list mailing list > > [EMAIL PROTECTED] > > http://www.intellij.com/mailman/listinfo/eap-list > > > > --- > [EMAIL PROTECTED] > To obtain my PGP public key, mail "SEND PUB KEY" in the > subject to "[EMAIL PROTECTED]" > > > _______________________________________________ > Eap-list mailing list > [EMAIL PROTECTED] > http://www.intellij.com/mailman/listinfo/eap-list _______________________________________________ Eap-list mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-list _______________________________________________ Eap-list mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-list
