Bugzilla – Full Text Bug Listing
| Summary: | [Patch] Apply Patch should have public API | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jeff Pound <jpound> |
| Component: | Compare | Assignee: | Bogdan Gheorghe <gheorghe> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | brockj, codex69, dmalcolm, ekuleshov, elias, jeff.bagu, Michael.Valenta, mik.kersten, mlists, pombredanne, thatnitind, tromey, villane |
| Version: | 3.1 | ||
| Target Milestone: | 3.3 M3 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 103932 | ||
| Attachments: | |||
|
Description
Jeff Pound
Created attachment 22533 [details] Creates public access for launching the ApplyPatch functionality. Here's a Patch that implements comment 1 CompareWithPatchAction becomes public API in org.eclipse.compare/ and provides a method to set the default patch location. If a project is selected then it will be selected in the wizard, if no project is select then the first one on the list is selected by default. Created attachment 22548 [details]
A sample plug-in showing an example use of the public CompareWithPatchAction
Attatching a sample use of the apply patch functionality. This is an adaptation
of the "HelloWorld" plug-in that launches the apply patch wizard with a default
patch path.
Thanks for the patch. Since APIs are frozen for 3.1 I cannot make it available for 3.1. But I'll try to get this into 3.2 as soon as 3.1 is ready. Created attachment 22638 [details]
Creates public access for ApplyPatch functionality with dialog settings control.
The last patch allowed a default patch file to be given for the wizard. This
one adds a PatchDialogSettings class which can be configured and passed to the
CompareWithPatchAction to set up the UI in more ways than just passing a patch
path (ie. useClipboard can be specified, patch given, etc..). If no
configuration is set, the current default configuration is used.
Essentially the same functionality, just a little more flexible than the first
patch :)
Jeff, can you please package a patch for 3.1 that would be possible to install from the update manager and maybe put it to your own update site at http://people.redhat.com/jpound/update You can find couple simple patches that can be used as a starting point at my update site at http://www.md.pp.ru/~eu/eclipse Thanks Eugene, The patched version of org.eclipse.compare is already available from http://people.redhat.com/jpound/updates with the feature "Bugizlla Plug-in for eclipse.org users". The feature for fedora users just includes the bug tracking stuff since the fedora eclipse packages ship with the patched org.eclipse.compare. The feature for upstream eclipse.org users includes the bug tracking stuff as well as the patched org.eclipse.compre. If you need the source version you should be able to check out org.eclipse.compare from the eclipse.org cvs repo and apply the patch attached to this report. (If you have the eclipse-bugzilla plug-in installed it can apply the patch directly from the bugzilla comment for you ;) The Apply Patch wizard has changed a bit in 3.2 (bug 110481). The patch wizard has been reworked a bit and now supports an Eclipse specific multi-project patch format. This change probably will cause parts of this patch to no longer match up. I'm working on porting (and improving) the patch for the 3.2 codebase. Is there a chance this will make it in before API freeze? Created attachment 34624 [details]
Compare API Patch - eclipse 3.2 M4
Revised patch for 3.2 codebase.
Provides API for specifying clipboard, file, or workspace resource as a source for the patch to be applied. The first page of the patch wizard (InputPatchPage) is then skipped and the patch specified is used. If no patch is specified, the current behaviour takes place.
This patch adds new API but does not break the current API and shouldn't break any other plug-ins that use org.eclipse.compare (assuming they don't use internal classes).
example of use:
CompareWithPatchAction compare = new CompareWithPatchAction();
compare.setPatchSource(PatchReader.CLIPBOARD);
compare.run(null);
(In reply to comment #9) > Compare API Patch - eclipse 3.2 M4 > > Revised patch for 3.2 codebase. Any chance of this getting into 3.2? How about 3.3? Please at least consider opening up the internal class if there are reasons this shouldn't be API, because Mylar's current patching functionality is stuck on the following goofy interaction, which should just be a single click: 1) right click patch in our editor 2) select "Copy to Clipboard" 3) invoke the patch wizard 4) apply from clipboard We are planning on addressing this issue in some form in 3.3. We are looking at providing API that supports the following: 1) Launch the Apply Patch wizard with a provided patch in the form of an IStorage (i.e. an IFile or some other stream). 2) Provide branding of the wizard through a CompareConfiguration (i.e. a custom wizard title, image, etc). (In reply to comment #13) > We are looking at providing API that supports the following: > > 1) Launch the Apply Patch wizard with a provided patch in the form of an > IStorage (i.e. an IFile or some other stream). I asked Jeff and he said this should be sufficient for what we originally wanted. Sounds perfect for our needs too. I assume that when an IStorage is provided the patch wizard will go immediately to the 2nd "verify" page since the input page won't be required? Yes, the behaviour of the wizard will be dictated by whatever inputs are supplied. If a patch is provided and a target is provided (or the patch is a Workspace patch), it will open right on the preview page. If a target is needed and none is provided it will open on the Target selection page. The list goes on... Added ApplyPatchOperation which allows the user to configure the ApplyPatchWizard with a patch, target, and UI elements (wizard title, wizard image, PreviewPatchPage / HunkMergePage labels + images). Verified in I20061031-0656 (In reply to comment #18) > Verified in I20061031-0656 Mihael, can you please clarify how this feature been verified? The JavaDoc for ApplyPatchOperation constructor promise the following: - If a patch is supplied, the initial input page is skipped. If a patch is not supplied the wizard will open on the input page. - If the patch is a workspace patch, the target selection page is skipped and the preview page is displayed. - If the patch is not a workspace patch and the target is specified, then the target page is skipped and the preview page is displayed. If a target is not specified, the wizard will open on the target selection page. But I can't find this login neither in ApplyPatchOperation, nor in PatchWizard or its pages. I am running on 3.3M3 and been trying to call ApplyPatchOperation. It always show the page that require to choose patch source (clipboard, file, workspace). It doesn't look like method PatchWizard.getNextPage() is not called when wizard is shown, and first page is not skipped. Also, can you please use ISource.getContents() to read patch content instead of reading it from the file? It would be easiest of you log bug reports for any problems you come across. |