1. From Eddie's original proposal, I'm a little concerned about the
possibility that this pushes more build logic/steps into local app
build files. This makes it much harder to rev build processes over
time. What happens if we want to introduce a new build step? I like
the idea of pulling out the non-webapp build macros and such, but not
necessarily of killing build-webapp.
2. For portability, it seems like there is a need for more than
property configuration... you may have ant tasks, macros, or extra
steps that are needed for build but are target-environment-specific.
Putting #1 & #2 together, I can' t help but wonder if what is needed
is some build.xml naming convention, triggered by an environment or
property setting that selects the target app server, such as:
build-webapp-tomcat.xml
build-webapp-jetty.xml
...
-- Kyle
On Wed, 09 Mar 2005 10:12:43 -0500, Bryan Che <[EMAIL PROTECTED]> wrote:
> Hi Eddie, sounds good. There is a bit of overlap in your proposal and
> my patch in http://issues.apache.org/jira/browse/BEEHIVE-195.
> Specifically, the part about setting up arbitrary paths for app servers
> to remove the dependancy on Tomcat. I was going to apply that patch
> today but can hold off for your work instead.
>
> A couple questions:
>
> -Right now, buildWebapp.xml references CATALINA_HOME to pick up the
> servlet api. Are you planning on moving the stuff in there to the
> arbitrary path?
> -How are users going to setup their path? Via a properties file or
> editing an XML file?
>
> Bryan
>
> > -----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
> >
> >
>
