From Apache OpenOffice Wiki
How is it different from oovbaapi
- written in Java
- supports both word and excel
- has a nice set of test documents
- each uno object in the helperapi is a service ( and has a service definition )
Why ditch the helperapi and use the oovbaapi from ooo-build written in C++
- with a java uno component implementation it's hard to track memory and performance problems across language and bridge boundaries
- in many instances the existing openoffice uno api ( e.g. for calc and writer ) does not provide enough easily leveraged functionality to efficiently ( and quickly ) build a compatibility api from.
- The existing applications ( calc & writer ) and the basic runtime are written in C++ and as such its easier to interact at a lower level using c++. The alternative is to expose the bits need via uno, that itself is not a trivial task.
How is it structured
- basic provides some global functions written in basic to bootstrap the api
- com idl subsytem
- impl java implementation
- test_documents a set of documents ( excel and word )
- util/constants generated building of uno constants
What pieces are worth porting?
- the auto generation of the constants type library
- constants are autogenerated form the *.api files located in the util/ms_api directory
- the object implementations themselves. see the porting example and the porting notes
- the testdocuments
- a nice test harness infrastructure is necessary to help track progress, highlight known errors and indicate any regressions. The test documents which are both word and excel documents already include a test framework for logging the test results in log files. Whats missing is the infrastructure to run these tests automatically and compare the test results and a 'known' expected result.
- a similar base class to HelperInterfaceAdaptor