Re: [OOEclipse] OO Debug launcher
Cédric Bosdonnat <[email protected]>
| Newsgroups | gmane.comp.gnome.ximian.openoffice |
|---|---|
| Message-ID | <[email protected]> |
Hi Dan, On Wed, 2010-05-26 at 14:19 +0300, Dan Corneanu wrote: > these are the steps an OO Debug launch configuration should perform: > 1. *Export the oxt file* Already done by the OXT Export wizard. In order > to automate this, I think that the destination path should be set to > point to some dit/build folder inside the project. As I mentioned it previously, the export wizard code is being refactored to get rid of the package description properties file. Some parts of that wizard will need to be reused in that launch configuration. > 2. *Start a remote debugger* from eclipse with Connection type: Socket > Listen and a default port (should be configurable) Should be done as the last step, otherwise there will be port opened for that. > 3. *Deploy the previously built oxt* by running unopkg with the > UserInstallation env variable set to point to a temporary folder inside > the project (this way we get a clean environment for testing the > extension under development) Indeed, this needs to be done. The code to deploy is already there. What needs to be done here is the use of the debug user installation. > 4. *Start soffice* with UserInstallation set as above and > JAVA_TOOL_OPTIONS = "-Xdebug" > "-Xrunjdwp:transport=dt_socket,address=plop:7861" Yes, but needs to be performed earlier (see comment on step #2) > What is the build folder used for? Is it possible to use it as a working > folder for storing the UserInstallation and exporting the oxt ? > Or should it be better to add a new folder to the project's layout, say > dist and use this one as a working folder? The build folder is containing the temporary build results, that is: URD files and .class files for the IDL types. We can of course use a build/dist folder to contain the OXT file. It could also contain a .ooo-debug folder for the user profile. That sounds like a nice plan. WRT the dialog of the debug configuration tab, subclassing the Java remote debugger could be a nice option... though they might use some internal classes. Regards, -- Cedric