Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Bjorn S on October 07, 2011, 02:01:41 am
-
I am using EA 9.1, on Windows 7.
I created a scripting group of type "Project Browser" and added a few scripts. Those scripts show up as selections for the Project Browser script context menus, and run fine.
I wanted to export those as a MDG Technology to make it easier to share with others on the team - it's easier to import just one file instead of having to create a correctly named and typed group, create empty scripts and then copy & paste each script etc.
So:
- I created a MDG Technology file using Tools -> Generate MDG Technology File...
- Clicked Next
- Selected "Create a new MTS file" and clicked Next
- Gave a good path and file name for the MTS file, clicked Next
- Entered the Script Group as the "Technology", selected a good path and file name for the XMI file, gave an ID, Version and Note, and clicked Next
- De-selected everything except "Scripts" and clicked Next
- Selected the scripts I wanted to include from my script group and clicked Next
- Clicked Finish
When I imported the MDG Technology I had just created (the XML), the scripting group was correctly created and named, and my scripts were all there. But, the group ended up with type "Normal" instead of "Project Browser", and thus my scripts were unavailable in the Project Browser. EA won't let me change the scripting group type for groups that were imported.
I have tried modifying the XML in both the XML and the MTS file so that the "type" attribute for each script element says "project browser" (also attempted with variations on capitalization, restarting EA between each attempt) instead of "normal". However, after reimporting (and importing into a fresh EA), the group still has type "normal" in EA and thus my scripts don't show up in the Project Browser.
Will modifying the "type" attribute help, and if so, what should I put in there to make the scripting group a Project Browser group?
Is this a bug in EA in that it doesn't get the correct group type right away? How may I get around it, if so?
Am I going about this wrongly? What is the recommended way to share a set of scripts, if not through a MDG Technology file, to avoid a bunch of copying and pasting? (The scripts are maintained separately in Subversion, as are the model packages .) How may I make EA export the scripting group as an MDG Technology file while keeping the group type intact upon import?
Any pointers and hints are appreciated.
Thanks,
Bjorn.
-
Old post, but if anyone comes across it like I did when trying to find a solution for this problem:
"Script goups are not really supported by MDG", as Hetmut Ortmann states in this thread: http://sparxsystems.com/forums/smf/index.php/topic,4734.msg121728.html#msg121728
He continues "Therfore it's a good idea not to include scripts in your MDG. Export your scripts as 'Reference Data' and import it in the repositories where you need the scripts and script groups. You have to restart the repository"
-
FWIW, I don't agree with herr Ortman here. He's right in that script groups don't survive an MDG generation, but the conclusion -- that all scripts should always be distributed as reference data -- doesn't follow.
The key question is: are you really including so many (user-facing) scripts in your MDG Technology that they need to be subgrouped? If not, you don't need to go the reference data route. For instance, you can categorize scripts using a structured naming convention. This takes care of a lot of simple cases.
The one crucial situation where you have to use the reference data approach is where you're dealing with non-normal scripts -- eg project browser or diagram scripts. When you've got scripts of these categories, write the bulk of them in regular scripts which you include in the MDG Technology (naming them "Browser-" or "Diagram-" something), and write a set of minimal browser / diagram scripts which just call the MDG Tech ones. These minimal scripts you export as reference data.
This way, you can keep those parts of the scripts which depend on your custom metamodel inside the MDG Technology with the profiles.
/Uffe
-
FWIW, I don't agree with herr Ortman here. He's right in that script groups don't survive an MDG generation, but the conclusion -- that all scripts should always be distributed as reference data -- doesn't follow.
The key question is: are you really including so many (user-facing) scripts in your MDG Technology that they need to be subgrouped? If not, you don't need to go the reference data route. For instance, you can categorize scripts using a structured naming convention. This takes care of a lot of simple cases.
The one crucial situation where you have to use the reference data approach is where you're dealing with non-normal scripts -- eg project browser or diagram scripts. When you've got scripts of these categories, write the bulk of them in regular scripts which you include in the MDG Technology (naming them "Browser-" or "Diagram-" something), and write a set of minimal browser / diagram scripts which just call the MDG Tech ones. These minimal scripts you export as reference data.
This way, you can keep those parts of the scripts which depend on your custom metamodel inside the MDG Technology with the profiles.
/Uffe
Yep, that's how I try to it do most of my scripts. Do the bulk of the work in a (read-only) script distributed by MDG and call that from a script in a specific group (project browser, diagram,...)
Keeps things a bit manageable.
But it would be even better if MDG's would support different script groups.
Geert
-
Ok, point taken. Not all scripts should be distributed as reference data as per default ;-)
However, in my case, I require a small number of user-facing project browser scripts to be made available to the user of the MDG with minimal effort. Ideally, the MDG would support the different types of script groups, but importing the scripts as reference data seemed a fair work-around to make these scripts easily available upon right-click in the project-browser.