I know that mistakes happen and we've all checked in compile errors, but there should be some mechanism in place which prevents you from checking in compile or even test errors, in the first place. JetBrains TeamCity has this notion of private builds, which are really helpful. You are running your build against the trunk on the CI server and get back the results, the same way as if you had checked in. This gives you at least a first idea, if your build has a chance to succeed or not.
with kind regards, David Linsin - - - - - - - - - - - - - - - - - - - - - - - - email: [EMAIL PROTECTED] blog: http://dlinsin.blogspot.com On Oct 24, 2008, at 7:11 PM, Jim Blackler wrote:
Consider a continuous build server that makes a large project, then runs tests on the code. If one programmer makes a submission that causes a compile error in a method, this breaks the build and the tests never even start. However many tests may never execute the broken method. Assuming the programmer that broke the build isn't me (of course), I'd still like to see my own test results. It would also be nice to get a visual indication of which tests the compile error would affect in practice. Jim 2008/10/24 Alexey Zinger <[EMAIL PROTECTED]>:I hope I'm not missing something crucial in this discussion, but what is the benefit of running partially compiled code? If I introduce a compilation error, why do I want to proceed with either an incomplete class set or one class out-of-date, while another is new?Alexey 2001 Honda CBR600F4i (CCS) 1992 Kawasaki EX500 http://azinger.blogspot.com http://bsheet.sourceforge.net http://wcollage.sourceforge.net --- On Fri, 10/24/08, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote:From: Reinier Zwitserloot <[EMAIL PROTECTED]> Subject: [The Java Posse] Re: A lenient compiler? To: "The Java Posse" <[email protected]> Date: Friday, October 24, 2008, 9:39 AM Eclipse does this, even if you don't use the debugger. The method with the error in it is replaced with a simple exception, and the rest is compiled normally. When that method is called, it blows up, otherwise, it runs fine. There are two separate steps in creating a lenient compiler: 1. 'error recovering' parser: We're obviously not going to get far if the simplest of syntax errors makes the parser just stop. 2. a compiler that still produces a class file and knows to insert a dummy. #1 is by far the hardest thing to do, and we're in luck: javac is even better at recovery than ecj these days (particularly when you use a lot of anonymous classes; the ecj error recovery system just stops flat out when something goes wrong there), and the new langtools project is focussed on improving recovery even more. #2 is relatively easy, but as far as I can tell, javac doesn't currently do it. Hacking javac shouldn't even be that difficult, but, given that the hard work is already done, it would be great if the official javac just had a parameter (something like -Xdummy at first, possibly introduce it as a required feature for the 'jdk' stamp (no -X, just -dummy), later. It might be worth it to see what netbeans does; if it does produce dummy code, then just rip the javac back out of netbeans, and voila. On Oct 24, 1:39 pm, Christian Catchpole <[EMAIL PROTECTED]> wrote:Or simply.. for (;;) { System.out.println("Donkey."); } On Oct 24, 4:32 pm, Casper Bang<[EMAIL PROTECTED]> wrote:- at the failing code block, insert thrownewCodeMissingYouNoobRuntimeException();Nah, better to reusejava.nio.charset.CoderMalfunctionError ;)--~--~---------~--~----~------------~-------~--~----~You received this message because you are subscribed to the Google Groups "The Java Posse" group.To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
smime.p7s
Description: S/MIME cryptographic signature
