Raible Designs

MyJavaPack - an Open Source version of Blue Glue?

As noted by John Munsch, MyJavaPack looks pretty cool. At first glance, it looks like an open-source version of Open Logic's Blue Glue. Since I actually did some work on Blue Glue this summer, I downloaded MyJavaPack and did a a quick install.

I was quite impressed. All it did was download the packages I requested and installed them. In most cases, this is what I want - especially on my machine where I already have everything setup. Blue Glue goes a bit further than MyJavaPack. It installs and configures everything for you. This is great for brand new machines, but can be a pain for pre-configured machines since it adds stuff to your PATH.

The thing I like about MyJavaPack is that it's open-source. Therefore, I might be able to dig in and customize it for an AppFuse-based installer. Such an intaller would include tools for developing AppFuse: Ant, Tomcat, MySQL, Eclipse and AppFuse. That'd be pretty cool to be able to download and install an entire development environment.

Neither product does what we all really want: the ability to do an "update" (like Windows Update or Software Update on OS X) of our existing packages.

Rename Packages Tool for AppFuse

One of the steps recommended in AppFuse's QuickStart Guide is to rename your project's packages from "org.appfuse" to "com.company.appname". In the past this has been a real pain. I recommended using Eclipse, but this only worked for renaming the .java files themselves. It didn't catch all the package names in .xml and .properties files. Furthermore, it did nothing to change any references to "org/appfuse/model" or any other similar paths.

No longer folks. Ben Gill has developed a "rename packages" Ant task that'll zip through your AppFuse project and rename everything for you!

To use it, simply download it and view the README file to install and use. The source for this project is also available. This tool should work regardless of whether you've installed any options or not. Thanks Ben!

BTW, I should mention there will be an AppFuse 1.6.1. There have been a few bugs entered and fixed in 1.6 and I'd like to add support for Tomcat 5.5.3 (now in Cargo's SVN) and upgrade to XDoclet 1.2.2 (due for release soon). I'll probably wait until there's both Cargo and XDoclet have been released - in case some more bugs trickle in.

No G5 PowerBooks Anytime Soon

Mac Rumors: No G5 PowerBooks Anytime Soon. If I had a vote, I'd say it's time to give up on the G5 for the PowerBook and make OS X run on Intel or AMD chips - then produce an Intel/AMD version of the PowerBook. Apple makes great hardware, but their laptops are much slower than their Intel counterparts (for Java at least). All I want is a PowerBook that can keep up with an Intel-based laptop - is that too much to ask?

MyEclipse VP is blogging

Wayne Parrott, the VP of Product Management at Genuitec (makers of MyEclipse) has started a blog.

For the past 3 years I have been involved with a great team at Genuitec (www.genuitec.com) of which I am a founder. While my title at Genuitec is VP, Product Management, I think of myself more as an Eclipse technologist and product delivery specialist. These days I spend most of my professional time working on Genuitec's MyEclipse Enterprise Workbench product. A quick fly by of my resume looks something like this: several startup failures, numerous consulting engagements, and some really cool work on the Human Genome Project and NASA's AI Section that dates back to the '80s.

Very cool! I love it when companies get closer to their customers via weblogs. Now we just need to get Wayne to start blogging some tips and tricks.

Eclipse tip o' the day

By default, Eclipse expects all its plugins to be in $ECLIPSE_HOME/plugins. This doesn't work too well for upgrading since you have to copy all of your installed plugins to Eclipse everytime you upgrade. To solve this, you can place all your plugins in an external direct and point to them using a link file. To do this, create a links directory in $ECLIPSE_HOME and create a file inside it that points to an alternate location. The name of this file doesn't seem to matter, but it must end with a ".link" extension. In this file, put a path:

path=C:\\Tools\\myplugins

Then in c:\Tools\myplugins, create an Eclipse-like directory structure so you end up with c:\Tools\myplugins\eclipse\plugins. Then drop your plugins in that directory. If you choose to use an alternate workspace as well, upgrading Eclipse will be as easy as copying in your links folder. BTW, here's more information on upgrading Eclipse.

How do I customize Eclipse on-the-fly?

My task for this week is to figure out how to customize Eclipse on-the-fly? By this, I mean that we're going to install Eclipse and then programmatically add plugins and configure them. Is this possible? We'd also like to add projects to the workbench and have them be there when the user first opens Eclipse. My current technique is to do diffs on directories after I've configured/added stuff, but that's probably not a good long-term solution.

FindBugs

I ran FindBugs on AppFuse last night and found/fixed a number of issues as a result. I'm now down to only a handful left - most of them being "Class is Serializable, but doesn't define serialVersionUID". I tried to generate one using serialver, but I couldn't it to work after numerous attempts. My issues seemed to be classpath related: it wanted the servlet api in my classpath, and once I'd add that, it could find my class. I'll have to try the SerialVer Ant Tasks. Fixing this issue would be nice, but I doubt it's really affecting appfuse-based applications. The other bug is "Inconsistent synchronization" in UserCounterListener.contextInitialized() method. Any tips on solving this one are appreciated.

Should I ditch Tiles in AppFuse?

I've haven't been developing applications with AppFuse since May. Instead, I've been using Equinox. One of the main things in Equinox I've grown to love is SiteMesh. It's worked in all the webapps I've written, which utilize frameworks like Struts, Spring MVC, WebWork, Tapestry and JSF. Tiles will only work in 3 of those.

I think it's time to make an executive decision on AppFuse and ditch Tiles in place of SiteMesh. It's faster and easier to develop with, and it doesn't get in your way. In fact, I didn't have to change a single line of SiteMesh-related code to support any of the aforementioned frameworks. Furthermore, using SiteMesh would also greatly reduce the duplicate between frameworks. I've thought about keeping Tiles around, but it's a pain in the ass to maintain parallel sets of documentation.

Whaddya think - any reason you can think of to keep Tiles? I can't. In fact, I think I'd cringe if I had to start my next AppFuse-based project w/o SiteMesh.

Why Java Desktop apps are better

Since I've been spending so much time with Microsoft Word lately, I decided to upgrade to the latest versions yesterday. Here's where products like IDEA really shine. If I buy a copy of IDEA, I get a copy for Windows, Linux and OS X. It's written in Java, so it's easy to create versions for different operating systems. I imagine it's just a matter of packaging each install differently.

So I went to CompUSA and had to buy 2 copies of Word - one for Windows and one for OS X. That's bullshit - I should only have to buy one software package. Oh well, it's already paying off since Word on Windows hasn't crashed yet.

log.debug vs. logger.debug - which do you prefer?

This is probably a bit of a religious debate, but it can't hurt to ask. Do you prefer to use log.debug() or logger.debug() in your Java classes? A fair amount of open source projects use Commons Logging and many of them seem to use logger. Personally, I prefer log (esp. b/c it's shorter), but I'm willing to change based on what the community (particularly AppFuse users) prefer.

Here's another tip I learned today. I typically declare a log variable for each class, such as this one in BaseAction.java:

A better design can be found in Spring's DaoSupport classes. They have a logger variable that all its subclasses can use - eliminating the need to initialize a log variable in each class.

Obviously this is cleaner than AppFuse's current design - so I'll be changing it for 1.6. Any reasons why I shouldn't?