By now, gentle readers, you have probably seen the Javamancy mini post about the one-liner deletion for .svn files.

I really like Adam Bien. He seems like a nice guy, and I occasionally drop by his blog, on a lark, to read his stuff, which is often focused on Java and NetBeans, one of our favorite IDE’s that we use regularly for DevPal and Javamancy dev work, especially for Java and PHP. Now, I have never met him personally (which is unfortunate, since the inevitable Formidable Brain-Pick would come out, and I’d be picking his brain with it furiously (figuratively, ‘natch)), nor have I observed his programming, CM, and shell skills in action.

So I thought it was curious that he posted about how to delete all .svn files with a “one-liner”. Being a collector of snazzy UNIX scripting that make my life easier, I just had to look…

The Debated Script

Now, keep in mind that Adam mentions that he found the one-liner elsewhere, but he liked it enough to post it.

Here is what he suggests as the one-liner:

find . -name ".svn" -exec rm -rf {} \;

And this would be fine, under normal circumstances, if you are considering a relatively small population of .svn files that you want to remove and you do not care if somebody mistakenly named something on the filesystem as “.svn” despite it not being a Subversion directory.

But if you are like me, and/or you have at least one of several different CM structures that you support within one or more different versioning systems, and/or you have both people and automata that frequently access and modify those CM structures, you are most likely going to have thousands, tens of thousands, hundreds of thousands, or perhaps millions of .svn directories that you have to account for. And you may have noticed that when you feed a large parameterized file list to the rm command directly causes it to choke after only a few hundred (or in some cases, several thousands, depending on your OS) entries.

What DevPal Does

So here’s an excerpt from one of my scripts that leverages the xargs utility to spoon-feed the rm command with smaller digestible chunks from the potentially huge file list that the find command readily retrieves:

find . -type d -name .svn | xargs rm -rfv

Like Adam’s snippet, I want to use the current directory position, but if you want to parameterize that to some other location (i.e., other than “.”), you certainly could.

Also, note that I’m only interested in directory names… I am not interested in non-directories that match “.svn“. This may or may not be the behavior you are supporting, so you may want to change the filetype specifier (say, to “f“) or drop it altogether.

Now, for the rm command switches: I tend to like to see what is going on during the deletion process, so in addition to inducing recursion through directories and forcing deletion without confirmation, I also want a bit of on-screen verbosity to show me what is being deleted. In this way, if I want to log the behavior, I can certainly redirect the output to a file or to a remote service. Anybody Hudson’ing, or just Ant’ing or Maven’ing with this?

Script or Not?

Technically, while Adam offered up the one-liner as just that… a one-liner… I would guess that many of you have wondered about whether it makes more sense to wrap a script around it and give it a snazzy name. My recommendation is, of course, yes.

N.B.

.svn as a directory

You may have noticed that there seems to be an interchangeable use of “files” and “directories” when referring to the .svn content. Which is correct? Both, actually, and it depends on your approach or perspective.

Contents of the .svn directory

Whenever you browse your local directories within your sandbox, you will see that the .svn entries are actually directories. But if you peek into those directories, you will notice that there appears to be a set naming scheme to the files in there… as if they are arranged in a certain way to allow something (like a local database engine or parser ( )) to efficiently access and modify the metadata for the versioned content. So, when referring to the .svn structure and contents, the UNIX-y notion of directories being also files can be more-inclusive.

By the way, this notion is also applicable for other versioning systems, including CVS (Subversion’s forebear).

After several weeks, the long-awaited update to NetBeans 6.7, now with JavaFX support, is finally released to the general public.

As you may recall, it was our expert recommendation to NOT uninstall or replace your NetBeans 6.5/6.5.1 IDE if you are actively developing for the JavaFX platform, since it was not available as a feature in NetBeans 6.7. And since there are no significant issues with installing NetBeans 6.7 alongside an existing 6.5 or 6.5.1 installation, that was a usable pattern at the time.

With the release of NetBeans 6.7.1, you may choose to replace your previous installation of NetBeans 6.7 with this update. For those of you who are cautious or conservative in your dev rig upgrading processes, it is advised that you do not immediately remove NetBeans 6.5/6.5.1 from your dev rigs until after you have determined that NetBeans 6.7.1 provides you with a satisfactory level of JavaFX programming functionality comparable to what you currently enjoy with the previous version.

