|Re: null text generated in editor plugin.xml [message #1399980 is a reply to message #1399069]
||Sun, 13 July 2014 13:46
| Ed Merks
Registered: July 2009
On 12/07/2014 3:30 AM, Alain Picard wrote:
> I have discovered what appears to be a bug.
> When I generate my editor code, my plugin.xml gets a number of null
> text fragments all over the place.
I see. I know someone else mentioned that a while back, but I've never
> I ran in debug and found that this happens during the mergePluginXML
> in AbstractGeneratorAdapter.
> What ends up happening is that the oldExtension.content is set to null
> here (see arrow):
> // If the new match has the same non-null generation key.
> ExtensionData newExtension = newExtensions.get(index);
> if (oldExtension.generated != null &&
> // Set up the old extension up to pull the new content.
> --> oldExtension.content = newExtension.content;
> // Set up the new extension to block it being pushed.
> newExtension.content = null;
> I'm not sure about the full validity of the pattern here, but the root
> cause is that the regex used is not foolproof.
> We have this regex:
> EXTENSION_POINT_PATTERN = Pattern.compile("[
> \t]*(\n\r|\r\n|\n|\r)", Pattern.DOTALL);
> and the extension key is based on the extension point and the id
> (group 1 and 2 in the regex).
> But I have the following in my plugin.xml which causes duplicate
> matches since the id used is not the correct one, since it picks up
> the id from the category which is not unique:
> <extension point="org.eclipse.ui.newWizards">
> <!-- @generated ba -->
> <selection class="org.eclipse.core.resources.IResource"/>
> So what is the solution here?
Is there more than one newWizards in the same plugin.xml?
> Is a regex really appropriate ?
Processing XML would be better, but it's much harder to avoid messing up
the whole file, i.e., reordering all attributes alphabetically which DOM
serializers are always so happy to do.
> Please advise.
Please open a bugzilla with a sample that reproduces the problem.
Powered by FUDForum
. Page generated in 0.01994 seconds