You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Roland Weber <ht...@dubioso.net> on 2006/08/06 22:20:18 UTC
[HttpAsync] build.xml
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: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpAsync] build.xml
Posted by sebb <se...@gmail.com>.
On 07/08/06, Oleg Kalnichevski <ol...@apache.org> wrote:
> 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.
[...]
> (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.
Maven is used by quite a few Jakarta and ASF projects, but is not used
by all projects. I'm not even sure that it is used by the majority of
ASF projects.
IMO, Ant is a lot easier to get started with ...
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpAsync] build.xml
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
Thanks for your feedback. See my comments below.
> (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.
It isn't my preferred build tool, and I doubt it will ever become.
I've used the Ant build from the start, and as long as Maven does
not do anything that Ant couldn't, I'd like to keep it that way.
Unless we find a majority for getting rid of Ant altogether, but
I don't see that happening if Gump supports only Ant.
> (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.
That's probably because you are using an IDE (Eclipse?) that compiles
everything you load into it. I don't. Without an Ant task to build
those packages, I will miss it if their code is broken by a change.
Which happened only last weekend in HttpCore. If the code is supposed
to compile, I want a build target to compile it :-) Defining a target
for packaging was only done for sake of consistency, since the compile
targets shouldn't define dependencies.
I think this is a difference in the way we develop code. An IDE gives
you a completely separate build environment for incremental compilation,
including JavaDoc-style popups for everything. I don't have that, so I
need the functionality readily accessible in a build process. As far
as I have learned by now, Maven provides a linear lifecylce with the
deliverable package at the end. Ant has more flexibility for defining
all kinds of intermediate or side-exit targets. That's why I consider
Maven the tool for cutting a release every few months, while Ant is
my tool of choice for day to day development. It's a replacement for
the IDE rather than for Maven.
> Otherwise, look ok to me
Thanks. I've spotted a big problem, though. The properties do not have
a namespace. If build files for HttpCore, HttpClient and HttpAsync all
use the same build.properties file, then the property names for
defining target directories like ${dist.api} must be distinct.
I'll try to come up with a new version sometime this week.
Maybe we'll also get some more feedback until then.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpAsync] build.xml
Posted by Oleg Kalnichevski <ol...@apache.org>.
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: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org