Re: [Classpathx-discuss] ANT build in infobus

[Raif S. Naffah]

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.

agree.


>    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.

...
source/gnu/...
      /test/...

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


> Later,
> Andrew...


cheers;
rsn