[jsword-devel] Building on Bible Desktop: BibleBlogs.Net

[DM Smith]

Don Brown wrote:
> Cool!  Good to hear you integrated it so quickly.  Actually, I don't 
> use Netbeans at all, as those artifacts were left over from Dave's code.
I don't have a problem with NetBean code being in BibleDesktop as long 
as someone is going to actively maintain it. So please remove all the 
Netbean auto generation markers.
>   In fact, I've already spent some time cutting out the generated GUI 
> code in favor of that GriddedPanel class.
You will notice that I moved GriddedPanel from bibledesktop into 
common-swing.
>   Personally, I use vim and jEdit, although I'm trying Eclipse out for 
> the first time with this project.  I've always actively avoided IDEs 
> but the way this project works so well with them, I'm giving them 
> another chance.
Emacs was the first IDE I ever used. Someone showed me how to compile C 
and C++ with in it and navigate from one error or warning to the next. I 
use an IDE if it makes me more productive. When I came to JSword, it was 
already set up as Eclipse projects. And as I had experience with IBM's 
WSAD, it was an easy step for me.

We have not used Eclipse as "the" IDE. So to date we have not used its 
ability to autogenerate code when that would tie us to Eclipse. That 
probably will change if we buy into using RCP/SWT/JFace to rewrite the 
UI. Even then the other code will remain free of requiring Eclipse as an 
IDE. And it will always be possible to compile it externally via ant.

Some of the reasons I like Eclipse (besides the philosophical):
1) Immediate feedback on errors. As I make changes it will let me know 
if it won't compile.
2) Immediate feedback on matters of style and support for editing with 
that style. We feel it is important for all our code to have a 
consistent style and we provide tooling to that end. E.g. No tabs, 4 
spaces per indent, curly braces around a single statement for control 
constructs, curly braces on a line to themselves.... Some of this is not 
the way I would have chosen to do things, but it really doesn't matter. 
So I go with it. As the body of code gets bigger, there is more inertia 
to stay the same, but if there is a compelling reason, we can change.
3) Auto-completion. The biggest advantage here is that it voids the 
argument for short, less meaningful names. Typing a long name is not an 
issue when you have auto-completion.
4) Smart search. For example, I can find uses of a particular method.
5) Refactoring is trivial.
6) Fully integrated debugging experience with stepping through 3rd party 
jar files.
7) Exceptions from a regular run are posted to the console and allow me 
to go directly to the problem location.
8) Integration with JUnit.
9) Widely adopted, so it keeps getting better.
10) But the biggest reason that I use it is that I am much faster in it 
than in vim, emacs, or any other text editor.