Community
Participate
Working Groups
I often need to instantiate an IHunk. I have all the fields I want its members to return, but actually obtaining the IHunk is complicated: 1. Generate a patch that will result in an IHunk with the given values. 2. Generate a file against which the hunk will fail to apply. (You need to be careful here because if you accidentally generate a file against which the hunk successfully applies, this doesn't work - for example, the empty file won't work when trying to create a hunk that creates a file) 3. Parse the patch using ApplyPatchOperation.parsePatch 4. Try to apply the patch to the generated file using IFilePatch.apply 5. Extract the IHunk from IFilePatchResult.getRejects(). Something like a static factory method for IHunks would be a great improvement. static IHunk createHunk (String label, int startPosition, IInputStreamFactory originalContents, IInputStreamFactory patchedContents, String charset);
Since it involves API changes, it will not be fixed for 3.4. Reassigning to 3.5 for further investigation.
Also a way to create a IFilePatch from a set of IHunks would be good. Otherwise the usability of instantiated hunks would be somehow limited.
Created attachment 125904 [details] Patch_v01 An POC patch. Any comments are welcome. I added two methods to IFilePatch2 interface: addHunk(IHunk hunk); removeHunk(IHunk hunk); And two static methods in new PatchFactory class: IFilePatch2 createFilePatch(IPath oldPath, long oldDate, IPath newPath, long newDate); IHunk createHunk(int oldStart, int oldLength, int newStart, int newLength, String[] lines); My main concern is whether to allow API clients to add and remove IHunks from IFilePatch2. As an alternative we can give them a way to create an instance of IFilePatch2 from a set of hunks (which would be read-only in terms of contained hunks).
Created attachment 125905 [details] Patch_v01 An POC patch. Any comments are welcome. I added two methods to IFilePatch2 interface: addHunk(IHunk hunk); removeHunk(IHunk hunk); And two static methods in new PatchFactory class: IFilePatch2 createFilePatch(IPath oldPath, long oldDate, IPath newPath, long newDate); IHunk createHunk(int oldStart, int oldLength, int newStart, int newLength, String[] lines); My main concern is whether to allow API clients to add and remove IHunks from IFilePatch2. As an alternative we can give them a way to create an instance of IFilePatch2 from a set of hunks (which would be read-only in terms of contained hunks).
Sorry for the doubled comment. It isn't Bugzilla greatest day.
(In reply to comment #4) To sum up our morning discussion: > I added two methods to IFilePatch2 interface: > addHunk(IHunk hunk); > removeHunk(IHunk hunk); We're not adding add/remove methods to IFilePatch2 . We agreed that allowing clients to add/remove hunks to the patch can be error-prone. > And two static methods in new PatchFactory class: > IFilePatch2 createFilePatch(IPath oldPath, long oldDate, IPath newPath, long > newDate); > IHunk createHunk(int oldStart, int oldLength, int newStart, int newLength, > String[] lines); We will add PatchBuilder class. This facility class would help to create IFilePatch2 from arbitrary set of hunks. Its methods could look like this. #add(IFilePatch2 filePatch, Set hunksToAdd, boolean recalculate) returns IFilePatch2 #remove(IFilePatch2 filePatch, Set hunksToRemove, boolean recalculate) returns IFilePatch2 or #modify(IFilePatch2 filePatch, Set hunksToAdd, Set hunksToRemove, boolean recalculate) returns IFilePatch2 'recalculate' flag indicates whether to recalculate hunks position/lenght at the end of the operation. These methods would create new patches, so original patches would be untouched.
Created attachment 126312 [details] Patch_v02 Patch addressing Szymon's comments. It's still rough a bit but I still expect some input from the review about the proposed API shape.
Created attachment 126453 [details] Patch_v03 I talk to Szymon about the previous patch and we decided to change API little bit. The most important change is that through exposed API we ensure that IHunks that are aggregated by IFilePatch2 are always sorted in order they apply to the file. Moreover IHunks' the "after" postition is updated after Hunks are added/removed from the IFilePatch2 to keep the patch coherent.
Created attachment 126468 [details] Patch_v04 Adding @noextend tag to PatchBuilder and a few javadocs.
Released to HEAD.
