Zach--

 Hey, thanks for adding a place to store Beehive-specific Ant tasks!

I'll just mention one comment on the structure of the change. A convention that we've tried to follow in how the Beehive tree is structured is to use the top-level and sub-project level "external/" directories for third party binaries / installers and to put tools code in a tools/src or test/src directory depending on how it's used. The benefit of doing this is that the structure of the tree enforces a separation between the components that Beehive owns / builds and those that we just use.

One of the things that could make it easier to add new Ant tasks is to build the "beehive-antext.jar" file from scratch at the beginning of the build. That way, the JAR is always up-to-date relative to its source files, and we could drop this JAR into the $BEEHIVE_HOME/build/ directory and define a Beehive-level property to expose it to sub-projects. If you're interested in an example of this, the NetUI "bootstrap" source module is used this way and is built first in the build to provide some Ant tasks (for example, a TLD generator) that are used by downstream source modules. Otherwise, we could just find a home for the "beehive-antext.jar" (tools/lib?) and document the process for adding tasks and re-building the JAR file.

Thoughts or comments from anyone? Any experiences with how these things work in other open source projects?

The build conventions that are used right now aren't written down anywhere yet; my apologies for any confusion has caused. I'll take responsibility for getting this posted to the wiki -- feedback is certainly be welcome once that's up.

Anyway, that's my $0.02...

Eddie




Zachary Smith wrote:

1. Creating $BEEHIVE_HOME/external/beehive-antext directory for custom
Ant tasks which may prove useful to other groups.

2. Adding GetHostName task to beehive-antext and a build.xml file to
support creating
$BEEHIVE_HOME/external/beehive-antext/beehive-antext.jar

3. Adding the first beehive-antext.jar which contains task listed in #2

4. Adding support to HttpReportTestCase class in Milton to search for
multiple HOSTNAME variables.  This is mostly for Windows which does not
have a HOSTNAME variable available.  One could use the GetHostName task
in an Ant script to set TEST_HOSTNAME or HOSTNAME automatically.  If
HOSTNAME and TEST_HOSTNAME are null it will default to "localhost".  (It
looks for TEST_HOSTNAME and then HOSTNAME and then defaults to
"localhost")

5. Fixing a few hard-coded paths and build/run class paths in build
scripts

Getting a bit closer to running the controls pageflow tests
automagically

===========================================================
=== diff inline since .diff files are being stipped off ===
===========================================================




Reply via email to