1. Home
  2. Categories
  3. Side Bar WTF
  4. Which comes first? Chicken? Egg? Ham salad?

Which comes first? Chicken? Egg? Ham salad?

  • Z

    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 = ""
    
endif
    

    checking 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
    
endif
    

    cvs -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.

    0
  • morbiuswilters

    When using ant, I usually find myself asking "How can I make this more cumbersome?"

    Now I know.

    0
  • blakeyrat

    @zelmak said:

    # insure that project name and working dir path are passed via commandline

    Found the WTF! He totally meant "ensure" there.

    0
  • Z

    @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"
    0
  • boomzilla
    ♿ (Parody)

    @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"
    0
  • morbiuswilters

    @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"
    0
  • R

    Reminds me of the Breakfast Food Cooker parable:

    Link in case anyone misses the reference...

    http://www.ridgenet.net/~do_while/toaster.htm


    0
  • E

    @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).

    0
  • morbiuswilters

    @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?

    0
  • boomzilla
    ♿ (Parody)

    @morbiuswilters said:

    Aren't you technically just making Maven more cumbersome?

    Is that like making water more wet?

    0
Log in to reply