You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/10/25 14:28:41 UTC

Re: Harmony passes 94% on derby tests.

On 25 October 2006 at 18:36, "Vladimir Ivanov" <iv...@gmail.com> wrote:
> 
> Excellent!
> 
> I have one more idea: we already have buildtest module. Some time ago we
> agreed to extends it by coverage and japi scripts (I hope it happens soon:)
> ). May be we extend it one more time and store here some scripts for
> automatic run of other-projects unit tests? Seems, in this case we can
> easily reproduce tests run and enable new platforms.
>
> Of cause, we can not cover all application but we can define some list of
> 'most important application'.
>
> Is it OK?

I think gump will do this?

> PS. The directory structure may be something like that:
> 
> builtest
>     - trunk
>         - cc
>         - coverage
>         - japi
>         - application_test
>             - derby
>             - ant
>             - etc
>         - misc (some other scripts)

I had assumed we'd make separate, optional cruisecontrol jobs to perform
the coverage/japi/etc reporting.  These jobs would depend on the build
ant test jobs succeeding.  Judging by the structure you suggest, it
seems to me that you may anticipate doing it differently?

Regards,
 Mark.



Re: Harmony passes 94% on derby tests.

Posted by "Geir Magnusson Jr." <ge...@pobox.com>.

Vladimir Ivanov wrote:
> On 10/25/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> 
>>
>>
>> Mark Hindess wrote:
> 
> 
> <snip>
> 
> 
> 
>> >> PS. The directory structure may be something like that:
>> >>
>> >> builtest
>> >>     - trunk
>> >>         - cc
>> >>         - coverage
>> >>         - japi
>> >>         - application_test
>> >>             - derby
>> >>             - ant
>> >>             - etc
>> >>         - misc (some other scripts)
>> >
>> > I had assumed we'd make separate, optional cruisecontrol jobs to 
>> perform
>> > the coverage/japi/etc reporting.  These jobs would depend on the build
>> > ant test jobs succeeding.
> 
> I agree.
>>
>> Judging by the structure you suggest, it
>> > seems to me that you may anticipate doing it differently?
>> >
> 
> 
> 
> my vision is: into each 'application' directory we have 3 files (at least):
> one - for manual run of application tests over checkouted workspace, one 
> for
> manual run of application tests over HDK and one - cruise control project
> description for this test set based on the first file (actually, 'cc' 
> may be
> is not good name. Let's rename it to 'hut' (harmony unit tests) or 
> something
> else).
> 
> The common part - classlib and drlvm builds - should be stored into root of
> buildtest/trunk module.
> 
> By default, the CC will include only builds and unit tests for classlib and
> drlvm but can be updated to builds and something else by command line
> options.
> 
> Is it OK?

Why not put everything in by default, and let people comment out what 
they don't need?

geir

> 
> thanks, Vladimir
> 
> 
> 
>> > Regards,
>> >  Mark.
>> >
>> >
>> >
>>
> 

Re: Harmony passes 94% on derby tests.

Posted by Vladimir Ivanov <iv...@gmail.com>.
On 10/25/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:

>
>
> Mark Hindess wrote:


<snip>



> >> PS. The directory structure may be something like that:
> >>
> >> builtest
> >>     - trunk
> >>         - cc
> >>         - coverage
> >>         - japi
> >>         - application_test
> >>             - derby
> >>             - ant
> >>             - etc
> >>         - misc (some other scripts)
> >
> > I had assumed we'd make separate, optional cruisecontrol jobs to perform
> > the coverage/japi/etc reporting.  These jobs would depend on the build
> > ant test jobs succeeding.

I agree.
>
> Judging by the structure you suggest, it
> > seems to me that you may anticipate doing it differently?
> >



my vision is: into each 'application' directory we have 3 files (at least):
one - for manual run of application tests over checkouted workspace, one for
manual run of application tests over HDK and one - cruise control project
description for this test set based on the first file (actually, 'cc' may be
is not good name. Let's rename it to 'hut' (harmony unit tests) or something
else).

The common part - classlib and drlvm builds - should be stored into root of
buildtest/trunk module.

By default, the CC will include only builds and unit tests for classlib and
drlvm but can be updated to builds and something else by command line
options.

Is it OK?

 thanks, Vladimir



> > Regards,
> >  Mark.
> >
> >
> >
>

Re: Harmony passes 94% on derby tests.

Posted by "Geir Magnusson Jr." <ge...@pobox.com>.

Mark Hindess wrote:
> On 25 October 2006 at 18:36, "Vladimir Ivanov" <iv...@gmail.com> wrote:
>> Excellent!
>>
>> I have one more idea: we already have buildtest module. Some time ago we
>> agreed to extends it by coverage and japi scripts (I hope it happens soon:)
>> ). May be we extend it one more time and store here some scripts for
>> automatic run of other-projects unit tests? Seems, in this case we can
>> easily reproduce tests run and enable new platforms.
>>
>> Of cause, we can not cover all application but we can define some list of
>> 'most important application'.
>>
>> Is it OK?
> 
> I think gump will do this?

I'm sure it will, but given we have the infrastructure that we want 
people to run anyway, why not use it?

> 
>> PS. The directory structure may be something like that:
>>
>> builtest
>>     - trunk
>>         - cc
>>         - coverage
>>         - japi
>>         - application_test
>>             - derby
>>             - ant
>>             - etc
>>         - misc (some other scripts)
> 
> I had assumed we'd make separate, optional cruisecontrol jobs to perform
> the coverage/japi/etc reporting.  These jobs would depend on the build
> ant test jobs succeeding. 

I agree.

  Judging by the structure you suggest, it
> seems to me that you may anticipate doing it differently?
> 
> Regards,
>  Mark.
> 
> 
>