Which comes first? Chicken? Egg? Ham salad?
-
The indirection/dependency hell ... it burns.
(1) .cshrc:
alias ant ant.csh
So, anytime I type 'ant' as a command, the shell replaces it with 'ant.csh'
(2) ant.csh:
#!/bin/csh -f if ( -e ./build.xml.properties ) then set ANT = "ant -propertyfile ./build.xml.properties -emacs " else set ANT = "ant -emacs " endif
if ( ${#argv} == 0 ) then
${ANT}
else if ( ${#argv} == 1 ) then
${ANT} ${1}
else if ( ${#argv} == 2 ) then
${ANT} -Dargument=${2} ${1}
endif
So, instead of learning to use the 'ant' command-line option to send a value to the build script, you can just add the extra value to the command line as a second argument.
(3) build.xml:
<target name="deploy" depends="package-all" if="argument"> <copy todir="${argument}"> <fileset dir="${dist}"> </copy> </target>
So, if I know what I'm doing with the ant.csh version of ant, I can choose my deploy directory with the second command-line argument. But wait, there's more here in the ant build script that uses 'argument':
<!-- Commit a change to the repository --> <target name="commit" depends="init" if="argument"> <cvs cvsRoot=${cvsRoot}"> <commandline> <argument value="commit"> <argument value="${argument}"> </commandline> </cvs> </target>
So, now I've been relieved of the burden of learning how to use cvs directly and can use the command
ant commit [filename]
instead of the more burdensome
cvs commit [filename]
Convenient. (Note: there is a non-filename specific version of the 'commit' target which commits from '.', not using the argument. There are also targets for 'log', 'delete', 'add', etc, so cvs is pretty much fully functional through these ant targets.)
What other goodies are in this build.xml file? Um ... wait ... what's this?
<!-- Checks out the project from the repository --> <target name="get" depends="init"> <cvs cvsRoot="${cvsRoot}"> <commandline> <argument value="checkout"> <argument value="-d"> <argument value="${basedir}"> <argument value="${project}"> </commandline> </cvs> </target>
So ... an ant target which checks out the code from the repository ... uh ... what? This build.xml ant script is IN the repostory! What on earth could use this?
(4) create_working_dir.csh
#!/bin/csh -f
script that establishes a developer's working directory
setenv CVSROOT /usr/local/cvsroot
insure that project name and working dir path are passed via commandline
if ( ${#argv} < 2 ) then
printf "Usage: $0 <project name> <working directory name> [<released id>]\n"else
set PROJECT_NAME=${1}
set WORK_DIR=${2}
set START_DIR=pwd
if ( ${#argv} == 3 ) then
set RELEASE_ID = ${3}
else
set RELEASE_ID = ""
endifchecking if directory exists
if ( -d ${WORK_DIR} ) then
# checking if the directory is empty
if ( (ls -l ${WORK_DIR} | wc -l
) > 1 ) then
printf "${WORK_DIR} is not empty, exiting.\n"
exit( -1 )
endif
endifcvs -d /usr/local/cvsroot get -d ${WORK_DIR} ${PROJECT_NAME}/build.xml
cd ${WORK_DIR}
if ( "${RELEASE_ID}" == "" ) then
ant get
else
ant get-release ${RELEASE_ID}
endif
ant scripts
endif
So, now I'm protected from cvs and certain portions of the ant build script.
But, what's this 'scripts' target that is being called at the end?
(5) build.xml (again)
<!-- Copy scripts to dist --> <target name="scripts" depends="init"> <echo message="Copying scripts"> <copy todir="${dist}/scripts"> <fileset dir="${scripts}"> </copy> </target>
So, there's an ant target to copy scripts around. And none of the other targets reference the 'scripts' target; the 'package-all' target repeats this functionality.
The structure of most projects is:
<project>/build.xml -- the ant build script <project>/src -- the source directory for code (usually Java) <project>/scripts -- the source directory for scripts <project>/doc -- the source directory for compiled help, also the target directory for javadoc creation <project>/resources -- various config files and such; runtime needs <project>/build -- build directory for the 'compile' target <project>/dist -- distribution 'staging' directory for 'jar' and 'package-all'
In order to use this environment in a developmental manner, we have to run the devel.csh script, which points major portions of the environment to 'here/dist' as the application home instead of the standard environment which points to the operational installation. This requires that the scripts inside of <project>/scripts to be copied to the <project>/dist/scripts directory to be found by this new environment.
Otherwise, you run production code pointed at the production database with the production configuration file(s).
tl;dr: So, in order to check out your code from the repo, you use a script which depends on the project's ant build script being able to check out its own code. So the checkout script first checks out the ant build script for the project. It then uses that build script to check out the rest of the project's source. But this depends on an ant 'wrapper' script which handles the extra command line options. Executing the wrapper script is dependent upon a c-shell alias which redirects ant to the wrapper script.
All this to keep me from having to learn
cvs co -Pd <working-dir> <project>
and
cp working-dir/scripts working-dir/dist/scripts
Fun, eh?
Note: I'm currently trying to unscrew this whole mess as the environment is completely inflexible. Pre-built classpaths in the environment are wiped and replaced with whatever the environment scripts and start scripts for the programs deem necessary. So, in order to change them, you have to change it in ./scripts and ensure the changes are copied to ./dist/scripts. But, some of THOSE scripts rely on environment scripts which exist solely in the production environment directories, which then undo what you've done in your dev environment.
-
When using ant, I usually find myself asking "How can I make this more cumbersome?"
Now I know.
-
@zelmak said:
# insure that project name and working dir path are passed via commandline
Found the WTF! He totally meant "ensure" there.
-
@blakeyrat said:
@zelmak said:
# insure that project name and working dir path are passed via commandline
Found the WTF! He totally meant "ensure" there.cvs commit -m "fixed mispelled word in comment"
-
@zelmak said:
@blakeyrat said:
@zelmak said:
# insure that project name and working dir path are passed via commandline
Found the WTF! He totally meant "ensure" there.cvs commit -m "fixed mispelled word in comment"
Surely you meant...
ant commit "fixed misspelled word in comment"
-
@boomzilla said:
@zelmak said:
@blakeyrat said:
@zelmak said:
# insure that project name and working dir path are passed via commandline
Found the WTF! He totally meant "ensure" there.cvs commit -m "fixed mispelled word in comment"
Surely you meant...
ant commit "fixed misspelled word in comment"
Surely you meant...
ant ci "fixed misspelled word in comment"
-
Reminds me of the Breakfast Food Cooker parable:
Link in case anyone misses the reference...
http://www.ridgenet.net/~do_while/toaster.htm
-
@morbiuswilters said:
When using ant, I usually find myself asking "How can I make this more cumbersome?"
Now I know.
You can add Maven into the mix and then call the ant script from within the Maven poms to do all the actual work. Fun fun.
(note: sometimes I use ANT tasks to do things Maven can't out of the box, its not by definition bad design).
-
@erikal said:
@morbiuswilters said:
When using ant, I usually find myself asking "How can I make this more cumbersome?"
Now I know.
You can add Maven into the mix and then call the ant script from within the Maven poms to do all the actual work. Fun fun.
(note: sometimes I use ANT tasks to do things Maven can't out of the box, its not by definition bad design).
Aren't you technically just making Maven more cumbersome?
-
@morbiuswilters said:
Aren't you technically just making Maven more cumbersome?
Is that like making water more wet?