ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Bailliez <sbaill...@imediation.com>
Subject RE: Feature Request: Ant batching support
Date Wed, 07 Mar 2001 18:11:31 GMT
> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: Wednesday, March 07, 2001 5:33 PM
> To: ant-dev@jakarta.apache.org
> Subject: Re: Feature Request: Ant batching support
> 
> 
> Stephane Bailliez <sbailliez@imediation.com> wrote:
> 
> >> -----Original Message-----
> >> From: Stefan Bodewig [mailto:bodewig@apache.org]
> > [...]
> >> > Also: I'd like the ability to specify <ant keepenv="true"...>, or
> >> > something like this, in order to preserve the environment of the
> >> > child project into the parent's.  This would be useful in setting
> >> > a common build environment from many build.xml files,
> >> 
> >> It seems to me as if including (either with entities as in the FAQ
> >> or via a new Ant specific include mechanism) would be the cleaner
> >> solution for your problem. Probably I am missing something.
> > 
> > What do you think about target and or project inheritance ? :)
> > 
> 
> Nice punchline 8-)
> 
> Care to explain?

Well in fact, I don't know, this is just an idea among others.

I have enormous problems to factorize all common things from different
modules (ie build.xml) and manage all this from a central build.xml (what
gump is doing in a way).
The problem is that build are somewhat very redundant and you could find
things to factorize.

For example I have a coverage target that is running all unit tests in a
module via JProbe Coverage, it thus produce information for source code
coverage. I have also an Audit task that is doing some static code analysis
and send back a report, a target that is running a class for remote
debugging, etc etc...
Ok, you can put all this in something like a lib.xml and include it via
entities...however sometimes...sh* happens, and you need to customize a
little bit more the target and adapt it to your project... as you cannot
override target, you're somewhat in trouble. Your build interface is broken
while you could benefit from work done :-(

Another thing related to properties:
For all modules I'm trying to make a clear distinction between tools used by
the project (such as JavaCC, Castor, Xalan, etc... everything that is needed
to pre-process or post-process some classes, info or whatever). they are
'tools'.
Then there are 'thirdparty' products. They are shipped with the whole
product.
Then there are dependencies between modules.

When I'm doing the global build, I want to force classpath (say
build.classpath) with the thirdparty and module dependencies, that will
really be shipped. As my modules might be at a different level and that some
of them have a basedir different than '.', I have to pass absolute path to
my libraries and as I want user of the build to use the lib abstracting
their location/version, I have an index.xml located at the place where are
stored the thirdparty libs that is doing things like:

--- thirdparty.xml --
<!-- solve the path in relative -->
<path path="${thirdparty.dir}/xalan2.jar" id="xalan"/>
<!-- now use it as property -->
<property name="xalan" refid="xalan"/>
...

---- globalbuild.xml ----

<ant file="module/build.xml">
	<!-- i'm calling the module from the 'official' dependencies -->
	<property name="build.class.path" value="${myclasspath}"/>
</ant>


--- build.xml --
<!ENTITY Thirdparty SYSTEM
"file:./../../thirdparty/java/lib/thirdparty.xml">

<property name="thirdparty.dir" value="../../thirdparty/java/lib"/>

&ThirdParty;
...
<path id="build.class.path"/>
	<pathelement path="${xalan}"/>
	<pathelement path="${something}"/>
</path>
<!-- if already specified, will not be overriden -->
<property name="build.class.path" refid="build.class.path"/>

<target name="dist">
	....
	<classpath path="${build.class.path}"/>
</target>

All this leads to something very very complicated...

What I would just to do in fact is to make sure that all modules are using
the same libraries that are located in one place and avoid lib duplication
in all modules and target duplication in all modules...

I feel like this is somewhat impossible to achieve at a reasonable level and
all we can do is being confident that people doing/maintaining the build of
their own module are good guys and do things the right way. It is possible
to break everything, so I think the latest is the only solution.

I'm open to any proposal...

-- 
 St├ęphane Bailliez 
 Software Engineer, Paris - France 
 iMediation - http://www.imediation.com 
 Disclaimer: All the opinions expressed above are mine and not those from my
company. 



Mime
View raw message