metamodelsemantics - Project Hosting on Google Code

Earlier this year May 14, 2009 r30 (some minor changes....................................) committed by voelter - some minor changes.................................... some minor changes.................................... Apr 29, 2009 issue 12 (linkorder-rule can produce StackOverflowError) reported by philipp.bollbach.dev - if you define a linkorder "A" for elements "X" that reference elements "Y" themselves that have to be linked first and are not in a linkorder definition "B" that is defined before "A" in the .seman-File (e.g. they are not in the same element) a stackoverflow error occurs when you open the model in its editor. java.lang.StackOverflowError at java.util.AbstractList.listIterator(AbstractList.java:389) at java.util.AbstractList.listIterator(AbstractList.java:349) at java.util.AbstractList.equals(AbstractList.java:605) at org.openarchitectureware.workflow.util.Pair.equals(Pair.java:56) at java.util.HashMap.eq(HashMap.java:299) at java.util.HashMap.containsKey(HashMap.java:381) at org.openarchitectureware.workflow.util.Cache.get(Cache.java:23) at org.openarchitectureware.type.AbstractTypeImpl.getOperation(AbstractTypeImpl.java:122) at org.openarchitectureware.expression.TypeSystemImpl.findOperation(TypeSystemImpl.java:74) at org.openarchitectureware.expression.ExecutionContextImpl.findOperation(ExecutionContextImpl.java:135) at org.openarchitectureware.expression.ast.OperationCall.evaluateInternal(OperationCall.java:96) at org.openarchitectureware.expression.ast.Expression.evaluate(Expression.java:51) Reason: The Linking.ext that is generated places all the elements "X" defined in a linkorder at the first position of the allVisibleElements extension, although they depend on other elements "Y" that have to be linked first and are not in a linkorder. Quickfix: Define a Rule (in .seman) for each class that has to be in a special order and place these rules in the required order in the .seman-File (beginning from the top). if you define a linkorder "A" for elements "X" that reference elements "Y" themselves that have to be linked first and are not in a linkorder definition "B" that is defined before "A" in the .seman-File (e.g. they are not in the same element) a stackoverflow error occurs when you open the model in its editor. java.lang.StackOverflowError at java.util.AbstractList.listIterator(AbstractList.java:389) at java.util.AbstractList.listIterator(AbstractList.java:349) at java.util.AbstractList.equals(AbstractList.java:605) at org.openarchitectureware.workflow.util.Pair.equals(Pair.java:56) at java.util.HashMap.eq(HashMap.java:299) at java.util.HashMap.containsKey(HashMap.java:381) at org.openarchitectureware.workflow.util.Cache.get(Cache.java:23) at org.openarchitectureware.type.AbstractTypeImpl.getOperation(AbstractTypeImpl.java:122) at org.openarchitectureware.expression.TypeSystemImpl.findOperation(TypeSystemImpl.java:74) at org.openarchitectureware.expression.ExecutionContextImpl.findOperation(ExecutionContextImpl.java:135) at org.openarchitectureware.expression.ast.OperationCall.evaluateInternal(OperationCall.java:96) at org.openarchitectureware.expression.ast.Expression.evaluate(Expression.java:51) Reason: The Linking.ext that is generated places all the elements "X" defined in a linkorder at the first position of the allVisibleElements extension, although they depend on other elements "Y" that have to be linked first and are not in a linkorder. Quickfix: Define a Rule (in .seman) for each class that has to be in a special order and place these rules in the required order in the .seman-File (beginning from the top). Apr 29, 2009 issue 11 (Scopes should not affect linking) reported by voelter - Currently a scope definition affects code completion and linking. Consequently, if an element is referred to (by name) that is not in scope, the linker won't be able to link to it, resulting in a "cannot resolve reference" error. This is not very user friendly. A better solution would be this: - use the scope for code completion - link against all elemnets - generate a constraint that complains if an element is not in scope - make the error message configurable by making it part of the scope definition in the seman file Currently a scope definition affects code completion and linking. Consequently, if an element is referred to (by name) that is not in scope, the linker won't be able to link to it, resulting in a "cannot resolve reference" error. This is not very user friendly. A better solution would be this: - use the scope for code completion - link against all elemnets - generate a constraint that complains if an element is not in scope - make the error message configurable by making it part of the scope definition in the seman file Apr 29, 2009 issue 10 (ScopeSpecs combinable) reported by voelter - It should be possible to combine (in the sense of union) several scope specs for a given property. It should be possible to combine (in the sense of union) several scope specs for a given property. Apr 29, 2009 issue 9 (PostProcess(...) for each meta type) reported by voelter - ... so all kinds of things can be done to any element after a model has been parsed. Also, an "inline/realtime" postprocess could be "faked in" via the linking functions.... ... so all kinds of things can be done to any element after a model has been parsed. Also, an "inline/realtime" postprocess could be "faked in" via the linking functions.... Apr 29, 2009 issue 8 (DerivedResourceSpec must work recursively) reported by voelter - ... for example in case something has a recursive Namespace-structure as its container, the names of all the recursive Namespaces must be part of the DerivedResource name. ... for example in case something has a recursive Namespace-structure as its container, the names of all the recursive Namespaces must be part of the DerivedResource name. Apr 29, 2009 issue 7 (Custom Scopes don't work) reported by voelter - For custom scopes, the idea is that * a scope_.... operation is generated in GenExtensions that throws an interrupt and stops linking execution * in Extensions.ext, you can override this scope_... function to do something sensible however, due to the way Xtend handles "overrwriting" the overwritten function is never called. Maybe use protected regions? Or also put the allVisibleElements(X) into Extensions.ext? For custom scopes, the idea is that * a scope_.... operation is generated in GenExtensions that throws an interrupt and stops linking execution * in Extensions.ext, you can override this scope_... function to do something sensible however, due to the way Xtend handles "overrwriting" the overwritten function is never called. Maybe use protected regions? Or also put the allVisibleElements(X) into Extensions.ext? Apr 29, 2009 r29 ([No log message]) committed by voelter - [No log message] [No log message] Apr 24, 2009 r28 ([No log message]) committed by voelter - [No log message] [No log message] Apr 24, 2009 issue 4 (Errors in GenExtensions.ext when using abstract rules and cr...) Status changed by voelter - I have fixed this bug. Status: Fixed I have fixed this bug. Status: Fixed Apr 22, 2009 r27 ([No log message]) committed by voelter - [No log message] [No log message] Apr 22, 2009 r26 (added globally unique naming constraints) committed by voelter - added globally unique naming constraints added globally unique naming constraints Apr 21, 2009 issue 6 (The language name arent't interpreted lower case) commented on by christian.dietrich.itemis - same problem reported here http://www.openarchitectureware.org/forum/viewtopic.php?showtopic=12895 same problem reported here http://www.openarchitectureware.org/forum/viewtopic.php?showtopic=12895 Apr 08, 2009 issue 6 (The language name arent't interpreted lower case) reported by Mischa.H...@itemis.de - What steps will reproduce the problem? 1. Create a xText project and use a CamelCase language name The issue is that the language name is used in lower case in the ecore model. This has to be taken into account when generating the import statements and the entries in the Linking.ext where meta-elements are fully qualified. What steps will reproduce the problem? 1. Create a xText project and use a CamelCase language name The issue is that the language name is used in lower case in the ecore model. This has to be taken into account when generating the import statements and the entries in the Linking.ext where meta-elements are fully qualified. Apr 08, 2009 issue 1 (Cannot run the workflow when checked out from svn) commented on by philipp.bollbach.dev - the same issue occurs in the emf model visualizer project, instead of creating the folder src-gen you could simply alter the buildpath (remove the missing src-gen), generate and then add src-gen to the buildpath again. I wrote a short wiki entry to help new users to get on track. the same issue occurs in the emf model visualizer project, instead of creating the folder src-gen you could simply alter the buildpath (remove the missing src-gen), generate and then add src-gen to the buildpath again. I wrote a short wiki entry to help new users to get on track. Apr 07, 2009 issue 5 (Type-Issue when navigating in scope schemes over cross refer...) reported by Misch...@gmx.de - What steps will reproduce the problem? 1. Navigate over a 1..1 reference inside a scope scheme 2. E.g.: dataElement follow port follow interface (expecting port->interface is 1..1) What is the expected output? -> Generated files without errors What do you see instead? Errors in the checks-editor "Couldn't find operation 'contains(mydsl::Interface)' for type 'Object'" What version of the product are you using? On what operating system? 0.5.6 / Windows Vista Please provide any additional information below. The cause of the issue is the following snippet based on the generated extension: ... "(res != null ? res : {}); " If "res" != null for all 1..1 references the element itself will be returned and thus the return type is "OBJECT". In the other case a emtpy List is returned. The Check editor must be able to statically check the types. By the way, the generated Check-file calls the "contains()" method on the returned value. I think this will lead to a crash at runtime. What steps will reproduce the problem? 1. Navigate over a 1..1 reference inside a scope scheme 2. E.g.: dataElement follow port follow interface (expecting port->interface is 1..1) What is the expected output? -> Generated files without errors What do you see instead? Errors in the checks-editor "Couldn't find operation 'contains(mydsl::Interface)' for type 'Object'" What version of the product are you using? On what operating system? 0.5.6 / Windows Vista Please provide any additional information below. The cause of the issue is the following snippet based on the generated extension: ... "(res != null ? res : {}); " If "res" != null for all 1..1 references the element itself will be returned and thus the return type is "OBJECT". In the other case a emtpy List is returned. The Check editor must be able to statically check the types. By the way, the generated Check-file calls the "contains()" method on the returned value. I think this will lead to a crash at runtime. Apr 07, 2009 issue 4 (Errors in GenExtensions.ext when using abstract rules and cr...) reported by Misch...@gmx.de - What steps will reproduce the problem? 1. Create a Rule below a corresponding abstract rule 2. Add a reference to the rule (anyRef=[AnyType]) 3. Create a EMPTY seman file containing the reference to the metaModel only 4. Create the grammer including seman What is the expected output? -> genExtensions without Errors What do you see instead? -> genExtensions using other not existing extensions What version of the product are you using? On what operating system? 0.5.6 on Windows Vista Please provide any additional information below. I looks like the scope_extensions delegate to the scopes of the abstract element, but the abstract scope were not generated. For further details look at the GenExtension Attachment at line 37: "scope_ABSTRACT_ELEMENT_ref();". The corresponding demo grammer is attached as well. What steps will reproduce the problem? 1. Create a Rule below a corresponding abstract rule 2. Add a reference to the rule (anyRef=[AnyType]) 3. Create a EMPTY seman file containing the reference to the metaModel only 4. Create the grammer including seman What is the expected output? -> genExtensions without Errors What do you see instead? -> genExtensions using other not existing extensions What version of the product are you using? On what operating system? 0.5.6 on Windows Vista Please provide any additional information below. I looks like the scope_extensions delegate to the scopes of the abstract element, but the abstract scope were not generated. For further details look at the GenExtension Attachment at line 37: "scope_ABSTRACT_ELEMENT_ref();". The corresponding demo grammer is attached as well. Apr 07, 2009 issue 3 (Eclipse Crash when creating endless loops inside seman-edito...) reported by Misch...@gmx.de - What steps will reproduce the problem? 1. Create a endless-loop inside the seman-definition 2. Open the seman file What is the expected output? -> Seman file inside the seman Editor What do you see instead? -> Error popUp and Editor Crash including StackOverflow What version of the product are you using? On what operating system? ->0.5.6 Please provide any additional information below. There should be either a endless loop detection mechanism or at least a proper error handling mechansims in order to prevent the workbench from break down. What steps will reproduce the problem? 1. Create a endless-loop inside the seman-definition 2. Open the seman file What is the expected output? -> Seman file inside the seman Editor What do you see instead? -> Error popUp and Editor Crash including StackOverflow What version of the product are you using? On what operating system? ->0.5.6 Please provide any additional information below. There should be either a endless loop detection mechanism or at least a proper error handling mechansims in order to prevent the workbench from break down. Mar 28, 2009 issue 1 (Cannot run the workflow when checked out from svn) commented on by michael_...@scharf.gr - and that way of traversing the classpath is very fragile... I understand that this might make sense for non-osgi apps but for eclipse plug-ins an extension mechanism would make more sense... Mihael and that way of traversing the classpath is very fragile... I understand that this might make sense for non-osgi apps but for eclipse plug-ins an extension mechanism would make more sense... Mihael Mar 27, 2009 issue 1 (Cannot run the workflow when checked out from svn) commented on by christ...@elsner-kulmbach.de - Hi Michael, this problem is a standard problem due to the usage of the classpath mechanism when locating workflow files, it is not directly related to workflows. The classpath mechanism is just missing the org.openarchitectureware.seman/src-gen/ folder. Instead of ignoring the missing folder it, it does not find any file at all. Just create a src-gen folder in the root folders of the eclipse projects and it should work. Hi Michael, this problem is a standard problem due to the usage of the classpath mechanism when locating workflow files, it is not directly related to workflows. The classpath mechanism is just missing the org.openarchitectureware.seman/src-gen/ folder. Instead of ignoring the missing folder it, it does not find any file at all. Just create a src-gen folder in the root folders of the eclipse projects and it should work. Mar 19, 2009 metamodelsemantics-0.5.6.zip (Deployable Plugins (v0.5.6)) file uploaded by voelter Mar 19, 2009 r25 ([No log message]) committed by voelter - [No log message] [No log message] Mar 16, 2009 metamodelsemantics-0.5.5.zip (Deployable Plugins (v0.5.0)) file uploaded by voelter Mar 11, 2009 r24 ([No log message]) committed by voelter - [No log message] [No log message] Mar 10, 2009 r23 ([No log message]) committed by voelter - [No log message] [No log message] Mar 10, 2009 r22 ([No log message]) committed by voelter - [No log message] [No log message] Mar 10, 2009 r21 ([No log message]) committed by voelter - [No log message] [No log message] Mar 09, 2009 issue 1 (Cannot run the workflow when checked out from svn) commented on by michael_...@scharf.gr - I was not able to bootstrap the test projects... I know you hate to check in generated code, and maybe there is a simple way to bootstrap it after the project has been checked out. BTW: this confirms once more my hate relation to workflow files.... I was not able to bootstrap the test projects... I know you hate to check in generated code, and maybe there is a simple way to bootstrap it after the project has been checked out. BTW: this confirms once more my hate relation to workflow files.... Mar 09, 2009 issue 2 (the downloaded plugins do not run with java 1.5) commented on by michael_...@scharf.gr - I successfully exported the plugins with java 1.5, there seems no reason to use a newer version of java. I successfully exported the plugins with java 1.5, there seems no reason to use a newer version of java. Mar 09, 2009 issue 2 (the downloaded plugins do not run with java 1.5) reported by michael_...@scharf.gr - It seems they are compiled with a version of java > 1.5. This is unfortunate, unless the plugins require some specific features of newer java versions.... It seems they are compiled with a version of java > 1.5. This is unfortunate, unless the plugins require some specific features of newer java versions.... Mar 09, 2009 issue 1 (Cannot run the workflow when checked out from svn) reported by michael_...@scharf.gr - What steps will reproduce the problem? 1. check out the projects 2. run the workflow ==> SEVERE: can't find the workflow file 'C:/.../org.openarchitectureware.seman/src/generateSemanDSL.oaw' in the current class path The problem is that in order to copy the workflow file into the bin directory (to make it visible from the classpath), the project has to compile. But to compile, the workflow has to run... A classical "chicken or egg: problem... What steps will reproduce the problem? 1. check out the projects 2. run the workflow ==> SEVERE: can't find the workflow file 'C:/.../org.openarchitectureware.seman/src/generateSemanDSL.oaw' in the current class path The problem is that in order to copy the workflow file into the bin directory (to make it visible from the classpath), the project has to compile. But to compile, the workflow has to run... A classical "chicken or egg: problem... Mar 09, 2009 r20 ([No log message]) committed by voelter - [No log message] [No log message] Mar 09, 2009 metamodelsemantics-0.5.0.zip (Deployable Plugins (v0.5.0)) file uploaded by voelter Mar 09, 2009 UsersGuide-0.5.pdf (Documentation PDF (v0.5)) file uploaded by voelter Mar 09, 2009 r19 (helper functions) committed by voelter - helper functions helper functions Mar 09, 2009 metamodelsemantics-0.4.0.zip (Deployable Plugins (v0.4.0)) file uploaded by voelter Mar 09, 2009 UsersGuide-0.4.pdf (Documentation PDF (v0.4)) file uploaded by voelter Mar 09, 2009 r18 ([No log message]) committed by voelter - [No log message] [No log message] Mar 08, 2009 semanticAnnotationsIntroScreencast-0.3.zip (Introductory Screencast (extract ZIP file and open semanticA...) file uploaded by voelter Mar 08, 2009 r17 (bug fixes for 0.3.1) committed by voelter - bug fixes for 0.3.1 bug fixes for 0.3.1 Mar 08, 2009 metamodelsemantics-0.3.1.zip (Deployable Plugins (v0.3.1)) file uploaded by voelter Mar 07, 2009 r16 ([No log message]) committed by voelter - [No log message] [No log message] Mar 07, 2009 r15 ([No log message]) committed by voelter - [No log message] [No log message] Mar 07, 2009 metamodelsemantics-0.3.zip (Deployable Plugins (v0.3)) file uploaded by voelter Mar 07, 2009 r14 (link ordering and namespaces added) committed by voelter - link ordering and namespaces added link ordering and namespaces added Mar 07, 2009 UsersGuide-0.3.pdf (Documentation PDF (v0.2)) file uploaded by voelter Mar 06, 2009 metamodelsemantics-0.2.zip (Deployable Plugins (v0.2)) file uploaded by voelter Mar 06, 2009 UsersGuide-0.2.pdf (Documentation PDF (v0.2)) file uploaded by voelter Mar 06, 2009 r13 ([No log message]) committed by voelter - [No log message] [No log message] Mar 06, 2009 r12 (updated docs) committed by voelter - updated docs updated docs

