You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Jeremy Mawson <je...@qsipayments.com> on 2000/08/09 15:24:13 UTC
Including other antfiles
In my original MAKE project I have the following pattern:
INCBUILDMAKEFILES = X Y Z
include $(INCBUILDMAKEFILES)
TargetA: TargetX.A TargetZ.B
Where the dependencies of TargetA do not exist in the same make file, but
in one of the included files.
One way I might translate this to Ant is:
<target name="TargetA">
<ant antfile="X"
dir=" ... "
target="TargetX.B" />
<ant antfile="Z"
dir=" ... "
target="TargetZ.B" />
...
</target>
My questions:
Is this the best way?
Is this the only way?
Am I missing something obvious?
Is there some way to call an "include" to include the targets of another
ant file?
Jem
=========================================
Jeremy Mawson
E-Commerce Consultant
QSI Payments, Inc
Phone (07) +617 3224 9886
Fax (07) +617 3210 2566
Email Jeremy.Mawson@qsipayments.com
URL http://www.qsipayments.com/
This message or any part of it is intended solely for the named addressee
and contains privileged and confidential information. If you receive this
message in error please notify QSI Payments, Inc by replying to the sender
and removing the message from your computer.
Re: Including other antfiles
Posted by Peter Donald <do...@mad.scientist.com>.
At 10:12 10/8/00 -0700, you wrote:
>This is what I am trying to avoid. I gave an example of this: all rules has
>to be propagated from the project build file to the template file. My rules
>are really simple but yet Ant makes it a nightmare and complicated.
>
>I don't understand why ant is not being designed for this. People make the
>argument that ant is not make. Well, true. However, I'm pointing out the
>most common use and Ant makes it really difficult to use. Don't we want to
>attract more people to use it?
I agree that maintaining a 100 sub-projects is bound to be a nightmare.
Many cases it is no longer necessary to have all sub-projects anymore.
Anyone whos uses ant in the same way they use make (ie with a build.xml per
directory) is bound to run in to troubles.
We could make ant capable of doing all this templating stuff - but we would
loose it's simplicity and eventually it would become make in java + xml. A
BAD thing. Make is extremely painful to read compared to ant, you have to
be familiar with a lot of things if you read my make files. However my top
make files are extremely simple -
###########################################################################
# Java libraries
###########################################################################
JAVA.DESCRIPTION = Java libraries
JAVA.DEPEND =
JAVA.JAVA = $(wildcard $(JAVADIR)/*/*.java
$(JAVADIR)/*/*/*.java $(
JAVADIR)/*/*/*/*.java )
JAVA.CLASSPATH.EXTRA =
/usr/local/jars/xerces.jar:/usr/local/bml-2.4/lib/bmlal
l.jar:/home/donaldp/junit/test.jar:/home/donaldp/log4j/log4j-v0.8.4d/log4j.jar
###########################################################################
# Scripting Support library
###########################################################################
SCRIPT.TYPE = exe
SCRIPT.NAME = script
SCRIPT.DESCRIPTION = Scripting Support library
SCRIPT.DEPEND =
SCRIPT.DEFINES = -DSCRIPTAPI=EXPORT
SCRIPT.SRC = $(wildcard $(SRCDIR)/script/*.cpp )
###########################################################################
# Cross Platform library
###########################################################################
XP.NAME = xp
XP.DESCRIPTION = Cross Platform Services
XP.DEPEND =
XP.DEFINES = -DXPAPI=EXPORT
XP.SRC = $(wildcard $(SRCDIR)/sys/$(OS)/xp*.cpp )
XP.LIB.EXTRA = $(LIB.XPSHLIB)
###########################################################################
# Standard Debugging library
###########################################################################
STDDBG.NAME = stddbg
STDDBG.DESCRIPTION = Standard Debugging library
STDDBG.DEPEND = $(XP.NAME)
STDDBG.DEFINES = -DDBGAPI=EXPORT
STDDBG.SRC = $(wildcard $(SRCDIR)/dbg/*.cpp )
etc ....
As long as someone using my makefiles doen't have to change rules then they
are right - if however they do need to make changes they got no chance.
I would love to see a tool built on top of ant that did transforming. This
hasn't happened thou so feel free to do it. It will never happen inside ant
but on top of it is another issue :P
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Including other antfiles
Posted by Dino Valente <di...@3dstockcharts.com>.
At 11:13 AM 8/10/00 +0930, you wrote:
[stuff deleted]
>
>I can't speak for the commiters or ant, this is what I have surmaised
>over a few weeks on being on the list.
>
>The separation of the rules to the use of rules is one of the
>confusing aspects of make. As a developer (and lets assume I dont
>know make) I write a makefile with some "magical" targets that are
>defined in the configuration management plan. These targets will
>compile, jar, clean etc my project automatically for me.
>
>If I need to do something a different from the magical targets I need
>to make modifications myself but I need to override the magical
>targets and now I need to know how make works in order to do so.
>
>In Ant I have all my targets and tasks in the build file. It does
>mean that you can end up with a large build file if you are doing
>complex things. But since there is a file for each project I can make
>changes to my specific file and I know I wont break other existing
>projects.
You can argue the same about OO libraries usage. If I copy code instead of
reusing code then you are reducing dependencies. But we know as developers,
this is a maintainence nightmare.
>
>Remember that you only have 20 projects. So you really only need to
>set up Ant for one project, parameterize the file so its easy to make
>changes, and copy to 19 other projects. You can then use this "Ant
>Template" for any new projects that start. It starts to become a
>maintenance nightmare if you need to make the same change to all the
>build files.
This is what I am trying to avoid. I gave an example of this: all rules has
to be propagated from the project build file to the template file. My rules
are really simple but yet Ant makes it a nightmare and complicated.
I don't understand why ant is not being designed for this. People make the
argument that ant is not make. Well, true. However, I'm pointing out the
most common use and Ant makes it really difficult to use. Don't we want to
attract more people to use it?
dino
Re: Including other antfiles
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "gb" == gt bradley <gt...@linkline.com> writes:
gb> Sooo.... when is the next version expected? (rough guess anyway)
months away - for a very rough guess.
Some new concepts have been introduced in the current CVS version that
need to be used consistently, the current behavior of properties and
${} replacements should change, optional tasks should be handled
differently ...
Still a lot of work to do.
Stefan
Re: Including other antfiles
Posted by gt bradley <gt...@linkline.com>.
Peter Donald wrote:
> At 06:00 10/8/00 -0700, you wrote:
> ><!DOCTYPE project [
> > <!ENTITY common SYSTEM "build.template">
> >]>
> >
> >I may have used the word "complex" incorrectly. The scenerio I described is
> >straight forward and is not complex rules wize. I suppose I could add an
> >include task and pre process the xml build file first to insert the
> >included file. Everyone knows what includes mean. There is no confusion
> >about this. I have no doubt that this issue will be raised again and again
> >because it is the first things developers encounter when they have more
> >than one project.
>
> okay - I don't seen any problem with that - I will pass it on to dev list
>
> >However, I'm still not convinced that the property values should be set
> >once (this is one aspect of ant that is not intuitive and people will keep
> >asking this group the same question all the time).
>
> Will change in next revision. It will occur at interpretation time and not
> at parse time - so all your intuitive assumptions will work from next
> version onwards :P
Sooo....
when is the next version expected? (rough guess anyway)
GT
>
> Cheers,
>
> Pete
>
> *------------------------------------------------------*
> | "Nearly all men can stand adversity, but if you want |
> | to test a man's character, give him power." |
> | -Abraham Lincoln |
> *------------------------------------------------------*
Re: Including other antfiles
Posted by Peter Donald <do...@mad.scientist.com>.
At 06:00 10/8/00 -0700, you wrote:
><!DOCTYPE project [
> <!ENTITY common SYSTEM "build.template">
>]>
>
>I may have used the word "complex" incorrectly. The scenerio I described is
>straight forward and is not complex rules wize. I suppose I could add an
>include task and pre process the xml build file first to insert the
>included file. Everyone knows what includes mean. There is no confusion
>about this. I have no doubt that this issue will be raised again and again
>because it is the first things developers encounter when they have more
>than one project.
okay - I don't seen any problem with that - I will pass it on to dev list
>However, I'm still not convinced that the property values should be set
>once (this is one aspect of ant that is not intuitive and people will keep
>asking this group the same question all the time).
Will change in next revision. It will occur at interpretation time and not
at parse time - so all your intuitive assumptions will work from next
version onwards :P
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Including other antfiles
Posted by Dino Valente <di...@3dstockcharts.com>.
At 10:28 AM 8/11/00 +1000, you wrote:
>At 10:17 10/8/00 -0700, you wrote:
>>
>>At 11:52 AM 8/10/00 +1000, you wrote:
>>>Feel free to make meta-Ant if thats what you want. A lot of other people
>>>want it aswell. Ant however is not the place for it.
>>
>>Why is that? We don't want Ant to be used for complex projects or multi
>>projects. It seems (to me at least) that ant is ideal for doing complex
>>java projects and flushing out the design properly will achieve this
>>without a problem.
>
>Ant can only cater to "complex" projects by including complex rules. Start
>adding rules and where would you stop ? You wouldn't stop - you would end
>up with make or worse yet another perl. ick !
>
>Ant is meant to be simple and readable by anyone. That was it's design
>goal. I see the need for extended version of Ant that includes templates
>and abstract rules but including this in base ant would lead to Ant being
>hard to read and non-simple. Hence It is better to keep this other
>functionality in another tool that expands on Ant. The best ideas so far
>have been to use XSLT to transform a simpler xml file to build.xml.
>Everyone complains it is not there but as far as I know no one has actually
>started to make it.
I would be happy if ant allowed the ability to include other ant xml files
and nothing else.
The following allowed for this but doesn't work when it is executed outside
the same directory as the build file since the relative directory gets
messed up (since java doesn't really support changing the current working
directory properly; I could be wrong):
<!DOCTYPE project [
<!ENTITY common SYSTEM "build.template">
]>
I may have used the word "complex" incorrectly. The scenerio I described is
straight forward and is not complex rules wize. I suppose I could add an
include task and pre process the xml build file first to insert the
included file. Everyone knows what includes mean. There is no confusion
about this. I have no doubt that this issue will be raised again and again
because it is the first things developers encounter when they have more
than one project.
However, I'm still not convinced that the property values should be set
once (this is one aspect of ant that is not intuitive and people will keep
asking this group the same question all the time).
dino
Re: Including other antfiles
Posted by Peter Donald <do...@mad.scientist.com>.
At 10:17 10/8/00 -0700, you wrote:
>
>At 11:52 AM 8/10/00 +1000, you wrote:
>>Feel free to make meta-Ant if thats what you want. A lot of other people
>>want it aswell. Ant however is not the place for it.
>
>Why is that? We don't want Ant to be used for complex projects or multi
>projects. It seems (to me at least) that ant is ideal for doing complex
>java projects and flushing out the design properly will achieve this
>without a problem.
Ant can only cater to "complex" projects by including complex rules. Start
adding rules and where would you stop ? You wouldn't stop - you would end
up with make or worse yet another perl. ick !
Ant is meant to be simple and readable by anyone. That was it's design
goal. I see the need for extended version of Ant that includes templates
and abstract rules but including this in base ant would lead to Ant being
hard to read and non-simple. Hence It is better to keep this other
functionality in another tool that expands on Ant. The best ideas so far
have been to use XSLT to transform a simpler xml file to build.xml.
Everyone complains it is not there but as far as I know no one has actually
started to make it.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Including other antfiles
Posted by Dino Valente <di...@3dstockcharts.com>.
At 11:52 AM 8/10/00 +1000, you wrote:
>Feel free to make meta-Ant if thats what you want. A lot of other people
>want it aswell. Ant however is not the place for it.
Why is that? We don't want Ant to be used for complex projects or multi
projects. It seems (to me at least) that ant is ideal for doing complex
java projects and flushing out the design properly will achieve this
without a problem.
dino
Re: Including other antfiles
Posted by Peter Donald <do...@mad.scientist.com>.
Feel free to make meta-Ant if thats what you want. A lot of other people
want it aswell. Ant however is not the place for it.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Including other antfiles
Posted by Barrie Treloar <Ba...@camtech.com.au>.
On Wed, 9 Aug 2000, Dino Valente wrote:
> >Where the dependencies of TargetA do not exist in the same make file, but
> >in one of the included files.
[del]
> This ability to include other ant files is really crucial in order for me
> to use ant. Othersize, I will be typing in the same stuff for all my
> projects (I have 20 projects). People have suggested to use the following
> method:
>
> <project name="fooproject" basedir=".">
> <ant antfile="X" dir=" ... " target="TargetX.B">
> <property name="name" value="foo" />
> </ant>
> </project>
>
> where X is the general file. This doesn't work for me since you would have
> to define all the rules again the build file and propagate the action to
> the general build file (e.g I have separate rules for building the jar
> file, cleaning the .class files and generating javadocs). Maintanence is a
> nightmare.
>
> Ant is a very good product. I was hooked. However, I was very disappointed
> on its ability to not handle complex projects. Basically, I wanted the
> ability build each project separately and the ability to build all my
> projects in an efficient way. With make, it is a no brainer except for
> compiling java files. This is why I like ant so much is that it takes care
> of this aspect for me. I was also disappointed on how Ant handles property
> values (you can only set it once and can never override them). I'm still
> hoping someone will post an example that will convince me that Ant is the
> answer to my problem (so far no one has).
I can't speak for the commiters or ant, this is what I have surmaised
over a few weeks on being on the list.
The separation of the rules to the use of rules is one of the
confusing aspects of make. As a developer (and lets assume I dont
know make) I write a makefile with some "magical" targets that are
defined in the configuration management plan. These targets will
compile, jar, clean etc my project automatically for me.
If I need to do something a different from the magical targets I need
to make modifications myself but I need to override the magical
targets and now I need to know how make works in order to do so.
In Ant I have all my targets and tasks in the build file. It does
mean that you can end up with a large build file if you are doing
complex things. But since there is a file for each project I can make
changes to my specific file and I know I wont break other existing
projects.
Remember that you only have 20 projects. So you really only need to
set up Ant for one project, parameterize the file so its easy to make
changes, and copy to 19 other projects. You can then use this "Ant
Template" for any new projects that start. It starts to become a
maintenance nightmare if you need to make the same change to all the
build files.
You need to ask this question:
"Does the effort of creating a shared template file outweigh
the time it takes to make the modifications to a copy?"
Unfortunately the answer in most case is no.
Which is a shame, sometimes automatiting causes more work than it
saves.
Barrie
--
Barrie Treloar
____________________________________________________________________
Barrie Treloar Phone: +61 8 8303 3300
Senior Analyst/Programmer Fax: +61 8 8303 4403
Electronic Commerce Division Email: barrie@camtech.com.au
Camtech (SA) Pty Ltd http://www.camtech.com.au
--- Level 8, 10 Pulteney Street, Adelaide SA 5000, Australia. ---
____________________________________________________________________
Re: Including other antfiles
Posted by Dino Valente <di...@3dstockcharts.com>.
At 01:24 PM 8/9/00, you wrote:
>In my original MAKE project I have the following pattern:
>
> INCBUILDMAKEFILES = X Y Z
> include $(INCBUILDMAKEFILES)
>
> TargetA: TargetX.A TargetZ.B
>
>Where the dependencies of TargetA do not exist in the same make file, but
>in one of the included files.
>
>One way I might translate this to Ant is:
>
> <target name="TargetA">
> <ant antfile="X"
> dir=" ... "
> target="TargetX.B" />
>
> <ant antfile="Z"
> dir=" ... "
> target="TargetZ.B" />
>
> ...
>
> </target>
>
>My questions:
>
>Is this the best way?
>Is this the only way?
>Am I missing something obvious?
>Is there some way to call an "include" to include the targets of another
>ant file?
>
This is the response I got for the last question (which I think is the most
important).
==========================================
You can do this using XML entities. Here's a simple example:
===========
build.xml
===========
<?xml version="1.0"?>
<!DOCTYPE project [
<!ENTITY usage SYSTEM "usage.ent">
<!ENTITY zip SYSTEM "zip.ent">
<!ENTITY compile SYSTEM "compile.ent">
<!ENTITY dist SYSTEM "dist.ent">
<!ENTITY test SYSTEM "test.ent">
]>
<project name="mypackage" default="main" basedir=".">
<!-- Usage -->
&usage;
<!-- Zip Targets -->
&zip;
<!-- Compile Targets -->
&compile;
<!-- Distribution Targets -->
&dist;
<!-- Test Targets -->
&test;
</project>
Then, you build each of your ".ent" (.ent is just a convention...it can be
anything) files:
=============
compile.ent
=============
<target name="compile">
<javac .../>
</target>
=================================================
Depending on the parser the line
<!ENTITY usage SYSTEM "usage.ent">
should be replaced with
<!ENTITY usage SYSTEM "file:usage.ent">
This solution is ok when the file is relative to the build file and you
execute the ant application in that directory. However, if you have a build
file in the parent directory (which basically goes through subdirectories
to call build) then it doesn't work since the current working directory is
taken from the parent directory for the <!ENTITY usage SYSTEM "usage.ent">
line. The only way to get around this is to use absolute paths (which is
unacceptable for development at my company).
This ability to include other ant files is really crucial in order for me
to use ant. Othersize, I will be typing in the same stuff for all my
projects (I have 20 projects). People have suggested to use the following
method:
<project name="fooproject" basedir=".">
<ant antfile="X" dir=" ... " target="TargetX.B">
<property name="name" value="foo" />
</ant>
</project>
where X is the general file. This doesn't work for me since you would have
to define all the rules again the build file and propagate the action to
the general build file (e.g I have separate rules for building the jar
file, cleaning the .class files and generating javadocs). Maintanence is a
nightmare.
Ant is a very good product. I was hooked. However, I was very disappointed
on its ability to not handle complex projects. Basically, I wanted the
ability build each project separately and the ability to build all my
projects in an efficient way. With make, it is a no brainer except for
compiling java files. This is why I like ant so much is that it takes care
of this aspect for me. I was also disappointed on how Ant handles property
values (you can only set it once and can never override them). I'm still
hoping someone will post an example that will convince me that Ant is the
answer to my problem (so far no one has).
dino