When it rains, it pours…

Hot on the heels of the official Eclipse 3.5 codebase release, heralded primarily by the “Galileo” tool set, the NetBeans group has announced the official release of its latest version, NetBeans 6.7.

Developer’s Perspective

The layout for NetBeans and its overall usability arguably has a lower ramp-up and learning curve than Eclipse, particularly with the latest “Galileo” launch, which further fragments the tool selection process. While NetBeans has a variety of packagings based upon programming language preference, most people tend to select the “All” feature in order to have the widest selection of languages supported (in the event that your shop needs to manage multiple languages, which is a common scenario). 

Integration to Project Kenai, Hudson (CI), and Maven have been long-awaited features. Hudson and Maven support have been available for NetBeans for some time, but as add-on modules, and there were issues with the integration aspects with the rest of the IDE.

Loss of JavaFX 1.2

This is a serious concern for developers who have been working with JavaFX: it is not shipped with this version of NetBeans, so if you were hoping for a single, unified IDE to support everything you’ve been working on, you’re currently out of luck. DO NOT UNINSTALL YOUR NETBEANS 6.5/6.5.1!

You may install NetBeans 6.7 alongside 6.5/6.5.1, so you will not be out of options, and if you are using a larger dev rig (for instance, like a 8-core Mac Pro with 16 GB RAM ), this should not be a serious concern. But if you are somewhat memory/resource constrained in terms of your workstation, you may find yourself switching in and out of the different versions.

There are additional gotcha’s associated with this release, particularly with “less glamorous” features that are not delivered in the downloaded installers. You will have to force them to download separately via the module updater feature in the IDE, post-installation. Also, there are certain caveats about some of the features being delivered in NetBeans 6.7. We definitely high recommend reading the release notes accompanying this version. The install instructions will be beneficial to those of you who only previously installed a single version of NetBeans at a time; and a lot of you recent Mac users will find some of the info applicable in your case as well, particularly with uninstallation and coexistence of previous versions (however brief the info is…).

Management Perspective

If your developers have unified on NetBeans 6.x to this point, there is most likely very little need to jump ship to a competing product; and if you have been dealing with a variety of extra modules beyond the core NetBeans IDE to handle your Hudson and Maven integrations, you’ll be very interested in bumping up to NetBeans 6.7.

On the other hand, if you recently fetched Eclipse “Galileo”, or even the base Eclipse 3.5 IDE, because you’ve been a staunch Eclipse dev group, you may be interested in allowing some of your developers to use NetBeans 6.7 to see if the different development flow works better for your team.

But, as above, if you’re managing active JavaFX projects, you will want to postpone upgrading en masse. Instead, you may opt to wait for an update to NetBeans 6.7 (like, perhaps 6.7.1 or 6.8, even) that contains JavaFX SDK support; or just continue using NetBeans 6.5/6.5.1 in your group.

DevPal’s (and Javamancy’s) Stance

It’s a bit too quick to pass judgment on a fresh release, particularly with Eclipse having recently begun its way through the evaluation cycle. However, since DevPal already uses NetBeans as part of the development workflow, there is a parallel on-ramp cycle for NetBeans 6.7 to replace the NetBeans 6.5 instances currently deployed for primarily Java-based projects. In the meantime, our NetBeans 6.5.1 instances will remain as-is, since we do use them for JavaFX activities. It is an odd situation, and it causes a spawning of additional user configurations to support both NetBeans 6.5.1 and 6.7 in the same user home directories. Fortunately, it is not a dramatically heavy storage investment.

And the evaluation will begin for NetBeans 6.7.

Yesterday, the Eclipse Consortium officially released the sixth major release of the IDE, Eclipse “Galileo”.

While Eclipse was originally developed to support Java development, it has experienced phenomenal growth and expansion to encompass a wide variety of programming languages and architectures. Since it has broad industry support from a galaxy of IT companies and groups, it has continued to gather more functionality, to such an extent that it is difficult for it to remain as the all-in-one IDE package. As a result, over the past several years, it has been released as a suite-of-sorts of different combinations of functional components: developers are obligated to pick and choose with configurations best suits their needs.