issue 12 (linkorder-rule can produce StackOverflowError) reported by philipp.bollbach.dev - if you define a linkorder "A" for elements "X" that reference elements "Y" themselves that have to be linked first and are not in a linkorder definition "B" that is defined before "A" in the .seman-File (e.g. they are not in the same element) a stackoverflow error occurs when you open the model in its editor. java.lang.StackOverflowError at java.util.AbstractList.listIterator(AbstractList.java:389) at java.util.AbstractList.listIterator(AbstractList.java:349) at java.util.AbstractList.equals(AbstractList.java:605) at org.openarchitectureware.workflow.util.Pair.equals(Pair.java:56) at java.util.HashMap.eq(HashMap.java:299) at java.util.HashMap.containsKey(HashMap.java:381) at org.openarchitectureware.workflow.util.Cache.get(Cache.java:23) at org.openarchitectureware.type.AbstractTypeImpl.getOperation(AbstractTypeImpl.java:122) at org.openarchitectureware.expression.TypeSystemImpl.findOperation(TypeSystemImpl.java:74) at org.openarchitectureware.expression.ExecutionContextImpl.findOperation(ExecutionContextImpl.java:135) at org.openarchitectureware.expression.ast.OperationCall.evaluateInternal(OperationCall.java:96) at org.openarchitectureware.expression.ast.Expression.evaluate(Expression.java:51) Reason: The Linking.ext that is generated places all the elements "X" defined in a linkorder at the first position of the allVisibleElements extension, although they depend on other elements "Y" that have to be linked first and are not in a linkorder. Quickfix: Define a Rule (in .seman) for each class that has to be in a special order and place these rules in the required order in the .seman-File (beginning from the top).

