I have a patch that gets stereotypes working with the method I suggested Its on another machine at the moment and the pub is my top priority right now
I'll attach it to issue 6185 when I get back tonight or some tomorrow at the latest. Cheers Bob On 10 February 2011 08:44, Thomas Neustupny <[email protected]> wrote: > Hi Bob, > > how exactly would addAllStereotypes look like when using the event pump the > way you suggested? I'd like to give it a try (make the whole UML2 stereotype > work based on that). > > Thomas > > -------- Original-Nachricht -------- >> Datum: Wed, 9 Feb 2011 21:55:34 +0000 >> Von: Bob Tarling <[email protected]> >> An: [email protected] >> Betreff: Re: [argouml-dev] UML2: How to feed the model event pump for tagged >> values? > >> Hi Thomas >> >> I'm not sure if I follow all the purpose of getRootElements but then >> again I'm not if need to right now. >> >> What I have confirmed is what you have said (that standard euml is >> used to link the model element with a stereotype) - i.e. this line in >> CoreHelperEUMLImpl.addAllStereotypes is clearly out of our control for >> how it attaches and so we can assume the stereotype is correctly >> placed in the repository >> >> ((Element) modelElement).applyStereotype((Stereotype) o); >> >> What you might consider if we find no better way to solve this is to >> generate some event of our own. >> >> We could have addAllStereotypes call the event pump instructing it to >> fire an event with a "stereotype" property after we have either >> applied a stereotype. >> >> So this event would look the same as what currently happens in MDR and >> so all our existing code that looks for stereotype events should work. >> >> Regards >> >> Bob >> >> >> >> On 9 February 2011 16:25, Thomas Neustupny <[email protected]> wrote: >> > Hi Bob, >> > >> > it took me so much time to get the persistence of stereotype >> applications running. Currently this is handled by managing the root >> elements of the >> project instance. It is done by calling the (new) method updateRoots() in >> ProjectImpl, which uses Model.getModelManagementHelper().getRootElements(m), >> which in turn calls ((EObject) model).eResource().getContents() on all >> models. So it's an EMF functionality, not UML2. (All this is not called via >> some event handling IIRC, but I'm not sure.) >> > >> > So, this is how the stereotype-related "model-outside" elements are >> handled. Beat me if you think that's sick, but I found no other way to get it >> reliable loaded/saved with eUML. >> > >> > So, the element we should listen to probably is not a UML2 element, but >> an eCore element (the eResource, which is an EObject)? >> > >> > Thomas >> > >> > -------- Original-Nachricht -------- >> >> Datum: Wed, 9 Feb 2011 12:20:40 +0000 >> >> Von: Bob Tarling <[email protected]> >> >> An: [email protected] >> >> Betreff: Re: [argouml-dev] UML2: How to feed the model event pump for >> tagged values? >> > >> >> I'm not in a position to check the code at the moment so I'll assume >> >> what you say is correct and that EUML is placing the stereotypes links >> >> in the correct place for us (although I am surprised this is not at >> >> least within the model). >> >> >> >> That leaves me stumped for the moment on what we should be listening >> >> to. If something is added at the top level then do we have an element >> >> to be listening to to detect the addition to it? >> >> >> >> If we can find what that element is we need to be listening to then I >> >> think I can work out how to get the event pump to simulate that the >> >> event actually came from the element the stereotype is applied to. I >> >> think doing that would keep the rest of the application simpler. >> >> >> >> Bob >> >> >> >> On 9 February 2011 10:45, Thomas Neustupny <[email protected]> wrote: >> >> > Hi Bob, >> >> > >> >> > thanks for looking at this. (Also thanks for the other replies from >> you >> >> and Tom, I just had no time to continue with my work on that.) >> >> > >> >> > We let eclipse UML2 do the work when applying a stereotype, see >> >> addAllStereotypes(...) in CoreHelperEUMLImpl. I've recently wrote an >> article about >> >> what happens in the dev wiki, see >> >> http://argouml.tigris.org/wiki/UML2%2C_Profiles_and_XMI where I used >> XMLDump a lot. >> >> > >> >> > I'd say that option a) is not the case, so I tend towards b). As you >> can >> >> see, the class itself is not altered when applying a stereotype. To >> check >> >> for applied stereotypes, we also use a eclipse UML2 method. >> >> > >> >> > Does that give you any idea from how to create and listen the events >> >> properly for applying/unapplying stereotypes? >> >> > >> >> > Thomas >> >> > >> >> > -------- Original-Nachricht -------- >> >> >> Datum: Wed, 9 Feb 2011 03:25:09 +0000 >> >> >> Von: Bob Tarling <[email protected]> >> >> >> An: [email protected] >> >> >> Betreff: Re: [argouml-dev] UML2: How to feed the model event pump >> for >> >> tagged values? >> >> > >> >> >> I've been looking at a similar issue for stereotypes and I think the >> >> >> clue comes from looking at the View->XMLDump results having added >> >> >> stereotypes to a class. >> >> >> >> >> >> Here I created a class Test and added all the possible stereotypes. >> >> >> The XMI portion of the dump is below. >> >> >> >> >> >> Notice that the tags that represent the stereotype attachments to >> the >> >> >> class are outside the </uml:Model> end tag. >> >> >> >> >> >> I suspect either >> >> >> a) We are creating the sterotypes (and tagged values??) in the wrong >> >> place >> >> >> or >> >> >> b) There is no way to listen for stereotypes being added to an >> >> >> element. Instead we need to listen for them being added to the >> >> >> repository and when detected determine what element they should be >> >> >> attached to. >> >> >> >> >> >> <xmi:XMI xmi:version="2.1" >> >> >> xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"; >> >> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> >> >> >> >> >> >> >> >> xmlns:UML22StandardElements="http:///schemas/UML22StandardElements/_EshpMAjiEeC74rHqA76v5A/0"; >> >> >> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"; >> >> >> xmlns:uml="http://schema.omg.org/spec/UML/2.2"; >> >> >> >> >> >> xsi:schemaLocation="http:///schemas/UML22StandardElements/_EshpMAjiEeC74rHqA76v5A/0 >> >> >> >> >> >> http://argouml.org/profiles/uml22/default-uml22.xmi#_Es-VIAjiEeC74rHqA76v5A >> >> >> http://schema.omg.org/spec/UML/2.2 >> >> >> http://www.eclipse.org/uml2/3.0.0/UML";> >> >> >> <uml:Model xmi:id="_SUdPoDPxEeCIdeSzV50Lfg" name="untitledModel"> >> >> >> <packagedElement xmi:type="uml:Class" >> >> >> xmi:id="_SxMO8DPxEeCIdeSzV50Lfg" name="Test"/> >> >> >> <profileApplication xmi:type="uml:ProfileApplication" >> >> >> xmi:id="_SUnAoDPxEeCIdeSzV50Lfg" >> >> >> applyingPackage="_SUdPoDPxEeCIdeSzV50Lfg"> >> >> >> <xmi:Extension >> >> extender="http://www.eclipse.org/emf/2002/Ecore";> >> >> >> <eAnnotations xmi:type="ecore:EAnnotation" >> >> >> xmi:id="_SUnAoTPxEeCIdeSzV50Lfg" >> >> >> source="http://www.eclipse.org/uml2/2.0.0/UML";> >> >> >> <references xmi:type="ecore:EPackage" >> >> >> >> >> >> href="http://argouml.org/profiles/uml22/default-uml22.xmi#_Es-VIAjiEeC74rHqA76v5A"/> >> >> >> </eAnnotations> >> >> >> </xmi:Extension> >> >> >> <appliedProfile xmi:type="uml:Profile" >> >> >> >> >> >> href="http://argouml.org/profiles/uml22/default-uml22.xmi#_PB5O8MoqEd6otN4YcPG1_w"/> >> >> >> </profileApplication> >> >> >> </uml:Model> >> >> >> <UML22StandardElements:focus xmi:id="_XG6ckDPyEeCIdeSzV50Lfg" >> >> >> base_Class="_SxMO8DPxEeCIdeSzV50Lfg"/> >> >> >> <UML22StandardElements:implementationClass >> >> >> xmi:id="_Y614UDPyEeCIdeSzV50Lfg" >> >> >> base_Class="_SxMO8DPxEeCIdeSzV50Lfg"/> >> >> >> <UML22StandardElements:auxiliary xmi:id="_az0MIDPyEeCIdeSzV50Lfg" >> >> >> base_Class="_SxMO8DPxEeCIdeSzV50Lfg"/> >> >> >> <UML22StandardElements:metaclass xmi:id="_bkeNADPyEeCIdeSzV50Lfg" >> >> >> base_Class="_SxMO8DPxEeCIdeSzV50Lfg"/> >> >> >> <UML22StandardElements:realization >> xmi:id="_cbhw0DPyEeCIdeSzV50Lfg" >> >> >> base_Classifier="_SxMO8DPxEeCIdeSzV50Lfg"/> >> >> >> <UML22StandardElements:specification >> >> >> xmi:id="_c_QI8DPyEeCIdeSzV50Lfg" >> >> >> base_Classifier="_SxMO8DPxEeCIdeSzV50Lfg"/> >> >> >> <UML22StandardElements:type xmi:id="_dlC9oDPyEeCIdeSzV50Lfg" >> >> >> base_Class="_SxMO8DPxEeCIdeSzV50Lfg"/> >> >> >> <UML22StandardElements:utility xmi:id="_eFpwUDPyEeCIdeSzV50Lfg" >> >> >> base_Class="_SxMO8DPxEeCIdeSzV50Lfg"/> >> >> >> </xmi:XMI> >> >> >> >> >> >> Bob >> >> >> >> >> >> On 31 January 2011 17:41, Bob Tarling <[email protected]> wrote: >> >> >> > I had hoped that the tagged values tab would move into a control >> on >> >> >> > the properties panel. >> >> >> > >> >> >> > The properties panel is driven by a configuration XML file for the >> >> >> > model subsystem where the property names are specified in that >> file. >> >> >> > So there is no need to map the UML2 property names to UML1.x >> >> >> > >> >> >> > Bob >> >> >> > >> >> >> > On 31 January 2011 11:31, Tom Morris <[email protected]> wrote: >> >> >> >> On Mon, Jan 31, 2011 at 5:00 AM, Thomas Neustupny <[email protected]> >> >> wrote: >> >> >> >> >> >> >> >>> my work on tagged values for UML2 (using stereotype properties) >> is >> >> >> stalling because I'm just not keen enough to work with the model >> event >> >> pump. >> >> >> At least this is what I'm guessing, because while with MDR events >> are >> >> fired >> >> >> when choosing a tag definition in the tagged values pane, nothing >> >> happens >> >> >> when doing the same with eUML. >> >> >> >>> >> >> >> >>> Can someone explain to me what I should do? I've read >> >> >> >>> http://argouml.tigris.org/wiki/%3C%3CSubsystem%3E%3E_Model, but >> >> still >> >> >> have no solution. >> >> >> >> >> >> >> >> A lot of this stuff at the top of that page is of historical >> >> interest >> >> >> >> only or no interest at all. The main thing to understand is >> that >> >> both >> >> >> >> the event listener registration and listener processing itself >> needs >> >> >> >> to be correct and the name of the events/properties, as well as >> >> their >> >> >> >> source, is tied to the UML metamodel. If you're listening to a >> UML >> >> >> >> 1.4 source for a UML 1.4 property name and this has changed in >> UML >> >> >> >> 2.x, your listener code will never get invoked. >> >> >> >> >> >> >> >> When I was working on the UML 1.3 to UML 1.4 conversion the event >> >> >> >> processing is where a large portion of the time went, so I >> wouldn't >> >> be >> >> >> >> surprised if the same were true when moving to UML 2.x. >> >> >> >> >> >> >> >> If you look at the current event pump implementation, you'll see >> >> that >> >> >> >> each event basically gets replicated. This is because >> >> relationships >> >> >> >> are asymmetric in MDR and it only fires an event for what it >> >> considers >> >> >> >> to be the "owning" end of the relationship, with the associated >> >> >> >> property name. The old NSUML event registration code basically >> >> >> >> expected to be able to register for either end, so the event pump >> >> >> >> looks up the inverse property and fires events for that too. I >> >> think >> >> >> >> either Bogdan or I replicated all this machinery for the eUML >> >> >> >> implementation already, so this is primarily background >> information >> >> >> >> rather than something you should need to actively worry about. >> >> >> >> >> >> >> >> As I recall there's also some simple property name mapping which >> >> will >> >> >> >> map from UML 2.x property names back to UML 1.4 equivalent names, >> >> but >> >> >> >> this is likely to only be effective in the simplest of cases. >> If >> >> >> >> you're listening to the wrong object, it won't matter what the >> >> >> >> property names are. >> >> >> >> >> >> >> >> If you've got a specific question I'd be happy to answer it, but >> >> there >> >> >> >> is not going to be any magic bullet here. It's just going to >> >> require >> >> >> >> going through and conditionalizing things that have changed >> between >> >> >> >> the two metamodels (or providing mappings within the event pump, >> >> where >> >> >> >> that's possible). >> >> >> >> >> >> >> >> Tom >> >> >> >> >> >> >> >> ------------------------------------------------------ >> >> >> >> >> >> >> >> >> >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2701698 >> >> >> >> >> >> >> >> To unsubscribe from this discussion, e-mail: >> >> >> [[email protected]]. >> >> >> >> To be allowed to post to the list contact the mailing list >> >> moderator, >> >> >> email: [[email protected]] >> >> >> >> >> >> >> > >> >> >> >> >> >> ------------------------------------------------------ >> >> >> >> >> >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2702922 >> >> >> >> >> >> To unsubscribe from this discussion, e-mail: >> >> >> [[email protected]]. >> >> >> To be allowed to post to the list contact the mailing list >> moderator, >> >> >> email: [[email protected]] >> >> > >> >> > -- >> >> > NEU: FreePhone - kostenlos mobil telefonieren und surfen! >> >> > Jetzt informieren: http://www.gmx.net/de/go/freephone >> >> > >> >> > ------------------------------------------------------ >> >> > >> >> >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2702984 >> >> > >> >> > To unsubscribe from this discussion, e-mail: >> >> [[email protected]]. >> >> > To be allowed to post to the list contact the mailing list moderator, >> >> email: [[email protected]] >> >> > >> >> >> >> ------------------------------------------------------ >> >> >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2703001 >> >> >> >> To unsubscribe from this discussion, e-mail: >> >> [[email protected]]. >> >> To be allowed to post to the list contact the mailing list moderator, >> >> email: [[email protected]] >> > >> > -- >> > Schon gehört? GMX hat einen genialen Phishing-Filter in die >> > Toolbar eingebaut! http://www.gmx.net/de/go/toolbar >> > >> > ------------------------------------------------------ >> > >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2703042 >> > >> > To unsubscribe from this discussion, e-mail: >> [[email protected]]. >> > To be allowed to post to the list contact the mailing list moderator, >> email: [[email protected]] >> > >> >> ------------------------------------------------------ >> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2703111 >> >> To unsubscribe from this discussion, e-mail: >> [[email protected]]. >> To be allowed to post to the list contact the mailing list moderator, >> email: [[email protected]] > > -- > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > > ------------------------------------------------------ > http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2703195 > > To unsubscribe from this discussion, e-mail: > [[email protected]]. > To be allowed to post to the list contact the mailing list moderator, email: > [[email protected]] > ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2703331 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
