ot -- Re: [proposal] distribution packaging of tools and a webapp build

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

   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
> 
> 
>