Error Executing EValidator

[richar...@taskize.co.uk]

Any idea why I might get this?

[INFO] 

[INFO] --- sculptor-maven-plugin:3.1.0:generate (code-generation) @ connect ---

[ERROR] Error executing EValidator

[ERROR] Error executing EValidator

[ERROR] Error executing EValidator

[ERROR] Error executing EValidator

[ERROR] Error executing EValidator

[ERROR] Resource validation error "Error executing EValidator" in line null

[ERROR] Executing generator workflow failed

[INFO] ------------------------------------------------------------------------

[INFO] BUILD FAILURE

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 4.376 s

[INFO] Finished at: 2015-10-28T20:20:49+00:00

[INFO] Final Memory: 36M/398M

[INFO] ------------------------------------------------------------------------

[ERROR] Failed to execute goal org.sculptorgenerator:sculptor-maven-plugin:3.1.0:generate (code-generation) on project connect: Sculptor code generator failed -> [Help 1]

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.sculptorgenerator:sculptor-maven-plugin:3.1.0:generate (code-generation) on project connect: Sculptor code generator failed

at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)

at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)

at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)

at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)

at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)

at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)

at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)

at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)

at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)

at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:497)

at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)

at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)

at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)

at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

Caused by: org.apache.maven.plugin.MojoExecutionException: Sculptor code generator failed

at org.sculptor.maven.plugin.GeneratorMojo.execute(GeneratorMojo.java:224)

at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)

at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)

... 20 more

[richar...@taskize.co.uk]

I have taken time to go through the btdesign files and cannot find any issues.

I have now marked this as an issue.

The output from the error is also not helpful so might be an idea to update. 

Will try and debug if I can. 

[richar...@taskize.co.uk]

The KEY issue is the ERROR is not specific. It doesn't indicate a file or a line!

[ERROR] Resource validation error "Error executing EValidator" in line null

On Wednesday, 28 October 2015 20:21:42 UTC, richar...@taskize.co.uk wrote:

[Torsten Juergeleit]

The output from the error is also not helpful so might be an idea to update.

This is a Maven thing. With the command line option "-e" you get more information.

In your case "-e" will not get enough information. Here the verbose debug output (via "-X") is needed.

/Torsten

[Richard Walsh]

Here you go.

[DEBUG] Executing workflow failed

[ERROR] Resource validation error "Error executing EValidator" in line null

[ERROR] Executing generator workflow failed

[INFO] ------------------------------------------------------------------------

[INFO] BUILD FAILURE

[INFO] ------------------------------------------------------------------------

[INFO] Total time: 4.449 s

[INFO] Finished at: 2015-10-29T13:07:07+00:00

[INFO] Final Memory: 33M/397M

--

You received this message because you are subscribed to a topic in the Google Groups "Sculptor Generator" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sculptorgenerator/suqbsL9xtqs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sculptorgenera...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Taskize Limited - Innovative solutions for Financial Services Technology.

Registered address: 33 Cannon Street, London, EC4M 5SB. Registered in England No. 7921239. This message may contain information that is privileged or confidential. If you are not the intended recipient please delete it and inform the sender immediately.

[richar...@taskize.co.uk]

Ok.

I finally found the issue. It was a needle in a heystack as we have quite a few btdesign files.

I had an abstract DTO as follows.

abstract DataTransferObject EntityDto {

}

It was defined in one BTDESIGN file but I had missed defining it in another. 

Once I copied it into the other file the error went away. I have no idea why either the Editor or the compilation process did not pick up on this. 

This cost me about a few hours in total to resolve through trial and error. However.

I am now seeing that sculptor does not like objects of the same name defined even if they are in different modules, different btdesign files and are going to be in different packages. 

[ERROR] Model validation error "Duplicate name.  There is already an existing Domain Object named 'EntityDto'." at DslModel.app->DslApplication'Taskize'.modules[7]->DslModule'bubble_dto'.domainObjects[0]->DslDataTransferObject'EntityDto'

[ERROR] Model validation error "Duplicate name.  There is already an existing Domain Object named 'EntityDto'." at DslModel.app->DslApplication'Taskize'.modules[9]->DslModule'tenant_dto'.domainObjects[0]->DslDataTransferObject'EntityDto'

Is this the case?

I can work around this but thought I would ask. 

Suggest improving the error messages around the issue I was seeing for others.

Thanks,

Richie 

To unsubscribe from this group and all its topics, send an email to sculptorgenerator+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Richard Walsh]

Ok. Having taken this a step further I may have found a bug in sculptor. 

I have reproduced this with the below dtdesign files. 

The error tells nothing of the issue so indicates to me that its a bug.

There are no errors indicated in eclipse in the btdesing files.

The error is :

[ERROR] Error executing EValidator

[ERROR] Resource validation error "Error executing EValidator" in line null

Thanks,

Richie. 

To unsubscribe from this group and all its topics, send an email to sculptorgenera...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Taskize Limited - Innovative solutions for Financial Services Technology.

Registered address: 33 Cannon Street, London, EC4M 5SB. Registered in England No. 7921239. This message may contain information that is privileged or confidential. If you are not the intended recipient please delete it and inform the sender immediately.

Taskize Limited - Innovative solutions for Financial Services Technology.

