Package stereotype jumps profile when checked out

[Geert Bellekens]

We are using the UPCC3 MDG technology for a part of our model (something inherited, don't ask )

We are also in the process of upgrading to v15 and noticed a really annoying bug.
These package are versioned in TFS, so in order to edit them we need to do a checkout (which performs an xmi import)

Now when I do a checkout of such a package, the stereotype that was previously part of UPCC3, now suddenly is part of UPCC2, and the tagged values belonging to the UPCC3 stereotype are now gone! (from the docked properties view. I can still see them in the properties Dialog)

EA does this despite of me setting UPCC3 as being disabled in the model options, and having an active perspective that also doesn't include UPCC2

This problem doesn't seem to arise when I disable the UPCC2 technology in the Specialize | Technologies | Manage Tech

This really worries me. Apparently EA doesn't store the correct profile in the xmi file upon checkin, and when checking out it simply uses the first profile it can find that contains a matching stereotype.
This guessing mechanism apparently
- doesn't take into account the used profile on the already existing package
- doesn't take into account the used perspective
- doesn't take into account the MDG required/disabled configuration on the model level

It does seem to look at the MDG configurations from Specialize | Technologies | Manage Tech, but unfortunately that is the only setting that is stored in the user profile, and I cannot influence on the model level.

Seems like I better resort to removing the unwanted MDG file from the program files folder

Luckily in this case we use remote desktop, so it only on one server that I need to remove the files.

Geert

[Eve]

Now when I do a checkout of such a package, the stereotype that was previously part of UPCC3, now suddenly is part of UPCC2, and the tagged values belonging to the UPCC3 stereotype are now gone! (from the docked properties view. I can still see them in the properties Dialog)

Sounds very troubling. I haven't tested the issue yet, but if this is the case I'll be pushing for a fix straight away. Both from the perspective of data loss in XMI round trip and my personal hatred of stereotype ambiguity. (Something I've been getting rid of for years)

Update: The information isn't exported for the root package of an export. I don't have version control set-up, so I'm not sure if the XMI for the parent package contains the information for its child package.

[Geert Bellekens]

Now when I do a checkout of such a package, the stereotype that was previously part of UPCC3, now suddenly is part of UPCC2, and the tagged values belonging to the UPCC3 stereotype are now gone! (from the docked properties view. I can still see them in the properties Dialog)

Sounds very troubling. I haven't tested the issue yet, but if this is the case I'll be pushing for a fix straight away. Both from the perspective of data loss in XMI round trip and my personal hatred of stereotype ambiguity. (Something I've been getting rid of for years)

Update: The information isn't exported for the root package of an export. I don't have version control set-up, so I'm not sure if the XMI for the parent package contains the information for its child package.

Thanks Eve,

I've been talking to Anil about this issue if you need more details.

Geert

[Eve]

No worries. I guessed as soon as I saw this that it was related to that issue. It's now been passed on to our XMI guy. Hopefully we'll have something helpful for you soon.

From my perspective seeing this bug is a win for EA 15. Before then you could have only seen the problem by looking into the database.