beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: Controls Test Tools Update
Date Thu, 26 Aug 2004 05:19:38 GMT
On Wed, 25 Aug 2004 22:48:14 -0600, Eddie O'Neil <ekoneil@bea.com> wrote:
> 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
> 

FWIW a lot of Apache projects have a "clean" target in their Ant or
Maven build scripts that simply deletes the output directories
(typically "build" and "dist").  If you're disciplined about having
all generated artifacts being output into one of these directories,
then you can be rest assured that "clean" really does what it implies
-- removes *all* generated artifacts, so that you can always do a
repeatable build without having to worry about special cases.

As an extra added benefit, you don't have to maintain complicated
".cvsignore" files to avoid annoying warnings about files in
"test/infra" that are not checked in :-).

Craig

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

Mime
View raw message