Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@jakarta.apache.org Received: (qmail 59502 invoked by uid 500); 16 Oct 2001 18:30:41 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: ant-user@jakarta.apache.org Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 59483 invoked from network); 16 Oct 2001 18:30:41 -0000 X-Server-Uuid: 6E802067-ECFC-4FC2-A617-DD5220DD9CBB Message-ID: <7382FCA44E27D411BD4A00508BD68F9501F83BE7@pigeon.tumbleweed.com> From: "Azariah Jeyakumar" To: "'ant-user@jakarta.apache.org'" Subject: RE: Including a common build file with common targets. Date: Tue, 16 Oct 2001 11:28:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 17D2A369444864-01-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15670.4CA54EF4" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15670.4CA54EF4 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit I forgot to address the question on how to include the common build file. We used relative paths. The common build file was in a specific place under the source tree and all build.xml files included this common file using paths like "../../config/build.config.xml". We tested this on both Windows NT and Solaris. Forward slash works on both using the standard XML parser that comes with ant. To my knowledge, there is no way to use an environment variable for the path of this common file. This include mechanism is like the C preprocessor's include. The include happens before any parsing of the xml takes place. This implies that ant properties cannot be used in the path. HTH Azariah -----Original Message----- From: Azariah Jeyakumar Sent: Tuesday, October 16, 2001 11:12 AM To: 'ant-user@jakarta.apache.org' Subject: RE: Including a common build file with common targets. Hi, We had a similar situation. We had only a partial solution which I will describe here: The targets are split into targets that do actual work and targets that are useful only for sequencing. For example, we had targets like: clean - cleans compile - compiles jar - jars docs - creates javadoc build - compile and jar rebuild - clean, compile, jar all - clean, compile, jar, docs The build, rebuild and all targets are sequencing targets. They are identical in all the build files, so they are defined in the common file. The targets that do the actual work also looked 'almost' identical but since they were slightly different in some build.xml files, they were defined in the individual build files. I guess some more improvising could have been done to further factor out common code. BTW, I believe that it is a common requirement to factor our common code especially in large projects where several people are working on it. I have seen suggestions like using build.properties file, but it can only factor out properties. We need to be able to factor out everything: filesets, targets, etc. Thanks Azariah -----Original Message----- From: Albertus Vermeulen [mailto:AlbertusV@meb.co.za] Sent: Tuesday, October 16, 2001 8:30 AM To: 'ant-user@jakarta.apache.org' Subject: RE: Including a common build file with common targets. Diane, Please excuse my ignorance if I don't quite understand all the power that Ant provides me. I'm not sure that I follow your comments exactly but I can explain to your why I thought that wouldn't quite work for me. The end effect I'm trying to achieve is as follows. In any project that a developer is coding one build.xml file should exist. I haven't mapped it yet to exactly what it should look like in ant but probably something like: .... include common file which defines all targets and rules for compiling idl,java,pcml (something specific in our environment), etc something to the effect of .... As I understand, by using as was suggested to me by Jerry Li, I would need to for each target (17 in total) have to do a replecation of the s defined in common.xml in the above build.xml. I would thus save on not having to expose the body of the target in the above file or the properties I need to achieve the completion of the target, but I would still add a lot of extra targets in the build.xml file. I also seemed to experience some difficulty in accessing properties declared in the build.xml file within the common.xml file. This could though just be a clear case of me not having RTFM'd enough yet. :) Am I wrong in my understanding of how can/should be used ? Is there some way in which I could achieve what I described above ? Thanks in advance Albertus -----Original Message----- From: Diane Holt [ mailto:holtdl@yahoo.com ] Sent: 16 October 2001 04:19 To: ant-user@jakarta.apache.org Subject: RE: Including a common build file with common targets. --- Albertus Vermeulen wrote: > Thanks for your input, your solution would mean less lines in the > build.xml files, but doesn't really provide me with the solution I'm > looking for. I'm really looking for an equavalent of include in > makefiles. In our development environment we have seperate components > that developers are working on. They all need to make the same targets, > but for their own projects. We currently maintain these "make" targets > in one file and this ensures that there is very little clutter in the > Makefiles of each developer. This can't be changed when we move to Ant. Can you explain a bit more why using the task won't work for you? I have a "common" target (eg.) for building parsers in my "main" build.xml file that lives at the top of the user's workspace (which can be anywhere). Building a parser in a sub-buildfile 's the common parser target, passing the properties it needs to use. That sounds like what you're looking to do, but maybe I'm missing something. Diane ===== (holtdl@yahoo.com) __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com ------_=_NextPart_001_01C15670.4CA54EF4 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: Including a common build file with common targets.
I forgot to address the question on how to include the common build file.
 
