You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2006/08/03 10:13:00 UTC
[HttpComponents] build-common.xml
Folks,
I am a big fan of Ant 1.6 feature that enables multiple modules to share
common build tasks. This makes build files of individual modules much
cleaner and less prone to errors. Unfortunately this poses a problem
preventing us from including Ant build files into the source
distribution of HttpComponents modules, as build files are dependent on
a specific location of build-common.xml in the file system.
Secondly, I am about to start changing the SVN structure of HttpCore
module in order to introduce sub-modules, which will also require a
significant rewrite of build-common.xml and will make it even more
complex.
This all leads to believe that we will be much better off with
self-contained build.xml and should do away with build-common.xml. The
inevitable duplication of common tasks in individual build files seems
like a lesser evil to me.
What do you think?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpComponents] build-common.xml
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> Agreed. build-common.xml must go. I'll take care of the HttpCore build
> file, unless someone beats me to it.
If I knew what you have in mind, I might give you a run for your credit :-)
I'll take care of http-async, to show what I have in mind.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpComponents] build-common.xml
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2006-08-05 at 20:18 +0200, Roland Weber wrote:
> Hi Oleg,
>
> > This all leads to believe that we will be much better off with
> > self-contained build.xml and should do away with build-common.xml. The
> > inevitable duplication of common tasks in individual build files seems
> > like a lesser evil to me.
>
> I have reconsidered. Something in build-common.xml is seriously
> broken, and I believe it's got to do with those "macro" definitions.
> I believe that mainly because I never used them, and it seems to
> be the only thing that might cause trouble. In particular, when I
> give more than one target that actually does something, the build
> fails with message "Element more-src already present". Examples:
>
> ant clean compile javadoc
> ant clean compile package
> ant clean package javadoc
> ant clean package test
> ...
>
> The Ant based build process is in need of a fundamental overhaul.
> When I consider the build files I write at work, they also define
> all component specific knowledge in the local build.xml, including
> <javac> and <jar> tasks. The shared definitions are only fundamental
> things, like a timestamp that can be used by each component during
> the build, and some properties.
>
> So I am in favor of creating self-contained build files for each
> component. When doing so, we also should reconsider the structure
> of the build. Currently, our Ant build tries to replicate a
> subset of the Maven build lifecycle. I'm not sure what value this
> adds, unless we want to let Maven call our Ant targets. Separating
> the target and temporary directories used by Maven and Ant might
> also be a good idea.
>
> And finally a feature request: do *not* make the javadoc target
> depend on the compile target! Whenever I change an interface and
> then run "ant clean compile" to see from the errors which classes
> I have to adapt, I am left without javadocs until I've finished
> the changes for which I would like to use them :-(
>
Agreed. build-common.xml must go. I'll take care of the HttpCore build
file, unless someone beats me to it.
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
Re: [HttpComponents] build-common.xml
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> This all leads to believe that we will be much better off with
> self-contained build.xml and should do away with build-common.xml. The
> inevitable duplication of common tasks in individual build files seems
> like a lesser evil to me.
I have reconsidered. Something in build-common.xml is seriously
broken, and I believe it's got to do with those "macro" definitions.
I believe that mainly because I never used them, and it seems to
be the only thing that might cause trouble. In particular, when I
give more than one target that actually does something, the build
fails with message "Element more-src already present". Examples:
ant clean compile javadoc
ant clean compile package
ant clean package javadoc
ant clean package test
...
The Ant based build process is in need of a fundamental overhaul.
When I consider the build files I write at work, they also define
all component specific knowledge in the local build.xml, including
<javac> and <jar> tasks. The shared definitions are only fundamental
things, like a timestamp that can be used by each component during
the build, and some properties.
So I am in favor of creating self-contained build files for each
component. When doing so, we also should reconsider the structure
of the build. Currently, our Ant build tries to replicate a
subset of the Maven build lifecycle. I'm not sure what value this
adds, unless we want to let Maven call our Ant targets. Separating
the target and temporary directories used by Maven and Ant might
also be a good idea.
And finally a feature request: do *not* make the javadoc target
depend on the compile target! Whenever I change an interface and
then run "ant clean compile" to see from the errors which classes
I have to adapt, I am left without javadocs until I've finished
the changes for which I would like to use them :-(
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpComponents] build-common.xml
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> The path is actually relative:
> <import file="../project/build-common.xml"/>
The trick is as follows:
<!-- override as appropriate for your environment -->
<property name="build.common" location="../project/build-common.xml" />
<import file="${build.common}" />
I have been thinking about another trick, where each module
would have a build-common.xml which includes the one from
the project directory. When building the release, the local
one could be replaced by a copy of the project directory one.
The problem with this idea is that releases are no longer
reproducible then. Manually replacing build-project.xml when
creating the SVN branch might solve this.
I also have some ideas that would affect the build process,
but I need more time to become familiar with Maven and the
Maven-Ant-interaction. I am quite familiar with Ant alone,
but I'm always afraid to break Maven functionality.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpComponents] build-common.xml
Posted by sebb <se...@gmail.com>.
On 03/08/06, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Thu, 2006-08-03 at 15:04 +0100, sebb wrote:
> > On 03/08/06, Oleg Kalnichevski <ol...@apache.org> wrote:
> > > Folks,
> > >
> > > I am a big fan of Ant 1.6 feature that enables multiple modules to share
> > > common build tasks. This makes build files of individual modules much
> > > cleaner and less prone to errors. Unfortunately this poses a problem
> > > preventing us from including Ant build files into the source
> > > distribution of HttpComponents modules, as build files are dependent on
> > > a specific location of build-common.xml in the file system.
> >
> > Can't one use relative path names here?
>
> The path is actually relative:
> <import file="../project/build-common.xml"/>
>
> The trouble is it points at the 'project' directly which available only
> if one checks it out from SVN. This is not a big deal for those who work
> with SVN, but may pose a problem for those who just get a source package
> off the download page.
>
We had similar problems in JMeter with running Anakia from Eclipse and
Ant; this was solved by adding an Ant property that could be set as
needed to reach the required files.
Or it might be possible to adjust the contents of the source archive
so that it reflected the SVN layout?
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpComponents] build-common.xml
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2006-08-03 at 15:04 +0100, sebb wrote:
> On 03/08/06, Oleg Kalnichevski <ol...@apache.org> wrote:
> > Folks,
> >
> > I am a big fan of Ant 1.6 feature that enables multiple modules to share
> > common build tasks. This makes build files of individual modules much
> > cleaner and less prone to errors. Unfortunately this poses a problem
> > preventing us from including Ant build files into the source
> > distribution of HttpComponents modules, as build files are dependent on
> > a specific location of build-common.xml in the file system.
>
> Can't one use relative path names here?
The path is actually relative:
<import file="../project/build-common.xml"/>
The trouble is it points at the 'project' directly which available only
if one checks it out from SVN. This is not a big deal for those who work
with SVN, but may pose a problem for those who just get a source package
off the download page.
Oleg
>
> > Secondly, I am about to start changing the SVN structure of HttpCore
> > module in order to introduce sub-modules, which will also require a
> > significant rewrite of build-common.xml and will make it even more
> > complex.
> >
> > This all leads to believe that we will be much better off with
> > self-contained build.xml and should do away with build-common.xml. The
> > inevitable duplication of common tasks in individual build files seems
> > like a lesser evil to me.
> >
> > What do you think?
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [HttpComponents] build-common.xml
Posted by sebb <se...@gmail.com>.
On 03/08/06, Oleg Kalnichevski <ol...@apache.org> wrote:
> Folks,
>
> I am a big fan of Ant 1.6 feature that enables multiple modules to share
> common build tasks. This makes build files of individual modules much
> cleaner and less prone to errors. Unfortunately this poses a problem
> preventing us from including Ant build files into the source
> distribution of HttpComponents modules, as build files are dependent on
> a specific location of build-common.xml in the file system.
Can't one use relative path names here?
> Secondly, I am about to start changing the SVN structure of HttpCore
> module in order to introduce sub-modules, which will also require a
> significant rewrite of build-common.xml and will make it even more
> complex.
>
> This all leads to believe that we will be much better off with
> self-contained build.xml and should do away with build-common.xml. The
> inevitable duplication of common tasks in individual build files seems
> like a lesser evil to me.
>
> What do you think?
>
> Oleg
>
>
> ---------------------------------------------------------------------
> 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