Definitely. :)
Scott Semyan wrote:
As long as we update the docs I'm fine with that ;-)
Scott Semyan
-----Original Message-----
From: Eddie O'Neil Sent: Tuesday, March 08, 2005 3:44 PM
To: Beehive Developers
Subject: [proposal] distribution packaging of tools and a webapp build
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
