Cascading reports in multiple-project projects with errors
Migrated from http://lampsvn.epfl.ch/trac/scala/ticket/2937
Reporter razie
issue described in thread http://old.nabble.com/It's-fast-now!-It's-fast-now!-td27230437.html#a27245266 sample files attached to https://lampsvn.epfl.ch/trac/scala/ticket/2767 Issue: have 3 or more dependent classes spread across projects: Project1 ( Class1 <- Class2) <- Project2 (Class3).
If Class1 is broken, then Class2 is correctly not compiled. However, Project 2 is compiled and Class3 fails with "not found: type Class2".
In multiple projects, this cascades and causes an unholly mess of hundreds of errors, every time a "base" class is saved with an error - actually hiding the original error.
Solution seems simple enough: if pre-requisite projects have compilation errors, do not compile dependent projects - especially during incremental builds. Maybe should still try them when clean/build...
Reporter razie
issue described in thread http://old.nabble.com/It's-fast-now!-It's-fast-now!-td27230437.html#a27245266 sample files attached to https://lampsvn.epfl.ch/trac/scala/ticket/2767 Issue: have 3 or more dependent classes spread across projects: Project1 ( Class1 <- Class2) <- Project2 (Class3).
If Class1 is broken, then Class2 is correctly not compiled. However, Project 2 is compiled and Class3 fails with "not found: type Class2".
In multiple projects, this cascades and causes an unholly mess of hundreds of errors, every time a "base" class is saved with an error - actually hiding the original error.
Solution seems simple enough: if pre-requisite projects have compilation errors, do not compile dependent projects - especially during incremental builds. Maybe should still try them when clean/build...
Leave a comment
on 2010-01-20 19:21 *
By tracImporter
Trac author: razie
this is with today's version of the plugin (2010-01-20).
this is with today's version of the plugin (2010-01-20).
on 2010-01-20 21:02 *
By
Could you try and reproduce this using the command line tools. Build your first project first, then the second with the first project's output directory on its classpath. Thanks.
on 2010-01-20 21:06 *
By
Summary changed from Cascading reports in multiple-project projects with errors to Cascading reports in multiple projects with errors
Also, when creating tickets, it's preferable to use a descriptive summary.
on 2010-01-20 21:07 *
By
Summary changed from Cascading reports in multiple projects with errors to Cascading reports in multiple-project projects with errors
on 2010-01-20 21:29 *
By tracImporter
Trac author: razie
I just found a workaround (took me long enough).
in the "problems" view, in the view menu (far right drop down) select "new problems view". in this new problems view, go to the same menu and "configure contents".
in this dialog, select the last two entries on the left list (e/w on Selection and on Project) and the scope that says "on any elements in the same project".
now, every time you look at a file, you'll see all errors in the same project...this makes the "base" errors more visible.
I still think we should fix the big build...it would behave more like the default Java Eclipse thing.
I just found a workaround (took me long enough).
in the "problems" view, in the view menu (far right drop down) select "new problems view". in this new problems view, go to the same menu and "configure contents".
in this dialog, select the last two entries on the left list (e/w on Selection and on Project) and the scope that says "on any elements in the same project".
now, every time you look at a file, you'll see all errors in the same project...this makes the "base" errors more visible.
I still think we should fix the big build...it would behave more like the default Java Eclipse thing.
on 2010-01-21 00:04 *
By tracImporter
Trac author: ijuma
CC Change: mlists@…
Yeah, that setting is much more sensible. It's what I've been using for years, no idea why it's not the default.
CC Change: mlists@…
Yeah, that setting is much more sensible. It's what I've been using for years, no idea why it's not the default.
on 2010-01-21 00:33 *
By
Could you clarify: are you saying that the issue is just one with the default Eclipse Problems View contents and can be fixed by configuring it more to your liking?
on 2010-01-21 00:58 *
By tracImporter
Trac author: razie
here's the test you asked: behavior as expected...
~/workspace7u6/tt/ScalaFail1/src\>
~/workspace7u6/tt/ScalaFail1/src\> scalac -d ../bin fail1/*
fail1/SC11.scala:4: error: type mismatch;
found : Int(1)
required: String
def m1 : String = 1
one error found
~/workspace7u6/tt/ScalaFail1/src\> cd ../../ScalaFail2/src
~/workspace7u6/tt/ScalaFail2/src\> scalac -d ../bin fail2/*
~/workspace7u6/tt/ScalaFail2/src\> > scalac -d ../bin -classpath ../../ScalaFail1/bifail2/*
fail2/SC22.scala:4: error: not found: type SC11
def m1 : String = new SC11().m1
fail2/SC23.scala:6: error: not found: type SC12
def m1 : String = new SC12().m1
two errors found
here's the test you asked: behavior as expected...
~/workspace7u6/tt/ScalaFail1/src\>
~/workspace7u6/tt/ScalaFail1/src\> scalac -d ../bin fail1/*
fail1/SC11.scala:4: error: type mismatch;
found : Int(1)
required: String
def m1 : String = 1
one error found
~/workspace7u6/tt/ScalaFail1/src\> cd ../../ScalaFail2/src
~/workspace7u6/tt/ScalaFail2/src\> scalac -d ../bin fail2/*
~/workspace7u6/tt/ScalaFail2/src\> > scalac -d ../bin -classpath ../../ScalaFail1/bifail2/*
fail2/SC22.scala:4: error: not found: type SC11
def m1 : String = new SC11().m1
fail2/SC23.scala:6: error: not found: type SC12
def m1 : String = new SC12().m1
two errors found
on 2010-01-21 01:04 *
By tracImporter
Trac author: razie
to answer ijuma - the default also makes sense to get a glimpse of all the problems. there may actualyl be errors in a bunch of places, trigerred by an interface change.
to answer Miles - no. I just found a work-around to filter the errors to the current project. I still think the original problem should be fixed: don't rebuild dependent classes in dependent projects when the prerequisites failed. They will surely fail and just pollute the errors list.
It is also an inconsisiteny in the example I gave: class 2 is not recompiled, because it's in the same directory and the compiler knows it will fail. class3 however is in a different project and I think the plugin just invokes the compiler like the manual test I did above. I don't think it should. You can compare this behavior with the default Java builder behavior.
to answer ijuma - the default also makes sense to get a glimpse of all the problems. there may actualyl be errors in a bunch of places, trigerred by an interface change.
to answer Miles - no. I just found a work-around to filter the errors to the current project. I still think the original problem should be fixed: don't rebuild dependent classes in dependent projects when the prerequisites failed. They will surely fail and just pollute the errors list.
It is also an inconsisiteny in the example I gave: class 2 is not recompiled, because it's in the same directory and the compiler knows it will fail. class3 however is in a different project and I think the plugin just invokes the compiler like the manual test I did above. I don't think it should. You can compare this behavior with the default Java builder behavior.
on 2010-01-21 01:09 *
By tracImporter
Trac author: razie
darn - sorry - mangled end of lines between linux and ??Chrome?? I don't know how to fix it - it looks fine when I submit, so it must be mangled by this whatever tracking system, when rendering the saved text...
darn - sorry - mangled end of lines between linux and ??Chrome?? I don't know how to fix it - it looks fine when I submit, so it must be mangled by this whatever tracking system, when rendering the saved text...
on 2010-02-10 18:08 *
By tracImporter
Trac author: shaberman
CC Change: stephen@…
CC Change: stephen@…
Updating tickets (#1000069, #1000195, #1000213, #1000223, #1000006, #1000021, #1000038, #1000048, #1000051, #1000052, #1000075, #1000103, #1000109, #1000115, #1000119, #1000156, #1000186, #1000207, #1000238, #1000262, #1000263, #380, #389, #683, #1238, #1331, #1635, #1645, #1715, #1729, #1744, #1783, #1839, #1869, #1885, #1890, #1902, #1918, #1919, #1924, #1925, #1946, #1964, #1991, #2131, #2233, #2342, #2348, #2408, #2459, #2499, #2523, #2572, #2582, #2602, #2614, #2615, #2675, #2710, #2745, #2763, #2816, #2830, #2834, #2878, #2879, #2887, #2888, #2901, #2911, #2912, #2922, #2937, #2938, #2942, #2951, #2955, #2957, #2961, #2964, #2965, #2974, #2975, #2989, #2990, #3002, #3055, #3070, #3087, #3135, #3139, #3173, #3182, #3184, #3200, #3213, #3214, #3221, #3243, #3251)
Closing as invalid.
The test projects doesn't compile at first, but after fixing them, the behavior is fine, only the directly impacted class have errors.
I cannot reproduce the problem on both 2.0.0-2.9 and master-2.10. This has likely been fixed during 2.0 development.
Please reopen with additional information if you still see the problem.
The test projects doesn't compile at first, but after fixing them, the behavior is fine, only the directly impacted class have errors.
I cannot reproduce the problem on both 2.0.0-2.9 and master-2.10. This has likely been fixed during 2.0 development.
Please reopen with additional information if you still see the problem.