Without any other comments, I'm going to get this done using the .properties file in the next couple of days.
Feel free to send along any additional feedback.
Thanks!
Eddie
Bryan Che wrote:
I would vote to put those in a build.properties file too--that's probably a bit easier for users to edit than the xml build file.
Bryan
Eddie O'Neil wrote:
Bryan--
Yeah; two good questions. Both points are related to setting up the build classpath path for a webapp (same thing goes for EJB and other EAR related projects -- but let's start with webapp).
The general issue is how to pass a user-defined and container-specific classpath to <build-pageflows>. In this case, I'd say that the <path> is built in the webapp's build file and presumably includes the classpath for resolving the servlet / jsp classes in your app server environment.
Specifically related to the Ant file for the webapp template we ship -- samples/netui-blank/WEB-INF/src/buildWebapp.xml, we could do it either as a ${os.CATALINA_HOME} reference in the build file or as a ${os.CATALINA_HOME} reference in the build.properties file. Then, the <path> that contains these would be passed to the <build-pageflows> macro.
Here's an example using the .properties file:
samples/netui-blank/WEB-INF/src/build.properties ::::: beehive.home=/path/to/beehive/distro servlet.jar=${os.CATALINA_HOME}/common/lib/servlet-api.jar jsp.jar=${os.CATLINA_HOME}/common/lib/jsp-api.jar :::::
samples/netui-blank/WEB-INF/src/buildWebapp.xml ::::: <property file="build.properties"/>
<import file="${beehive.home}/ant/beehive-tools.xml"/>
<path id="this.webapp.classpath"> <pathelement location="${servlet.jar}"/> <pathelement location="${jsp.jar}"/> <fileset dir="${webapp.dir}/WEB-INF/lib"> <include name="*.jar"/> </fileset> </path>
<target name="build"> ... <build-pageflows srcDir="..." destDir="..." tmpDir="..." classpathRef="this.webapp.classpath"/> ... </target> :::::
I don't have a strong prefernce where this servlet.jar / jsp.jar classpath goes. It's probably best in the build.properties file.
But, either way.
Thoughts?
Eddie
Bryan Che 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
