On Mon, 21 Oct 2002, Eddie Bush wrote:
> Date: Mon, 21 Oct 2002 13:45:38 -0500
> From: Eddie Bush <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Struts-EL - BUILD FAILED
>
> Ok - exploring that path. I need to know how the directory structure is
> on the machine nightlies run on (Craig's machine?). Does he have the
> different servlet APIs out there on the same level as the Struts directory?
>
I leverage the following statements at the top of the build.xml file:
<property file="${user.home}/build.properties"/>
<property file="build.properties"/>
to allow me to put all my default paths into the single global file
(shared across all projects), with occasional individual overrides in a
local build.properties file. Therefore, my particular directory structure
doesn't need to have any influence over the standard build.xml files we
ship, or the build.properties.example files we provide.
> Either all paths have to be specified as relative or they must be
> absolute (duh!). Currently they're relative - but incorrect (at least
> in my updated checkout they are). Should we stay relative and expect
> there will be checkouts of the dependencies on the same level as the
> "jakarta-struts" directory (ie jakarta-taglibs, etc), or move to
> specifying those base directory names independently?
>
I think relative paths like this for the default property values are a
reasonable default convenience, but everything should be parameterized
(for example, each JAR file should have its own property) so that
individual users can easily adapt.
> Any preference? Which is "best"? I'm thinking that the least painful
> approach would be to stick with relative paths and expect people would
> have the dependencies checked out on the "same level" as struts. Sound
> good?
>
> When I say "same level", I mean:
>
> someDirectory/
> jakarta-struts/
> jakarta-taglibs/
> somethingElse/
>
> they all share the same parent directory.
>
This happens to be true of my build environment (for the Jakarta packages
I'm interested in building, chiefly Struts and Commons), but *not* of what
I actually compile with -- I will often point at production releases of
particular commons packages, for example.
> Karr, David wrote:
>
> >You don't really need to build the JSTL, just use the binary package.
> >
>
That's one of my examples for being independent of the directory structure
-- my global build.properties file includes (among others) the following
directives to force the use of a binary release of JSTL:
standard.home=/usr/local/standard-1.0.1
jstl.jar=${standard.home}/lib/jstl.jar
standard.jar=${standard.home}/lib/standard.jar
so the default values for the latter two properties are totally irrelevant
to me.
> --
> Eddie Bush
>
>
Craig
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
