[proposal] distribution packaging of tools and a webapp build

[Eddie O'Neil <ek...@bea.com>]

All--

   After much consternation and pouring over some build files which have 
been sent to me directly, I've come to the (personal) conclusion that 
the structure of the Ant build / tools infrastructure in the 
distribution could be improved upon.

   Today, we've got the following layout:

beehive-imports.xml
   Defines a set of commonly used paths (xbean, velocity, etc) and a set 
of <macrodef>s that deploy netui / wsm and build / clean a webapp.

ant/buildWebapp.xml
   Defines a single target that can build a webapp where the source is 
embedded in WEB-INF/src.  Also defines a target to clean such a webapp.

ant/buildWebappCore.xml
   Defines the Ant <macrodef>s used to build controls, JWSs, JPFs, and 
XSDs.  This Ant is at the core of how Beehive-enabled EARs, WARs, and 
other Java projects build Beehive source artifacts.

   In the end, this is just too complicated:

- the buildWebapp.xml file is a one-size-fits-all solution that doesn't 
fit lots of things.
- buildWebappCore.xml is inappropriately named as the targets here could 
build XSDs for a web service, build controls for an EJB, and so on. 
It's not all about webapps.
- beehive-imports.xml provides an illusion that the the <build-webapp> 
macro can be called and it will do the right thing.  In many webapps, 
this isn't the case.

   So, the proposal is to simplify the files above by doing the following:

- rename buildWebappCore.xml to beehive-tools.xml.  The functionality 
here doesn't change and can still build all of the source artifacts.

- add the ability to pass in an arbitrary <path> name to the compilation 
targets in beehive-tools.xml.  This provides a discoverable and 
well-known hook for app builds to customize the classpath used to build 
an app.

- move the functionality in buildWebapp.xml into the webapps that use 
it, namely petstoreWeb and netui-blank.  When starting from netui-blank, 
you'll get this build file which is setup to build a project of that 
structure.  The result is a transparent build file with obvious places 
for app-specific build logic to be plugged in.  Today, the hooks are 
basically before and after compilation, and this isn't sufficient when 
builds get interesting (ie real).

- convert beehive-imports.xml to define common paths into JARs in the 
distribution (such as velocity and xbean)

- remove the <build-webapp> and <clean-webapp> macros from 
beehive-imports.xml

- all of these changes make for easily switching an app onto another app 
container because the classpath logic isn't baked into Beehive's 
provided buildWebapp.xml.  Custom classpaths (for JOnAS or Geronimo) can 
easily be passed to the compilation targets in beehive-tools.xml because 
a user's application owns the entire build process end-to-end.

   In the end, a webapp build file will look something like 
buildWebapp.xml today except that it's owned by an app instead of by the 
Beehive framework.

   And, the beehive-tools.xml file defines a set of well-defined tasks 
that expose configurable classpaths and can be composed to build 
controls projects, webapps, enterprise apps, etc.

   In the push to Beta, I'd like to get these changes made soon if 
everyone agrees just so that we're shipping a more consistent tools 
story for the next "release".

   Obviously, I'm in support of doing all of this.  :)

   Any other thoughts?

Eddie