Hi all,
I've created a new build.xml for HttpAsync. Here are the general ideas.
There are several logical groups of source files. In HttpAsync, these
are "src/java" (main classes), "src/test" (test classes), "src/contrib"
(contributions) and "src/examples" (examples). In other components,
there may be more. For example, HttpCore may split "src/java" in two,
one which is 1.3 compatible and one for NIO. HttpCore may also split
"src/contrib" in two, one that does depend on the Spring framework
and one that doesn't. You get the idea.
For each logical group of source files, there are two targets:
one compiles source files that have changed, the other one removes the
compilation result. If you want to force recompilation, you can execute
the clean target followed by the compilation target. There is also a
target that combines all logical groups. In HttpAsync, the targets
for the logical groups are:
compile-src clean-src
compile-tests clean-tests
compile-examples clean-examples
compile-contrib clean-contrib
compile-all clean-compile
The targets for the logical groups do NOT define dependencies.
That's because I've had problems with unwanted dependencies before.
If you start from scratch and want to compile the examples, you
have to compile the main src first. But that's not a big deal,
as there are more comfortable targets to use anyway.
HttpAsync can assemble two JARs, one for the main classes and one
for the examples and contributions. These do define dependencies.
There are two targets for each of these JARs, one that compiles
only the modified classes and one that enforces recompilation of
all classes. The latter has a suffix -fs, meaning "from scratch".
package-src package-src-fs
package-addon package-addon-fs
The default target is "package-src". In the old build, it was
"compile". But I've always considered JARs to be build results
and compiled classes to be intermediate, temporary files :-)
There are targets to execute unit tests and to run Clover.
These do define dependencies. For running unit tests, there are
two targets, one that compiles only the modified classes and one
that enforces recompilation of all classes. For Clover there is
only one target that always enforces recompilation, since the
source needs to be instrumented for this specific occasion.
run-tests run-tests-fs
run-clover
A findbugs target is still missing. I've never used findbugs
before and I thought learning Clover was enough for today :-)
There are two JavaDoc targets, one for only the "src/java"
classes and one that additionally includes the examples and
contributions. JavaDoc does not depend on compiling anymore.
javadoc-src
javadoc-addon (including src)
I've added groups to the JavaDocs to separate API classes,
implementation classes, examples, and contributions.
There are some more targets for cleanup:
clean-build - removes ${build.home}
clean-dist - removes ${dist.home}
clean-docs - removes ${dist.docs}
clean-api - removes ${dist.api} (JavaDocs)
And there is a target echo-properties which only prints some
important Ant properties. That comes in handy if you are defining
your local build.properties and want to be sure that the values
are picked up correctly by Ant.
To ease the migration, there is a set of traditional targets:
compile, package, javadoc, test, clover, clean
I've made some changes to the property names used internally,
please have a look at the build file if you want to review them.
The local build properties no longer have a search path as before.
The properties are read from only one file. The default location
is in ../project/build.properties, but can be overridden when
Ant is called:
> ant -Dlocal.properties=/home/rolandw/http/build.properties
I've changed the default version to "SNAPSHOT", without an
additional version number. The version numbers are already in
too many places for my liking. I'm thinking about letting
Maven call Ant for building in the future, in which case it
would simply override that property to the correct value.
There are some differences to the build files I write at work.
The biggest is that I don't have separate compilation and
packaging targets there. But I've kept that distinction from
the old build process and Maven. As mentioned above, I am
thinking about letting Maven call Ant, and then we'll need
those steps separately.
Another difference is that at work, I'm generating a timestamp
file that has the build time in it's name. That file is
packaged into every JAR below META-INF, so that "jar tf" will
give access to the timestamp. If the project has a versioning
scheme, the version is also in the filename. If you like the
idea, I'll add it here too.
So, that's it for today. Please let me know what you think.
If we can finish the reviews this week, I would spend some
time next weekend to move HttpCore and HttpClient to the
new build process.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
