Version: svn - 565476 (using KDE KDE 3.5.0) Installed from: Slackware Packages Compiler: gcc 3.4.4 OS: Linux When a java class is imported, the classes that the imported class needs are assumed to be in the default package. If the dependent classes are imported they left in the default package from the navigation trees point of view, but cannot be move to the correct package. As well, depending on the order that classes are importted more than one class might be created (one in the default package and one in the correct package). When this occurs usually the associations are against the class in the default package instead of against the class in the real package. I will attempt to attach some "demo" classes to this bug report. For example: - import these classes: Pack2.java Pack3.java Pack4.java Pack5.java - this results in Pack4 being placed in the default package and cannot be moved to the pack2 package - import Pack1.java - this results in the related classes placed in the default package even though they belong in their respective packages - now import Pack2.java Pack3.java Pack4.java Pack5.java this results in am empty pack2 package -import Pack7.java -import Pack1.java - this results in duplicate Pack7 classes the associations are against one of the Pack7s and the member variables are included in the other
Created attachment 17104 [details] test classes for import described in bug report test.tar.gz is agziped tar of the classes described in this bug report
Created attachment 17105 [details] patch to resolve dependencies on java import The attached patch solves the issues described in the bug report. Patch was created with this command: diff -c svn/kdesdk/umbrello/umbrello/codeimport/ kdesdk/umbrello/umbrello/codeimport/ > javaresolve.diff Basically the idea is that when a new type in encountered an attempt is made to import the new type. This way associations and packages are created correctly. Most of this change is limited to the java import class, however in import_utils: - added a new version of insertAttribute that accepts a UMLClassifier* instead of a string - adjusted createGeneralization to be able to deal with realization regards jp
SVN commit 565676 by okellogg: Apply attachment id=17105 from JP Fournier 2006-07-24 > Basically the idea is that when a new type in encountered an attempt is made > to import the new type. This way associations and packages are created > correctly. Most of this change is limited to the java import class, however > in import_utils: > - added a new version of insertAttribute that accepts a UMLClassifier* > instead of a string > - adjusted createGeneralization to be able to deal with realization > Kudos to JP for his many JavaImport fixes (to appear in version 1.5.4.) BUG:131270 M +5 -4 ChangeLog M +26 -11 umbrello/codeimport/import_utils.cpp M +8 -2 umbrello/codeimport/import_utils.h M +150 -5 umbrello/codeimport/javaimport.cpp M +33 -0 umbrello/codeimport/javaimport.h