Well there you've got to go and embarrass me in front of the whole list :-) I can't believe I didn't think of that! Ugh!!!
Thanks Laurie for pointing out what should have been the obvious solution. Sheesh. Man, I can't believe I missed that. Jake At 09:58 PM 9/9/2002 -0400, you wrote: >Why bother with all that file copying? :-) Just do: > ><property file="build.properties"/> ><property file="sample.build.properties"/> > >If build.properties doesn't exist it wont be loaded; if it does exist the >properties it contains will override those in sample.build.properties. Now >the user simply adds only those properties they want to override to their >build.properties. > >L. > >On 9/9/02 6:05 PM, "Jacob Kjome" <[EMAIL PROTECTED]> wrote: > > > Hello Dominique, > > > > Thanks for the suggestion, but that solution misses the point. If we > > just had it stored as "build.properties" so that it always existed it > > would achieve the same thing as the entity include stuff you are > > talking about so that doesn't seem to approach my hopeful solution. I > > actually am using the entity include for Tomcat Ant Manager tasks and > > it works pretty slick :-) > > > > But the point of the sample.build.properties is that each person may > > have their own. Each person can add/change/remove properties from > > their own copy of build.properties but we always want to have a > > reference available for the standard stuff that goes in > > build.properties hence the copy from sample.* to * only if * doesn't > > exist. > > > > Sounds like I'm going to have to forgo the sample. stuff for > > build.properties. Works fine for everything else because we can > > guarantee that the other files will be copied from sample.* to * > > before they are needed by the build. There just isn't a good way to > > do that will build.properties. > > > > BTW, is the <import> tag that you mention available in Ant-1.5.1beta1? > > I thought that was only going to be Ant2 functionality? > > > > Jake > > > > Monday, September 09, 2002, 4:41:21 PM, you wrote: > > > > DD> Sounds to me that you should maybe avoid this kind of trouble by using > > DD> entity include instead of your <copy> of sample files... That way, > you can > > DD> have a properly named project whose entire body is empty but for the > > entity > > DD> reference. Pretty much achieve what you do with <copy>, without the > > trouble > > DD> you're running into with properties. Check out the Ant FAQ for > details on > > DD> entity including an XML fragment file. > > > > DD> You could also go with the embed proposal (that defines an <import> > tag), > > DD> but that's a little more on the bleeding edge. --DD > > > > DD> -----Original Message----- > > DD> From: Jacob Kjome [mailto:[EMAIL PROTECTED]] > > DD> Sent: Monday, September 09, 2002 4:29 PM > > DD> To: Ant Users List > > DD> Subject: loading build.properties before other properties when it > doesn't > > DD> exist before building ... > > > > DD> Hi, > > > > DD> I have a project where we have sample files such as sample.web.xml or > > DD> sample.build.properties. I copy these files to a file of the same > > DD> name minus the ".sample" prefix. That is all working fine. The > > DD> problem is with the unique case of build.properties. > > > > DD> Normally, I load buld.properties first thing before defining other > > DD> properties so that properties in the build file can be overridden by > > DD> those in build.properties. However, the target that runs the copy of > > DD> sample.buld.properties to build.properties runs *after* all the > > DD> properties would have been defined. So, with a fresh CVS tree, > > DD> running ant for the first time on my build file fails to load > > DD> properties from build.properties because it does not exist yet. > > > > DD> Now, I would put the <copy> deal before > > DD> <property file="build.properties"/> > > DD> but the latter needs to be before all the properties are defined which > > DD> aren't inside a target. Since I can't put <copy> anywhere outside a > > DD> <target> element, I can't make the copy happen before the rest of the > > DD> properties are defined. > > > > DD> Is there a good way to deal with this situation other than, maybe, > > DD> putting all the <property ...> definitions inside a <target ...> > > DD> element, thereby allowing me to run the <copy ...> task to copy the > > DD> sample.build.properties to build.properties then load it, then define > > DD> all the other propeprties? > > > > DD> Jake > > > > > > > > > > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
