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
