Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Cyclic linking detected when building in maven(Error occurs only when building with xtext-maven-plugin )
Cyclic linking detected when building in maven [message #1736601] Thu, 30 June 2016 14:20 Go to next message
Peter Luthardt is currently offline Peter LuthardtFriend
Messages: 43
Registered: February 2014
Member
Hello,

I am stuck. My DSL provides a scoping which works nice in Eclipse, but when I try to build the project with maven it fails with:
DefaultComponentFeatureDotRef.right->DefaultComponentFeatureDotRef.right
What is the difference between the maven build and the Eclipse build?
Why does it fails with maven?
Any help, hint welcome.

Thanks
Re: Cyclic linking detected when building in maven [message #1736605 is a reply to message #1736601] Thu, 30 June 2016 14:25 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
there should not be any difference. can you come up with a small reproducing example?

the error says basically you have a cycle in scoping / access scope at wrong places e.g. nameprovider


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Cyclic linking detected when building in maven [message #1736739 is a reply to message #1736605] Fri, 01 July 2016 12:03 Go to previous messageGo to next message
Peter Luthardt is currently offline Peter LuthardtFriend
Messages: 43
Registered: February 2014
Member
Sorry but it took me a long time to strip all the unnecessary parts.

Hope the project works for you.

The problem still exists in eclipse the project builds correctly but maven fails.
Re: Cyclic linking detected when building in maven [message #1736908 is a reply to message #1736739] Mon, 04 July 2016 10:42 Go to previous messageGo to next message
Peter Luthardt is currently offline Peter LuthardtFriend
Messages: 43
Registered: February 2014
Member
I have solved the problem for now.

It seems that the late initialization within the Inferrer works different in maven build.
When I put the initialization into the toClass() method everything seems to be ok now.

Hope it stays this way.
Thanks
Re: Cyclic linking detected when building in maven [message #1736909 is a reply to message #1736908] Mon, 04 July 2016 10:45 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
can you tell what your change exactly was?

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Cyclic linking detected when building in maven [message #1736926 is a reply to message #1736909] Mon, 04 July 2016 12:02 Go to previous messageGo to next message
Peter Luthardt is currently offline Peter LuthardtFriend
Messages: 43
Registered: February 2014
Member
   			acceptor.accept(comp.toClass(className))[
   				val start = System.currentTimeMillis
   				lateInitializationSetupComponent(it, comp.name, comp.toJvmType, comp.content)
				static = false
				printDuration("create Component "+comp.name+": ", start)
			]

to
   			acceptor.accept(comp.toClass(className, [
   				val start = System.currentTimeMillis
   				lateInitializationSetupComponent(it, comp.name, comp.toJvmType, comp.content)
				static = false
				printDuration("create Component "+comp.name+": ", start)
			]))


But this raises other issues, but I hope I can cope with them.
Re: Cyclic linking detected when building in maven [message #1736934 is a reply to message #1736926] Mon, 04 July 2016 12:30 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
it should work the first way. (depending on what you are actually doing inside the method lateInitializationSetupComponent

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Cyclic linking detected when building in maven [message #1736963 is a reply to message #1736934] Mon, 04 July 2016 16:47 Go to previous messageGo to next message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
here is the cycle and a potential workaround

at om.lutte.cyclicLinking.Util.getDefaultTypeByRef(Util.java:301)
at om.lutte.cyclicLinking.Util.toJvmType(Util.java:230)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$6(LinkJvmModelInferrer.java:331)
at org.eclipse.xtext.xbase.lib.ObjectExtensions.operator_doubleArrow(ObjectExtensions.java:139)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.createSetupTriggerPoint(LinkJvmModelInferrer.java:375)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$5(LinkJvmModelInferrer.java:320)
at java.lang.Iterable.forEach(Iterable.java:75)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lateInitializationSetupComponent(LinkJvmModelInferrer.java:323)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$3(LinkJvmModelInferrer.java:291)
at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator$1.run(JvmModelAssociator.java:397)
at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator.installDerivedState(JvmModelAssociator.java:407)
at org.eclipse.xtext.resource.DerivedStateAwareResource.installDerivedState(DerivedStateAwareResource.java:242)
at org.eclipse.xtext.xbase.resource.BatchLinkableResource.getContents(BatchLinkableResource.java:148)
at org.eclipse.emf.ecore.util.EcoreUtil.getAllContents(EcoreUtil.java:1176)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider$3.iterator(XImportSectionNamespaceScopeProvider.java:283)
at com.google.common.collect.Iterables$8.iterator(Iterables.java:713)
at com.google.common.collect.Iterables$6.iterator(Iterables.java:589)
at org.eclipse.xtext.scoping.impl.MultimapBasedSelectable.setExportedObjects(MultimapBasedSelectable.java:106)
at org.eclipse.xtext.scoping.impl.MultimapBasedSelectable.<init>(MultimapBasedSelectable.java:36)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider.internalGetAllDescriptions(XImportSectionNamespaceScopeProvider.java:287)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider$2.get(XImportSectionNamespaceScopeProvider.java:274)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider$2.get(XImportSectionNamespaceScopeProvider.java:1)
at org.eclipse.xtext.util.OnChangeEvictingCache.get(OnChangeEvictingCache.java:77)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider.getAllDescriptions(XImportSectionNamespaceScopeProvider.java:271)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider.getGlobalScope(XImportSectionNamespaceScopeProvider.java:89)
at org.eclipse.xtext.xbase.scoping.XImportSectionNamespaceScopeProvider.getScope(XImportSectionNamespaceScopeProvider.java:82)
at om.lutte.cyclicLinking.scoping.LinkScopeProviderDelegate.getScope(LinkScopeProviderDelegate.java:107)
at org.eclipse.xtext.xbase.scoping.batch.XbaseBatchScopeProvider.delegateGetScope(XbaseBatchScopeProvider.java:63)
at org.eclipse.xtext.xbase.scoping.batch.XbaseBatchScopeProvider.getScope(XbaseBatchScopeProvider.java:107)
at org.eclipse.xtext.linking.impl.DefaultLinkingService.getScope(DefaultLinkingService.java:59)
at org.eclipse.xtext.linking.impl.DefaultLinkingService.getLinkedObjects(DefaultLinkingService.java:119)
at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:247)
at org.eclipse.xtext.xbase.resource.BatchLinkableResource.getEObject(BatchLinkableResource.java:119)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:223)
at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:199)
at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:259)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(BasicEObjectImpl.java:1477)
at om.lutte.cyclicLinking.link.impl.DefaultComponentFeatureRefImpl.getFeature(DefaultComponentFeatureRefImpl.java:73)
at om.lutte.cyclicLinking.Util.getDefaultTypeByRef(Util.java:303)
at om.lutte.cyclicLinking.Util.toJvmType(Util.java:230)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$8(LinkJvmModelInferrer.java:501)
at org.eclipse.xtext.xbase.jvmmodel.JvmTypesBuilder.initializeSafely(JvmTypesBuilder.java:207)
at org.eclipse.xtext.xbase.jvmmodel.JvmTypesBuilder.toClass(JvmTypesBuilder.java:385)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.createTpPiece(LinkJvmModelInferrer.java:523)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$15(LinkJvmModelInferrer.java:460)
at java.lang.Iterable.forEach(Iterable.java:75)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$7(LinkJvmModelInferrer.java:463)
at org.eclipse.xtext.xbase.jvmmodel.JvmTypesBuilder.initializeSafely(JvmTypesBuilder.java:207)
at org.eclipse.xtext.xbase.jvmmodel.JvmTypesBuilder.toClass(JvmTypesBuilder.java:385)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.createSetupPiece(LinkJvmModelInferrer.java:490)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$11(LinkJvmModelInferrer.java:119)
at java.lang.Iterable.forEach(Iterable.java:75)
at om.lutte.cyclicLinking.jvmmodel.LinkJvmModelInferrer.lambda$0(LinkJvmModelInferrer.java:122)
at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator$1.run(JvmModelAssociator.java:397)
at org.eclipse.xtext.xbase.jvmmodel.JvmModelAssociator.installDerivedState(JvmModelAssociator.java:407)
at org.eclipse.xtext.resource.DerivedStateAwareResource.installDerivedState(DerivedStateAwareResource.java:242)
at org.eclipse.xtext.xbase.resource.BatchLinkableResource.getContents(BatchLinkableResource.java:148)
at org.eclipse.xtext.builder.standalone.StandaloneBuilder.launch(StandaloneBuilder.java:292)
at org.eclipse.xtext.maven.XtextGenerator.internalExecute(XtextGenerator.java:165)

override getScope(EObject context, EReference reference) {
var IScope retval = null

// println("<getScope> context: "+context)
// println("<getScope> reference: "+reference.name+" / "+reference)
val superScope = if (reference == LinkPackage.Literals.DEFAULT_COMPONENT_FEATURE_REF__FEATURE) IScope.NULLSCOPE else super.getScope(context, reference)
if (retval == null)
{
retval = linkScopeDefaultTypes.getScope(context, reference, superScope)
}
if (retval == null)
{
retval = linkScopeTopologyFeature.getScope(context, reference, superScope)
}
if (retval == null)
{
superScope
} else
{
retval
}
}


Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Re: Cyclic linking detected when building in maven [message #1737441 is a reply to message #1736963] Fri, 08 July 2016 09:46 Go to previous messageGo to next message
Peter Luthardt is currently offline Peter LuthardtFriend
Messages: 43
Registered: February 2014
Member
Thank you for the replay, I found an other solution. It looks different, but my real dsl is much more complex.
I had to override org.eclipse.xtext.xbase.resource.BatchLinkableResource as in my case the cycle seems to be the normal behavior.
I am doing something like this
File one contains:
defaultObject = new XYZObject (xyzAttribute1 = "x", xyzAttribute2="x2", ...) 

File two contains:
aNewObject = extends defaultObject  (xyzA1 = "x", xyzAttribute2="x2", ...)

To create the sope for xyzA1 I need to find the JvmType of XYZObject. When I try to resolve the type of XYZObject the whole model of "File one" seems to be parsed, and this causes the cycle. At the second call the model of "File one" has been parsed, so the cycle is broken.(At least this is my guess)

	val counter = new HashMap<Triple<EObject, EReference, INode>, AtomicInteger>()
	override protected handleCyclicResolution(Triple<EObject, EReference, INode> triple) throws AssertionError {
		try{
			val calls = incrementAndGetCounter(triple)
			if (calls > 3)
			{
				super.handleCyclicResolution(triple)
			} else
			{
				val node = triple.third
				val message = "Cyclic linking detected " +calls+": "+ getReferences(triple, resolving)+"\n"
					+"       "+getReferencesNode(triple, resolving)
				println(message)
//					new Exception(message).printStackTrace
				val linkedObjects = getLinkingService().getLinkedObjects(
					triple.first, 
					triple.second,
					node);
				linkedObjects.head
			}
		} finally
		{
			decrepementAndGetCounter(triple)
		}
	}
	
	def int incrementAndGetCounter (Triple<EObject, EReference, INode> triple)
	{
		val c = counter.get(triple)
		if (c == null)
		{
			counter.put(triple, new AtomicInteger(1))
			1
		} else
		{
			c.incrementAndGet
		}
	}
	
	def int decrepementAndGetCounter (Triple<EObject, EReference, INode> triple)
	{
		val c = counter.get(triple)
		if (c == null)
		{
			counter.put(triple, new AtomicInteger(-1))
			(-1)
		} else
		{
			c.decrementAndGet
		}
	}
	
	
	def protected String getReferencesNode(Triple<EObject, EReference, INode> triple,
			LinkedHashSet<Triple<EObject, EReference, INode>> resolving2) {
		val buffer = new StringBuffer();
		var found = false;
		for (Triple<EObject, EReference, INode> triple2 : resolving2) {
			found = found || triple2.equals(triple);
			if (found)
				buffer.append(getQualifiedNodeName(triple2.third)).append("->");
		}
		buffer.append(getQualifiedNodeName(triple.third));
		return buffer.toString();
	}

	def private String getQualifiedNodeName(INode node) {
		return node.text;
	}


In my case the cycle only occurred once.
Cyclic linking detected 1: EmuContentRef.emuContent->Parameter.parameterFeature->EmuContentRef.emuContent
       chuteTp->unitId->chuteTp
Cyclic linking detected 1: JvmParameterizedTypeReference.type->Parameter.parameterFeature->JvmParameterizedTypeReference.type
        VarioscNodeComponent->nodeIdVariosc-> VarioscNodeComponent
Cyclic linking detected 1: EmuContentRef.emuContent->Parameter.parameterFeature->EmuContentRef.emuContent
       defaultTp->name->defaultTp


I am fine with this solution. And for now it works.
But it does not answers the question, why it is behaving different in Eclipse, than in Maven. (But for now I am happy Smile )


Re: Cyclic linking detected when building in maven [message #1737443 is a reply to message #1737441] Fri, 08 July 2016 09:49 Go to previous message
Christian Dietrich is currently offline Christian DietrichFriend
Messages: 14665
Registered: July 2009
Senior Member
i actually dont know

Twitter : @chrdietrich
Blog : https://www.dietrich-it.de
Previous Topic:can we have two different xtext grammar files from single xtext project?
Next Topic:Convert xtext code to JavaScript
Goto Forum:
  


Current Time: Tue Apr 23 08:18:19 GMT 2024

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

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

Back to the top