Bugzilla – Full Text Bug Listing
| Summary: | Juno RC compatibility: Error messages after startup / when changing perspectives in an 4.2 AUT | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Technology] Jubula | Reporter: | Oliver Goetz <Oliver.Goetz> | ||||||
| Component: | RC | Assignee: | Project Inbox <jubula.rc-inbox> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Oliver Goetz <Oliver.Goetz> | ||||||
| Severity: | critical | ||||||||
| Priority: | P3 | CC: | Achim.Loerke, alexandra.schladebeck, bluesoldier, ccorless42, clairelee, lchen, Lei.du, markus.tiede, marvin_m, phil.m.fischer, raimar.buehmann, ykuo, zeb.ford-reitz | ||||||
| Version: | 1.2.0 | ||||||||
| Target Milestone: | Kepler | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows Server 2008 | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 399745 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Oliver Goetz
This issue was previously filed as bug 367068. Probably caused by bug 332708. This Bugs is because we are using internal methods which has changed to Juno. See bug 375305. We have recently moved to Juno and have seen the same issue. Paul Webster presented an idea in bug 375305 comment 3 that seems feasible. It would still require use of non-API, but it may at least resolve this particular issue in the short-term. Some additional thoughts regarding PW's suggested approach (note that this is all speculation, I haven't actually tried any of this out yet): * In order to get the action bars, we would need to cast the site to either IViewSite or IEditorSite (as appropriate) in order to get access to the getActionBars() method. * I initially thought that we may be able to cast the IToolBarManager from IActionBars#getToolBarManager() to an IToolBarManager2 instead of a ToolBarManager. This would allow us to use provisional API instead of non-API (still not good, but at least better in my opinion). However, ToolBarManager does not implement IToolBarManager2, so this is not even an option. *** Bug 392283 has been marked as a duplicate of this bug. *** Is there updates on this bug? This is definitely a blocker one for our BIRT team since we rely on Jubula to run GUI smoke test cases. We've not done any work on this as yet, no. We're going to be starting on pure e4 support over the course of the next weeks. Our idea would be to have a look at this as a part of our work on that. I'm going to put the target milestone as SR2. We are using the E4.2SR1 as target platform for our project. For us this has also become a show stopper. A fix for this issue is highly appreciated. Since there is a great deal of interest in this bug, we've discussed that we could, very soon, provide a workaround that may help the affected parties. Our suggestion would be that we catch and ignore the error message. This would remove the problem that the error is displayed, but not the underlying problem that the name generation for toolbar items is not currently working. The effects of this change would be: - toolbar items would (still) not be testable in a meaningful way at the moment, as the mapping would "degenerate" after e.g. a perspective change - this in turn would mean that instead of toolbars, menus / context menus / keyboard shortcuts must be used if the functions from the toolbar are required (possible test specification changes necessary) - using menus would mean that SR1 minimum is needed (before SR1 there was a problem with testing menus, see BUG 375826) We would prefer to fix this for the current Jubula version (1.3). Is anyone not using this version? Please comment on whether this would help you past the blocking issue for the moment. If so, then we can provide a new rc.rcp plugin containing the workaround. This same problem occurs when you open an editor as well. To reproduce, just attempt to open a text file with the text editor. I would also consider this a major show stopper. We've started working on the separation of the rc.rcp plugin that will allow us to fix this issue for e4 AUTs that use the compatibility layer. Since no-one replied about their opinions on the quick solution for the moment (as mentioned in comment 10), our plan is to get straight to working on the actual fix instead of the workaround. We'll keep you posted with the details. Created attachment 224561 [details]
Renamed plugin ...jubula.rc.rcp to ...jubula.rc.rcp.e3
This patch prepares the next steps for fixing the bug by creating separate bundles:
* renamed org.eclipse.jubula.rc.rcp to org.eclipse.jubula.rc.rcp.e3
* created the following two empty bundles:
* org.eclipse.jubula.rc.rcp.e3.specific
* org.eclipse.jubula.rc.rcp.e4.compat
* changed all depending build files (pom.xml, ...)
A developer test with the "ant dev-release" build as AUT using the renamed accessor bundle org.eclipse.jubula.rc.rcp.e3 was successful.
Created attachment 224867 [details] Sprint task - Implemented e3.specific and e4.compat bundle to fix bug 379217 This patch fixes the bug by creating separate bundles: * Renamed org.eclipse.jubula.rc.rcp to org.eclipse.jubula.rc.rcp.e3 * created the following two empty bundles: * org.eclipse.jubula.rc.rcp.e3.specific * org.eclipse.jubula.rc.rcp.e4.compat * Changed all depending build files (pom.xml, ...) * Separated getting the control of a tool bar by using an abstract method [1] in the original Startup class. * Implement e4.compat by using the hint of Paul Webster [2]. * Created an own juno.target file for the e4.compat bundle. A developer test with the "ant dev-release" build as AUT using the renamed accessor bundle org.eclipse.jubula.rc.rcp.e3 and the new bundle org.eclipse.jubula.rc.rcp.e3.specific was successful. In the test the target file development/rcp-support.zip is extracted into the plugins folder of the Eclipse AUT. The previous attachment is obsolet. [1] Package org.eclipse.jubula.rc.rcp.e3.accessor and method getToolBarFromWorkbenchPartRef() in class E3Startup [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=375305#c3 Update on the target milestone: I've moved the milestone to Kepler, as we're not going to have the new bundles properly deployable in the next couple of weeks, so Juno SR2 isn't going to be possible. However, as the comments from Raimar show, we are currently making good progress on this. If anyone would like to try out the artefacts that are in development at the moment, then comment on this ticket. We'll be happy to provide what we're working on for people to test / use until it's in the official build. @Triaged:+ just to keep it out of the triage process. Hi everyone - I've posted an update on bug 397856 for a pre-version of the support for e4 (with and without compat layer). Please add any relevant comments to that ticket. Marking this as fixed - support for e4 applications is in Kepler, is currently available in the 2.0 standalone, and has been fixed for Kepler applications (see bug 404124). Verified. |