RE: Application Builds

[Mike Foster <mf...@bea.com>]

Hi Bob, users,

A couple of my thoughts on app builds --

1) Self contained project.  This is probably useful for people authoring Netui within an exploded webapp, but maybe not for controls/WSM.  I'm assuming that the controls.jar wouldn't be copied into every controls project, or the WSM jars for that matter.  Here's how I'd see application setup/build shaking out for the three components:

	- Netui.  Authoring inside a webapp.  Build environment could be contained in the app, but for consistency sake I'd like to require that $BEEHIVE_HOME be set (I'll explain below).  Beehive libraries at runtime can either be on the web container classpath, or in WEB-INF/lib.

		<WebAppRoot>/ (I'm using the <> to denote, this could be any name)
			build.xml -> imports tasks from $BEEHIVE_HOME/ant

	- Controls.  Essentially a java src directory structure.  build.xml probably references controls.jar or any controls extended somewhere on disk.  The output is a jar file to be included in any classloader (not just WEB-INF/lib).

		<ControlRoot>/
			<src/com/foo>/*.jcs
			build.xml -> imports tasks from $BEEHIVE_HOME/ant

	- WSM.  Also a java src directory structure.  The build will APT/compile the *.jws files into a WSM enabled WebApp (or alternately, create one).  Note:  I think this WSM enabled WebApp shouldn't be one that developers work in or drop files into (with the exception of some web.xml configuration).  We want to encourage people to keep their web-ui applications and their web service applications separate.

		<WSMRoot>
			<src/com/foo>/*.jws
			build.xml -> imports tasks from $BEEHIVE_HOME/ant

$BEEHIVE_HOME.  I'd propose we require that this be set for all beehive development, because it doesn't make sense to copy controls/wsm jar files into every controls/wsm enabled project.  We can reference them from the build, and copy them into WebApps or put them on the system classpath at runtime.  If this is set, it makes sense to me to have a common set of ant tasks and ant scripts under $BEEHIVE_HOME rather than copied into each application.  The template app build.xml files can import these.

2) Extending the ant scripts for import in the /ant directory to include control specific builds, and control and WSM builds together.  To be clear, I think it'd be cool to have importable scripts for the following:

- Netui webapp build including automatic java and control compilation
- WSM build including automatic java and control compilation
- Control build only

Thoughts?

-Mike 

-----Original Message-----
From: bob@codehaus.org [mailto:bob@codehaus.org]
Sent: Sunday, October 31, 2004 10:47 AM
To: Beehive Users
Subject: Re: Application Builds


My preference would be to allow your project to be self-contained,
not reliant on having the full beehive distribution on your disk.
Setting up a project should copy everything that's needed to do
the build.  I think though the magic of <import> or such we can
give you a build.xml that's mostly blank for your stuff, and
a build-beehive.xml that does the beehive magic.  That'd make it
easier to keep your specific project's targets and mix in the
beehive helper targets.  Plus, you would be able to upgrade
the beehive portions if required, without having to modify the
contents of your project's build.xml.  Just copy in a new build-beehive.xml.

	-bob


Chris Hogue wrote:
> On the wrappers you're talking about, it sounds like that would
> work fine. Would the targets be copied to the build file in the app
> directory or would they simply call out to the build files in the
> beehive directories?