Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » TMF (Xtext) » Weird behavior using "Project/Clean.." in Eclipse(Model validation fails with a full build, but works fine for incremental buidls..)
icon8.gif  Weird behavior using "Project/Clean.." in Eclipse [message #1393261] Thu, 03 July 2014 14:01 Go to next message
Michel de Blok is currently offline Michel de BlokFriend
Messages: 10
Registered: February 2010
Junior Member
Hi all,

there's some strange behavior with XText/XBase if you perform a full build of a project with DSL models. If I perform a "Project/Clean.." which triggers a clean build then some models have validation errors that don't occur with an incremental build.

It only seems to occur if a Java class is generated in model #1 and used in an XBlockExpression in model #2. An example:

- I generate a Java class (A) with model #1
- I generate a Java class (B) with model #2
- I generate a method in B that has A as its return type
- I have a XBlockExpression in model #2 that returns a 'new A'

If I use incremental compilation (model by model) or the xtext-maven-plugin then everything works fine.
But if I do a clean project build in Eclipse then I get a validation error: "Type mismatch: cannot convert 'inassignable type' from A to A"

Another example:
- I generate a Java class (A) with model #1
- I write a Java class 'manually' and method xxx with A as a method parameter
- I invoke method xxx(new A) from the XBlockExpression of model #2

Again, works fine with incremental compilation, but with a full build I get validation error: "The method xxx(A) is undefined"

If I open model #2 and save it, then the error disappears again..

It seems to me like it's a linking or indexing issue, but I don't have a clue how to fix it. I'm using XText version 2.6.1. Any help would be very welcome Smile

Regards,
Michel de Blok

Re: Weird behavior using "Project/Clean.." in Eclipse [message #1400479 is a reply to message #1393261] Mon, 14 July 2014 08:57 Go to previous messageGo to next message
peter luthardt is currently offline peter luthardtFriend
Messages: 22
Registered: March 2014
Junior Member
I just had the same problem.
The reason was, that different projects referenced different versions of the same artifact (which containts the model). So I guess I had the same model loaded in two versions.
After refering the same version of the artifact all worked fine again.
May be this will help others Smile


Xtext 2.8.1
Re: Weird behavior using "Project/Clean.." in Eclipse [message #1400523 is a reply to message #1400479] Mon, 14 July 2014 10:19 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6538
Registered: July 2009
Senior Member
Hi

After copmplex project manipulations, particularly GIT checkouts it can
be necessary to restart in order to flush all the clever caches.

I just had an Xtext editor determinedly using a stale model.

Regards

Ed Willink


On 14/07/2014 09:57, peter luthardt wrote:
> I just had the same problem.
> The reason was, that different projects referenced different versions
> of the same artifact (which containts the model). So I guess I had the
> same model loaded in two versions.
> After refering the same version of the artifact all worked fine again.
> May be this will help others :)
Re: Weird behavior using "Project/Clean.." in Eclipse [message #1402572 is a reply to message #1400523] Thu, 17 July 2014 07:12 Go to previous message
Michel de Blok is currently offline Michel de BlokFriend
Messages: 10
Registered: February 2010
Junior Member
It is not a caching or restart issue, it's persistent after restarting, checking out the code again, etcetera..
Seems plausible that different versions of a model are in the classpath, but can't trace that back to the source Sad

I didn't have this issue in older versions of XText (2.3.x), so it seems that it has been introduced in v2.4 or higher.

It looks like the "isAssignableFrom" function in XText has been changed and causes the problem.

The (ugly) workaround that I'm using now is to copy and modify the "org.eclipse.xtext.xbase.typesystem.internal.RootResolvedTypes" in my DSL project and implement a fallback in the "createTypeDiagnostic" method for the isAssignableFrom call:

protected AbstractDiagnostic createTypeDiagnostic(XExpression expression, LightweightTypeReference actualType, LightweightTypeReference expectedType) {
	if (!expectedType.isAny()) {
		String actualName = actualType.getSimpleName();
		String expectedName = expectedType.getSimpleName();
		if (actualName.equals(expectedName)) {
			// MdB: this is where it all goes wrong.. sometimes similar JvmTypes are not 're-assignable' ?
			if (expectedType.isAssignableFrom(actualType)) {
				return null;
			// MdB: dirty fix: consider types with the same identifier (FQN) to be compatible..
			} else if (actualType.getIdentifier() != null && actualType.getIdentifier().equals(expectedType.getIdentifier())) {
				return null;
			}
		}
	...
}


Previous Topic:Replacement for TypeReferences.isInstanceof()
Next Topic:Semantic Models X AST's
Goto Forum:
  


Current Time: Mon Dec 16 02:11:18 GMT 2019

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

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

Back to the top