Community
Participate
Working Groups
Build Identifier: 3.6.2 In XpandJob, it requires to have model file and a read transaction to execute code generation: IFile file = EcorePlatformUtil.getFile(xpandEvaluationRequests.iterator().next().getTargetObject()); IModelDescriptor model = ModelDescriptorRegistry.INSTANCE.getModel(file); ... model.getEditingDomain().runExclusive(new Runnable() { ... This is really a painful point for end user in some cases: - The model user uses exists in memory only (for ex., result of m2m job) Please consider again these code. Other point is logging info in XpandJob, XtendJob and CheckJob. We should provide facility for developer to enable/disable or change logging info as they want (current logging info is technical info, not suitable for end-user to read) Reproducible: Always
(In reply to comment #0) > In XpandJob, it requires to have model file and a read transaction to execute > code generation: > IFile file = > EcorePlatformUtil.getFile(xpandEvaluationRequests.iterator().next().getTargetObject()); > IModelDescriptor model = ModelDescriptorRegistry.INSTANCE.getModel(file); > ... > model.getEditingDomain().runExclusive(new Runnable() { > ... > > This is really a painful point for end user in some cases: > - The model user uses exists in memory only (for ex., result of m2m job) > > Please consider again these code. This is a valid issue. Xpand/Xtend/CheckJob must support operation on in-memory models that are in no editing domain. I've now revised Xpand/Xtend/CheckJob and made sure that execution is not wrapped in an EMF Transaction in such cases. Along with that I've modified the XtendJob so that its execution is done in a write transaction rather than a read transaction. This enables it to be used for model transformations that perform in-place modifications of the model it is invoked on. > Other point is logging info in XpandJob, XtendJob and CheckJob. We should > provide facility for developer to enable/disable or change logging info as they > want (current logging info is technical info, not suitable for end-user to read) I don't think that this is really necessary. All logging is done with Apache Log4J. It is a quite versatile facility and enables applications to specify via a log4j.properites file the levels of logged information that they want to see. All information with other log levels is then automatically suppressed. Check out the following links to find out more about it: http://logging.apache.org/ http://www.mobilefish.com/developer/log4j/log4j_quickguide_loggers.html
Mass-closing Resolved tickets
