On Thu, 12 Apr 2001, Peter Donald wrote:
> Hi,
>
> At 01:48 11/4/01 -0700, Craig R. McClanahan wrote:
> >(4) Source Directory Structure
> >
> >The following directory layout will be typical for a Commons component:
> >
> >jakarta-commons/foo/ For component "foo"
> > build/ BUILD SCRIPTS
> > build.xml Standard build.xml script (with others
> > if appropriate)
> > build.properties.sample Example external dependencies file (see
> > below for details)
>
> I will say this again because no one seems to listen but doing this is a
> good way to screw your users. "build" is used in many projects to indicate
> intermediate files. For newbies it also requires intimate knowledge of
> build practices before they can locate the base build.xml file. Hence why
> this directory should not exist and file sshould exist in base directory.
>
I've actually been in Peter's camp on this issue (i.e. Struts and Tomcat
both do this currently). The counter-argument is messiness in the
top-level directory, especially for projects that have several (Cactus) to
lots (Turbine) of build script variants. I'm fine with either placement.
On the issue of where the output of a build goes, I've seen just as many
uses of "out" or "target" as I have of "build". Again, I'm not hung up on
*which* directory name we choose - I just want us to select standards (at
least within Commons) and stick with them. We can worry about conquering
the rest of the world later.
> > conf/ CONFIGURATION FILE SOURCES
> > MANIFEST.MF Manifest file for JAR(s)
>
> Considering many project manipulate/filter/transform their conf files
> doesn't it make more sense to place them under src/conf ???
>
The filtering happens on the way to the output directory (target/conf in
the current proposal). There is also sometimes filtering being done on
files in the "web" directory (if your component is or builds a webpp), so
you'd want to make the same argument for the "web" directory if it exists.
Again, I'm fine with either -- just not with both :-).
> Cheers,
>
> Pete
>
Craig