Unfortunately, the extensive componentization of Eclipse has also increased its apparent complexity (some would even argue that it is overly complicated). This is part of the lively competition between Eclipse and its arch-nemesis, NetBeans, which is also undergoing an upcoming 6.7 release. This also brings into the equation the issue of which company is supporting what… after all, given Oracle’s [ORCL] acquisition of Sun Microsystems [JAVA] and its support of the Eclipse Consortium, what will Oracle’s own tool set evolve into?

Developer’s Perspective

Exploring new dev tools is always a mixture of trepidation (“Oh, is it going to break everything I’ve been working on?”) and fun (“Oh, another new feature I’ve been buggin’ them to include… got it now!”). The new Eclipse release is no exception.

What makes Eclipse unique in considering whether the upgrade is valid is its componentized nature. Some savvy developers have, in the past, merely reached into their current configuration set, inspected the new modules, and fetched just the ones that they needed and/or grabbed the source code for the modules they were interested in, and just hacked it into their current version, disregarding the core platform upgrade altogether. This has become more and more daunting of a task, however, so during the inspection process, I would imagine that a lot of developer-hackers who have done this in the past may reconsider.

As for dev shops that have worked with both Eclipse and NetBeans: long gone are the days when you could build a hybrid Eclipse-NetBeans IDE for your developers. The codebases are too disparate, and unless you’re using one of our Mac Pro monsters, managing the code updates may not be worth it.

If you’re using a combination of Eclipse and NetBeans, or some other 2+ IDEs, the level of integration or coordination frequently converges at the VCS level. On more rare circumstances, it may be abstracted to the build/CI level; and even more rare, it may be at the issue tracking level– which would be quite dire indeed. If this manner of dev coordination is acceptable, you’re not going to want to change it any time soon. But if not, this latest release of Eclipse may be the deciding point to force the issue to a single-IDE methodology.

For the Love o’ the Mac

In case you haven’t noticed yet… The Eclipse 3.5 distributions are now shipping with Cocoa-built binaries now. This has been a long time coming for many developers who’ve used Eclipse on the Mac, and for some developers, has often made them strongly veer toward NetBeans instead.

It remains to be seen, outside of those developers who’ve been playing with the beta versions of this release, whether native Cocoa support is what brings developers back to Eclipse. I’d imagine that iPhone developers who also manage their OS X apps via Xcode will be at least curious about how Eclipse can mesh with their Xcode-provided libs; and it almost goes without saying that GNU C/C++ and Web developers who have been struggling with other tools on the Mac will want to look at Eclipse 3.5-based IDEs (even if not the official Galileo toolset).

Management Perspective

Always a sticky subject for the stricter management teams, unless they are distinctly single-IDE shops.

The reliable way of handling this issue is to assign your most experienced developer-architect to experiment with the new release to see how well it works in your existing dev environments. This becomes more crucial when you have a continuous dev cycle that blends your dev, testing, staging, and deployment targets together.

DevPal’s (and Javamancy’s) Stance

It’s all good ‘n fine to sit around and speculate on how great one dev tool is, blah blah blah. But outside of generating noise, it isn’t otherwise productive.

Since we’re running a mixed-tool studio, it’s clear that we want to put the new release through its paces before we make any significant retooling efforts. But most likely, unless there are glaring problems, we would be using a customized Eclipse 3.5 as our main IDE with several Eclipse Galileo variants for more specialized work and deployments given to clients who require special code considerations during design or coding phases.

In the meantime, good hunting, folks!

Here’s a fun news bit, on the cusp of the upcoming FCS release of NetBeans 6.7:

Just when you thought you’d heard everything about declarative programming on the NetBeans platform… there’s the “rise” of Scheme, as both a dev language supported on NetBeans technology and as an implementation of an alternative NetBeans-based IDE on its own.

