At 15:03 07.05.2001 +0100, you wrote:
>+1 also
>
>Here are some comments I have after reading the dirlayout.html file (for the
>first time, I have to admit. Actually I don't know where it is linked to on
>the jakarta web site !) ...
>
>I don't want to start a lengthy discussion (as it is very difficult to reach
>an agreement on these subjects ... :) ) but I still wanted to help ... :)
Sure, all suggestions are welcome and even encouraged.
>1) There is no directory defined for configuration files (top level
>properties file, top level xml files, manifest file to include in jar, ...).
>Do we want to define a location for these ?
Peter's suggestion in a follow up mail makes sense. Just to make sure, what do you
mean by configuration files (top level properties file, top level xml files)? Are
these config files for ANT?
Let me mention that I have had a hard time to have build.xml file in anywhere except
the project top level directory but that might be due to my level of incompetence.
>2) The rule for the output directory says : either bin/ or build/. I think
>that a) we must make up our minds on one choice only and b) then names are
>not well choosen as they be misinterpreted. I would suggest something less
>equivocal like out/ : build/ can be both the location of the files needed
>for building the project or the result of the build and bin/ can be location
>of generated executables or executable needed by the project for some tasks.
>Also, bin/ is inherited from previous languages like C/C++ where you built
>and executable. In java it is not really an executable, more like a library
>but lib/ wouldn't be good either.
I agree, bin/ implies an executable and build/ can be confused with the files required
for building, or the intermediary files or the (final) results of the build.
Although out/ is quite reasonable, it also leaves an ambiguity. Does out/ contain the
actual distribution (final) results or intermediary results?
>3) Until we all agree, I would let the project decide on how to use Ant :
>a) as an application that need to be installed on the computer doing the
>build. This means no need to have ant.jar, optional.jar, xerces.jar,
>xalan.jar, stylebook.jar, .... in the build/lib directory and no .bat or .sh
>files needed either.
>b) as a "component", i.e. located in build/lib with all it's needed jar
>files
It is up to the project to decide whether to include jar files or not whether in CVS
or in the actual distribution.
>4) The section on docs/ is not clear. Is it output docs not in CVS or non
>generated docs in CVS. It seems to be both. Should be clarified I think
IMHO, there is no absolute requirement to have the generated doc files under CVS
control. As long the docs/ directory contains all the files in the project's home page
it is possible to dump the contents of the docs/ directory to the directory
corresponding to http://jakarta.apache.org/some_project.
For log4j, this is what we do:
1) At project build time, we tar and zip the contents of the distribution to
jakarta-log4j-vX.X.tar.gz.
2) On the jakarta web server, we untar jakarta-log4j-vX.X.tar.gz in
$JAKARTA_WWW/log4j/ where $JAKARTA_WWW is the top-level directory for all jakarta
project home pages. This creates a directory called
$JAKARTA_WWW/log4j/jakarta-log4j-vX.X/
3) We soft link $JAKARTA_WWW/log4j/jakarta-log4j-vX.X/docs/ to $JAKARTA_WWW/log4j/docs/
4) We also (once and for all) redirect most requests to $JAKARTA_WWW/log4j/ to
$JAKARTA_WWW/log4j/docs/. See the .htaccess file under $JAKARTA_WWW/log4j/.
Are you confused yet? I would be... :-) In any case, that is one way to do it without
having files in docs/
under CVS control. The drawback of this approach is that you cannot easily change the
contents of your web-site without making a new release. That sucks big time unless you
mandate that the contents of docs/ in your distribution is identical to the contents
of your web-site.
>5) There should be only one name for the build scripts and tools. I would
>tend to prefer build/ with the output directory named out/. I don't really
>care about the name but there should be only one proposed
Sure.
>6) 2 options should be left to the project for the external jar needed to
>build/run the project. Until we reach an agreement on course ... (maybe
>CJAN/JJAR - see the discussion on jakarta-commons mailing list - will help)
>:
>a) leave the external jars out of CVS. i.e. use a build.properties file
>(used by Ant) that defines the location of needed external jars
>b) or check the needed external libs in CVS with the project.
When CJAN/JJAR provide a flexible alternative, I assume that jakarta projects would
migrate to benefit from the functionality offered by these tools. I am silently
following the discussion in commons. Cheers, Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
