Stepan,
> > What the reason for calling classlib's build in this way? Why we have
> > to run 'ant.bat' (or 'ant.sh' for Linux) via <exec>?
>
> It's workaround for Ant's OutOfMemory problem arising after doing the same
> by <ant> target. The <ant>-rebuild of classlib project causes big memory
> leaks somewhere in the Ant and the further BTI execution is impossible
> becouse of arising OOM.
>
As far as I remember the solution was to increase the max memory used
by Ant with setting ANT_OPTS to "-Xms256M -Xmx512M". Have you tried
this?
2Gb was not enough.
> >
> > 3) In exec-adaptor.xml antconrib's wrapper 'trycatch' and 'runtarget'
> > task are used for calling adaptor's(i.e. suite's) target.
> >
> > <trycatch property="execution.exception">
> > <try>
> > <runtarget target="@{target}"/>
> > </try>
> > <catch>
> > Echo error message
> > </catch>
> > </trycatch>
> >
> > Again, why it is not possible use <ant> task? And this leads to the
> > next question.
>
> Infra needs some failure processing means here. Default <ant> task does
> not allow to do it. Using of <runtarget> instead of <ant> saves memory
> as it does not fork the ant's project.
>
What kind of failure processing it does?
Sets up the property, prints trace, and keeps execution going on.
> > 5) Patching ANT - is there any workaround?
>
> It's a workaround itself. For Ant's basedir problem. Ant does not set
> basedir properly if <ant> task executes the code containing <subant>
> task. This path is taken from the bug report filed on both versions of
> ant. Here it's supposed that 1.6.5 version is used. To be more correct
> here we should check current ant's version and take suitable patch.
>
Oops ... does it mean that this workaround binds the infra to selected
ANT version (in our case 1.6.5)? For example, if I have Ant 1.7
installed the infra won't work?
Yes, I'm composing TODO list for BTI and it already has this item.
Also ... I wonder why we haven't meet this issue in classlib or drlvm
builds yet? It might mean that we use this Ant bug as a feature and
once Ant get fixed ... need to check classlib and drlvm.
I've executed classlib's and drlvm's build system under patched ant -
everything worked fine. So there are no 'bug as feature' substitution.
> > 6) And minor question: is there any strong reason for naming build
> > scripts 'adaptor.xml' not 'build.xml'?
>
> I'm positioning the BTI framework not as an Ant-based Build System,
> but as an Application implemented in Ant Scripting Language.
> In build systems build.xml is a self-documenting file name.
> In BTI the name adaptor.xml does the same - it documents itself.
> I think it would be better to rename root build.xml to buildtest.xml.
Sorry, I didn't catch about proposed infra positioning. Could you clarify?
What exactly needs clarification?
BTW, if we rename build.xml=>buildtest.xml we have to type each time:
ant -f buildtest.xml.
The standard usage of BTI supposes launching by means of shell scripts
(buildtest.bat/.sh), not by ant launcher.
Thanks,
Alexander
