Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » GMF (Graphical Modeling Framework) » Solution for exceeding the 65535 bytes limit error
Solution for exceeding the 65535 bytes limit error [message #1752847] Sun, 29 January 2017 02:47 Go to next message
Lainis 20 is currently offline Lainis 20Friend
Messages: 26
Registered: November 2016
Junior Member
Hi,
When I generate the editor with GMF I get the following errors: The code of method getViewChildren(View, Object) is exceeding the 65535 bytes limit

The code of method getNodeVisualID(View, EObject) is exceeding the 65535 bytes limit

The code of method addDestroyChildNodesCommand(ICompositeCommand) is exceeding the 65535 bytes limit

One of the code lines is around 90.000 lines. I cannot simplify or change the ecore. Is there a way or a GMF solution for this instead of split the method manually?

In case not I have read about templates and xpt files to split the methods but the links that are here http://wiki.eclipse.org/Graphical_Modeling_Framework/Tutorial/Part_3#Customizing_generation_templates are not available. Can anyone provide me a link to understand how a template works and how to use it.

Thank you so much
Re: Solution for exceeding the 65535 bytes limit error [message #1752871 is a reply to message #1752847] Mon, 30 January 2017 08:04 Go to previous messageGo to next message
Aurélien Pupier is currently offline Aurélien PupierFriend
Messages: 634
Registered: July 2009
Location: Grenoble, FRANCE
Senior Member

Hello,

I updated the link on http://wiki.eclipse.org/Graphical_Modeling_Framework/Tutorial/Part_3#Customizing_generation_templates (waiting for moderation)

the correct link is http://community.bonitasoft.com/customize-your-gmf-editor-customizing-templates

regards,


Aurélien Pupier - Red Hat
Senior Software Engineer in Fuse Tooling team
Re: Solution for exceeding the 65535 bytes limit error [message #1753766 is a reply to message #1752871] Thu, 09 February 2017 22:05 Go to previous messageGo to next message
Lainis 20 is currently offline Lainis 20Friend
Messages: 26
Registered: November 2016
Junior Member
Hi Aurelien,

Thanks, I use the tutorial you suggest and it works perfectly.
But I have an error now. I'm trying to modify the NodeItemSemanticEditPolicy to split the method addDestroyChildNodesCommand. And I get this error:
Problems while generating code
Can't organize imports due to syntax errors in the compilation unit StrategyElementItemSemanticEditPolicy.java
Can't organize imports due to syntax errors in the compilation unit BusinessElementItemSemanticEditPolicy.java
Can't organize imports due to syntax errors in the compilation unit ApplicationElementItemSemanticEditPolicy.java
Can't organize imports due to syntax errors in the compilation unit ... Others units

and I do not understand why.

My xpt modifies is this:

/*
* Copyright (c) 2007, 2010 Borland Software Corporation and others
*
* All rights reserved. This program and the accompanying materials
* are made available under the terms of the Eclipse Public License v1.0
* which accompanies this distribution, and is available at
* http://www.eclipse.org/legal/epl-v10.html
*
* Contributors:
* Alexander Shatalin (Borland) - initial API and implementation
* Artem Tikhomirov (Borland) - [257632] do not rely on EditPart presence for element deletion
*/

«REM»
This template should be called only for non-design nodes (modelFacet != null)
because *ItemSemanticEditPolicy responsible for dealing with semantic model
elements and meaningless (should not be generated) for pure design nodes.
«ENDREM»

«IMPORT 'http://www.eclipse.org/gmf/2009/GenModel

«EXTENSION xpt::diagram::editpolicies::Utils»

«DEFINE NodeItemSemanticEditPolicy FOR gmfgen::GenNode-»
«EXPAND xpt::Common::copyright FOR getDiagram().editorGen-»
package «getDiagram().editPoliciesPackageName»;

«EXPAND xpt::Common::generatedClassComment»
public class «itemSemanticEditPolicyClassName» extends «getDiagram().getBaseItemSemanticEditPolicyQualifiedClassName()» {

«EXPAND xpt::diagram::editpolicies::BaseItemSemanticEditPolicy::defaultConstructor-»

«EXPAND xpt::diagram::editpolicies::childContainerCreateCommand::childContainerCreateCommand FOR childNodes->asSequence()-»

«EXPAND getDestroyElementCommand-»
«IF hasChildrenOrCompartments(self)-»
«EXPAND addDestroyChildNodesCommand-»
«ENDIF-»
«EXPAND generateMethods-»
«EXPAND xpt::diagram::editpolicies::linkCommands::linkCommands-»

«EXPAND additions-»
}
«ENDDEFINE»

«DEFINE getDestroyElementCommand FOR gmfgen::GenNode-»
«EXPAND xpt::Common::generatedMemberComment»
protected org.eclipse.gef.commands.Command getDestroyElementCommand(org.eclipse.gmf.runtime.emf.type.core.requests.DestroyElementRequest req) {
org.eclipse.gmf.runtime.notation.View view = (org.eclipse.gmf.runtime.notation.View) getHost().getModel();
org.eclipse.gmf.runtime.emf.commands.core.command.CompositeTransactionalCommand cmd = new org.eclipse.gmf.runtime.emf.commands.core.command.CompositeTransactionalCommand(getEditingDomain(), null);
cmd.setTransactionNestingEnabled(false);
«EXPAND destroyEdges('view')-»
org.eclipse.emf.ecore.EAnnotation annotation = view.getEAnnotation("Shortcut");«EXPAND xpt::Common::nonNLS»
if (annotation == null) {
// there are indirectly referenced children, need extra commands: «childNodes->union(compartments.childNodes->asBag())->exists(not isDirectlyOwned(self))»
«IF hasChildrenOrCompartments(self)-»
addDestroyChildNodesCommand(cmd);
«ENDIF-»
addDestroyShortcutsCommand(cmd, view);
// delete host element
cmd.add(new org.eclipse.gmf.runtime.emf.type.core.commands.DestroyElementCommand(req));
} else {«REM»Here, we may play smart and don't generate else for non-toplevel nodes(which can't be shortcuts). Is it worth doing?«ENDREM»
cmd.add(new org.eclipse.gmf.runtime.diagram.core.commands.DeleteCommand(getEditingDomain(), view));
}
return getGEFWrapper(cmd.reduce());
}
«ENDDEFINE»

«DEFINE generateMethods FOR gmfgen::GenNode-»
«EXPAND destroyEdges('cnode') FOREACH childNodes-»
«ENDDEFINE»

«DEFINE addDestroyChildNodesCommand FOR gmfgen::GenNode-»

«EXPAND xpt::Common::generatedMemberComment»
private void addDestroyChildNodesCommand(org.eclipse.gmf.runtime.common.core.command.ICompositeCommand cmd) {
org.eclipse.gmf.runtime.notation.View view = (org.eclipse.gmf.runtime.notation.View) getHost().getModel();
for («EXPAND CodeStyle::G('java.util.Iterator', '?' /*FIXME Refactor once Notation model is Java5*/)» nit = view.getChildren().iterator(); nit.hasNext();) {
org.eclipse.gmf.runtime.notation.Node node = (org.eclipse.gmf.runtime.notation.Node) nit.next();
switch («EXPAND xpt::editor::VisualIDRegistry::getVisualIDMethodCall FOR getDiagram()»(node)) {
«EXPAND destroyChildNodes('node', self) FOREACH childNodes-»
«IF compartments->notEmpty()»«FOREACH compartments AS compartment-»
«EXPAND xpt::Common::caseVisualID FOR compartment»
for («EXPAND CodeStyle::G('java.util.Iterator', '?' /*FIXME Refactor once Notation model is Java5*/)» cit = node.getChildren().iterator(); cit.hasNext();) {
org.eclipse.gmf.runtime.notation.Node cnode = (org.eclipse.gmf.runtime.notation.Node) cit.next();
switch («EXPAND xpt::editor::VisualIDRegistry::getVisualIDMethodCall FOR getDiagram()»(cnode)) {
«EXPAND destroyChildNodes('cnode', self) FOREACH compartment.childNodes-»
}
}
break;
«ENDFOREACH»«ENDIF-»
}
}
}
«ENDDEFINE»

«DEFINE destroyChildNodes(nodeVar : String, gmfgen::GenNode genNode) FOR gmfgen::GenChildNode-»
«EXPAND xpt::Common::caseVisualID»
case«self.editPartClassName»(cnode, cmd);
cmd.add(new org.eclipse.gmf.runtime.emf.type.core.commands.DestroyElementCommand(new org.eclipse.gmf.runtime.emf.type.core.requests.DestroyElementRequest(getEditingDomain(), «nodeVar».getElement(), false))); // directlyOwned: «self.isDirectlyOwned(genNode)»
// don't need explicit deletion of «nodeVar» as parent's view deletion would clean child views as well
// cmd.add(new org.eclipse.gmf.runtime.diagram.core.commands.DeleteCommand(getEditingDomain(), «nodeVar»));
//break;
«ENDDEFINE»

// @param view - Notation element for the passed node
// assumes 'cmd' to point to composite command
«DEFINE destroyEdges(String view) FOR gmfgen::GenNode-»
«REM»
XXX: Though semantic editpolicy is supposed to create commands that operate with semantic elements only,
old code used to delegate child/link deletion to respective editparts, which in turn led to semantic commands
being combined with notational commands (BaseItemSemanticEditPolicy#addDeleteViewCommand()).
---
Use DiagramUpdater.get[Incoming|Outgoing]View instead, to clean links that are not present on a diagram
(but don't forget to clean corresponding Edge, if any)
«ENDREM-»
private void case«self.editPartClassName»(org.eclipse.gmf.time.notation cnode, org.eclipse.gmf.runtime.common.core.command.ICompositeCommand cmd){
«IF genIncomingLinks->notEmpty()-»
for («EXPAND CodeStyle::G('java.util.Iterator', '?' /*FIXME Refactor once Notation model is Java5*/)» it = «view».getTargetEdges().iterator(); it.hasNext();) {
org.eclipse.gmf.runtime.notation.Edge incomingLink = (org.eclipse.gmf.runtime.notation.Edge) it.next();
«FOREACH genIncomingLinks AS il-»
if («EXPAND xpt::editor::VisualIDRegistry::getVisualIDMethodCall FOR getDiagram()»(incomingLink) == «EXPAND xpt::editor::VisualIDRegistry::visualID FOR il») {
«EXPAND impl::diagram::commands::DeleteLinkCommand::newRequest('r', 'incomingLink') FOR il-»
cmd.add(«EXPAND impl::diagram::commands::DeleteLinkCommand::newInstance('r') FOR il»);
cmd.add(new org.eclipse.gmf.runtime.diagram.core.commands.DeleteCommand(getEditingDomain(), incomingLink));
continue;
}
«ENDFOREACH-»
}
«ENDIF-»
«IF genOutgoingLinks->notEmpty()-»
for («EXPAND CodeStyle::G('java.util.Iterator', '?' /*FIXME Refactor once Notation model is Java5*/)» it = «view».getSourceEdges().iterator(); it.hasNext();) {
org.eclipse.gmf.runtime.notation.Edge outgoingLink = (org.eclipse.gmf.runtime.notation.Edge) it.next();
«FOREACH genOutgoingLinks AS ol-»
if («EXPAND xpt::editor::VisualIDRegistry::getVisualIDMethodCall FOR getDiagram()»(outgoingLink) == «EXPAND xpt::editor::VisualIDRegistry::visualID FOR ol») {
«EXPAND impl::diagram::commands::DeleteLinkCommand::newRequest('r', 'outgoingLink') FOR ol-»
cmd.add(«EXPAND impl::diagram::commands::DeleteLinkCommand::newInstance('r') FOR ol»);
cmd.add(new org.eclipse.gmf.runtime.diagram.core.commands.DeleteCommand(getEditingDomain(), outgoingLink));
continue;
}
«ENDFOREACH-»
}
«ENDIF-»
}
«ENDDEFINE»

«DEFINE additions FOR gmfgen::GenNode»«ENDDEFINE»

Can anyone help me? Thanks!

[Updated on: Thu, 09 February 2017 22:08]

Report message to a moderator

Re: Solution for exceeding the 65535 bytes limit error [message #1754551 is a reply to message #1753766] Mon, 20 February 2017 07:40 Go to previous message
Aurélien Pupier is currently offline Aurélien PupierFriend
Messages: 634
Registered: July 2009
Location: Grenoble, FRANCE
Senior Member

Hi,

Can you point the exact diff that you have done?
BTW you can use aspect templates as explained at the end of the article.

A common mistake is that you need to specify the full qualified name of the class that you are using.
Another one is to use class that are not visible, in this case you need to add the dependencies to the MANIFEST.MF, there is a property on the gmfgen file for that if i remember well .

Regards,


Aurélien Pupier - Red Hat
Senior Software Engineer in Fuse Tooling team
Previous Topic:How to manipulate the contents of a GMF diagram programmatically?
Next Topic:Link style doesnt work
Goto Forum:
  


Current Time: Sat Dec 16 18:53:06 GMT 2017

Powered by FUDForum. Page generated in 0.01758 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software