Move absolute paths in MDG model

[Geert Bellekens]

I'm working on an MDG for a client, and they are supposed to be able to maintain it later on.

So from time to time I will be making adjustments (say create new stereotypes), and sometimes they will make adjustments themselves (change document generation templates)

The problem is that a lot of the path involved in this process are absolute paths.
- All of the icon paths in the stereotypes
- The file paths for the different UML profiles in the .MTS

Has anyone already solved this problem?
I was thinking to write a little script (what else ) to do a mass change of all the absolute paths for both icons and the MTS, but I don't wanna be reinventing the wheel. (or the hot water as we say here)

Geert

[Uffe]

Heeey,

Has anyone already solved this problem?

Well, yes. Microsoft. Not ideal, perhaps, but it should work: use a drive letter.

You and the client agree on a drive letter, and of course the directory structure beneath it. You may want to provide a ZIP archive for this to make sure there's no snags with that.
You map the drive letter to your NAS or whatever with that client's stuff, and the client's MDG hacker maps it to their file server.

Here's a sample directory structure I like:
Root\
|- Icons\
|- Images\
|- Reference Data\
|- Searches\
|  |- EA_Search.xml
|- Tech A\
|  |- Tech A.mts
|  |- Tech A.xml
|  |- Diagrams\
|  |- Patterns\
|  |- Profiles\
|  |- Templates\
|  |- Toolboxes\
|- Tech B\
etc.

You see how it goes. One directory for each type of thing in the technology. Add and delete as needed, although for a situation like yours you may want to create all subdirectories you might need from the beginning just so the structures don't change and confuse the client.

Reference data (where you need to stick things like context scripts, requirement types and style sheets) isn't strictly part of any technology, so goes up one level. Icons and images tend to get reused between technologies, so they go there as well.

Searches are a separate circle of hell. They are imported into the technology from %APPDATA%, so yours and the client's EA_Search.xml must both contain the relevant searches. But since they are referenced by GUID in the MTS, you can't just send the SQL source to the client and have them recreate them. You must distribute your search definitions with GUIDs, so I've included them here. Since EA doesn't actually use this file, changes to the searches is something you need to keep extra track of.

Workspace layouts are probably the same but I haven't checked.

HTH,


/Uffe

[Geert Bellekens]

Thanks Uffe,

That looks a lot like the folder structure I'm using

I was indeed thinking of using a drive letter, then I have to get my client, in a large university with a very locked down IT, to make a drive letter that is persistent.

I'll check if that is a possibility at all, probably easier and less error prone than using a script to switch over from path A to path B

Geert

[Paolo F Cantoni]

Thanks Uffe,

That looks a lot like the folder structure I'm using

I was indeed thinking of using a drive letter, then I have to get my client, in a large university with a very locked down IT, to make a drive letter that is persistent.

I'll check if that is a possibility at all, probably easier and less error-prone than using a script to switch over from path A to path B

Geert

Hey Geert,
Did you consider the local paths feature?  If so, why did you reject it?
It's been a while since I used it, but it was useful at the time.  I also extended the use to places Sparx hadn't got to yet (Consistency, Consistency, Consistency! ^TM), if ever!!!!

Paolo

[Geert Bellekens]

I haven't, maybe I'll have a look at it.
It would be a solution to my problem if that works

Geert