[OWASP-LEADERS] Re: [OWASP-FILTERS] filters module created in CVS

Ingo Struck ingo at ingostruck.de
Wed Oct 30 17:09:39 EST 2002


Very good.
Our activity percentile just explodes... :o)

You are very right with the motto: 
"Premature optimization is the root of all evil."
But sometimes you spare lots of rewriting if you just keep out some
of the worse things right from the start...

Anyway, the only thing I really care about for the moment is that the 
subpackages come in a fairly uniform structure. It would be great, if our 
"users" could rely upon a uniform package tree structure.
Maybe we could agree upon some basics?

My proposal for this is appended in the file PACKAGING
(shipped under ocl/doc/ too)

For the src/ subdir I propose the following additions:
If a project only contains one programming language, then the sourcefile
are placed directly under the src/ subdir.
If a project contains multiple languages, it should provide one subdir for
each language, e.g. src/java src/c src/pl etc.pp.
The source for Documentation should go to

Regarding idmef I browsed through the filters mail archive.
The only thing I discovered is that there was not really much discussion
about the idmef stuff... So I guess we just forget about it and do not port it
to the SF owasp project?

Kind regards


-------------- next part --------------
Copyright (c) 2002 Free Software Foundation
developed under the custody of the
Open Web Application Security Project

This software package is published by OWASP under the GPL.
You should read and accept the LICENSE before you use,
modify and/or redistribute this software.

This is the mandatory packaging structure for any OWASP
project. It describes which part of a software package should
be placed in which directory subtree.

1. root directory


The root directory should be called like the owasp subproject,
e.g. webscarab/ webmaven/ or similar. A packed (.zip or .tar.??)
distribution must extract files to this directory and _not_ to
the current working directory.
The root directory must contain at least the following files:

a) README, a short fingerpost to some of the other resources to
   be found in the project, with at least a lead to the LICENSE,
	 to detailed documentation and a short instruction how to build
	 and use the software. The file must be plaintext with at most
	 80 characters per line.
b) LICENSE, a file that contains the GNU General Public License
   (GPL), Version 2 or higher, or in some special cases the 
	 Lesser GNU Public License (LGPL).
c) build.xml and/or Makefile, the ant respectively make instruction
   files to build the software from source
d) config.build.xml and/or rules.make, the centralized configuration
   files for build processes. More complex packages may consider to
	 use a full-fledged autoconf configuration setup

2. source directory

This directory contains any needed source files to build a binary
release of the software. Binary distributions do not need to provide
this directory.

3. documentation directory


This directory contains any documentation in the final form.
Preferably this is a tree of static html documents. Automatically
generated documentation from the sourcecode should go here too.

4. build directory


All generated files produced by the build process (except documentation,
see above) are stored here. It is the place where compiled libraries
(e.g. .jar files, .a and .so files, .dll and the like) are stored.
Source distributions must provide an empty build tree, binary distributions
have to provide the precompiled binaries and any other needed resources
to run the software here.

5. library directory


If a software package depends on third party libraries, they should be
provided here completely in the needed binary form.

6. binary directory


Auxiliary binaries to *build* (not to run) the software should be placed
here. Binaries that are part of the software should go to build/bin

7. template directory


Files that could be used as a start point for extensions of the software
(e.g. class templates, doc templates et al.) should be placed here.
The OWASP common library should provide a complete "project-template" here.


More information about the OWASP-Leaders mailing list