[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Classpathx-discuss] ANT build in infobus

From: Raif S. Naffah
Subject: Re: [Classpathx-discuss] ANT build in infobus
Date: Tue, 04 Dec 2001 20:46:31 +1100

At 10:04 PM 12/3/01 -0500, Andrew Selkirk wrote:
On December 3, 2001 04:05 am, Raif S. Naffah wrote:
> ...if we're to use ANT it
> would be a good idea to standardise on one way of using it...

I'm definitely all for that!!  From the scripts I have written so far, most
of the build.xml can be quite generic and it can be personalized from a
properties file.


   Also, we can standardize on directory structures, etc.
For example, where do junit test files live?  In a {base}/test directory,
a {base}/source/test directory, or along side the actual class files.  The
one in infobus has a source directory under a top level test.

the gnu.crypto one uses a test/ hierarchy under source/; ie.


test/ would map to the first subdir of gnu/ that has classes; ie. if gnu/crypto has no classes, only directories underneath, then test/ --> gnu/crypto.

thinking about it now as i'm writing this message, it probably is a better idea to have test/ maps to gnu/. this would allow building/coding a gnu.AllTests class that would invoke crypto.AllTests, infobus.AllTests, etc... when more than one GNU projects are to be packaged/released together. yes?

if we have consensus, i'm happy to modify the gnu.crypto test tree accordingly.

the rationale of having test under source/ is that because the test classes are 'source' too. this way when you want to package the 'source files' you work with one directory. it also means less clutter under the project's root.

gnu.crypto uses the following pattern:

* build a gnu-crypto-test.jar in addition to the gnu-crypto.jar,
* have both jars in the classpath, and
* invoke the root AllTests.
* fail the build if the test does not succeed.

  The build
script generates a build, results, and report in this test area.

i like the idea of generating a report, even though failing the build process because of an unexpected result in the test is good enough for a build tool. as mentioned earlier my concern is more to do with the size of ancillary jars needed for that.

  Is there
any value to this structure?

Mandatory targets could include:
compile - compilation
javadoc - JavaDoc
test - run test suite
release - generate a release

absolutely, how about adding these:

configure - prepare environment for build process, fetching, if needed required jars
jar - build the binary deliverables
distclean - remove all files generated by a build run
clean - remove binary files; eg. .class
licence - prints licensing information
version - prints version information
install - installs binaries and build scripts to use those binaries on client platform

> i've already an iteration of an AntStyle document for a coding style (a
> JavaStyle one also exists) for the gnu.crypto project and wouldn't mind if
> others have a look, adopt and/or modify to suit.  if people are interested
> i can email it to them or if enough interest exists i can post it to this
> list.

I'll have a read.  Thanks.

i'll attach it in a separate mail.

> ...where can i have a look at your build.xml?

In the infobus module.

ta :-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]