if you define a linkorder "A" for elements "X" that reference elements "Y" themselves that have to be linked first and are not in a linkorder definition "B" that is defined before "A" in the .seman-File (e.g. they are not in the same element) a stackoverflow error occurs when you open the model in its editor. java.lang.StackOverflowError at java.util.AbstractList.listIterator(AbstractList.java:389) at java.util.AbstractList.listIterator(AbstractList.java:349) at java.util.AbstractList.equals(AbstractList.java:605) at org.openarchitectureware.workflow.util.Pair.equals(Pair.java:56) at java.util.HashMap.eq(HashMap.java:299) at java.util.HashMap.containsKey(HashMap.java:381) at org.openarchitectureware.workflow.util.Cache.get(Cache.java:23) at org.openarchitectureware.type.AbstractTypeImpl.getOperation(AbstractTypeImpl.java:122) at org.openarchitectureware.expression.TypeSystemImpl.findOperation(TypeSystemImpl.java:74) at org.openarchitectureware.expression.ExecutionContextImpl.findOperation(ExecutionContextImpl.java:135) at org.openarchitectureware.expression.ast.OperationCall.evaluateInternal(OperationCall.java:96) at org.openarchitectureware.expression.ast.Expression.evaluate(Expression.java:51) Reason: The Linking.ext that is generated places all the elements "X" defined in a linkorder at the first position of the allVisibleElements extension, although they depend on other elements "Y" that have to be linked first and are not in a linkorder. Quickfix: Define a Rule (in .seman) for each class that has to be in a special order and place these rules in the required order in the .seman-File (beginning from the top).

Earlier this year