Bugzilla – Full Text Bug Listing
|
Description
amehrega
This feature is *critical* to our long term goal of automating our entire test suite (8000 functional tests) ... a significant portion of our features are built upon GEF. Ali, Do you have any ETA for this? As Kim states, this is critical for us and has not seen any action for 6 months. Hi Yves, There were a few e-mails recently exchanged between me, Antony Hunter, and Harm Sluiman. What's limiting us in pursuing this feature (and other Auto GUI features) is funding. I will forward you the e-mails exchanged. We'll appreciate any help that you can contribute in completing this feature. The GEF Team is interested in helping to work on this feature during the Eclipse 3.3 release timeframe. (In reply to comment #4) That's great. You can organize a meeting with me whenever it's convenient for you. I can point you in the right direction to get started. I played around with this idea last year (for some testing I needed for visualization toolkit built on GEF). I extended the Draw2D Graphics layer and instead of rendering the different operations (drawLine, fillArc, etc...), I wrote the information to a buffer. It worked pretty well, and you could replay the buffer to reproduce the final graphics. I thought about hooking this into JUnit, and when a render differed from the recorded buffer, it would flag the test case. The user could then view both images (the one currently rendered, and the stored buffer), and if it was determined that the new one was ok (because there was no visual different, or the test case was updated, etc...), the new buffer could be stored as the "correct" result. I never completed this because I am trying to complete my thesis, but I could try and dig up my bufferedGraphics stuff. Updating target to future as requested by the PMC. Enhancements are targeted to future if not in plan for the current release. Reassigning to current component lead. We have problem of using TPTP to test GEF app as well. Can this problem be solved by using TPTP's widget resolver (2.4.1 The Adaptive Widget Resolver) to add the GEF widget entries to the widgetReg.xml? (In reply to comment #9) > We have problem of using TPTP to test GEF app as well. > > Can this problem be solved by using TPTP's widget resolver (2.4.1 The Adaptive > Widget Resolver) to add the GEF widget entries to the widgetReg.xml? > Unfortunately, no. However, you can use the positional-based recording/playback to work-around this limitation. So, as long as the application is based on GEF, position-recording is the only choice? I am trying to work out how to let TPTP to recognize the objects under canvas, but I just need some direction. It's strange to me that all the tools I know, such as Rational Functional Tester, Mercury QTP, QF-test, TPTP, etc, do not support testing GEF application. Is there any proper way to work around with it (instead of position-recording)? Many thanks! (In reply to comment #11) > So, as long as the application is based on GEF, position-recording is the only > choice? I am trying to work out how to let TPTP to recognize the objects under > canvas, but I just need some direction. Yes. Created attachment 80668 [details]
Patch of HEAD version to allow draw2d figures as verification hook targets
Created attachment 80669 [details]
Patch of HEAD version to allow draw2d figures as verification hook targets
I tweaked the head version of the auto gui recorder so that a draw2d figure can be selected as a valid verification hook target (it is passed as a second parameter to the verification hook method during playback). What I basically did is that I changed the VerificationCommand to store the position of the FocusEvent issued when selecting the validation target as an additional attribute. Having the position, the draw2d figure inside the FigureCanvas can be obtained (so that the verification hook method can be generated) and passed to the verification hook during playback. I created an attachment with my changes, maybe this will help somebody as a starting point ... (sorry I attached it twice - I had connection problems). I think a "clean" solution could rely on extending the stored path so that not only the path to the editor/view is stored but an additional suffix to retrieve the draw2d figure residing in a nested FigureCanvas (in case such a widget is selected). To be able to do so, I would need to obtain an individual identifier for a draw2d figure and I did not see an easy solution for this issue (the IFigure interface does not provide anything useful, as far as I can judge). If somebody could guide me on how such an ID could be retrieved, I would be willing to work on a "clean" solution. Correcting priority since not a 4.5 candidate enhancement (see http://www.eclipse.org/tptp/home/documents/process/development/bugzilla.html). Having investigated this a bit further, I see two things which are needed to add profound support for Draw2d-based auto-gui-recording: 1) A general possiblity to resolve UI objects beyond the widget level would be needed. E.g. in case of a org.eclipse.draw2d.FigureCanvas widget, the figures nested inside its LightWeightSystem should be valid valid command targets. 2) The verification hook mechanism would have to offer the possibility to insert verfication hooks also beyond the editor/view/shell level, to be able to add a hook to e.g. test a single IFigure in a JUNIT-method. My already provided hack somehow allows what is specified in 2); however, it is a really dirty hack that will only work with editors and finds the FigureCanvas via the IAdaptable-mechanisms of the editor. I will upload a more decent solution that uses the AGR resolving mechanism to locate the FigureCanvas inside the editor. However, it will still be a hack, as the resolving beyond the FigureCanvas (which is the level that is currently recognized by AGR) has to be added manually in the VerificationCommand (the glabal widget resolving mechanisms do not go beyond the widget level), what is currently done by adding the position to the objectId of the FigureCanvas (I now store the objectId additionally to the contextId in the Verification meta data). In order to realize it thoroughly, the possibility to resolve beyond the widget level, which is the essential part of 1), would have to be realized first. I investigated this to some extend, and I believe the following would have to be done: 1) extend the WidgetIdentifier/WidgetResolver mechanism to not rely on wizeards but more generally on UIObjects (which could go beyond the widget level, e.g. to have draw2d figures as valid command targets) 2) the widget resolving in MacroUtil and MacroObjbectLocator would have to be generalized accordingly, so that the WidgetID<->Widget forward and back resolving would work more general on UIObjects (the same holds for the WidgetResolver that would also have to be extended). 3) All dependencies on Widget, e.g. in CommandTarget would have to be generalized as well. Any comments? Created attachment 84044 [details]
Draw2d figures as verification hooks
Enhanced version that modifies the VerificationHook mechanism to store the objectId additionally to the contextId. For draw2d figures, the position is added to the objectId of the FigureCanvas to be able to relocate the figure nested in it.
Thanks Alex. This looks like great progress. Unfortunately, we do not have the time to review the patch in detail. My only concern is with moving existing code around and breaking API. We would prefer to provide extensions (via subclass and extension point) rather than break API. Although this component is moving to as-is (see http://wiki.eclipse.org/4.5_Component_Reorganization), we will still accept a fully completed and tested patch including new test cases. Once you have a completed patch and new test cases, attach it to the enhancement and we will go through the necessary legal process: http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf In TPTP 4.5, the AGR was moved from a Technology Preview component to an As-Is component. As-Is components are primarily provided for prior users but imply no support (for example, defects, news group, and mailing lists) or commitment to triage or resolve opened defects. For this defect to be considered, please re-open with an attached patch including code to resolve the symptom and test cases to test the fix. Created attachment 88247 [details] Revision of AGR to allow its extension to support testing of Draw2d applications As agreed with Paul, please find attached my completely refactored version of AGR, which allows to extend AGR with the possibility to extend AGR to support Draw2d applications. The archive also contains a new org.eclipse.tptp.test.auto.gui.draw2d plugin to demonstate the new extensibility support. It supports the creation of verification hooks for IFigures inside a FigureCanvas to demonstrate the potential of the proposed revision. The refactoring of the AGR plugin includes the following changes (you can find a more detailed list inside the CHANGES.txt contained org.eclipse.tptp.test.auto.gui): - Complete refactoring of the widget resolving/deresolving mechanism to allow resolving beyond the widget level. While the current implementation of AGR does only allow to extend the resolving mechanism (via the WidgetResolver extension point), the resolving/dersolving is now completely bidirectional. To achieve this, this revision includes a replacement of the old WidgetResvoler extension mechanism with a new UIObjectResolverDelegate one. All new extensions do not only have to deal with proper resolving of UIObjects (i.e. to compute an id form them during recording), but also with the deresolving (i.e. locating) of them (during playback). - Creation of a new extension point to exchange the command creation mechanism. This is also needed for Draw2d extensions, as the current command implementations do not "focus" on the subwidget level (e.g. the VerficationCommand does not recognize an IFigure as a valid target). - Resolving of bug #206768 (->FIXED) - Resolving of bug #201248 by introducing a new extended scope mode to the verification hook insertion (i.e. not only the context, but the selected UIObject can be inserted into the hook method, if selected) (->FIXED) - Revision of improper fix for bug #147766. As documented in CHANGES.txt, the current workaround for ambiguous widget identifiers is no legal one and was thus revised. I propose to reopen the bug and to work on resolving unique identifiers for those widgets where more than one match would be found during deresolving (->REOPEN) - Several minor improvements and fixes to achieve a more proper and better maintainable code base. The revised AGR version comes with some changes to the macro format (due to clean-ups in some commands), it is however capable of reading and playing formerly recorded macros (i.e. it is backwards compatible). I propose to adopt the patch to the next TPTP release and would then be willing to support further improvements and enhancements (some commands still perform parts of the resolving/deresolving by themselves and should be refactored as well to use the newly introduced mechanism). Given Alexander's patch/test cases, reopening this enhancement for consideration during the planning cycle of the next TPTP release. Thanks Alexander for your contribution. *** Bug 206768 has been marked as a duplicate of this bug. *** Alexander, please review the Eclipse Legal process for contributions (see http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) and the necessary information for this contribution. I hereby confirm that the code of the patch/enhancement was written 100% by myself, and I agree to contribute the code to Eclipse under the terms of the EPL. Alexander Nyßen Created attachment 88970 [details] Revision of enhancement to AGR which additionally contains a workaround to deal with bug #147766 As several existing TPTP test cases seem to be affected by bug #147766, I built in a workaround to my enhancement to deal with the resulting ambiguity issues (the prior version of my enhancement only reported that there is an ambiguity problem and failed). The workaround works as follows: -During recording, when trying to resolve an IMacroObject into an IMacroObjectIdentifier (in MacroObjectResolver) it is checked (in case the contained widget is a Control) if the IMacroObjectIdentifier being resolved can be unambigously deresolved back into the respective IMacroObject. If this is not the case (i.e. if an ambiguity is detected), a suffix is added to the widget id (of the IUIObjectIdentifier nested in the IMacroObjectIdentifier) to point to the desired match. The suffix is of the form !!!x, where x is the index of the desired match. -During playback, the locateVisibleChild method in IUObjectDeprecatedDeresolvingSupport evaluates, if the provided identifier has a respective suffix and returns the desired match. Otherwise it throws an Exeption to denote an ambiguity issue. To demonstrate/test the workaround, I added a new AGR test case to org.eclipse.tptp.test.auto.gui.test, which uses the already documented build.properties issue (see bug# 147766). Existing test suites, which are affected by bug #147766, can thus be preserved by adding a respective !!!x suffix to all ambiguous widget identifiers (those are reported during playback if no suffix is provided). It should however be clear, that this is just a workaround and a decent solution would have to be build into the UIObjectResolverDelegates (as they deliver ambiguous identifiers) Created attachment 89819 [details]
Updated User Guide
Updated the User Guide of AGR 4.5.0 to reflect the changes incorporated into the enhancement (new resolving, extension to verification hooks, Draw2d extensions).
Created attachment 90299 [details]
Revision of enhancement to AGR, fixing object ids were not stored in object mine, defines new MacroVersion 1.1 to denote changes
The formerly uploaded enhancement did not properly store the objectId of an UIobject (additonally to the widgetId) in the object mine, but only embedded in the macro.
As it seemed to be misleading in this context to add the objectId as suffix to the widgetId (and store it with the widgetId, as it was done by my formerly uploaded enhancement), an additional objectId attribute was introduced (in the macro and the object mine). The macro version was changed to Version 1.1 to reflect this. An updater to migrate from 1.0 to 1.1 was implemented. Further, AUTOGUIRunner was enhanced to check for the correct macro version when executing a test macro.
As it was regarded to be obscure that several attributes were used to actually store the widgetId (in case of shells, the id-attribute was used, in case of items the path-attribute was used, and for other objects the wigetId-attrbite; in the object mine just the id-attribute was used), this was changed to now always use the widgetId-attribute to store a respective widget id (the updater migrates this as well). That is, the attributes stored for a macro object (directly in the macro or in the object mine) are now contextId and widgetId, the optional objectId, as well as the resolverId, no matter what type of UI object is resolved.
Requesting AG review and PMC approval for this enhancement to be included in the TPTP 4.5 plan. Duwayne, I can own this enhancement since I have been working with Alexander on his contribution. Alexander has confirmed that his contribution falls under figure 3 in http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf: Written 100% by Submitting Contributor (Non-Committer) and Submitted under the terms of the EPL. We will open a Contribution Questionnaire when the enhancement/contribution has been approved by the PMC. Having investigated non-fixed bugs for AGR, I noticed that bugs #207041 and #110416 are also fixed by my proposed patch. Maybe one could add some dependencies there, I will drop a respective commands on both. Having investigated non-fixed bugs for AGR, I noticed that bug #207041 and bug #110416 are also fixed by my proposed patch. Maybe one could add some dependencies there, I will drop a respective comment on both. AG Approval: http://dev.eclipse.org/mhonarc/lists/tptp-pmc/msg04566.html PMC Approval: http://wiki.eclipse.org/TPTP-AG-20080331#Test_Project Deferring to I7 as approved on the latest AG call (http://wiki.eclipse.org/TPTP-AG-20080331#Test_Project). Created attachment 95022 [details]
Revision of AGR to support capturing/replay of mouse move commands in position based mode
Added a new command type to record/playback mouse move commands in position based mode.
This is essentially when testing GEF-based applications, as it may be necessary to explicitly move the cursor to a certain position and wait there (e.g. when clicking the palette and selecting a creation tool and moving the cursor to the editor's content pane). This was observed to be very essential on Linux/GTK, as selecting a creation tool and clicking in the content pane area with mouse click commands was too fast.
Mouse move commands are automatically inserted during recording in position based mode before each mouse up, down and click command. Multiple successive mouse move commands are merged together to just one (specifying the final cursor position).
In this context, refactroed existing position based commands to use the merge operation as in case of non-position based commands (and not leave this functionality to the command creation factory, as this was done before).
Created attachment 95024 [details]
Revision of user guide to reflect changes in latest revision of AGR
(In reply to comment #33) > We will open a Contribution Questionnaire when the enhancement/contribution has > been approved by the PMC. CQ: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2246 Hi Alexander, I know you have answered some of these questions, but Eclipse Legal requires answers to each of following questions for the CQ: a. He has authored 100% of the code contained in the contribution b. He has the rights to donate the code to Eclipse under the EPL c. He is submitting the code for inclusion in future Eclipse releases under the EPL I hereby confirm that the contribution was written 100% by myself (while the zip-File attached as attachment does not only contain my contribution but the overall modified AGR code base taken from the TPTP repository). I hereby also confirm that I have the rights to donate my contributed code to Eclipse under terms of the EPL and that I submit it as well for inclusion to future releases. (In reply to comment #38) > Created an attachment (id=95022) [details] The following files require default Eclipse copyright and license header: http://www.eclipse.org/tptp/home/documents/process/development/copyright.html Created attachment 96551 [details]
Revision, containing fixed copyright entries
Fixed/Added copyright comments for all files being newly created by me. Left those files of existing plug-ins, which were not created by me and did formerly also not contain copyright entries, which are:
Plug-in: org.eclipse.tptp.test.auto.gui
-TestSuiteToXMLConvertor
-VerificationHookClassGenerator
-VerificationHookMethodGenerator
Plug-in: org.eclipse.tptp.test.auto.gui.tests
-AllTests
-TestAutoGUIUtil
-TestsPlugin
-AutoGUINodeList
-build.properties
(In reply to comment #40) > (In reply to comment #33) > > > We will open a Contribution Questionnaire when the enhancement/contribution has > > been approved by the PMC. > > CQ: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2246 > Approved. Patch and documentaiton reviewed and approved. Alexander, please provide a rough estimate of the number of hours worked on this patch. I think it roughly has to be somewhat around 50h. Updating Alexander's hours worked. Since we will be running AGR test suites to smoke test the RC5 candidate, we will defer the integration, testing, and check-in until RC5 has dropped (target: June 17). This enhancement also requires updates to the [http://www.eclipse.org/tptp/test/documents/userguides/Intro-Auto-GUI-4-5-0.html AGR user guide] for the outstanding function (see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=219951 Support capturing additional draw2d related events when recording user's interactions with a GEF editor]). Paul, please confirm the triaging of this enhancement Since this enhancement is isolated to the AGR component (as-is component) and many community members are wait for this enhancement, re-targeting to 4.5.1. Alexander, the number of changes are making the merge of the code very difficult. Since your are more familiar with your changes than I, can you please create a patch file (http://help.eclipse.org/ganymede/topic/org.eclipse.platform.doc.user/tasks/tasks-68c.htm) based on the latest code in CVS (HEAD)? To decrease the Release Engineering effort for this enhancement, we will package everything in the existing AGR plug-in/feature. That is, the classes in the org.eclipse.tptp.test.auto.gui.draw2d plug-in can be moved to the following packages in the org.eclipse.tptp.test.auto.gui plug-in: org.eclipse.tptp.test.auto.gui.internal.draw2d.commands org.eclipse.tptp.test.auto.gui.internal.draw2d.resolvers Please make these changes before creating the patch file. The same applies to the tests in the org.eclipse.tptp.test.auto.gui.draw2d.tests plug-in; they can be moved to the org.eclipse.tptp.test.auto.gui.tests plug-in. Since binary files (e.g. *.testsuite) cannot be added to the patch file, please attach a patch file for the code changes to the org.eclipse.tptp.test.auto.gui plug-in and attach the updated org.eclipse.tptp.test.auto.gui.tests plug-in, which include your new tests. In addition, I see that you have removed the org.eclipse.tptp.test.auto.gui.widgetResolver extension point. This extension point is considered API and cannot be removed (see http://www.eclipse.org/tptp/home/documents/process/development/api_contract.html). Finally, please change the copyright date year to 2008 instead of {2008}. Thanks Alexander. Yes, I see what I can do. Two decisions however have to be made before I can start with it: 1) I renamed all packages by removing the "internal" segment of all packages to denote that the code could now serve as a starting point for defining a real public API. Do you want me to revise that in order to preserve traceability because most of my changes indeed affected only the resolving mechanism (but the renaming of course would include the only moved resources into the patch)? 2) As already stated, the widged resolving mechanism was totally revised by me. Due to the new resolving mechanism, the old extension point widgetResolver makes no sense any more (it is replaced by the uiObjectResolverDelegate extension point). Here, we have to decide between two solutions: 2a) Instead of also preserving the widgetResolver extension point I decided to remove it completely and to instead offer support of an easiy migration of existing widgetResolvers to the new extension mechanism by means of the UIObjectDeprecatedDeresolvingSupport class, which I introduced for this purpose (I migrated the existing widgetResolvers to AdaptiveUIObjectResolverDelegate and NonTrivialUIObjectResolverDelegate respectively using this mechanism as well). As all existing WidgetResolvers can thus be easily migrated to the new interface, the old extension point could be removed without loosing general backwards compability. I prefer this solution because it clearly points out the new extension mechanisms for bidirectional deresolving is the only valid extension mechanism offered for future use. 2b) The alternative would be to preserve the old extension point in parallel (marking it deprecated) to the new uiObjectResolverDelegate and to adapt them internally to the new interface using the DeprecatedDeresolvingSupport. I do not prefer this solution because it would introduce a lot of internal overhead just to keep direct compatibility to an outdated extension mechanism. If however this is what you want I can build in the respective functionality as well. (In reply to comment #54) Thanks for your reply. I have added some comments below: > Yes, I see what I can do. Two decisions however have to be made before I can > start with it: > > 1) I renamed all packages by removing the "internal" segment of all packages to > denote that the code could now serve as a starting point for defining a real > public API. Do you want me to revise that in order to preserve traceability > because most of my changes indeed affected only the resolving mechanism (but > the renaming of course would include the only moved resources into the patch)? According to our API Contract (http://www.eclipse.org/tptp/home/documents/process/development/api_contract.html) we should only make public APIs that are absolutely necessary for extensibility (e.g. interfaces required for our extension points). All other APIs should have 'internal' in the package name. Initially, non-internal is marked provisional either in the package name (experimental) or with the @provisional JavaDoc tag in the class comment (stable). Your public APIs would be considered stable provisional APIs. > 2) As already stated, the widged resolving mechanism was totally revised by me. > Due to the new resolving mechanism, the old extension point widgetResolver > makes no sense any more (it is replaced by the uiObjectResolverDelegate > extension point). Here, we have to decide between two solutions: > > 2a) Instead of also preserving the widgetResolver extension point I decided to > remove it completely and to instead offer support of an easiy migration of > existing widgetResolvers to the new extension mechanism by means of the > UIObjectDeprecatedDeresolvingSupport class, which I introduced for this purpose > (I migrated the existing widgetResolvers to AdaptiveUIObjectResolverDelegate > and NonTrivialUIObjectResolverDelegate respectively using this mechanism as > well). As all existing WidgetResolvers can thus be easily migrated to the new > interface, the old extension point could be removed without loosing general > backwards compability. I prefer this solution because it clearly points out the > new extension mechanisms for bidirectional deresolving is the only valid > extension mechanism offered for future use. > > 2b) The alternative would be to preserve the old extension point in parallel > (marking it deprecated) to the new uiObjectResolverDelegate and to adapt them > internally to the new interface using the DeprecatedDeresolvingSupport. I do > not prefer this solution because it would introduce a lot of internal overhead > just to keep direct compatibility to an outdated extension mechanism. If > however this is what you want I can build in the respective functionality as > well. > We are bound by our API Contract (http://www.eclipse.org/tptp/home/documents/process/development/api_contract.html) with our users and consumers and extension points are considered APIs. That said, we need to deprecate but maintain the old extension point (and any other non-internal extension points/APIs). Please implement solution 2b. (In reply to comment #55) > (In reply to comment #54) > Thanks for your reply. I have added some comments below: > > Yes, I see what I can do. Two decisions however have to be made before I can > > start with it: > > > > 1) I renamed all packages by removing the "internal" segment of all packages to > > denote that the code could now serve as a starting point for defining a real > > public API. Do you want me to revise that in order to preserve traceability > > because most of my changes indeed affected only the resolving mechanism (but > > the renaming of course would include the only moved resources into the patch)? > According to our API Contract > (http://www.eclipse.org/tptp/home/documents/process/development/api_contract.html) > we should only make public APIs that are absolutely necessary for extensibility > (e.g. interfaces required for our extension points). All other APIs should > have 'internal' in the package name. Initially, non-internal is marked > provisional either in the package name (experimental) or with the @provisional > JavaDoc tag in the class comment (stable). Your public APIs would be > considered stable provisional APIs. > > 2) As already stated, the widged resolving mechanism was totally revised by me. > > Due to the new resolving mechanism, the old extension point widgetResolver > > makes no sense any more (it is replaced by the uiObjectResolverDelegate > > extension point). Here, we have to decide between two solutions: > > > > 2a) Instead of also preserving the widgetResolver extension point I decided to > > remove it completely and to instead offer support of an easiy migration of > > existing widgetResolvers to the new extension mechanism by means of the > > UIObjectDeprecatedDeresolvingSupport class, which I introduced for this purpose > > (I migrated the existing widgetResolvers to AdaptiveUIObjectResolverDelegate > > and NonTrivialUIObjectResolverDelegate respectively using this mechanism as > > well). As all existing WidgetResolvers can thus be easily migrated to the new > > interface, the old extension point could be removed without loosing general > > backwards compability. I prefer this solution because it clearly points out the > > new extension mechanisms for bidirectional deresolving is the only valid > > extension mechanism offered for future use. > > > > 2b) The alternative would be to preserve the old extension point in parallel > > (marking it deprecated) to the new uiObjectResolverDelegate and to adapt them > > internally to the new interface using the DeprecatedDeresolvingSupport. I do > > not prefer this solution because it would introduce a lot of internal overhead > > just to keep direct compatibility to an outdated extension mechanism. If > > however this is what you want I can build in the respective functionality as > > well. > > > We are bound by our API Contract > (http://www.eclipse.org/tptp/home/documents/process/development/api_contract.html) > with our users and consumers and extension points are considered APIs. That > said, we need to deprecate but maintain the old extension point (and any other > non-internal extension points/APIs). Please implement solution 2b. Thanks Paul, I have renamed the packages back to internal so I have the chance to create a patch (otherwise, I do not have the chance to trace any changes that have occured within the HEAD since). I think we can think about defining a stable public API as soon as the patch is then integrated. Having started on 2b, the question raises whether it would be legal to at least move the deprecated code from the internal.core package to a more appropriate place (because I reorganized the packages) or does the IWidgetResolver interface have to stay in place because the extension point refers to it? Further, do you really want to merge the draw2d extensions into the auto gui project, as this would introduce a GEF dependency to TPTP AGR, which is currently not in place? Keeping it in a separate plug-in seems to be the better solution to me, also because the plug-in will probably grow as soon as further Draw2d/GEF support is built in. (In reply to comment #56) > Thanks Paul, I have renamed the packages back to internal so I have the chance > to create a patch (otherwise, I do not have the chance to trace any changes > that have occured within the HEAD since). I think we can think about defining a > stable public API as soon as the patch is then integrated. All non-internal classes/methods (with or without the @provisional tag) are considered stable API. For new stable API, we still want to keep the @provisional tag in the event that changes need to be made in the future. > Having started on 2b, the question raises whether it would be legal to at least > move the deprecated code from the internal.core package to a more appropriate > place (because I reorganized the packages) or does the IWidgetResolver > interface have to stay in place because the extension point refers to it? Please keep it in the same package so existing implementations do not need to be changed. > Further, do you really want to merge the draw2d extensions into the auto gui > project, as this would introduce a GEF dependency to TPTP AGR, which is > currently not in place? Keeping it in a separate plug-in seems to be the better > solution to me, also because the plug-in will probably grow as soon as further > Draw2d/GEF support is built in. You make a good point. Lets use the same feature and a separate plug-in. Spoke with Alexander and agreed that we should defer this enhancement to 4.5.2 given the shorten development schedule for 4.5.1 and the number of outstanding changes required. Created attachment 108487 [details]
Patch manifesting refactorings to org.eclipse.tptp.test.auto.gui (not including added icons)
Attached find the patch to org.eclipse.tptp.test.auto.gui. The patch does not contain the added icons, which I will attach successively bundled with the test plug-ins and the draw2d extension plugin in an archive file.
Created attachment 108488 [details]
Archive containing Draw2d extension, test plugins, as well as icons (not included in patch)
Created attachment 108613 [details]
As the patch does not seem to include the extension point schemas as well, I added an archive of the tptp.test.auto.gui plug-in, which contains the complete contents.
(In reply to comment #61) > Created an attachment (id=108613) [details] > As the patch does not seem to include the extension point schemas as well, I > added an archive of the tptp.test.auto.gui plug-in, which contains the complete > contents. > Thanks Alexander. Yes, the Eclipse Team support does not support binary files in patches. We will integrate this patch (and updated documentation and binary files) after 4.5.2 development begins (Sept. 24 - http://www.eclipse.org/tptp/home/project_info/releaseinfo/4.5.2/schedule.html). Again, thanks for your contribution! Comment on attachment 108487 [details]
Patch manifesting refactorings to org.eclipse.tptp.test.auto.gui (not including added icons)
adding iplog+ per Ganymede IP log
Deferring to TPTP 4.5.3 since TPTP 4.5.2 development is closed (http://www.eclipse.org/tptp/home/project_info/releaseinfo/4.5.2/schedule.html) and P2 defects are not considered candidates during release shut-down. Approved for the TPTP 4.5.3 defect plan (see PMC minutes from 02/25/09). Created attachment 127394 [details]
Archive containing complete patch (all AGR projects, newly created AGR-Draw2D projects, and userguide)
-Updated with lates changes from repository (since upload of former patch)
-Updated copyright notices (2008->2009) in all files that were affected by patch
Created attachment 127395 [details] Source code patch related to attachment 127394 [details] Contains a patch to apply the source code changes (not the added code or changed binaries), incorporated into attachment 1273945. Comment on attachment 108613 [details]
As the patch does not seem to include the extension point schemas as well, I added an archive of the tptp.test.auto.gui plug-in, which contains the complete contents.
Replaced by latest attachments.
Comment on attachment 108488 [details]
Archive containing Draw2d extension, test plugins, as well as icons (not included in patch)
Replaced with latest attachments.
Comment on attachment 108488 [details]
Archive containing Draw2d extension, test plugins, as well as icons (not included in patch)
Replaced with latest attachment
Comment on attachment 108487 [details]
Patch manifesting refactorings to org.eclipse.tptp.test.auto.gui (not including added icons)
Replaced with latest attachments
Comment on attachment 108488 [details]
Archive containing Draw2d extension, test plugins, as well as icons (not included in patch)
Replaced with latest attachments
Approved by the PMC to defer to TPTP 4.6.1. After reviewing the open-source community contribution, the risk is too high (excessive API changes) to deliver the patch in TPTP 4.6 since TPTP uses the AGR for internal testing. Alexander, can you please build an AGR plug-in with the patch and attach it to the Bugzilla for the open-source community use/testing? (In reply to comment #73) > Alexander, can you please build an AGR plug-in with the patch and attach it to > the Bugzilla for the open-source community use/testing? Once attached, we can add a reference to the AGR Getting Started (http://www.eclipse.org/tptp/test/documents/gettingstarted/Automated_GUI_Recorder_Getting_Started.html). Created attachment 138251 [details]
AGR 4.6.0 (patched version)- Binaries
Updated, zipped version of AGR, not including Draw2d Enhancements
Created attachment 138252 [details]
Draw2D Extensions for AGR 4.6.0 - Binaries
Enables user to insert verification hooks on individual figures.
Created attachment 138255 [details]
Archive containing complete contribution sources (modified AGR projects, newly created AGR-Draw2D projects, and extended userguide), adopted to TPTP 4.6.0
Created attachment 138256 [details] Source code patch related to attachment 138255 [details], i.e. adopted to TPTP 4.6.0 Thanks Alexander. I added a reference to the AGR Getting Started (http://www.eclipse.org/tptp/test/documents/gettingstarted/Automated_GUI_Recorder_Getting_Started.html#4.0). Comment on attachment 138255 [details]
Archive containing complete contribution sources (modified AGR projects, newly created AGR-Draw2D projects, and extended userguide), adopted to TPTP 4.6.0
Changed description to better reflect what is provided by this archive.
Comment on attachment 127394 [details]
Archive containing complete patch (all AGR projects, newly created AGR-Draw2D projects, and userguide)
Marking this as obsolete, as it is related to TPTP 4.5.
Comment on attachment 127395 [details] Source code patch related to attachment 127394 [details] Marking this as obsolete, as it is related to TPTP 4.5. Comment on attachment 95024 [details]
Revision of user guide to reflect changes in latest revision of AGR
Marking as obsolete, as an updated version is included in the latest overall archive.
(In reply to comment #79) > Thanks Alexander. > > I added a reference to the AGR Getting Started > (http://www.eclipse.org/tptp/test/documents/gettingstarted/Automated_GUI_Recorder_Getting_Started.html#4.0). > Thanks Paul. Maybe instead of referencing the overall source archive within the getting started guide, it would probably be easier for community members to find references to the two binary archives (containing the patched AGR as well as the Draw2d Extensions) there. (In reply to comment #84) > (In reply to comment #79) > > Thanks Alexander. > > > > I added a reference to the AGR Getting Started > > (http://www.eclipse.org/tptp/test/documents/gettingstarted/Automated_GUI_Recorder_Getting_Started.html#4.0). > > > > Thanks Paul. Maybe instead of referencing the overall source archive within the > getting started guide, it would probably be easier for community members to > find references to the two binary archives (containing the patched AGR as well > as the Draw2d Extensions) there. > Done. Thanks for the suggestions and attachments. Deferring to TPTP 4.5.3 since there has been no feedback on the patch build (http://www.eclipse.org/tptp/test/documents/gettingstarted/Automated_GUI_Recorder_Getting_Started.html#4.0). Resolving as fixed since code/binaries are publicly available. Closing for originator since he is no longer part of the project. |