Community
Participate
Working Groups
While the Organize Manifest tool is very helpful, it would be more helpful if the user could review the changes that will be made before committing themselves. Today the only way to achieve this is to make sure that the project is commited to the repository before running the tool, and then comparing the changes with the stream. Please consider adding a preview page, which might be rather complicated since there can be multiple files updated and of course you can select multiple projects. Tricky, perhaps.
cool, may look at it once PDE survives M5
Assigning to Adam. Brian to advise/review.
Created attachment 74406 [details] lightly tested prototype
Created attachment 74506 [details] improved patch This patch: - Cleans up some inconsistencies with the wizard settings - Removes some unnecessary references and applies some best practices - Adds context highlighting for changes to manifest files and properties files (still not available for plugin.xml files due to bug 192863) - Removes the nondescript top level change item in the preview viewer (by marking the top level CompositeChange as synthetic) This patch still needs heavy testing to ensure no functionality has been broken and that the previewing works for all edge cases.
Created attachment 74578 [details] further improved patch Removed a couple unnecessary instance variables and corrected one unexternalized String.
It is my fault this bug has not been fixed yet. I have not been able to keep up with Adam :) When we started on the preview page, I told Adam to start easy and work up from there. During some final testing I seem to have come across a slight quirk in an advance case. To reproduce: 1. Open a Manifest.MF file which has been organize in the Manifest Editor. 2. From the Dependencies Tab, add a dependency to a new unused bundle. Do NOT save the file. 3. Run the Organize Manifest action, select preview. When prompted to save, select No. Notice how there won't be any changes. Do the same steps again, except in #2 add the dependency from the Manifest.MF source page (again, don't save and click No at the prompt). This time you will see the plug-in added in step #2 shows up in the preview. This happens because the modification to the form editor creates a TextChange. The TextChange is not applied until the user switches to the source page. So when we commit the buffers in the PDEModelUtility, the buffer is not update with the TextChange. There is another small detail. When we modify the Manifest.MF source page and run the OrganizeManifestAction without saving, the editor is saved upon the user selecting preview. If we can, we need to try to not save the editor until the user clicks OK.
Adam, I released the plugin.xml compare so you could go ahead with previewing plugin.xml changes. Unfortunately, the PDEUIMessages changes in your patch are now out of sync.
Created attachment 74719 [details] addresses issues in comment 6 and adds functionality in comment 7
Created attachment 74731 [details] more improvements Added a check for fragment.xml as well as plugin.xml to set the text type to PLUGIN2. This way fragments are also handled by the PluginContentMergeViewer. Also refactored both RenamePluginRefactor and OrganizeManifestRefactor into PDERefactor since they were identical.
Oh so pretty! I really liked the way you went back and refactored RenamePluginRefactor to PDERefactor so it can be reused, very thorough. And the use case with a dirty editor added only a slight bit of code, very elegant. The only modification I made was in PDEModelUtility. When creating the TextFileChange, I called TextFileChange.setSaveMode(TextFileChange.FORCE_SAVE). This caused dirty editors to be saved after the change was applied. This was just for consistency with the old way it worked. Adam, I am impressed how fast you were able to do this bug with very little help or guidance, good job!
It certainly is pretty. However, it is not quite right. The checkbox tree acts funny. When a node has two children, and one of them gets deselected, the parent node currently gets deselected. This is incorrect. If a parent node has n children, and m nodes are selected where 1 <= m < n, the parent node should have a green square, not completely lose its checked status. See the build page of the product editor and the Plug-ins tab of the Eclipse app launcher for examples.
Reopening to address the issue in comment 11.
closing since the tree is fine now.
adding noteworthy keyword
