[furcas-discussion] Zweimal dieselbe Sprache

[Sebastian Schlag]

Hi Axel,

thanks for this in-depth analysis!

Instead of maintaining two versions of the NestedScopes.tcs I'd rather 
merge the two test classes into one class, since the only difference 
between the tests contained in these classes is that
/TestNestedScopesTCSandMetamodel/ tests that the usage of TCS and 
metamodel works as intended while the actual IA-relevant rename tests 
are located in TestNestedScopesWithTextBlocks.
Thus we could avoid to load parser and lexer using a different class 
loaders and also wouldn't have additional effort to keep both TCS 
versions in sync.

I just pushed the corresponding changes to gihub.

Best regards,
Sebastian

> ------------------------------------------------------------------------
>
> 	Uhl, Axel <mailto:axel.uhl at sap.com>
> 3. Februar 2011 15:04
>
>
> Hi Sebastian,
>
> it seems the problem you were having with the two tests failing when 
> executed in a suite instead of separately is related to you using the 
> same language definition with the same name in two subsequent distinct 
> test cases. I copied NestedScopes.tcs to NestedScopes2.tcs and renamed 
> the language defined inside, then adjusted the second test case that 
> previously used NestedScopes.tcs, too. Now all tests are green for me 
> locally.
>
> I suppose the following happened: when parsing the language 
> definition, a transient resource containing the mapping definition was 
> created. The parser generated produced a parser class which got 
> compiled. The package/name for this class is derived from the language 
> name. When the second test case is run, the same language definition 
> is used again to produce another mapping / parser combination. I 
> assume the mapping ended up in a new transient resource as another 
> copy. The parser may have gotten written again to the generationTemp 
> folder, overwriting the previously generated parser / lexer files. And 
> even though the compiler may have produced a new copy of the .class 
> files, I don't assume the class loader would have loaded those new 
> copies again because it still had the old copy loaded.
>
> This would even have been OK from a language / parsing perspective 
> since the language definition hasn't changed in between. However, 
> since the parser contains the URIs of the mapping elements and the 
> mapping was re-created / re-loaded with a new transient resource, 
> parser and mapping are out of sync, and the parser now can't find the 
> mapping elements anymore. This also explains why it works if the 
> failing test is executed in isolation.
>
> I pushed the change to github and hope this will "blueify" the master. 
> We should probably keep this in mind when constructing test cases in 
> the future. If you find a good, robust way to re-use the same language 
> definition, e.g., by trying to use a separate class loader for loading 
> the parser and lexer class, then that's fine, too.
>
> Best,
> -- Axel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.furcas.org/pipermail/furcas-discussion/attachments/20110203/a81496ed/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 1421 bytes
Desc: not available
URL: <http://lists.furcas.org/pipermail/furcas-discussion/attachments/20110203/a81496ed/attachment-0001.jpg>