Archive for February 2013

Back to netbeans again after intelliJ misrepresenting compilation

So IntelliJ says it compiled successfully a project. However, when I execute maven jetty plugin to run a small web project, I end up with jars not being found. So what does it exactly mean when IntelliJ says compile successfully ? It seems that it just compiles them, and it really does not make any difference whether you compile or Make the project both cases will result in missing jars if you run the project using maven jetty plugin.

There’s lots of crap in netbeans however it seems to be the only edit that does what it says it’s going to do in terms of maven compilation. It sill suffers from some issue like for example you won’t be able to disable tests if you compile with dependencies.

For the time being I have to accept the flaring white colors of netbeans until one day I can figure out a more consistent way of configuring it.

Finally a driver that does not crash for 82845G/GL

Finally found a solution for a dinosaur machine Dell GX260 graphics driver issues. My lspci shows this:

VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) (prog-if 00 [VGA controller])

As a plus, I found that compiz works. Hopefully wayland will work as well once released.

Where to get it from? install the drivers from this PPA: . I’m running ubuntu 12.10 so that’s what my tests are based on.

Threw in the towel for using netbeans

I admitted defeat in using netbeans for doing anything useful. I tend to waste my time trying to fix the colors so that I can read the code, and that if I didn’t get totally frustrated from simple actions not happening as expected. Simple things like dependencies between maven modules should be happening automatically. If you used intelliJ’s idea and set auto-compilation to true, and change a class in one module, it will automatically build the dependent modules and fire errors if necessary.

There are several issues some of which are poorly written code. For example this bug report ( ) during typing javascript the editor will block to update the document structure. Since the primary function of an editor is to edit, then that should not be blocked by any other secondary function enhancing the editing. Things like auto-complete would block editing and for every few character I type I will have to click Esc just to continue editing. Formatting of HTML, JSP and JavaScript during editing is totally screwed up. Even though the setting will specify a certain location for braces and indents, things will end up in totally different locations and they won’t be fixed until you mark the whole code and reformat it.

For their credit they have a very good core integration with maven. However, features are not finished nicely all the way to the end. I really don’t know if the project is losing volunteers and that’s why it is adequately tested or it is being steered to the death path to be replaced by an even slower and worse project aka JDeveloper.

Using astyle from inside intelliJ idea

A simple way to maintain your code style, even possible across your team without a lot of configuration sharing. Add astyle as an external tool with the following command line:

astyle -A1 -Lpjt $FilePath$

That’s a reminder to myself as well when I forget. Then add a shortcut from the settings to the Tools -> astyle. A good short-cut that does not conflict with intelliJ shortcuts is Alt+F .