Zach--
Apologies for the delay in getting back to this. Moving the source out of external/ and into test/ would be great; I'd still prefer using the test/src directory so that the directory structure is self describing but am not religious about it.
As far as the build output, the point of the build/ directory is to store all of the artifacts generated during the build (and everything else that can be transient relative to a build such as a component's Javadoc). Seems that if "tch.jar" is generated into test/infra it could just as easily be generated into build/test-infra and then works like the Beehive sub-component builds. Or is this something that is generated once and then only replaced when it's stale? If so, how about just putting the output into installed/beehive-test-infra which is where JSR 173 is stored. The "installed" directory can also be deleted at any point and can be replaced by the Beehive build itself.
I'm not trying to be a pain here, but as Beehive grows and (hopefully!) attracts more developers and potentially sub-components, having all of those share a common directory structure lowers the bar for understanding how Beehive is structured, builds, and hangs together. And, it's easier to make this happen sooner rather than later.
:)
Eddie
Zachary Smith wrote:
Eddie,
How about this: I'll move beehive-antext from $BEEHIVE_HOME/external/
to $BEEHIVE_HOME/test/tools/, add a build.xml to test/tools and add a
call to the top level build script to call the test/tools/build.xml
file.
Now for the build output target: Controls tests stores all test infrastructure tools $BEEHIVE_HOME/controls/test/infra. For example, tch is stored in $BEEHIVE_HOME/controls/test/infra/tch/ and tch.jar and all supporting files are stored under that directory (schemas, 3rd party libs the tools relies on which are not shared in $BEEHIVE_HOME/external, etc). How do you feel about having $BEEHIVE_HOME/test/infra as a target location for shared tools such as beehive-antext.jar?
#!/zach
-----Original Message-----
From: Eddie O'Neil Sent: Thursday, August 19, 2004 9:41 PM
To: Beehive Developers
Subject: Re: Controls Test Tools Update
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:
(It1. 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".
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 === ===========================================================
