On Sun, 2006-08-06 at 22:20 +0200, Roland Weber wrote:
> 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.
>
Roland,
Just a few comments:
(1) Maven should stay the preferred building tool for HttpComponents
(not because I like it that much, but for the consistency sake with the
rest of Jakarta and ASF). Therefore, I would not invest too much efforts
into Ant build file beyond a reasonable minimum.
(2) The 'contrib' and 'example' artifacts (at least to this point) are
meant to be distributed in source as a reference material only. I would
not bother including 'contrib' and 'example' specific tasks into the
build file.
Otherwise, look ok to me
Oleg
> cheers,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
