Show Me Your Skeleton And I’ll Show You Mine

Normally when I’m about to start a new Java project I go and get my skeleton project and make a copy of that to the correct directory name to get started. Maybe you call your skeleton something else, a template, a prototype, whatever but I’m curious if you have one. Mine consists of an already created directory structure, a build.xml file that serves as a good starting point, a handful of libraries that appear in 100% of all my apps (logging, unit testing, etc.), the shell of a ReadMe.html, etc..
Personally I don’t think this is much of a solution. What I wish I had was something that was like what the old Visual Studio did. It had a wizard that you could step through and it would ask you a set of questions before producing what was largely the same application skeleton every single time 🙂 Why don’t we have something better than that for eclipse, NetBeans, etc. It wouldn’t have to be proprietary to any one particular vendor because the core code would be agnostic to any IDE. It would be a set of instructions to ask some questions and generate files.
You could have templates for a web app, a Swing app, an SWT app, and a console app. Each one would be responsible for creating directories, writing out a build script, asking you the name of the application, the packages where the files would be put, features for that particular kind of application, etc. Where is this feature? It’s not complicated, most of it could be done by scanning through some XML that told you which directories to create, some Velocity templates that created all of the files you needed, etc. and yet the two IDEs I’ve worked with the most (eclipse and NetBeans) seem more focused on helping you create individual files but not starting points for entire applications. NetBeans did have the ability to create a simple Swing app but all it created was a file or two of Java, no build structure, place to put documentation, etc.
I do know about AppFuse and Equinox and I think they are really cool. However, correct me if I’m wrong, but I don’t believe that even those offer a wizard to tailor anything in their skeletons. Where there are choices mentioned in the documentation (e.g. iBATIS and Spring for AppFuse) they are just more documentation on what you can change, not a checkbox that you check and the change is made for you. The closest they seem to come is changing some names via ant when you create a new instance.
I can anticipate one of the biggest objections likely to be raised to this. If we do this, then how many developers are going to become dependent upon the crutch of wizards creating the shell of an application for them and they won’t understand the very IOC container or persistence framework, etc. they are using because they didn’t have to set it up. If that is your objection then I agree, but I’m not sure it makes sense to deprive the more skilled developers of the tools because others might abuse them. I’m betting with a little collaboration we could come up with some killer starting points that would be tailor made to cut time off the front of a new application.

5 thoughts on “Show Me Your Skeleton And I’ll Show You Mine

  1. John Munsch

    I don’t have anything that resembles a procedure but I’ve made two changes to it quite recently. One was to remove the log4j library and replace it with the Jakarta Commons logging. My thought there was that the commons logging was much smaller and in those cases where I want more logging muscle I can use the two together to get it. The other change was to add the JReleaseInfo to the lib directory and to the Ant build script so I have an easy source of build and version number for my apps.
    It all boils down to thinking, “Is this something I’ll be doing over and over? And if so, is it something I can put into the project shell?” Now that I know about Megg, I’ll start trying to do a shell for the three kinds of applications I do which have distinct differences (i.e the web app, the Swing app, and the console app).

Comments are closed.