Incorporate Model Templates Problem shall be embedded in generated MDG technolog

[PeterHeintz]

This link:
http://www.sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/model_templates2.html
describes how to distribute a model template with MDG.
However the template file is expected to be deployed in the EA installation folder.

This feature request asks for embedding the model template in the generated mdg file to have the mdg file containing everything what is intended to be distributed.

[PeterHeintz]

I created a official feature request as registered Sparx user.

[Glassboy]

However the template file is expected to be deployed in the EA installation folder.

Nope.  Same directory as the MDG file.

[RoyC]

From the Help topic that you refer to:

• location: The path of the XML file that contains the XMI export of the model template Package, relative to the location of the MDG Technology file; if the XMI file is in the same folder as the technology file then this just contains the file name

[Glassboy]

From the Help topic that you refer to:

• location: The path of the XML file that contains the XMI export of the model template Package, relative to the location of the MDG Technology file; if the XMI file is in the same folder as the technology file then this just contains the file name

I remember when that was an undocumented secret passed from MDGer to MDGer.

[PeterHeintz]

In our environment we deploy the MDG not on user base but on amodel base, to ensure that everyone working on a certain model, is using the same version. So loading the mdg is a "one shot" activity and nobody needs to take care that there is the right mdg on the local machine.

This makes configuration management of that stuff quiet simple.

However if some parts of the mdg are not contained in the mdg file or cannot be imported into the model, things get more complex and error prone.
From my perspective MDG files should be capable to contain all features provided, rather than to depend on things that might be stored somewhere.

[Glassboy]

In our environment we deploy the MDG not on user base but on amodel base, to ensure that everyone working on a certain model, is using the same version. So loading the mdg is a "one shot" activity and nobody needs to take care that there is the right mdg on the local machine.

You don't have to deploy the MDGs to the local machine.  Do you deploy keys to the local machine, so why would you do MDGs that way?

[Glassboy]

There's a registry key called MDGTechnology PathList.  If you work in a managed environment an Active Directory GPP can be configured to set this to a central location for every EA user.

[Geert Bellekens]

There's a registry key called MDGTechnology PathList.  If you work in a managed environment an Active Directory GPP can be configured to set this to a central location for every EA user.

Quite often the people that develop the MDG's are not the same ones who control the technical stuff like AD and registry distribution.
The strings you have to pull, and the hoops you have to jump through to get a change like that distributed often isn't worth it.

That is why I like the model distribution. The model is something we control ourselves, and we don't need anyone approval or help to get it done.

As for development and testing, we have  DEV, TEST and PROD databases to be able to develop and test the MDG, scripts, and other stuff on.

Geert

[Glassboy]

There's a registry key called MDGTechnology PathList.  If you work in a managed environment an Active Directory GPP can be configured to set this to a central location for every EA user.

Quite often the people that develop the MDG's are not the same ones who control the technical stuff like AD and registry distribution.
The strings you have to pull, and the hoops you have to jump through to get a change like that distributed often isn't worth it.

That is why I like the model distribution. The model is something we control ourselves, and we don't need anyone approval or help to get it done.

As for development and testing, we have  DEV, TEST and PROD databases to be able to develop and test the MDG, scripts, and other stuff on.

Geert

So let's get this right; you should only follow the best practice is it is a developer practice.  Perhaps if you treated operations people with a bit of respect and less hypocrisy you may find that there aren't any hoops to jump through.

If you thinking I'm sounding a little bit too scornful it's because I've actually lost count of the number of times I've stopped or minimized the damage from a developer doing something stupid which in a country with laxer employment laws would have got them fired.  Not to mention the number of times I've debugged issues caused by the arrogant attitude that doing it our own way is the best.

Not to mention that modern distribution and management environments are very powerful tools which most organisations have invested in to perform standardized distributions and reduce the complexity and cost of environments.

[Geert Bellekens]

Perhaps if you treated operations people with a bit of respect and less hypocrisy you may find that there aren't any hoops to jump through.

