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: >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 === >=========================================================== > > > >
