Fixes corruption of e4xmi files when class is renamed

The corruption happens in a setup with a top level Maven project and plug-in projects in sub directories (eg bundles).
If the name of a Java handler class is renamed in the Java file the e4xmi file is found twice with
  full workspace path
  plug-in project path
This leads to 2 changes in one e4xmi file with the same text, offset and length.
If the old and new names are of different length, the corruption occurs.
This fix skips the change if the combination of attributes (file, text, offset, length) is already included for renaming.

Author: p-O-q

e4tools/bundles/org.eclipse.e4.tools.emf.editor3x/META-INF/MANIFEST.MF

@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %Bundle-Name
 Bundle-SymbolicName: org.eclipse.e4.tools.emf.editor3x;singleton:=true
-Bundle-Version: 4.10.200.qualifier
+Bundle-Version: 4.10.300.qualifier
 Bundle-RequiredExecutionEnvironment: JavaSE-21
 Require-Bundle: org.eclipse.ui;bundle-version="3.6.0",
  org.eclipse.core.runtime;bundle-version="3.29.0",

e4tools/bundles/org.eclipse.e4.tools.emf.editor3x/src/org/eclipse/e4/tools/emf/editor3x/refactorparticipants/RefactorParticipantDelegate.java

@@ -15,8 +15,11 @@
  ******************************************************************************/
 package org.eclipse.e4.tools.emf.editor3x.refactorparticipants;
 
+import java.net.URI;
 import java.util.HashMap;
+import java.util.HashSet;
 import java.util.Map;
+import java.util.Set;
 
 import org.eclipse.core.resources.IFile;
 import org.eclipse.core.resources.IProject;
@@ -57,11 +60,22 @@ public static CompositeChange createChange(IProgressMonitor pProgressMonitor, fi
 		final FileTextSearchScope scope = FileTextSearchScope.newWorkspaceScope(filenames, false);
 
 		final Map<IFile, TextFileChange> changes = new HashMap<>();
+		final Set<ChangeAttributes> uniqueChangeAttributes = new HashSet<>();
 		final TextSearchRequestor searchRequestor = new TextSearchRequestor() {
 
 			@Override
 			public boolean acceptPatternMatch(TextSearchMatchAccess matchAccess) throws CoreException {
 				final IFile file = matchAccess.getFile();
+
+				final ChangeAttributes changeAttributes = new ChangeAttributes(
+						file.getLocationURI(),
+						pModel.getNewTextCurrentIndex(),
+						matchAccess.getMatchOffset(),
+						matchAccess.getMatchLength());
+				if (!uniqueChangeAttributes.add(changeAttributes)) {
+					return false;
+				}
+
 				TextFileChange change = changes.get(file);
 
 				if (change == null) {
@@ -97,12 +111,13 @@ public boolean acceptPatternMatch(TextSearchMatchAccess matchAccess) throws Core
 				}
 
 				final ReplaceEdit edit = new ReplaceEdit(
-						matchAccess.getMatchOffset(),
-						matchAccess.getMatchLength(),
-						pModel.getNewTextCurrentIndex());
+						changeAttributes.offset(),
+						changeAttributes.length(),
+						changeAttributes.text());
 				change.addEdit(edit);
 				change.addTextEditGroup(new TextEditGroup(E4_MODEL_CHANGES,
 						edit));
+
 				return true;
 			}
 		};
@@ -131,4 +146,17 @@ public boolean acceptPatternMatch(TextSearchMatchAccess matchAccess) throws Core
 		}
 		return result;
 	}
+
+	/**
+	 * This record contains attributes for a single change. A change has to be
+	 * unique.
+	 * <p>
+	 * The {@code location} is an {@link IFile#getLocationURI()}, which may be
+	 * {@code null} for files without a local file-system location. A
+	 * {@code null} location is treated like any other value: two records with
+	 * {@code null} locations and otherwise equal fields are considered
+	 * duplicates. For e4xmi files on disk this case does not arise in practice.
+	 */
+	private static record ChangeAttributes(URI location, String text, int offset, int length) {
+	}
 }