Hmm, I don't really like the tone of that. Why are you assuming, for no apparent reason, that I would not treat certain people with respect?
The hoops we need to jump through are not there because of the people, but because of the management structures, procedures etc..

For me MDG distribution through models IS a best practice in a lot of organisations and settings as it makes things less complex.
- No shared drives or website locations to worry about
- No security concerns regarding those shared drive/locations
- No local settings to distribute
- No local settings that can get messed up by users

I don't see a lot of con's here; but I'm happy to agree to disagree with you.

Geert

[PeterHeintz]

Our company has a modern distribution and management environment. Apart of getting distributed something, needs considerable time (done by out IT) that works fine for many cases. I personally distribute lots of things this way.
However distributing a mdg this way, that will have in future maybe once a week a new mdg version, were the users should decide which version to use on project level, what should work maybe ten years later, would cause nothing but trouble.
By having all stuff in one file, we would need no effort and nor trouble at all.

[Glassboy]

Our company has a modern distribution and management environment. Apart of getting distributed something, needs considerable time (done by out IT) that works fine for many cases. I personally distribute lots of things this way.
However distributing a mdg this way, that will have in future maybe once a week a new mdg version, were the users should decide which version to use on project level, what should work maybe ten years later, would cause nothing but trouble.
By having all stuff in one file, we would need no effort and nor trouble at all.

You don't distribute the MDG this way.  You already have a central key store, why would you also not have a central MDG and model store?  Bear in mind you're talking about text files that take at the most seconds to load even at distance over a WAN.  The IT management infrastructure ensures that all Sparx EA clients are configured correctly.

The shortcoming with loading the MDG and models into the repository is that it is all or nothing.  Everybody gets everything.  Next you'll be asking Sparx for development resource to go into developing more granular controls.  You can already achieve all that with the MDG path\URL functionality.  You can even hide things using excludes in the file system ACLs.

For that matter you can already achieve much the same outcome as a [wizard] model by importing UML patterns directly into the resource view.

[PeterHeintz]

Well, yes we have a central key store, and we have a central place where the MDG file versions are located, and we have a central asset DB, and we have a modern distribution and management environment as well
However in my scenario the model templates belong to MDG version, and in addition I want to ensure (because of the model template can be used several times in the same repository) that new GUID’s are created.

A MDG xml file is typically created from many other files (e.g xml profile files, doc-templates, icons, scipts,…) and as far as I understand, the MDG xml file is all about to pack all that stuff in one file.
For me that works well (apart of this http://sparxsystems.com/forums/smf/index.php/topic,30648.0.html), but there is one thing what is different from all the others, and that is the model template stuff. For model templates there are not GUI elements to write the mts file (ok for me) and model templates are not packed in the xml mdg file (what this issue is about).
Doing that, would make EA mdg stuff implementation consistent and would help me and obviously some other people a lot; it is not at all “all or nothing”. It is about “providing consistency which helps”.

[Glassboy]

A MDG xml file is typically created from many other files (e.g xml profile files, doc-templates, icons, scipts,…) and as far as I understand, the MDG xml file is all about to pack all that stuff in one file.
For me that works well (apart of this http://sparxsystems.com/forums/smf/index.php/topic,30648.0.html), but there is one thing what is different from all the others, and that is the model template stuff. For model templates there are not GUI elements to write the mts file (ok for me) and model templates are not packed in the xml mdg file (what this issue is about).

Packing the models into the MDG xml would remove several pieces of functionality.  Currently I can give a MDG to another organisation and they can create their own model templates or tweak mine and the MDG doesn't have to be recompiled.  And as I have said before you can change what parts of the MDG employee roles can use but using file system permissions to make them unavailable.

Doing that, would make EA mdg stuff implementation consistent and would help me and obviously some other people a lot; it is not at all “all or nothing”. It is about “providing consistency which helps”.

What you're suggesting isn't consistency, its downgrading current functionality to suit a very narrow usage of the application.