You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/10/10 04:42:46 UTC

.ant.properties

Hi,

I just got a few complaints that .ant.properties is kinda an ugly construct 
when stored in project directory because it gets hidden. So I propose we 
rename this to ./ant.properties but we still keep the one in home directory 
with . in front of it (ie ~/.ant.properties).

-- 
Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |
*------------------------------------------------------*

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Re: .ant.properties

Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> 
> On Wed, 10 Oct 2001 21:18, Jeff Turner wrote:
> > On Wed, Oct 10, 2001 at 12:42:46PM +1000, Peter Donald wrote:
> > > Hi,
> > >
> > > I just got a few complaints that .ant.properties is kinda an ugly
> > > construct when stored in project directory because it gets hidden. So I
> > > propose we rename this to ./ant.properties but we still keep the one in
> > > home directory with . in front of it (ie ~/.ant.properties).
> >
> > build.properties perhaps?
> >
> > It's as near to a standard as there is,
> 
> you sure? That convention was birthed when commons was created if I am not
> mistaken. Besides commons I haven't really seen it used elsewhere. Most
> projects I know still use ant.properties because thats the way that the ant
> build file works (and it's also the way the ant-dev used to always recomend).

Actually, on the Alexandria dev list where we finally got around to discussing
my proposal on build.xml standardization, the "build.properties" was the final
verdict.  The .* files are perfect for the user directory, and that still stands.
There is still some things being discussed along the lines of "do we want all
properties to be defined in build.properties" or "just document them".  So far
the current consensus is to document the standard properties in build.properties
but not define them there.

> > and it implies a nice rule that
> > "<whatever>.xml" has properties file "<whatever>.properties". So
> > build-docs.xml and build-docs.properties are obviously associated.
> 
> Perhaps. However I guess I don't see that as desirable ;) If I have 3 build
> files in a directory that would mean I could potentially have 3 different
> property files all containing the same thing. eek ! ;)

Again, the current consensus on the properties file (only one [1] file)
is that it documents the standard properties that can be overridden.  It is
one file named "build.properties", not one for _every_ build script.

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Re: .ant.properties

Posted by Jeff Turner <je...@socialchange.net.au>.
On Wed, Oct 10, 2001 at 09:57:32PM +1000, Peter Donald wrote:
> On Wed, 10 Oct 2001 21:18, Jeff Turner wrote:
> > On Wed, Oct 10, 2001 at 12:42:46PM +1000, Peter Donald wrote:
> > > Hi,
> > >
> > > I just got a few complaints that .ant.properties is kinda an ugly
> > > construct when stored in project directory because it gets hidden. So I
> > > propose we rename this to ./ant.properties but we still keep the one in
> > > home directory with . in front of it (ie ~/.ant.properties).
> >
> > build.properties perhaps?
> >
> > It's as near to a standard as there is, 
> 
> you sure? That convention was birthed when commons was created if I am not 
> mistaken. Besides commons I haven't really seen it used elsewhere. Most 
> projects I know still use ant.properties because thats the way that the ant 
> build file works (and it's also the way the ant-dev used to always recomend).

According to 'slocate', the following Jakarta projects use build.properties:

commons
struts
taglibs
tomcat
regexp
watchdog
turbine

Apart from Avalon and friends, the only Jakarta project using .ant.properties
is Ant itself. There are some non-Jakarta projects, like xerces and jython.

> > and it implies a nice rule that
> > "<whatever>.xml" has properties file "<whatever>.properties". So
> > build-docs.xml and build-docs.properties are obviously associated.
> 
> Perhaps. However I guess I don't see that as desirable ;) If I have 3 build 
> files in a directory that would mean I could potentially have 3 different 
> property files all containing the same thing. eek ! ;)

The implied rule only becomes evident if it's exploited:

build.xml
build.properties
build-docs.xml
build-docs.properties

If you only have one build.properties and multiple *.xml files, there's no
indication that there's a 'broken pattern', and you're in the same situation as
.ant.properties.

--Jeff
(who doesn't mind, really.. running +P mode;)

> -- 
> Cheers,
> 
> Pete
> 
> ----------------------------------------
> Whatever you do will be insignificant, 
> but it is very important that you do it. 
>                               --Gandhi
> ----------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Re: .ant.properties

Posted by Peter Donald <do...@apache.org>.
On Wed, 10 Oct 2001 21:18, Jeff Turner wrote:
> On Wed, Oct 10, 2001 at 12:42:46PM +1000, Peter Donald wrote:
> > Hi,
> >
> > I just got a few complaints that .ant.properties is kinda an ugly
> > construct when stored in project directory because it gets hidden. So I
> > propose we rename this to ./ant.properties but we still keep the one in
> > home directory with . in front of it (ie ~/.ant.properties).
>
> build.properties perhaps?
>
> It's as near to a standard as there is, 

you sure? That convention was birthed when commons was created if I am not 
mistaken. Besides commons I haven't really seen it used elsewhere. Most 
projects I know still use ant.properties because thats the way that the ant 
build file works (and it's also the way the ant-dev used to always recomend).

> and it implies a nice rule that
> "<whatever>.xml" has properties file "<whatever>.properties". So
> build-docs.xml and build-docs.properties are obviously associated.

Perhaps. However I guess I don't see that as desirable ;) If I have 3 build 
files in a directory that would mean I could potentially have 3 different 
property files all containing the same thing. eek ! ;)

-- 
Cheers,

Pete

----------------------------------------
Whatever you do will be insignificant, 
but it is very important that you do it. 
                              --Gandhi
----------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Re: .ant.properties

Posted by Jeff Turner <je...@socialchange.net.au>.
On Wed, Oct 10, 2001 at 12:42:46PM +1000, Peter Donald wrote:
> Hi,
> 
> I just got a few complaints that .ant.properties is kinda an ugly construct 
> when stored in project directory because it gets hidden. So I propose we 
> rename this to ./ant.properties but we still keep the one in home directory 
> with . in front of it (ie ~/.ant.properties).

build.properties perhaps? 

It's as near to a standard as there is, and it implies a nice rule that
"<whatever>.xml" has properties file "<whatever>.properties". So
build-docs.xml and build-docs.properties are obviously associated.

--Jeff

> -- 
> Cheers,
> 
> Pete

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org