build.xml & build.properties best practices

[Adam Hardy <ad...@cyberspaceroad.com>]

Hi All,

I am using ant for several different java projects:

- often using completely different 3rd party jar like JAXB or struts or 
cachedRowset
- sometimes with tomcat, sometimes with weblogic, occasionally just java
- some are web apps, one is EJB, one is Swing.

I am always editing my build.xml and I often think I am not making best 
use of build.properties.

Should I write a build.xml file which takes a build.properties that will:

- allow me to specify just one variable in the build.properties to 
switch appserver such as appserver.name=${weblogic}

- let me say which external jars I want to include in the classpath, 
deploy and dist targets, for instance 
external.jars=${struts.jar}:${rowset.jar}:

Would this be a sensible use of time or should I just carry on hacking 
my build.xml, or is there an optimum in between?

TIA for any comments!

Adam

Re: build.xml & build.properties best practices

[Adam Hardy <ad...@cyberspaceroad.com>]

mmay@gmx.net wrote:
> - userhome\build.properties
> - projectroot\project\project.properties
> - projectroot\global.properties
> 
> This is how we made a very easy way on how to use ant. I am currently
> waiting to get 1.5.2 because there you can include targets from another file and
> overwrite them in the build.xml specific to your project.
> 

That sounds like a neatly structured approach. I'll try it out, thanks.

Re: build.xml & build.properties best practices

[webhiker <we...@tiscali.fr>]

Could you tell me if you found a less ridiculous (cryptic) way to 
factorise your tasks into a common include file
other than the wonderfully "only it's mother could love it" syntax such as :

<?xml version="1.0"?>

<!DOCTYPE DOCUMENT [<!ENTITY include SYSTEM "file:../common.xml">]>

<project name="toto" default="usage" basedir="." >

&include;

.....


WH

>Hello Adam,
>I just can explain how we have structured our build process.
>We have basically the Project Root Directory beneath which all our projects
>are stored. In this directory, we have central includes, which can be
>included by all our build scripts. On top of this there is a global.properties file,
>where e.g. Directories for our JBoss Installation and the Webserver are
>stored in properties. 
>In each project we have a build.xml file, which includes the common targets
>and properties, and also defines some project specific targets and properties
>(e.g. the classpath). Also we are using a project.properties here, where for
>example the name of the project is defined. These properties should never be
>overwritten.
>Last but not least we have a build.properties stored in the userhome
>directory, where each developer can store properties specific for him (e.g.
>debug=on, ...). The property files get read in the following order:
>- userhome\build.properties
>- projectroot\project\project.properties
>- projectroot\global.properties
>
>This is how we made a very easy way on how to use ant. I am currently
>waiting to get 1.5.2 because there you can include targets from another file and
>overwrite them in the build.xml specific to your project.
>
>Greets
>
>Markus M. May
>
>  
>

Re: build.xml & build.properties best practices

[mm...@gmx.net]

Hello Adam,
I just can explain how we have structured our build process.
We have basically the Project Root Directory beneath which all our projects
are stored. In this directory, we have central includes, which can be
included by all our build scripts. On top of this there is a global.properties file,
where e.g. Directories for our JBoss Installation and the Webserver are
stored in properties. 
In each project we have a build.xml file, which includes the common targets
and properties, and also defines some project specific targets and properties
(e.g. the classpath). Also we are using a project.properties here, where for
example the name of the project is defined. These properties should never be
overwritten.
Last but not least we have a build.properties stored in the userhome
directory, where each developer can store properties specific for him (e.g.
debug=on, ...). The property files get read in the following order:
- userhome\build.properties
- projectroot\project\project.properties
- projectroot\global.properties

This is how we made a very easy way on how to use ant. I am currently
waiting to get 1.5.2 because there you can include targets from another file and
overwrite them in the build.xml specific to your project.

Greets

Markus M. May

> Hi All,
> 
> I am using ant for several different java projects:
> 
> - often using completely different 3rd party jar like JAXB or struts or 
> cachedRowset
> - sometimes with tomcat, sometimes with weblogic, occasionally just java
> - some are web apps, one is EJB, one is Swing.
> 
> I am always editing my build.xml and I often think I am not making best 
> use of build.properties.
> 
> Should I write a build.xml file which takes a build.properties that will:
> 
> - allow me to specify just one variable in the build.properties to 
> switch appserver such as appserver.name=${weblogic}
> 
> - let me say which external jars I want to include in the classpath, 
> deploy and dist targets, for instance 
> external.jars=${struts.jar}:${rowset.jar}:
> 
> Would this be a sensible use of time or should I just carry on hacking 
> my build.xml, or is there an optimum in between?
> 
> TIA for any comments!
> 
> Adam
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-user-help@jakarta.apache.org
> 

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!