LambdaBeans is the IDE in question (at 1.0 RC1 as of this writing), built specifically to support Scheme development in a NetBeans-like development context. Geertjan interviewed the intrepid developer who embarked on creating LambdaBeans; it seems surprising that fans of other languages have not created similar IDEs targeting their languages of choice. After all, NetBeans itself is the prime example of a decently sophisticated application built on the NetBeans Platform. So why not just use as much of the IDE source as possible, remove the extraneous code not applicable for your features, and then focus on adding language-specific highlighting and management?

Good times, folks… good times.

N.B.

Want to try LambdaBeans 1.0 RC1? Download it now from the Project Kenai site.

The Setup

As many of you know, I use NetBeans. A lot. And, of course, I also use a variety of other Java-based IDE’s, like Oracle’s JDeveloper and the Eclipse platforms.

But I really like NetBeans because it, like JDeveloper, has that unified IDE feel that Eclipse doesn’t (I always feel like there’s something else I just have to have– if only I can figure out what it is, look it up in one of many repositories, log in, browse the catalogs, spot the components, download them into the IDE, wait for all the dependencies to resolve, update the IDE’s other components, scan again, download the last remaining bits ‘n pieces, and then wait for the IDE to restart… and maybe then go back out and download some more components or updates to the components I already have…).

But NetBeans is also differentiated from JDeveloper and other unified IDE’s  because it doesn’t follow the old JBuilder project/workspace management behaviors.

And, additionally, NetBeans does not have the specter of that potential commercial license hovering over it, like JDeveloper does…

Larry, I’m telling you, if you make JDeveloper a completely commercial product again, I’m dropping it again! Your pricing model should be based upon your production deployment setups, like your databases, not the development tools or APIs or frameworks!

So I was pleasantly surprised when the new DVD bundling of NetBeans 6.5 was announced a couple of days ago.

The Premise

Traditionally, Sun and the NetBeans guys have released DVD’s of the current shipping version of NetBeans.

This time, the DVD image appears to be released instead, which obviously saves them quite a bit of disc burning and postage fees. And, for developers (and even development directors like Yours Truly), it makes it much more convenient to download the image, burn it, and start using it. And, even better, in the case of various advanced OS’ out there, you can directly mount the DVD image and install directly from it, without having to generate any physical media copies (except as a form of archival, ‘natch).

The Action

Go fetch your copy DVD image of the NetBeans 6.5 Starter Kit. 

In addition to NetBeans 6.5 (the “main” form of the IDE), it also comes with:

• NetBeans IDE 6.5 for JavaFX 1.0
• GlassFish V2 UR2 application server
• GlassFish V3 (Prelude) application server
• Tomcat 6.0.18 container
• JDK 6 Update 11 (you may know this as JDK 1.6.0_11)

In the regular installer, you can have the GlassFish and Tomcat containers installed at the same time that the IDE is installed.

N.B.

Other related Javamancy posts (in reverse chronological order):

• NetBeans 6.5

It’s been awhile in coming, but it’s finally here: NetBeans 6.5.

Like many of you, I’ve been itching to have a plethora of development capabilities integrated into a single unified interface that does not require me to constantly scour the Internet, or several different vendors’ sites, or even just constantly ping around various different “repositories”, for the latest updates and fixes.

Not to take anything away from Eclipse (the other heavy hitter in the IDE arena), but having to manage the massive amount of Eclipse-lets or fall in line with a specific distribution has brought along its own synchronization issues. In the past, it had gotten so onerous that I had to create a team to manage our Eclipse configurations. In contrast, my NetBeans-using teams were able to just get along with their single image and a select set of add-ons, getting their work done.

Of course, there’s a lot of convergence between NetBeans and Eclipse; that will undoubtedly continue well into the future, until perhaps the two projects merge into a single product(?).

One of the big things that NetBeans 6.5 brings to the table is the long-awaited official support for more dynamic languages. This production release brings some of them to us, especially PHP (which previewed on a beta of 6.5 for awhile).

Check out the NetBeans release at the NetBeans.org site. You can also read about its features and even watch a few screencasts to familiarize yourself with the product prior to installing it.

Or you can just click on the download banner in this blog entry to start fetching your own copy.

N.B.

Yes, I advocate the use of NetBeans as part of the primary development rig at DevPal and Javamancy. Now comes the fun part: testing the IDE for its appropriate integration with the rest of the dev rig, as well as the CM and project control platforms.