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.
Posted by Dan Q. on June 23, 2005 at 08:06 AM MDT #
Posted by Mathias Bogaert on June 23, 2005 at 08:32 AM MDT #
Posted by Lee on June 23, 2005 at 09:28 AM MDT #
Posted by Erik Hatcher on June 23, 2005 at 12:56 PM MDT #
You probably haven't seen performance hit from using commons builders for hashCode() and equals() because you haven't run specific performance tests. Try to put your objects into (reasonaby large) Collection and perform, for example, sort operation on it - at minimum you would see 20% perforance hit which can reach as high as 200% if you're using reflection builders.
Posted by Dmitri Maximovich on June 23, 2005 at 01:46 PM MDT #
Posted by Greg Jones on June 23, 2005 at 02:06 PM MDT #
Posted by reddeagle on June 23, 2005 at 02:28 PM MDT #
Posted by erickreid on June 23, 2005 at 03:05 PM MDT #
Posted by Steven Citron-Pousty on June 23, 2005 at 03:37 PM MDT #
Posted by Rossi on June 23, 2005 at 04:01 PM MDT #
Hi Matt,
You are doing an absolutely incredible job with Appfuse. You heavy lifted Appfuse off the ground yourself and it has taught 1000's of developers (based on download numbers) the basics of how java, struts, spring, hibernate, etc. fit together. Thanks from one of those developers!
I know you've already had several "What's Next For Appfuse" threads on the appfuse mailing list. It seems like appfuse will continue to grow and evolve.
Personally, I would like the directory layout to more closely match what Idea does for it's web directory layout and build process. This would allow faster edit build reload cycles for me with tomcat reading the exploded build directory directly. I believe this is how MyEclipse and other web development environments work. If I had your time management skills I would rewrite appfuse to do this. Perhaps later in the year :)
Regards,
Phil
Posted by Phillip Hershkowitz on June 23, 2005 at 04:44 PM MDT #
Anyway, since this isn't the bileblog, here are some helpful ideas:
For IzPack, build an offline installation. The download size is bigger, but it's less flakey than the net install, and you can define different packs for webwork/struts/whatever support. Even nicer for the target audience you have in mind would be to let them specify stuff like what database they want to use (and maybe even ship with hsqldb for an better out of the box experience)
Prompting for package name twice: Why is this hard to fix? I'd suggest writing a custom ant task where you can put in whatever logic you want. Not as sexy as bsh or groovy or whatnot, but far more suitable and functional for the job at hand.
Non-tomcat specific: Clever use of the <available> task in ant should allow you to detect tomcat and behave accordingly. For tasks that require it, you can have a <target name="blah" depends="check.tomcat">, with the check.tomcat target failing if the tomcat classes aren't in the classpath. That way users can still get stuff done if they're doing tomcat specific stuff, and if they do want to deploy or whatnot, they get a helpful message saying why it isn't possible. For people wanting resin/orion/jetty/whatever support, it'd be easy to just write more tasks to do it. Most users are likely to be comfortable with a war file being spit out, so a built-in deployment step isn't that vital anyway.
Consolidation of directories: While the directories are fairly intuitively named, it is a bit much to navigate for a first time user, especially given the target audience of webapp newbies
BaseObject: providing (or even mandating) hashCode via an interface is a bad idea generally, because there isn't really a generic way of modelling domain specific objects to provide meaningful hashcodes. Relying on the generic one from Object.class is perfectly adequate. Same goes for equals, you're not gaining anything by defining this since it's still a non-domain aware solution.
Posted by Hani Suleiman on June 23, 2005 at 05:24 PM MDT #
Posted by Doug Pham on June 23, 2005 at 08:09 PM MDT #
Posted by Rick Hightower on June 24, 2005 at 04:02 AM MDT #
Posted by Rusty on June 24, 2005 at 05:41 PM MDT #
Posted by Ken Yee on June 24, 2005 at 07:20 PM MDT #
Posted by Allan on February 27, 2007 at 04:06 AM MST #