OperationContext disapeard, last seen in 2018.3 !

 
Hi Pro's,
 
i have to report a missing OperationContext in the LOOP-Macros.The OperationContext was last seen in 2018.3, but disapeard with 2019.1.
 
I need it however, to access the all project models. How can i get access to the project?
 
 
Do you want me to call police?
Dan
4 comments
Comment actions Permalink

operationContext has been deprecated for years prior to removal, the reason being its contract is quite vague and unspecific. Generally, it's bad idea to assume too much about environment your generator runs in (except for the input model itself), access to a project from within generator queries make these queries quite fragile. E.g. transformations executed from the context of build script would get completely different "project" than the same transformations executed in IDE (different kind, different set of project modules, etc). I doubt this sounds like something you'd like to care about in your transformations. Besides, Project gives access to various IDE-related functionality (e.g. Editor, Messages View) which could lure users into dependencies mess (i.e. when m2m code starts to depend from UI), All in all, less external stuff queries depend from, the better.

I'm not familiar with your project to give a reasonable advice, general rule of thumb is to keep everything you'd need for m2m transformation inside the input model. This doesn't necessarily mean 'owned' by the input model, there could be references to external nodes.

For transition, you can try to walk modules of input model's repository (genContext.originalInputModel/.getRepository().getModules()), though you'd need a mechanism to tell project modules from those coming in distribution (you can try use SModule.isPackaged() to tell deployed from source modules, just keep in mind it's not 100% equivalent to Project.getProjectModules() - e.g. if you use project libraries with modules in source form, these would get isPackaged()==false as well). Keep in mind that set of modules in the repository could be different for IDE and build script runs.

Just a note, using the fact inputModel comes from a repository is also an assumption I'd like to avoid, but at the moment I'm not aware of any scenario that would transform a 'free-floating' (e.g. not attached to a repository) model.

0
Comment actions Permalink

Hi Artem,

thank you for your in detail response. Generally, i do only rely on the input model, of course! However, in this particular situation, i m generating a project summary XML file, which instantiates all components decared in the project. That information is already available via model imports (jetbrains model properties dialog). Therefore i do not want the user to specify all used components again in a model. The components should be calculated automatically by the given project. This feature is primarily used within the IDE when using the "Play" (Executed node) button.

Of course, if applied in a different setting, the dependencies are not calculated correctly. The user can resort to manually specifieng dependencies then.

 

Right now i  use genContext.originalModel/.getModule().getModels() because i  get basically all modules loaded when accessing the repository(). There are some modules loaded as global libraries, which do not belong the the current project.

Should i do the dependency calcs somewhere else, where i can access the project? pre/post processing scripts? Store them somewhere and access them in the tempalte? 

Cheers,

Daniel

 

 

 

0
Comment actions Permalink

When transforming a given model, do you need to collect component declaration from any model in a project, or just those "visible" (accessible) through model imports? For the latter, just walk imported models and collect components in there. This approach is beneficial as it makes your model less vulnerable to any project inconsistency - as it's the thing MPS could check for you (i.e presence of a module with imported model. Generally, MPS could not deal with implicit dependencies like "component declared in a project" unless instructed for each specific case. Generic way to let MPS know about a dependency is model/module import/node reference). Proper dependencies would make m2m transformation reliable in scenarios where MPS assembles 'project' based on its own idea what to include (e.g. command-line build or tests) - modules your model has imports to would be considered 'dependencies' and automatically present.

 

For the former, if you do need to access IDE project, I'd suggest to use your 'Play' functionality, i.e Action/Button which is bound to UI and therefore can safely access IDE things like Project. You'd need to collect relevant information there and then pass it to Generator/M2M process.

0
Comment actions Permalink

Hi Artem,

thanks for this explanatin - i ll follow the model imports ...

0

Please sign in to leave a comment.