> -----Original Message-----
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 07, 2001 5:33 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Feature Request: Ant batching support
>
>
> Stephane Bailliez <[EMAIL PROTECTED]> wrote:
>
> >> -----Original Message-----
> >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]]
> > [...]
> >> > 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.
