Helperapi

As you may have read Sun has kindly donated it's compatibility helperapi that was part of the macro migration toolkit.

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

Useful directories

• 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?

1. the auto generation of the constants type library
   1. constants are autogenerated form the *.api files located in the util/ms_api directory
2. the object implementations themselves. see the porting example and the porting notes
3. the testdocuments
   1. 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.
4. a similar base class to HelperInterfaceAdaptor