Return-Path: <jwtodd@pacbell.net>
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 76209 invoked from network); 4 Feb 2000 06:01:55 -0000
Received: from mta4.snfc21.pbi.net (206.13.28.142)
  by locus.apache.org with SMTP; 4 Feb 2000 06:01:55 -0000
Received: from pacbell.net ([207.214.212.193])
 by mta4.snfc21.pbi.net (Sun Internet Mail Server
 sims.3.5.1999.09.16.21.57.p8)
 with ESMTP id <0FPE0046L600G3@mta4.snfc21.pbi.net> for
 ant-dev@jakarta.apache.org; Thu,  3 Feb 2000 22:00:01 -0800 (PST)
Date: Thu, 03 Feb 2000 21:56:34 -0800
From: James Todd <jwtodd@pacbell.net>
Subject: Re: Properties and subprojects
To: ant-dev@jakarta.apache.org
Message-id: <389A6A12.592C074D@pacbell.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: 
 <E1B81A5627BAD01191B500805FC16B0E77AA31@nlnwx001.origimail.origin-it.com>


i subscribe to this approach as well.

question:

    it seems to me that when i build a "branch of a project", eg:

        <javac srcdir="${dir.src}/util/src/falcon/util"
            destdir="${dir.build}/client/classes"/>

    where the project package is rooted at falcon, that any and
    all resources (eg  falcon/util/foo.properties) *do not* end up
    co-located with the relevant branch classes yet are instead
    deposited at the destdir. put another way, i wonder if something
    in ant/javac is broken when it comes to prepending the src
    package name for non-java source objects.

    to work around this i have a peer "resource" directory structure
    which gets overlayed on the javac destdir with a simply
    copydir call, eg:

        <copydir src ="${dir.src}/util/resources/falcont"
            dest="${dir.build}/client/classes/falcon"/>

    that said i'd like to avoid this second step and the associated
    bookeeping all together. any ideas?

    thx much,

- james


"Kuiper, Arnout" wrote:

> You got a valid point here, although I'm not sure if we must bother
> the user by explicitly passing properties to sub-projects.
>
> For myself I use some sort of namespacing to prevent property clashes;
> I prepend every property inside a project, with the projects name.
> So in a project with the name "foenix", I have properties called
> "foenix.src", "foenix.dist", etc.
> This way, the user can override the settings for each project,
> including all subproject, from the commandline, and we don't have
> naming conflicts between projects.
>
> Personally I like the "namespacing" approach better.
>
> My 2 cents,
>
>   Arnout
>
> > -----Original Message-----
> > From: Ludovic Claude [mailto:lc@websitewatchers.com]
> > Sent: zondag 30 januari 2000 22:14
> > To: ant-dev@jakarta.apache.org
> > Subject: Properties and subprojects
> >
> >
> >
> > Still struggling with Ant & properties ... Now I came across
> > a problem with ant
> > subprojects:
> > By default, when you launch a subproject, all the properties
> > defined in the
> > parent project override
> > the subproject properties.
> > But if I define in the parent project a property called
> > src.dir, and in the
> > subproject a property with
> > the same name, they may not have the same value, so you need
> > to keep the
> > subproject value when
> > running it from the parent project.
> > I added a patch to Ant.java, so now you have a property
> > called properties where
> > you can
> > explicitely give the list of properties to use from the
> > parent project. By
> > default, you still have the
> > old behavior of using all properties from the parent project.
> >
> > You can download the new Ant.java file from
> > http://www.ringsys.co.uk/opensource/Ant.java
> > And the diff is
> > http://www.ringsys.co.uk/opensource/Ant.java.diff
> >
> > Ludovic Claude.
> >
> >
> >