"Morrison, John" wrote: > > > -----Original Message----- > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, 18 October 2001 2:43 pm > > To: [EMAIL PROTECTED] > > Subject: Re: Build.xml standardization > > > > > > "Morrison, John" wrote: > > > > > > > > I've extended the build.xml file so that if install.dir > > > > _isn't_ defined then > > > > > the system displays a 'can't do' message. What do people think? > > > > > > > > I think a project should define a default install dir that > > > > can be overridden > > > > by the user's .ant.properties file. > > > > > > I was thinking more for the projects which don't install. > > The mods I made > > > to the build.xml file mean that, if a install.dir isn't > > defined *anywhere* > > > (note it's still in there, just commented out), the > > build.xml already has > > > the functionality to say the project can't do an (un)installation. > > > > > > <shrug/> I thought it was a good idea ;) > > > > > > Now that I have more information, I see where it might be > > useful. However, > > if a project does not support installs, then they should > > simply <echo/> a > > message saying something to the fact--regardless of whether > > ${install.dir} > > is set or not. > > > > But that's my oppinion.... > > That OK. I don't mind trying to change it - as long as you have an > open mind. How about a situation: > > I have a webapp which I want to distribute to lots of customers. I > don't know which servlet engine they are running or where it's installed. > > Until I *know* where it is located I *can't* install. Telling users that, > as part of installing the software they have to modify the build.properties > file and set install.dir seems quite reasonable...? That means that, when > the user _has_ set this property I *can* install the war file. > > What do you think?
Ah. Ok, that makes sense. +1. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
