Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of kleymenov@gmail.com designates
 64.233.184.235 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=PwlWgtBcE1zNxZyV2ZyQ6fs8cde++HyJMu9yefgdlUBq5QyR6HAiWMkCbiXvWGb1GjNR5NHq5TAwSenKhNgqGVCCQo2c5vIRCLgtzRPMzII8NAKR1vwqb1Krtlnl1NDpwA0WWBhoa1HkcgoMu8GQcJtr4NrLCRUIUM/+nfHtwo8=
Message-ID: <e09a11790704192242m36214826qc33454ea037b3859@mail.gmail.com>
Date: Fri, 20 Apr 2007 12:42:42 +0700
From: "Alexander Kleymenov" <kleymenov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [buildtest] Proposal for Build Test Infrastructure Improvement
In-Reply-To: <6e47b64f0704192052t6c635898xaf2fe1255e7f3dc1@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e09a11790703262343m576dee90j5a59d52e14290274@mail.gmail.com>
	 <e09a11790704170240i2428d843jdd350ec05093ced6@mail.gmail.com>
	 <6e47b64f0704170354v47e011d2t2fb4f475d38aad0d@mail.gmail.com>
	 <e09a11790704172221u765fa719o41cd456da66d089e@mail.gmail.com>
	 <6e47b64f0704180211k44a3de04g8b2ec55b3f4f6267@mail.gmail.com>
	 <6e47b64f0704182131v59859fa2s69114d601e39f1b1@mail.gmail.com>
	 <e09a11790704182254q60fca758t44238a540644228a@mail.gmail.com>
	 <6e47b64f0704190036p1b61c989p695e5ae3a8caa7e6@mail.gmail.com>
	 <e09a11790704190127m47ec5cabj2ce16f1348bcb976@mail.gmail.com>
	 <6e47b64f0704192052t6c635898xaf2fe1255e7f3dc1@mail.gmail.com>

Hi,

> > There can be a HDK building test suite, so all of the suites depending
> > on drlvm will depend and on this test suite. And there can appear
> > another dependencies between the suites.
>
> This is not clear for me: currently there is no hdk suite. Could you
> give more info?

I'm not telling about the facts, but about possibilities here.
Such a suite can arise, and BTI should handle new dependencies without
need to be reimplemented.

> > The test-suite dependency managing is a simple and quite natural way to
> > define the relationships between the suites.
>
> It is quite big peace of code. And I'm just trying to understand
> whether we really need this functionality. If it is used only to
> resolve suites dependencies on classlib and drlvm then I'd substitute
> it with something that more simple.
>
> BWT, how the framework resolves cycle dependencies?

It should report an error. Now it just cut the circle.

> > The information on such a
> > relationships is very useful during the test run setup and execution
> > stages. The resolution of default values for required parameters is
> > dependent on this information, the order in which the selected test
> > suites will be run (for single and CC run) is determined by means of
> > this information, CC related functionality uses dependency info to
> > retrieve SVN modifications lead to test-suite execution.
> >
> > So test-suite dependency management is an important architectural part
> > of the proposed BTI. It can't be simply removed from the system. Can you
> > suggest substitution for it?
>
> My current view that the most of suites just need to know where is JRE
> for testing.

No, there are other things. For example - to run classlib unit tests we
define test suite 'classlib-test' which depends on 'classlib' suite.
All we need to do to implement 'classlib-test' is to define the dependency on
'classlib', use its shared 'trunk.dir' parameter as a default for
'built.classlib.workspace' required parameter, and write single line in
adaptor's run target:
    <ant dir="${built.classlib.workspace}" target="test"/>
It's quite simple and natural solution in the current BTI approach
with dependency management means presented.

> Then the framework can do the following
> 1) if classlib is specified then test.jre.home=${classlib}/deploy/jdk/jre
> In this case the framework user should just place VM implementation to
> ${classlib}/deploy/jdk/jre/bin/default. (for example, it may be IBM
> VME). So the framework first rebuild classlib and then runs other
> suites.
>
> 2) if classlib+drlvm are specified then
> test.jre.home=${drlvm}/build/deploy/jdk/jre
> In this case the framework first rebuild classlib, then drlvm suite
> and after that runs other suites.
>
> 3) classlib and drlvm are not specified. test.jre.home is specified by
> framework user.
>
> Does this work for you?

I think we should keep the general approach to dependency management and
do not tie with particular intersection points (I mean tested jre in
your case).
I think we should keep the information about such intersections on the
level of test suites (as it's done now). In the current approach the
appearance of a new test suite with the product which can be shared does
not cause the fixes inside the framework. In your case such a new
'shared' product causes drilling into framework.

Alexander