Here is my problem>
We currently have several Ecore models for our applications. One of the Ecore models (mainModel.ecore) has stuff that is common in all the rest of the models. So, what i want to do is have all the other models reference the contents of that one model so we do not have to constantly copy the contents of that one model into all the models every time there is a change.
Is this possible and how can I do this?
(I am very new to Ecore and still do not understand a lot of the terminology.)
EDIT:
How do i get the EcoreUtil.getRootContainer to return the the container of the loaded resource? I need to have that location so that i can resolve certain paths from that root. This may resolve my issue.
Here is what i attempted so far:
I tried "load resource..." by loading the mainModel.ecore into all the other models and deleting the local references. There were a lot of places that i had to fix after doing this and i did. After re-generating the source and trying to compile there are places where it tried accessing the "dotpath" that was local to the original file and i do not know how to change that "dotpath" to reference the "loaded resource". So it is not able to resolve those paths.
Thanks!
You'll generally get answers about EMF more readily by using the EMF newsgroup (eclipse.tools.emf) which is web accessible via
http://www.eclipse.org/forums/index.php/f/108/
Your problem isn't so clear. I don't understand how the compiled code accesses anything via a "dot path". I know if you load a resource and refer to it's contents you'll generally end up with relative paths, but those are normally resolved during loading to an absolute URI. Of course the referencing resource itself needs to be loaded with an absolute URI, but the generator does that properly...
Related
I'm trying to create a custom annotation processor that generates code at compilation time (as hibernate-jpamodelgen does). I've looked in the web, and I find custom annotation processors that works with maven, but do nothing when added to the Annotation Processing > Factory Path option. How could I create a processor compatible in this way? I have not found a tutorial that works.
My idea is to, for example, annotate an entity to generate automatically a base DTO, a base mapper, etc that can be extended to use in the final code.
Thank you all
OK, Already found out the problem. The tutorial I hda found out dint't specified that, in order to the compiler to be able to apply the annotation processor, there must be a META-INF/services/javax.annotation.processing.Processor file that contains the qualified class name of the processor (or processors).
I created the file pointing to my processor class, generated the jar and added it to Annotation Processing > Factory Path and all worked correctly.
Just be careful to keep the order of the processors correctly (for example, hibernate model generator claims the classes, so no more generation will be made after it), and change the jar file name each time you want to replace the library (it seems eclipse keeps a cache). These two things have given me a good headache.
Thanks all
I'm trying to understand mapping of URIs to files. Let's take this URI:
modelica://foo.bar/file.png
Is it correct that there are two possible locations for file.png?
It could be either
$MODELICAPATH/foo/file.png if file $MODELICAPATH/foo/bar.mo exists.
Or
$MODELICAPATH/foo/bar/file.png if file $MODELICAPATH/foo/bar/package.mo exists.
Likely Section "13.2.3 External resources" of the Modelica Language Specification helps.
A little modification of your example should help to understand how it works. Using modelica://foo/bar/file.png refers to foo as top-level package/library. The library the path is resolved when it is loaded in the simulation environment. In case you store the library hierarchically (i.e. every package is represented as folder, each model is a file) bar would be a subfolder within the libraries root directory. file.png would be the file name within bar.
This is different if the package is stored as a single file, but as this has several disadvantages I would recommend to go with the hierarchical option.
No need to edit $ModelicaPath$ if the library is loaded.
Usually pictures etc. are put into a Resources folder within the library. This folder can contain additional folders like data, Images, Scripts...
I would like to add a post-build hook to my code generation process. However, when I try to associate a function with the simulink model's PostCodeGenCommand, I get the following error.
set_param(bdroot, 'PostCodeGenCommand', 'packNGo(buildInfo);')
A configuration set reference does not allow writing to parameters in the source configuration set
I don't really understand the error message, and it doesn't bring up any useful hits on my favourite search engine. Can anyone help me decipher it?
Unfortunately, I could not reproduce this problem on a simple simulink model, even if I included a reference model. (I thought that might be what the word "reference" was, um, referencing in the error message. And I've noticed previously that referenced models are handled differently to other models in the simulink code generator.)
I'm using R2015a, but have access to the newer versions if that would help.
Note that this question was originally posted on the Matlab forum, but didn't get any answers.
It turns out that the model was using a "configuration reference" rather than storing its configuration internally. The Model Explorer provides the following description
Configuration Reference
A model may reference a 'Configuration set' that is defined in the
source location rather than stored in the model....
This is useful for us because we use several models which all share the same configuration set. It's saved in a central place and all updates apply immediately to all models.
The side effect is that bdroot no longer has a PostCodeGenCommand associated with it. Instead, the command I was looking for was
configurationSettings.set_param('PostCodeGenCommand', 'packNGo(buildInfo);')
where configurationSettings is a variable in your workspace, and the variable's name should match the "Referenced configuration set name" in the Model Explorer.
In SugarCRM, you can create your custom modules (e.g. MyModule) and they are kept in /modules just like stock objects, with any default metadata, views, language files, etc. For a custom module MyModule, you might have something like:
/modules/MyModule/MyModule.class.php
/modules/MyModule/MyModule.php
/modules/MyModule/language/
/modules/MyModule/metadata
And so on, so that everything is nicely defined and all the modules are kept together. The module becomes registered with the system by a file such as /custom/Extension/application/Include/MyModule.php with contents something like:
<?php
$beanList['MyModule'] = 'MyModule';
$beanFiles['MyModule'] = 'modules/MyModule/MyModule.php';
$moduleList[] = 'MyModule';
Obviously, the $beanFiles array references where we can find the base module's class, usually an extension of the SugarBean object. Recently I was advised that we can adjust that file's location for the sake of customization, and it makes sense to a degree. Setting it like $beanFiles['MyModule'] = 'custom/modules/MyModule/MyModule.php'; would allow us to access the base class via Module Loader even if the security scan tool prevents core file changes, and this would also allow us to not exactly extend, but replace stock modules like Accounts or Calls, without modifying core files and having system upgrades to wipe out the changes.
So here's my question: what is the best practice here? I've been working with SugarCRM pretty intensely for several years and this is the first time I've ever been tempted to modify the $beanFiles array. My concern is that I'm deviating from best practice here, and also that somehow both files modules/MyModule/MyModule.php and custom/modules/MyModule/MyModule.php could be loaded which would cause a class name conflict in PHP (i.e. because both classes are named MyModule...). Obviously, any references to the class would need to be updated (e.g. an entryPoint that works with this module), but am I missing any potential ramifications?
Technically it should be fine, but I can see how it could be possible that both the core version and your version could conflict if both are referenced. It all depends on the scenario, but I prefer to extend the core bean and find somewhere in the stack where I can have my custom version used in place of the core bean. I wrote up an example a couple of years ago here: https://www.sugaroutfitters.com/blog/safely-customizing-a-core-bean-in-sugarcrm
For most use-cases, there's a way to hijack Sugar to use your bean at a given point.
If you can't get around it you can always grep to see where the core module is explicitly being included to ensure that there won't be conflict down the road.
I can't find a good answer to this simple question:
Where can I add my i18n files in a GWT project ?
I see two solutions:
- create a module and add all i18n files for this module in this module
- create a complete different structure to put all i18n files (no matter what module) in the same directory (and so, easy to create a new language)
My feeling is that the second approach is better but in gwt samples, it's the first approach which is generally used.
And you, what do you do with yours i18n files ?
Thanks
1) Create a separate package in your module. Dump all message files there along with the property files.
2) As a best practice create a base message class and EXTEND other message interfaces from the base one. You can reference base message class in code and depending on which instance of message class you point too, your actual value will change.
Another approach, create a new i18n module and inherit that in your actual model.
1) Allows all messages to be in one place.
2) Easy to hand over to localization people for translation.
I usually put the i18n files (*.properties) in the same package as the Constants (or any other i18n related class) derived interface that's using them (less hassle with setup) - usually the package is named i18n.