Greetings, Hongbing,
I've spent the car ride home thinking about the hackyCore_Build.dist Ant
task that you've volunteered to work on, and I've a few ideas about how to
approach it.
The first thing to note is that in retrospect, the Version 6 distAll task
was a complete mess. What it basically did was zip together:
- the contents of each individual hackystat module
- the contents of the hackyBuild/build directory
- a hackystat-<config>-<version>.war file.
This could lead to _three_ copies of many jar files and libraries in a
single distribution, which is a big reason why these distribution zip files
got so ridiculously large. In Version 7, I think we can do a lot better.
The first thing I suggest is that we make a significant effort to avoid any
duplication of files in a Version 7 distribution zip file. I think we can
do that by making the following design decisions:
1. Distribution zip files are 'binary'. No source code is included in a
distribution zip file. If you really want source code, you have to (a) install
an svn
client, and (b) checkout svn://hackydev.ics.hawaii.edu/hackystat/trunk.
That doesn't seem too painful to me. (Indeed, we can supply an Ant task for
that along with a checkout.build.xml file, just like we did for CVS.)
2. The contents of a distribution zip file expands to the following:
hackyCore_Kernel/local.build.xml
hackyCore_Report/local.build.xml
:
hackyCore_Build/**
In other words, apart from the hackyCore_Build subdirectory, every other
module directory in a distribution contains only a single file: its
local.build.xml.
3. No pre-built .war file in the distribution .zip file. In a version 7
distribution, the hackyCore_Build directory should not contain a war file,
which after all is just a duplicate of the build/war directory in that
distribution. I believe that one improvement in Tomcat 5 is that
"hot" deploys are now persistent across webserver startups. This means we
may not have to physically copy a .war file into the tomcat/webapps
directory, and thus we can deploy a distribution using the same hot deploy
method we use for development purposes.
(I'm not sure whether we will run into a soap deployment issue with this
method. If it turns out we need to create the .war file, then we should zip
up the build/war file and copy it over to the tomcat/webapps directory as
part of an install task--not as part of creating the .zip file. This will
cut down the size of our distribution .zip file substantially, albeit at
the added cost of an additional <zip> invocation as part of installation.)
4. The JUnit tasks in all local.build.xml files need to be altered to not
reference _anything_ outside of the hackyCore_Build directory. This is
because all of the regular hackystat modules contain nothing other than
their local.build.xml file in a distribution. This is the tricky part, and
will take a little work. There are at least a couple of modifications that
will need to be made to all of the <module>.junit tasks:
a. The identification of the Test classes will need to be made by looking
at a subdirectory tree of hackyCore_Build/build/war/WEB-INF/classes/. For
example, hackyCore_Kernel will need to obtain its Test classes by looking
for
hackyCore_Build/build/war/WEB-INF/classes/org/hackystat/core/kernel/**/Test*.class.
b. Any external references (using <classpath.elements>,
<sysproperty.elements>, or <fileset.elements> must refer to objects
available in the distribution (i.e. in hackyCore_Build). So, if there's a
jar file you're using in your JUnit tests, you need to make sure that the
jar file is in the hackyCore_Build directory someplace. Copy it over before
invoking JUnit.
That's all I can think of at the moment. Let me know if you see any
problems with this.
Cheers,
Philip