We used relative paths. The common build file was in a specific place under the source tree and all build.xml files included this common file using paths like "../../config/build.config.xml". We tested this on both Windows NT and Solaris. Forward slash works on both using the standard XML parser that comes with ant.
 
To my knowledge, there is no way to use an environment variable for the path of this common file. This include mechanism is like the C preprocessor's include. The include happens before any parsing of the xml takes place. This implies that ant properties cannot be used in the path.
 
HTH
Azariah
-----Original Message-----
From: Azariah Jeyakumar
Sent: Tuesday, October 16, 2001 11:12 AM
To: 'ant-user@jakarta.apache.org'
Subject: RE: Including a common build file with common targets.

Hi,
 
We had a similar situation. We had only a partial solution which I will describe here:
 
The targets are split into targets that do actual work and targets that are useful only for sequencing. For example, we had targets like:
 
clean - cleans
compile - compiles
jar - jars
docs - creates javadoc
build - compile and jar
rebuild - clean, compile, jar
all - clean, compile, jar, docs
 
The build, rebuild and all targets are sequencing targets. They are identical in all the build files, so they are defined in the common file. The targets that do the actual work also looked 'almost' identical but since they were slightly different in some build.xml files, they were defined in the individual build files. I guess some more improvising could have been done to further factor out common code.
 
BTW, I believe that it is a common requirement to factor our common code especially in large projects where several people are working on it. I have seen suggestions like using build.properties file, but it can only factor out properties. We need to be able to factor out everything: filesets, targets, etc.
 
Thanks
Azariah
-----Original Message-----
From: Albertus Vermeulen [mailto:AlbertusV@meb.co.za]
Sent: Tuesday, October 16, 2001 8:30 AM
To: 'ant-user@jakarta.apache.org'
Subject: RE: Including a common build file with common targets.

Diane,

Please excuse my ignorance if I don't quite understand all the power that Ant provides me. I'm not sure that I follow your comments exactly but I can explain to your why I thought that <ant> wouldn't quite work for me.

The end effect I'm trying to achieve is as follows. In any project that a developer is coding one build.xml file should exist. I haven't mapped it yet to exactly what it should look like in ant but probably something like:

<project name="QuoteSystem">
  <property environment="ENV"/>
  <property name="MODULE_VERSION" value="1.1.14"/

  <property name="MODULE_DEPENDENCIES" value="list of jars that this project depends on. Used to setup classpath. This is though not a full path, manipulation needs to happen in common.xml"/>

  .... include common file which defines all targets and rules for compiling
    idl,java,pcml (something specific in our environment), etc something to the effect of ....
  <include ${ENV.DEVELOP_HOME}/common.xml>
</project>

As I understand, by using <ant> as was suggested to me by Jerry Li, I would need to for each target (17 in total) have to do a replecation of the <target>s defined in common.xml in the above build.xml. I would thus save on not having to expose the body of the target in the above file or the properties I need to achieve the completion of the target, but I would still add a lot of extra targets in the build.xml file. I also seemed to experience some difficulty in accessing properties declared in the build.xml file within the common.xml file. This could though just be a clear case of me not having RTFM'd enough yet. :)

Am I wrong in my understanding of how <ant> can/should be used ? Is there some way in which I could achieve what I described above ?

Thanks in advance
Albertus

-----Original Message-----
From: Diane Holt [mailto:holtdl@yahoo.com]
Sent: 16 October 2001 04:19
To: ant-user@jakarta.apache.org
Subject: RE: Including a common build file with common targets.


--- Albertus Vermeulen <AlbertusV@meb.co.za> wrote:
> Thanks for your input, your solution would mean less lines in the
> build.xml files, but doesn't really provide me with the solution I'm
> looking for. I'm really looking for an equavalent of include in
> makefiles. In our development environment we have seperate components
> that developers are working on. They all need to make the same targets,
> but for their own projects. We currently maintain these "make" targets
> in one file and this ensures that there is very little clutter in the
> Makefiles of each developer. This can't be changed when we move to Ant.

Can you explain a bit more why using the <ant> task won't work for you? I
have a "common" target (eg.) for building parsers in my "main" build.xml
file that lives at the top of the user's workspace (which can be
anywhere). Building a parser in a sub-buildfile <ant>'s the common parser
target, passing the properties it needs to use.  That sounds like what
you're looking to do, but maybe I'm missing something.

Diane

=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

------_=_NextPart_001_01C15670.4CA54EF4--