J2EE "Wizard"

[Ashton]

After creating a number of applications using J2EE components, I've
settled (well, mostly) on a common directory structure, collection of
tools, and some standard utility classes that I'm likely to use in
future projects. I've built an archive file that I can use a a starter
kit for any new project...expand it, rename some files, edit a few more
and away I go.

However, I've been toying with the idea of creating a web application
where I'd fill in a form and have it create the skeleton of the new
application. As a proof of concept I have it at a stage where it can
create something unique that builds with no extra intervention on my
part except typing 'ant'. (No renaming, no editing.)

My question is, am I looking at "wheel re-invention" here? It might be
fun to add some more features and turn this into something useful, but I
won't bother if there are similar utilities already available.

Anyone familiar with non-proprietary tools that already do this?

 

[Sudsy]

After creating a number of applications using J2EE components, I've
settled (well, mostly) on a common directory structure, collection of
tools, and some standard utility classes that I'm likely to use in
future projects. I've built an archive file that I can use a a starter
kit for any new project...expand it, rename some files, edit a few more
and away I go.

However, I've been toying with the idea of creating a web application
where I'd fill in a form and have it create the skeleton of the new
application. As a proof of concept I have it at a stage where it can
create something unique that builds with no extra intervention on my
part except typing 'ant'. (No renaming, no editing.)

My question is, am I looking at "wheel re-invention" here? It might be
fun to add some more features and turn this into something useful, but I
won't bother if there are similar utilities already available.

I don't know about others but I've done the same thing with a
generic "project" for Eclipse. It includes the build.xml files
and directory strcuture for an application which uses EJBs, Struts,
servlets, JSPs, custom tags and regular HTML files.
I guess it's something most of us get around to in order to reduce
the effort required when configuring each new project. I don't have
a GUI front-end but if I don't create elements in the various
subdirectories then there's nothing to build in that task.
I believe that most experienced developers create their own little
"toolbox". I've got tools which generate EJBs directly from data-
base meta data, for example. There are commercial products out
there which do the same thing but I wrote mine before they were
available.
As to whether you're reinventing the wheel, I don't know for a
fact that there are other tools out there which do the same
thing but I'd be surprised if there weren't.

 

[Ashton]

I guess it's something most of us get around to in order to reduce
the effort required when configuring each new project. I don't have
a GUI front-end but if I don't create elements in the various
subdirectories then there's nothing to build in that task.

One of my reasons for going a bit "higher tech" is having the ability to
customize file names, package names, ant targets...other internal data
that needs to be synch'ed. Is that handled in the Eclipse solution?

(I had been thinking of doing what I want in Netbeans, but couldn't
quite see how to do the mods internal to the files...whereas feeding my
templates through a JSP processor works quite nicely.)

 

[Sudsy]

One of my reasons for going a bit "higher tech" is having the ability to
customize file names, package names, ant targets...other internal data
that needs to be synch'ed. Is that handled in the Eclipse solution?

There are standard names for the build files in Eclipse, namely
xdoclet-build.xml and packaging-build.xml. As far as the directory
structure, I adhere to the "standard" of building projects in the
namespace of a domain. All a shell scripts requires is the name
of the project, the domain subname, and the destination directory.
Everything is then "boilerplate" and you can just start coding.

 

[Ashton]

There are standard names for the build files in Eclipse, namely
xdoclet-build.xml and packaging-build.xml. As far as the directory
structure, I adhere to the "standard" of building projects in the
namespace of a domain. All a shell scripts requires is the name
of the project, the domain subname, and the destination directory.
Everything is then "boilerplate" and you can just start coding.

Interesting. The domain subname was the main item that caused me to go
the way I did. I wanted new packages to have the project name as part
of the package, which meant variable direcory names somewhere down the
source tree(s) *and* a corresponding somewhere in the 'package'
statement...and inside build.xml, and as a prefix to the properties file
name.

Once I was automating all that, it was a short step to adding a project
description, author name, automatic creation date....