harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: [buildtest] Proposal for Build Test Infrastructure Improvement
Date Tue, 17 Apr 2007 10:54:38 GMT
On 4/17/07, Alexander Kleymenov wrote:
> 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.
>

Wow ... and do you have any idea why 512M is enough for the current
infra and 2Gb is not enough for the proposed one? As I understand
certain ANT tasks can use a lot of memory - classlibrary complies over
3500 with javac task, so we may assume that this requires a lot of
memory. But root cause of such essential increase (more then x4 times)
is somewhere in the proposed infa from my POV. Can this impose some
limits, for example, to a number of testing suite that the infra can
setup and run?

> > > >
> > > > 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.
>

Did I understand it correctly that if suites are run not under
CruiseControl it lets to collect exit status for all suites without
stopping the build (even there are failed suites)?

> > > > 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.
>

Frankly, I'm not quite comfort with this. So you are going to detect
ANT version and apply corresponding patch. Correct? Let me think a bit
if there are any potential issues with this approach. For example, if
I setup the infra with ANT 1.6.5 and after that switch to ANT 1.7 then
I need to re-set up the infra. Right? Other issues?

> > 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.
>

Thanks for your investigation!

> > > > 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?
>

Why this is not Ant-based framework? What is Ant Scripting Language
(because it uses antcontrib)?

> > 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.
>

Just to setup classlib and lanch ant with -f buildtest.xml (like DRL VM build)?

Thanks,
Stepan Mishura

Mime
View raw message