beehive-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Foster" <>
Subject RE: Application Builds
Date Fri, 05 Nov 2004 22:45:11 GMT
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).

			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.

			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



-----Original Message-----
From: []
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.


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?

View raw message