Registered address: 33 Cannon Street, London, EC4M 5SB. Registered in England No. 7921239. This message may contain information that is privileged or confidential. If you are not the intended recipient please delete it and inform the sender immediately.

--
You received this message because you are subscribed to a topic in the Google Groups "Sculptor Generator" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sculptorgenerator/suqbsL9xtqs/unsubscribe.

To unsubscribe from this group and all its topics, send an email to sculptorgenera...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Richard Walsh]

My question on this then is this.

Is it possible to reference a DTO from another file when the DTO being references in abstract?

As thats what I want to do?

[Richard Walsh]

I also read up the docs on sharing and tried the 

generate.module.shareddto=false - where shareddto is the module for all shared dto types and this didnt work either. 

[Torsten Juergeleit]

I finally found the issue. It was a needle in a heystack as we have quite a few btdesign files.

I'm glad you found it. Excellent.

I am now seeing that sculptor does not like objects of the same name defined even if they are in different modules, different btdesign files and are going to be in different packages. 

Is this the case?

Yes, this is a limitation of Sculptors internal meta model (lack of name space). Every domain object defined within a Sculptor application domain model (no matter of being located within different application parts or modules) needs a unique name. At the end of the day every domain model will be added to a map which is keyed by the domain object names.

Suggest improving the error messages around the issue I was seeing for others.

I'll check your example. Maybe I'm able to come up with a more helpful validation error.

/Torsten

[Torsten Juergeleit]

generate.module.shareddto=false - where shareddto is the module for all shared dto types and this didnt work either. 

With the property "module.generate.<module name>" set to "true" the corresponding module is omitted from code generation - only the meta data defined in the btdesign is used. This is needed in importing Sculptor Maven projects to keep Sculptor from generating code which is already generated within the JAR in the shared Maven project.

/Torsten

On Thursday, October 29, 2015 at 5:20:55 PM UTC+1, Richard Walsh wrote:

I also read up the docs on sharing and tried the 

generate.module.shareddto=false - where shareddto is the module for all shared dto types and this didnt work either. 

On 29 October 2015 at 16:00, Richard Walsh wrote:

My question on this then is this.

Is it possible to reference a DTO from another file when the DTO being references in abstract?

As thats what I want to do?

[Richard Walsh]

Ah good to know for the future. 

--

You received this message because you are subscribed to a topic in the Google Groups "Sculptor Generator" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sculptorgenerator/suqbsL9xtqs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sculptorgenera...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Walsh]

Thanks. Again excellent tool and its free so appreciate the effort. There are very few areas of any weakness I can find, well done. 

[Torsten Juergeleit]

Thanks. Again excellent tool and its free so appreciate the effort. There are very few areas of any weakness I can find, well done. 

Glad yoou like it.


Regarding your issue with Sculptors validator:

You found a bug in the validator related to the DSL object "DataTransferObject". The validator found an issue in the btdesign files (unresolved plain Java type "EntityDto" due to missing "@" prefix in "extends EntityDto") and badly fails while associating the corresponding validation error with the wrong DSL model feature. The corresponding IllegalArgumentException logged by Xtexts validation framework is only visible in the verbose Maven log.

The correct validation error can be triggered by omitting the "@" prefix with Entity, ValueObject, Service or Repository.


This will be fixed in the next release. Meanwhile add the missing "@" prefix and you're set :-)

/Torsten

On Friday, October 30, 2015 at 10:15:23 AM UTC+1, Richard Walsh wrote:

Thanks. Again excellent tool and its free so appreciate the effort. There are very few areas of any weakness I can find, well done. 

On 30 October 2015 at 09:14, Richard Walsh richard.walsh wrote:

Ah good to know for the future. 

[Richard Walsh]

Excellent thanks. 

--

You received this message because you are subscribed to a topic in the Google Groups "Sculptor Generator" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sculptorgenerator/suqbsL9xtqs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sculptorgenera...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[richar...@taskize.co.uk]

Would it be possible to easily add recognition of namespaces in generator during code generation?

Excellent thanks. 

To unsubscribe from this group and all its topics, send an email to sculptorgenerator+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Torsten Juergeleit]

By design (simplification) Sculptors model artefacts are identified by their simple names (their object name) instead of a qualified name (the Xtext details for both approaches are described here). So Sculptors DSL and Eclipse editor provide no way for defining qualified names (e.g. via "import" keyword like Java). Each domain objects name must be globally unique.

Introducing qualified names for Sculptors domain objects is a major undertaking:

• The DSL must use the QualifiedNameProvider (instead of the SimpleNameProvider) und need a keyword to define qualified names.
• The generator meta model must support qualified names.
• The model-to-model transformations must support qualified names as well.
• And the generator templates must be updated too.

This is a task for Sculptor version 4 or 5 :-)

Maybe you can you can use the hint keyword in the model to provide a different object name which is used during code generation. But therefore you have to extend / override the generator templates to pick up this hint to generate differently named artefacts.

/Torsten

On Saturday, November 21, 2015 at 4:54:30 PM UTC+1, richard.walsh wrote:

Would it be possible to easily add recognition of namespaces in generator during code generation?

On Friday, 30 October 2015 13:51:20 UTC, Richard Walsh wrote:

Excellent thanks.