Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Guillaume

Pages: [1] 2 3 ... 72

Working on 2 EA Projects in parallel, I'd like to get an element style (colours) from a project and apply it to an element within a project opened in a different EA instance.
Note that Copy/Paste between projects via the clipboard works ok.

The issue is related with the MDG Office and I haven't any new release since so I'm afraid this is not fixed (or dealt with as a new feature)

Bugs and Issues / Re: Empty enumerations with an XMI 2.1 Import
« on: September 24, 2021, 07:35:35 pm »
I found out that empty enumerations are linked with "Enumeration" stereotyped classes that EA then associated with the GML profile. This could explain why something weird happens when importing the XMI.
I ran a number of tests and version 1.1 indeed works fine for the entire model.

Suggestions and Requests / Re: Transparent color support
« on: September 24, 2021, 07:04:41 pm »
I just found out that it's actually already supported with the Custom draw line:

Setting the opacity to 25 or 50% works well.
All the other options such as rotating the title or changing it position to top left, etc. can be very useful.
It would be great if such options could be made available on the native view.

Bugs and Issues / Empty enumerations with an XMI 2.1 Import
« on: September 24, 2021, 06:15:01 pm »

A team used the XMI v2.1 export to published class models.
When importing it into a blank EAPx file, we noticed that some enumeration classes are empty, even though literal values are visible in the XMI File.

Code: [Select]
<packagedElement xmi:type="uml:Class" xmi:id="EAID_...." name="EnumType" visibility="public">
<ownedLiteral xmi:type="uml:EnumerationLiteral" xmi:id="EAID_..." name="literal value 1" visibility="public"/>

The odd thing is that some enums are populated with a similar content in the XMI.

The User Guide states the following: "When performing Enterprise Architect-to-Enterprise Architect transfers, ensure that XMI version 1.1,  XMI version 2.1 or Enterprise Architect's Native XML is selected"
Yet I recently experienced a case with the Merge where only XMI 1.1 worked. I also found the following thread:

Users tend to use the latest version and choose 2.1 instead of 1.1. Should we rule out 2.1 and use by default 1.1 to avoid any issue?
Is there a way to sort this issue based on the existing XMI 2.1 file ?

Suggestions and Requests / Re: Change the default search to a custom MDG
« on: September 24, 2021, 04:55:09 pm »
Hi Takeshi,

You suggestion is interesting yet it doesn't fulfill the need (Paolo is right): users only use the MDG installed on their shared EA project i.e. they won't install any addin.
The aim is to keep it simple i.e. users simply open EA Model Search and instead of scrolling to the appropriate list of searches, having the right default search group would be much better. In a way these groups could be managed like the available MDG technologies: one could disable /hide search groups and change the default one


Suggestions and Requests / Re: Compare diagrams - gap analysis
« on: September 23, 2021, 12:04:08 am »
Thanks for your feedback.

I just released today a few improvements on this feature (eaUtils 1.19.8): by default diagram 1 content ("old") appears greyed out, and you can also customize all colours (font, background, border).

Suggestions and Requests / Re: Transparent color support
« on: September 22, 2021, 08:32:15 pm »
Hi Paolo,

I meant without shapescript: users working on ArchiMate models asked if they could set the background colour as transparent when showing a hierarchy of elements e.g. functions, processed.


Suggestions and Requests / Transparent color support
« on: September 22, 2021, 07:47:04 pm »

Would it be possible to to add the transparency support on background colours?



I have many custom searches that have been created for clients or demo MDG Technologies.
Since all searches as available from the "My Searches" group, I apply a prefix matching the client or project e.g. eaUtils - Find ...

The issue with this approach is that clients get a list of searches that start with this prefix e.g.
ProjectA - Find applications by Vendor
ProjectA - Find applications by Domain ...

When generating the MDG, could we have an additional step on Searches so after the embedded custom searches are selected, one could enter the search name that will be visible in the Search Menu (removing Project A prefix from the previous example) ?

Alternatively, could we create locally search groups (My Searches 1, My Searches 2) to manage separate lists?

Suggestions and Requests / Re: Change the default search to a custom MDG
« on: September 17, 2021, 07:27:56 pm »
Submitted as a feature request.

Suggestions and Requests / Change the default search to a custom MDG
« on: September 15, 2021, 06:52:32 pm »

A group of users is using a shared EA repository (hosted in Postgres DB) using a custom MDG which includes searches.
When they open the model search (Ctrl + F), they would like to have their MDG selected instead of Common Searches.
Is this feasible or would this be a new option/feature?


Bugs and Issues / Re: Native XML import hangs
« on: September 08, 2021, 10:48:02 pm »
I find the following explanation interesting as I didn't expect it to work this way.

Sparx Support answer:
... the Native XML import does not delete previous information before importing, it simple updates any data already present.  The Native XML export/import has been designed from the ground up to be as fast as possible by reducing the amount of data being transferred over the network which greatly improves performance.

Since the purpose of the Native XML is to replace/load all the data, shouldn't it make sense to provide an option to clear the data from all tables (same as the Project Transfer) if it improves the time to run a Native XML import ?


Reopening this topic, in my case Postgres case sensitivity impacts EA searches, which is an issue for a client.

Using Postgres 12 , we created a case insensitive collation:
CREATE COLLATION case_insensitive (
 provider = icu,
 locale =
 deterministic = false

I then updated the SQL script to create the tables e.g. object_type varchar(255) COLLATE "case_insensitive",

Running a query with the equal operator works ok e.g. name = 'class' returns Class, CLASS and class. However queries using the "like" operator generates the following error:
nondeterministic collations are not supported for like

Looking at Stackoverflow posts, I don't see any solution.

I got the same results as Geert and ended up creating the tagged values on the XSDelement stereotyped attributes, including the enum values + descriptions when applicable.


Pages: [1] 2 3 ... 72