Nick Chalko wrote:
>
> temp.dir should probably default to "/tmp/${user.name}"
Good point. Multi User machines need to distinguish between users.
However, don't forget the project name as it will be more common for
one user to build several projects than it would be for many users
on one machine.
tmp.dir = "/tmp/${user.name}/${project.name}"
would be the one to handle for all users.
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 21, 2001 1:04 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Build.xml standardization
>
> ---- you [EMAIL PROTECTED] wrote ----
> > Perhaps this can be further bettered by further specifying standard
> > names for the build and test directories:
> >
> > project.name - Name of the project (no default).
> > temp.dir - Location of the system's temporary directory (default
> ="/tmp")
> > build.dir - Build directory (default="${tmp.dir}/
> ${project.name}/build")
> > check.dir - Test results directory (default="${tmp.dir}/
> ${project.name}/check")
> >
> > This way, it is easy to specify that these artifacts are all
> > outside of the project directory (one of my pet peeves).
>
> Yes, standardizing on these Ant-based property names for the various
> directories in the guidelines is critical. It might be nice to merge the
> directory guidelines with the build target guidelines to show how they
> compliment each other.
>
> Note that I'd like to be careful to also keep as many of the guidelines
> compartmentalized where possible. While it would be nice for every project
> (and I hope to push similar or simply stolen ideas on xml.apache.org too)
> to have exactly the same mainline targets and dir structure, I'd like to
> make it as easy as possible for individual projects to start converging.
> One way is to let a project adopt part of the guidelines without having to
> immediately implement all of them. Having ant properties for various
> directory locations will give some flexibility, in that having the standard
> property names is pretty easy, even if some projects don't yet have the
> same defaults or physical cvs source locations.
>
> I'm not sure when I can get to this on the xml side, but I think there
> we'll have a slightly different perspective on documentation: we really
> want to emphasise that we 'eat our own dogfood' and write all docs, etc in
> XML, which are then transformed in one of several ways to an end-user-able
> set of docs (whether a static xsl transformation to html, or a servlet that
> you can install to do it on the fly, or through FOP, etc to PDFs, or
> various xsl transformations to different html-like formats)
>
> And yes, in general I make sure that *all* outputs of a build go into a
> single root location. I can see wanting to put it outside the source tree
> too - perhaps I'll try to sell xalanites on the idea.
>
> - Shane
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
