Ok, what about this:
apps bsf struts-build/ site/ build/ core el faces flow sandbox shale site taglib tiles
That would allow us to simply copy the nested build/ during the source build of any specific subproject, and still allow the relative references from struts-build/build/ to work (same for site/).
struts-core-1.3.0-dev/
build/
core/
config/
src/
-- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx
----- Original Message ----- From: "Martin Cooper" <[EMAIL PROTECTED]>
To: "Struts Developers List" <dev@struts.apache.org>
Sent: Thursday, February 17, 2005 11:07 PM
Subject: Re: Building Struts
On Thu, 17 Feb 2005 22:20:39 -0500, James Mitchell <[EMAIL PROTECTED]> wrote:Right, sorry.
If we don't want to include the build/ folder as a peer, then we can just
warn the user to go and fetch the src for that one as well (if not found).
What I meant was that normally the subproject-level directory would not be a subdirectory of the distribution, so when you unzip the distro, you'd see something like this:
struts-core-1.3.0-dev/ config/ src/ ...
But if we include the build "subproject" in the distro, and have the structure above, we'd end up with this:
struts-core-1.3.0-dev/ build/ config/ src/ ...
which is "wrong" from a peer directory level, and wouldn't work without adjustment to the build files in one place or another. We'd have to include the original subproject directory in the distro as well to make this work. So that would mean:
struts-core-1.3.0-dev/ build/ core/ config/ src/ ...
so introducing a 'core' directory that we would normally not have in the distro. That's not necessarily a huge big deal, it just seems a little odd. (But it does avoid the weirdness with mixing levels in the distro, and it does let people build from the source distro, and those are both Good Things. ;)
-- Martin Cooper
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
