Community
Participate
Working Groups
Add option to profile definition which would indicate whether dependencies should or should not be made to the metadata from other profiles (the default would be not to). It would be useful to add arguments to the Profile#define() method that would allow a diagostic chain and/or options to be specified.
Note that automatic migration of profile data may need to be revisited to account for the fact that the metadata for classifiers could be in referenced profiles. One approach to consider would be to change the metadata for existing instances instead of creating new instances and copying the data - this should improve footprint and performance of profile migration significantly.
Please note that stereotypes are special case. Here is an example. Create two profiles "P1" (with stereotype "S1") and "P2" (with stereotype "S2"). Add property "a" of type "S1" (essentially create association between "S2" and "S1") to "S2". Currently, define(...) call on "P2" will create EClass for "S1" and use that as type of "a". That makes "a" useless because applying S1 to some element is going to create stereotype application (dynamic EObject) using EClass for S1 defined in P1, not one from P2. You essentially cannot reference those objects because they are of wrong type. That implies that metadata for stereotypes should always be referenced and not recreated. The current situation limits such associations to stereotypes in the same profile. Note: Even for the classifiers I don't think it would do to have a single Boolean parameter. The option should be more fine grained. Also, this problem cannot be fixed only on the Profile#define(...) side - there is issue on the profile migration side as well (Package#applyProfile(...). Lets assume that above example works or that "S1" and "S2" are from the same profile. Now apply "S1" to an element in model "M1". Apply "S2" to an element in model "M2". Set value of "a" in the second stereotype application to reference "S1" stereotype application in the model "M1". Make some change to profile(s) and re-define them. Migrate the profile in "M1". That migration is going to remove existing stereotype application object and re-create it, with new ID. The reference in "M2" is broken and cannot be fixed. Even if you go there and migrate profile (call applyProfile) it will remain broken.
It sounds as if passing a new option to define() to indicate whether we should referenced vs. recreated is not fine grain enough. From my understanding we would need the ability to tag specific objects in existing profile/models as having the ability of being referenced vs. recreated. Are we all in agreement on that? I can still update the define(..) method to pass options for robustness but I question whether adding a new option as mentioned above is really sufficient. Also, The applyStereotype() would probably have to be changed to not remove existing setreotype applications but rather, change the Eclass to point to the new one and remove unapplicable values thereby preserving existing ID's. I think we all agree on that.
Copying part of a discussion thread from UML2 newsgroup. Profile migration should allow for changes to extension metaclass and not attempt to copy all "base_*" properties. It would be very helpful if the log message were more concise and more helpful than a complete NPE stack trace. E.g. a message: <stereotype::property> does not exist in profile: <name> version <x>. I migrated the profile version for a relatively small model, and my log file contained 340K of completely redundant (and mostly useless) stack traces for the same null pointer... > In my profile, I > modified a stereotype that previously extended Classifier, so that it > instead extends both Class and DataType. The reason is that UML editors > (e.g. RSA 7) offer the stereotype on too many other Classifiers where it > is not applicable. This change causes a NullPointerException when > migrating a model from the previous version of the profile (the > base_Classifier eReference is missing). I expected this to be OK because > the base_Class and base_DataType properties in the new Stereotype version > are filled when the stereotype is created. > > This raises a question about the expected/desirable behavior when > migrating to a new profile version. Should properties removed from the > stereotype be silently ignored when copying data to the new stereotype, > instead of throwing NPE? >
Created attachment 61933 [details] model changes Changes to the metamodel to accomodate new profile#define signature. This is the first of several patches.
Created attachment 61947 [details] Non-ui changes Partial solution. Does not include changes to Stereotype copier or dialog changes.
Created attachment 61988 [details] model only changes
On the subject of Profile::define() options, can we add one also to suppress the creation of validation operations, e.g., xyz(diagnostics : EDiagnosticChain, context : Map<EJavaObject,EJavaObject>) : EBoolean from ownedRule Constraints of a Stereotype (or other Classifiers in profiles)? I think sensible defaults for this option may be: - suppress constraints for dynamic profiles (EOperations aren't useful in dynamic EMF) - enable constraints for static profiles (developer can fill in the constraint method bodies)
Created attachment 62022 [details] merged patch. missing changes to stereotype copier, but including ui changes.
The last patch will have to be redone with new merged changes. Please hold off adopting just yet.
Created attachment 62842 [details] changes to package operation 1. preserve the id of the stereotype application 2. consider any profile when looking for definition. does not include improved error recovery.
Created attachment 63000 [details] UI enhancements.
Created attachment 63001 [details] UI enhancements with ecore updates
Changes to add an options dialog for profile definition and new options to process comments/documentation have been committed to CVS. Further changes will be done for M7.
A change has been committed to ensure that XMI identifiers are preserved during stereotype application migration.
The remainder of the work for this feature (i.e. adding the option to specify whether metadata dependencies should be copied and addressing the related profile migration issues) is deferred to a future release.
Regarding comment #4, target properties that cannot be found (e.g. because they have been removed or renamed) during profile migration are now silently ignored as a result of the changes for bug 178250.
P659 of the spec talks about this issue. It mentions ... Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than the other class/metaclass.
The changes for a new profile definition option to support "foreign definitions" have been committed and pushed to the 'master' branch in git. These changes will support even the scenarios described by Dusko in comment #2, provided that both the referring and referenced models/profiles are loaded into the same resource set and modified/saved at the same time; the NPEs that Dave complained about in comment #4 have also been replaced by IllegalStateExceptions with appropriate messages. Of course, one must be careful with this option, as it allows creation of dependencies between different (versions of) profile metadata in different profiles. Particular care must be used when creating generalization relationships that span profiles and when defining and applying new versions of classes and stereotypes independently of models and/or profiles that may be referencing them.
An integration build containing these changes is now available.
