But, of course, you can't please everyone. Using ANT as a backend means that, of course, you need some custom ant targets to make the IDE-integration better. Thus, you're not 100% independent of NetBeans, you still need those custom tasks (some JARs basically) and the core ant scripts.
Using ANT also means some overhead for each action.
But the most nasty stuff in my projects are the 3rd party JARs. Most projects use some outside blobs. Normally, you can have the JARs in SVN and NetBeans will take care of this quite nicely (using relative paths).
But what happens if you decide not to include those JARs in the SVN ? Well, you enter a world of tweaking of .properties files and custom ant tasks to re-populate those properties files. It's not pretty and error-prone in a distributed project.
Maven on the other side has this repository concept. That is, a place where some 3rd party JARs sit. Your POM file (project metadata basically) just declares the dependencies and the repository list.
Imagine that: you have a local intranet repository and everyone in the team is using it. No more relative paths, no more custom ant tasks !
I've been migrating my SVN for about 3 weeks over to maven. I have normal Java projects, Enterprise projects (EJB/WAR) and NetBeans Platform modules (NBM). It's a bumpy road (I haven't used maven until now) but it does seem to simplify thigs.
But what you win on the dependency side you lose on the integration part. With MevenIDE you have normal NetBeans IDE projects, but not that kind of IDE-integration you have to module-projects for example. No more easy configuration for public-packages -- back to editing manifest files like in the old NetBeans 3.x times ;-)
Overall, Maven2 seems a better choice for the build backend then Ant. You can't customize it that much but once you have all the plugins properly configured, it works better. Plus that you are totally decoupled from the IDE and IDE tasks, but you depend now on the extra plugins.
Most of the continuous integration servers offer support for Maven2 projects so you can drop the new projects immediately.
One nice feature Gnome has that I didn't know of it is Typing Break, found in System -> Preferences -> Keyboard.
It basically forces you to take a break after a period of time. Gets useful after you start getting some hand-aches. During the break you see something like this:
It takes a bit of discipline to actually respect the breaks (especially when something is urgent and you have the "Postpone" button -- which should be renamed to Snooze). Then again, even if I disable the postpone button I might be tempted to Ctrl+Alt+Backspace or Ctrl+Alt+F1, login then kill process.
I'm also looking at some exotic and ergo- keyboards lately. Anyone has something to recommend ?
I would really like something like 2 half-keyboards. One for each hand, then going into the USB port. This way I can place them to the right and left side of the laptop and use them quite nicely -- it's almost impossible to use an external keyboard with a laptop without also adding an external display.
OK, no flying cars. But 2007 and no mind-reading input devices ? Someone is slacking off...
It's quite decent for a novice programmer because it consists of small tutorials and introductions in all the different technologies that the NetBeans IDE supports. It gives you the starting point in your endeavor. It's most needed for an introductory course in any Enterprise since it touches a lot of important points like unit-test, good javadoc, version control, build system (ant-centric, like the IDE) and more.
Since it covers that many topics there isn't actually enough space to go too deep into any of the subjects. The spotlight is after all on the NetBeans IDE and the features it has. This is quite a shame since there were some unique things that could have been discussed more upon: Jackpot refactorings made me really curious...
It's also nice to see some features I've discovered myself in the IDE after a while - like the database support and SQL command window - which turned out to be quite useful. Readers get a chance to find out about them from the start.
All in all, a good book that covers a lot of ground. It doesn't touch at all making NetBeans Platform modules, but that's not expected for a NetBeans IDE user. Although, after a while of living in your own IDE, you can't help it but customize it a little -- enter module development.
There is truth, my boy. But the doctrine you desire, absolute, perfect dogma that alone provides wisdom, does not exist. Nor should you long for a perfect doctrine, my friend. Rather, you should long for the perfection of yourself. The deity is within you, not in ideas and books. Truth is lived, not taught.
Herman Hesse, The Glass Bead Game
Sun's OpenOffice.org engineering team has developed a plug-in for building OpenOffice.org extensions. It is an easy to use set of wizards to create OpenOffice.org extensions that can be used to integrate new functionality, adopt existing functionality, and create Java applications that can remotely control OpenOffice.org. Everything is ready for you to start implementing OpenOffice.org extensions, including a Java code skeleton.
For some time now (I remember I was running some samples last year), OpenOffice has some nice Java bindings (or API). Now, this is all great, but the actual code looks quite arcane.
What troubles me is this: why was OpenOffice so late with this move ? I mean, most programmers don't want to live inside Excel and Visual Basic so if you have a choice, you move a simple dedicated "application" from Excel + VBA to OpenOffice + Java.
I guess it's obvious Java is a better choice (than VB) for most programmers (it would have been for me) and the final product would have been better in so many ways:
- More happy programmers that they don't have to use VB or (oh, the horror), maintain VBA.
- A decent codebase for your initial small application in Java, that could, potentially be migrated to a full Swing application (if we just treat OpenOffice Calc or Write as the GUI toolkit). I mean, most code will get thrown away anyhow, but it's quite a waste of time reimplementing the same business logic (with the VB code as a reference). This would be a perfect change to actually use the IDE's refactoring.
- Possible introduction of OpenOffice in the corporate ! Sure, people would still copy-paste from your "application" into Microsoft Excel but that should be quite pain-less. But the developer won't have to worry about a new Office version or some other Microsoft-specific (DLL) nightmares.
- it's really hard (look at the API) and the practice isn't actually encouraged. The 100% Java purity had probably done more wrong than right here and most people will just suggest using some Swing Application or framework like NetBeans Platform. But why shouldn't people do this kind of applications ? Most internal apps have some sort of tabular data and lists and then fancy reports. Why should we struggle with JasperReports and such when you have the nice OpenOffice Writer codebase ? Export to PDF: check, export to tons of other formats : sure!
- OpenOffice doesn't provide a nice "platform". Something to put in a folder with all the jars and DLLs and work flawlessly. I don't need to "install" OpenOffice: I just want to distribute my application as a simple ZIP file. No DLL hell, no nothing. Make that with (Consumer) JRE included and a simpler API ! (this is linked to the previous point).
- We have reached the point where tiny web-apps seem good enough and are developed fast enough to give existing Excel-based tools a short lifespan. This is a good way because we get rid of Excel but people still need to reinvent the same things over and over: charts and nice (PDF) reports that OO Calc should have facilitated (do I hear OpenOffice-based rich-client ?).
Sure, this would have destroyed the purity of your application, mixing it with the OpenOffice native code and maybe even with some other COMs but I think it would have been better overall.