Ah, his makes sense.
I did not get suggestions to solve my problem (see below).
Now speaking Ant pre1.2 (CVS version):
I plan to have a flat file 'configure', where developers enter their EJB
name and package (all required parameters). *This is the only file,
developers maintain*. And I generate my build.xml file using AWK:
I generate my top level build.xml file to include the new top level targets
EJB1, EJB2.. (read from my 'configure' file) and a target 'allEJBs'
depending on EJB1, EJB2, ...
I can set my parameters as <property .../> values in my toplevel EJBi
targets before calling ant again on my generic subproject build.xml.,
which does all the required EJB deployment steps.
Am I doing something completly stupid?
I just want one place where everything goes in: My 'configure' file. My awk
skript knows, how to build the build.xml syntax for EJBs, the Framework
(with all the different jar files to package) and so on.
Adding a new EJB would be just one line in my 'configure' file
Any comments?
[Hans Schmid]
Hello,
i am completely new to ant, so forgive me if, I have overlooked something
in the docs, or a similar question
has been discussed earlier.
I would like to port some Makefiles to Ant (currently 1.1) and would
appreciate any help or pointers to help
on the following topics:
Is it possible to pass parameters into targets?
like <target name="ejb" depends="compile,jetace,deploy"
parameterlist="name,package")
which would pass on two parameter. I would like to use them properties
<jar jarfile="./$(name).jar"
basedir="./classes"
includes="${package}/*.class"
/>
this would allow me to have a target similar to the Makefile.bean in my
makefile:
Makefile:
all: a b
a:
make -f Makefile.bean name=Ejb1 package=package1
b:
make -f Makefile.bean name=Ejb2 package=package2
and have only one Makefile.bean (resp. ant target) to be executed for
compiling, rmic, jar, deploying.
I tried to use properies, but they seem to be like global constants.
Any help or suggestions are highly appreciated.
Thanks,
-----Ursprungliche Nachricht-----
Von: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]
Gesendet am: Mittwoch, 16. August 2000 14:23
An: [EMAIL PROTECTED]
Betreff: RE: Cascading build.xml files
That's true in the 1.1 release, but in the CVS version, the property
subelements of the ant task will override any existing properties in both
the parent project and the subproject. Someone on the ant-user list (my
appologies for not remembering who) discovered this behaviour, and it was
verified in a fairly recent CVS version. So far, the consensus is to leave
this behaviour alone and not change it back to the 1.1 style, but there
really hasn't been much discussion.
Glenn McAllister
TID - Software Developer - VisualAge for Java
IBM Toronto Lab, (416) 448-3805
"An approximate answer to the right question is better than the
right answer to the wrong question." - John W. Tukey
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED]
Subject: RE: Cascading build.xml files
Looks good to me, but I would point out that the properties for the
subproject
are not conditional on the location in the file or target. What I've
discovered (I've setup something similar to what you describe in your file)
is that <property ... /> is processed before the targets no matter where in
the file. So unless you specify subproject unique properties they will get
ignored later on in the same file or in subprojects. Something to keep in
mind.
....
<target name="SubProject1" depends="prepare">
<ant antfile="${src.dir}/SubProject1/Build.xml"
target="SubProject1">
>>>> Get processed no matter what <<<<<
<!-- Property definitions here to pass to the subproject -->
</ant>
</target>
....
