incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From De Bin Lei <debin....@gmail.com>
Subject Re: [REQUEST][VCLAuto]Create two new modules under SRC_ROOT to place vclauto code.
Date Thu, 28 Jun 2012 06:10:34 GMT
The VCLAuto code had copy from symphony to the trunk and re-factory as
design[1].
Also the license for these files had updated to ASF 2.0.
Thanks Liu Zhe's great work, everyone can enjoy the new automation GUI test
framework now !

[1] http://wiki.services.openoffice.org/wiki/Test_Refactor

2012/6/25 De Bin Lei <debin.lei@gmail.com>

>
>
> 2012/6/25 Zhe Liu <aliuzhe@gmail.com>
>
>> 2012/6/25 Andre Fischer <af@a-w-f.de>:
>> > On 25.06.2012 10:46, Zhe Liu wrote:
>> >>
>> >> 2012/6/25 Andre Fischer <af@a-w-f.de>:
>> >>>
>> >>> On 25.06.2012 10:00, Zhe Liu wrote:
>> >>>>
>> >>>>
>> >>>> 2012/6/25 Andre Fischer <af@a-w-f.de>:
>> >>>>>
>> >>>>>
>> >>>>> Hi Zhe Liu,
>> >>>>>
>> >>>>> we already have four test related modules under main/ (test,
>> >>>>> testautomation,
>> >>>>> testgraphical, testtools).
>> >>>>>
>> >>>>> Would one of these be a good place to add two sub-directories
for
>> the
>> >>>>> new
>> >>>>> testing code?
>> >>>>
>> >>>>
>> >>>> Are you concerned about too many modules?
>> >>>
>> >>>
>> >>>
>> >>> Yes.
>> >>>
>> >>>
>> >>>>
>> >>>> The new 2 modules are top level modules.  qadevoo and  testoo depend
>> >>>> on testcommon.
>> >>>> qadevoo->testcommon
>> >>>> testoo -> testcommon
>> >>>> If
>> >>>> qadevoo->test/testcommon
>> >>>> test/testoo ->test/testcommon
>> >>>>  I don't know if it works according to the current build system.
In
>> >>>> addition, I don't want to overwrite the existing code. They are
>> >>>> totally different. The 4 modules is maintained by nobody and can
be
>> >>>> removed in future, I said it in
>> >>>> http://wiki.services.openoffice.org/wiki/Test_Refactor
>> >>>
>> >>>
>> >>>
>> >>> I see.  The goal is to remove the modules test, testautomation,
>> >>> testgraphical, testtools?  Then it is OK to ignore them for now.
>> >>>
>> >>> But then my question is: why not one new module and place testcommon
>> and
>> >>> testoo as subdirectories into it?
>> >>
>> >> Do you mean the code structure like the following?
>> >> test/testcommon
>> >> test/testoo
>> >> J├╝rgen suggested the same code layout. Actually I also prefer to it. I
>> >> have one question. test/testoo depends on "test/testcommon".
>> >> cd test/testoo
>> >> build
>> >> Is testcommon built automatically? If yes, it's ok.
>> >
>> >
>> > We have main/test/prj/build.lst for that.  There is one line for each
>> > directory that is to be build, together with dependencies on other
>> modules
>> > (in the first line) and on other directories in the same module (on each
>> > line after the '-')
>> >
>> > You would probably add two lines similar to these:
>> >
>> > te test\source\testcommon nmake - all te_testcommon NULL
>> > te test\source\testoo nmake - all te_testoo te_testcommon NULL
>> >
>> > Which state that te_testoo depends on te_testcommon.
>> > Then build the module with
>> >
>> >    cd main/test
>> >    build
>> >
>> > (please note that you build in main/test/, not in main/test/testoo or
>> > main/test/testcommon)
>> >
>> > -Andre
>> >
>> >
>> OK. I accept. Thanks for your advice, Andre.
>> De Bin, what's your opinion?
>>
> Both are ok for me.
>
>> >>
>> >>>
>> >>> Besides, has the naming scheme (test{common/oo}) anything to do with
>> the
>> >>> now
>> >>> obsolete distinction between oo and so (the Sun only code parts)?
>> >>
>> >> No!  Do you have better name?
>> >>
>> >>>
>> >>> -Andre
>> >>
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Best Regards
>> From aliuzhe@gmail.com
>>
>
>
>
> --
> Best regards
> Lei De Bin
>
>


-- 
Best regards
Lei De Bin

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message