Bugzilla – Full Text Bug Listing
| Summary: | [Subclipse] Subclipse blocks Mylyn tests | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Steffen Pingel <steffen.pingel> |
| Component: | Mylyn | Assignee: | Alvaro Sanchez-Leon <alvaro.sanchez-leon> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | 0.9 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Steffen Pingel
The subclipse connector has dependencies on subclipse.core not the ui. Steffen, do you know what triggers the loading of the UI ? We may need to take the Sublipse.core connector out of the nightly build while we figure it out. I merely added the Subclipse feature to the target environment but did not include the connector, yet. I understand that we only need certain core plug-ins to build the connector but in order to run meaningful integration tests I prefer to consume dependencies on the feature level which includes the UI. We'll either need to tweak Subclipse during test setup to avoid the modal dialog or work with the Subclipse team to make changes upstream. For now I have removed Subclipse from the target environment. Unfortunately, we won't be able to distribute the connector before this has been addressed. More info: After checking the stack trace, and correlating it with Plug-in Selection spy, the dialog is the one explained at: http://subclipse.tigris.org/usage.html Next: I will prepare a preferences.ini file and see if this can be placed in the test environment to prevent this dialog. There are two possible work around found so far, not perfect but might be suitable for the test environment. 1) insert a a preferences.ini file in the plug-in jar file org.tigris.subversion.subclipse.tools.usage_1.0.1.jar content: @org.tigris.subversion.subclipse.tools.usage=1.0.1 /instance/org.tigris.subversion.subclipse.tools.usage/ask_user_for_usage_report_preference=false 2) removing usage bundle from %ECLIPSE_HOME%\configuration\org.eclipse.equinox.simpleconfigurator\bundles.info see http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=2728624 Steffen, do they seem suitable to use within the test environment ? Neither solution is going to work as the dialog also comes up when testing locally. Can you file a bug against Subclipse to suppress the prompt when running from unit tests? o.e.m.commons.core.CoreUtil.TEST_MODE has an example how to check that. (In reply to comment #5) > Neither solution is going to work as the dialog also comes up when testing > locally. Can you file a bug against Subclipse to suppress the prompt when > running from unit tests? o.e.m.commons.core.CoreUtil.TEST_MODE has an example > how to check that. The following issue has been raised to subclipse: http://subclipse.tigris.org/issues/show_bug.cgi?id=1302 see initial comment from http://subclipse.tigris.org/issues/show_bug.cgi?id=1302 Steffen, could you extend on the limitations of why couldn't we exclude the following plug-in from the test environment: org.tigris.subversion.subclipse.tools.usage It would be great if you could join the discussion in the subclipse bug, we can later summarize the outcome on a single comment on this one. Thanks for filing that. I have commented on the Subclipse bug report. I am lowering severity of this bug since Subclipse is not included in integration builds at this point and it's not clear yet if that is going to become a priority. Alvaro, if you add a test plug-in for Subclipse and we don't have another solution it would be great if you tried the approach in comment 4. It should be possible to tweak preferences in the test suite. Alvaro, are you able to provide a patch for Subclipse to suppress the modal dialogs when running in test mode? We need to sort our several issues before setting the preferences programatically from a test plug-in 1) Bundle activation sequence, if the test plug-in uses early activation as the Usage plug-in does. how can we make sure that we can set up the preferences before the usage plug-in fires the dialogue ? 2) The subclipse usage plug-in, does not export any of its packages, so there is no public access to the plug-in to retrieve the preference store. 3) Comment 4 indicates possibilities to achieve this via the file system. this would require some sort of ant script to add the preferences.ini or remove the usage bundle as they are fetched from the repositories. Any ideas are very welcome. A new alternative to consider: see http://wiki.eclipse.org/Steps_to_use_Fragments_to_patch_a_plug-in The alternative above requires to wrap the original plug-in jar in another plug-in with the same identity, and modify the bundle properties to allow api extensions via a fragment, and giving higher priority to the loading of the fragment jar then the actual fragment can load a new version of a class and modify the behaviour. I have done a quick test on this, and it would work, but the question is: Since this approach wraps an external bundle it does not go well with the IP process, unless this is hosted on an external server. Comments are very welcome Alvaro, any reason not to provide a patch for Subclipse so we don't have to deal with this problem at all? (In reply to comment #12) > Alvaro, any reason not to provide a patch for Subclipse so we don't have to > deal with this problem at all? Comment 9 to Comment 11 are exploring the request in comment 8, to provide a test plug-in. As there no additional ideas on this. I will prepare a patch for the usage plug-in. All of your suggestions are very valid approaches but if feasible I prefer to address the root cause in Subclipse. Otherwise we'll end up having to apply the same work around in the various scenarios where tests are executed (e.g. local workspace). I have updated the dev targets to include Subclipse 1.8 which appears to fix the observed problem. |