RE: AppFuse, 'tool' of experts
I'm please to say that I've been biled yet again. The first time wasn't so bad, and this time seems pretty mild too. There's no mention of asshat, chozgobbler or turdburglar in the whole post, which is somewhat disappointing. Nevertheless, it's what I've come to expect from a guy who sallies car bombs and dances like a sissy.
Regardless of the lack of bile in Hani's post, he does bring up some good points. Let's take a look at them individually:
- IzPack and MyJavaPack: the progress bar doesn't work, and the installer downloads everything rather than just including/installing it all.
- To be honest, I didn't know it was possible to pack up everything and skip the internet download part. I'll definitely look into fixing this.
- You must have Tomcat installed to work with AppFuse.
- This is true, and I've thought about changing it to be Resin friendly, or possible Orion friendly, but there simply hasn't been any demand. Of course, Orion isn't that attractive to many folks because it doesn't even support Servlet 2.4. Maybe you should crackin' on that Hani! Or maybe you just like living in the dark ages with your affections for EJB 2.1, Servlet 2.3 and WebWork 1.4.
- When creating a new project, you get prompted for the package name twice.
- This is true, and something we should fix. The major reason we haven't is because I didn't want to distribute a 2MB BeanShell JAR that would support the 3 lines of code to fix the problem. I guess I should bite the bullet and add the bloat, or figure out a more elegant way to fix the problem. Issue #75.
- Project generation auto-detects MySQL when you don't have it installed.
- MySQL is the default, but it's pretty easy (IMO) to use PostgreSQL or Oracle.
- I'm a web monkey.
- True, but that's cool now with Ajax and all.
- Half the build targets don't work.
- I think this is more like a handful don't work, but good effort. I agree we should remove the install-* targets when installing a web framework. Issue #76.
- Every object creates builder objects in hashCode and toString.
- This is true, and I've seen no performance implications from it. In reality, these are a product of the commons-lang project, as well as Commonclipse. We should probably change these to use smarter methods like the ones IDEA generates. It'd be nice if Eclipse has hashCode() and equals() method generation like IDEA.
- The project's directory layout is bound to confuse a seasoned webapp veteran.
- The directory structure is largely based off the example app in Java Development with Ant. Since AppFuse uses Ant, I figured it was a good idea to use a "best-practices" structure like Erik describes in his book. I've often thought about consolidating the 3-source tree, 3-test tree directory structure to one, but users are very attached to the current setup. Maybe for 2.0.
- XDoclet generates web.xml.
- I agree that using 11 XML fragments to generate 1 XML file is a little ridiculous. You're right - developers should know how to write a web.xml and what goes where. Issue #77.
Thanks for the feedback Hani - sounds like I owe you a car bomb or two at JavaOne. 