For some time, I have been working on one of your comments on the Eclipse integration: I am making it work with OpenOffice.org 3.0 and its SDK. In the same time, I have found some problems with the UNO types browser. I have started to fix them and improve the OpenOffice.org bootstrapping system from Eclipse.
- The Eclipse integration will now be able to bootstrap OpenOffice.org 2.x or 3.0 with some custom classloader instead of running a small Java application and reading its output. This will improve the stability of the UNO types provider. I won't explain this custom classloader system here, but it will certainly be the topic of a next post.
- The fetched UNO types will be stored in a cache on the Eclipse side. The user will be able to refresh this cache. This improvement will increase the speed to display the UNO types selection list: the UNO types don't change so often.
Among the other points I would like to improve is the build system. It is yet depending on the Eclipse integration and I would like to extract the necessary code for the manifest generation and provide some ant scripts generating a package from the project sources.
As I am working on the Eclipse integration during my spare time now, I have no time to fix some important bugs on the COOoder extension. I hope you will understand the timing issue...