Created attachment 68396 [details] A umbrello model file demonstrating the failure Version: unspecified (using KDE 4.5.5) OS: Linux I have a moderately complex model in umbrello. When I attempt to run the code generation wizard all the classes, except one, create some sort of python code structure. But one does not. It pauses on the progress screen and its status never changes from "Not Yet Generated" I don't think there is anything fancy about this class, and in fact as a test I went in to its properties and deleted all Attributes and Operations and then deleted all the Associations. It still won't generate code. Reproducible: Always Steps to Reproduce: Open the attached temp.xmi, attempt to generate python code. note that the only visible class, "Primitive Test Functions" never leaves the "Not Yet Generated" state. Actual Results: Some code frameworks are generated, others are not. Expected Results: All specified code frameworks should be generated. This is a very worrisome bug as code framework generation is key to the work flow that I am setting up for my department.
Created attachment 68402 [details] Same file, further stripped. I stripped everything I could find out of this class and it still won't build code.
It occurs to me that there was one thing that I might have done differently. I think I used the "Source Code" tab somewhere in that class and put in some psuedocode, just to test that function. The generation failed, and the first thing I did was delete that code, thinking that I had done it wrong. But the problem continued even with the code deleted. But I suspect perhaps some trace has been left.
I was able to create a seemingly identical class. Then plug it in to the same place in the diagram. Delete the problematic class. Rename my new class to the originals name. And everything now exports. Very clumsy.
Looking into your attachment id=68402, the class in question is: <UML:Class visibility="public" isSpecification="false" namespace="Logical View" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="hLB5tjdEVzQ6" name="Primitive Test Functions."/> However, this class (xmi.id="hLB5tjdEVzQ6") has a few dangling dependencies to classes not contained in the file, <UML:Dependency visibility="public" isSpecification="false" namespace="Logical View" supplier="hLB5tjdEVzQ6" xmi.id="ZYGic8C768cZ" client="jTuo0mdW6PeR" name=""/> <UML:Dependency visibility="public" isSpecification="false" namespace="Logical View" supplier="jTuo0mdW6PeR" xmi.id="1ZTJnXX4rdr0" client="jTuo0mdW6PeR" name=""/> <UML:Dependency visibility="public" isSpecification="false" namespace="Logical View" supplier="jTuo0mdW6PeR" xmi.id="mmtJN3ihe4Pl" client="jTuo0mdW6PeR" name=""/> [...] <UML:Dependency visibility="public" isSpecification="false" namespace="Logical View" supplier="hLB5tjdEVzQ6" xmi.id="CuwyanplvHio" client="jTuo0mdW6PeR" name=""/> <UML:Dependency visibility="public" isSpecification="false" namespace="Logical View" supplier="jTuo0mdW6PeR" xmi.id="VemOvUDr3R4Q" client="hLB5tjdEVzQ6" name=""/> and I see further dangling associations/generalizations/dependencies. Apparently the cleanup of associations on removal of participant classes is not working as it should. Or did you hand edit the XMI file?
Nope, no hand editing. That is the XMI file produced by Umbrello. I did edit the model beforehand for clarity, removing all extraneous diagrams and classes. But that was all from within Umbrello. The XMI is exactly as produced by Umbrello.
Another oddity has cropped up. In my exported code many of the classes now have a dependency on a library called "Undef" which I certainly have never used.
Created attachment 68474 [details] very simple demo XMI, original version (In reply to comment #5) > Nope, no hand editing. That is the XMI file produced by Umbrello. > > I did edit the model beforehand for clarity, removing all extraneous diagrams > and classes. But that was all from within Umbrello. The XMI is exactly as > produced by Umbrello. I can reproduce this: In the demo file attached, there are classes A, B_will_be_removed, and C. Further, there are two associations, - "assoc_between_A_and_B" between A and B_will_be_removed, - "assoc_between_A_and_C_will_be_removed" between A and C. (text is continued in next attachment)
Created attachment 68475 [details] previously attached model after deletions This file is a modification of the previous attachment: - Class B_will_be_removed was removed using right-mouse-button "Delete" in the tree view - Association assoc_between_A_and_C_will_be_removed was removed in the diagram area using right-mouse-button "Delete" after selecting the association The XMI still contains <UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="XnIYsvMtysVJ" name="assoc_between_A_and_B" > although class "B_will_be_removed" was removed. (The other test, namely the deletion of association assoc_between_A_and_C_will_be_removed, seems to have been successful as this <UML:Association> is no longer in the file.)
(In reply to comment #4) > [...] > However, this class (xmi.id="hLB5tjdEVzQ6") has a few dangling dependencies to > classes not contained in the file, > [...] > and I see further dangling associations/generalizations/dependencies. To be precise, running http://uml.sourceforge.net/developers/ducheck.sh on your attachment 68396 [details] yields: $ ducheck.sh bug293042-att68396-temp.xmi dangling ref "HXlrwGZbDgpX" in line: 277 dangling ref "U8uSDGx9nOlJ" in line: 209 227 dangling ref "33ggVf38NIOa" in line: 283 dangling ref "kFgW6wFNUyEO" in line: 289 dangling ref "CnzORnvSob8H" in line: 295 dangling ref "gmBSFhoPEarb" in line: 221 226 dangling ref "tMCZ0w1dneni" in line: 227 233 dangling ref "z0Emb5xhbI1j" in line: 171 176 182 dangling ref "wyZjp3CVZTW0" in line: 99 105 110 dangling ref "D0TxuePqawZP" in line: 122 dangling ref "GBQbSm9Czoj6" in line: 271 dangling ref "3cofBiIRpMpa" in line: 250 dangling ref "tyz8MNY1QFG4" in line: 153 158 164 192 197 dangling ref "tvlhAYwbkCeL" in line: 208 214 220 dangling ref "8eYrDspQ6bqh" in line: 116 dangling ref "Vihz7ELPD9fU" in line: 270 276 282 288 294 300 dangling ref "DSsrOcwKg7Bn" in line: 301 dangling ref "fcAQQi3bRXc3" in line: 234 240 dangling ref "YjYJzFEmQceA" in line: 98 104 111 117 123 dangling ref "Wqys6oFQqHaT" in line: 215 225 dangling ref "X7iX3jBoOwXC" in line: 225 226 239 248 250 dangling ref "r7wt4pJOXMw5" in line: 165 183 dangling ref "RfQZdrlB4cAx" in line: 248 > Apparently the cleanup of associations on removal of participant classes > is not working as it should. I will try to review the Umbrello source code with an eye to this.
*** Bug 256716 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > Another oddity has cropped up. In my exported code many of the classes now > have a dependency on a library called "Undef" which I certainly have never > used. Yes, Umbrello creates this "undef" type as a placeholder when dangling <UML:AssociationEnd>s are loaded. I take the liberty of renaming this bug according to my findings.
SVN commit 1283458 by okellogg: umbrello/umlcanvasobject.cpp - removeAssociationEnd(): Call UMLDoc:removeAssociation() on the assoc. umbrello/umldoc.cpp - removeUMLObject(): Remove associations that this object may participate in. M +5 -4 umlcanvasobject.cpp M +31 -0 umldoc.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1283458
apply fixed bug from 4.9.0 changelog