This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Martin, I noticed something odd regarding the JMI interface generation. I performed the following steps: 1. I read the UML 1.4 metamodel into an extent UML14-original. 2. I generated the resultant metamodel using MDR Explorer. 3. I wrote the UML 1.4 metamodel to another XMI file. 4. I created another extent and read the XMI file into it. 5. I generated the JMI interfaces again into a different directory. I expected that the resultant interfaces should be exactly identical. However, it seems that the "javax.jmi.substituteName" tag on the Model_Management::Package class is not getting picked up consistently. At first I thought that it might be a problem with XMIWriter. But, from looking at MDR Explorer I observed that the tag was serialized properly. Also, in some cases the JMI mapper picks up the renaming, and in other cases it doesn't (see the attached diff). Also, the same thing notices when I am using my SSM tool to write and then read the metamodel. The tag gets written (and read) correctly. So, perhaps this is a problem with the changes you just recently made to the TagProvider?
Created attachment 6891 [details] Differences in the generated interfaces
Here is an example line from the second pass of generation: + public org.omg.uml.modelmanagement.UmlPackage getPackage(); Notice that the renaming is being picked up correctly for the return type but not for the method's name. Also, to reproduce this reliably you might need to shutdown the repository and start it back up between each step. When I tried to do it all in the same session, it worked correctly.
Brian, are you sure that also AttachesTo association is preserved correctly? (tag may be there but if the link in AttachesTo association between the tag and element is missing, the tag will be ignored as MDR doesn't know which element it belongs to). This bug may also be caused by a non-deterministic behavior of association end iterators we are sometimes experiencing (and going to investigate) - there seems to be some loss of information when an association exceeds size of a btree page.
Yes, the link exists (I verified it in MDR explorer using the reflective look). What is odd is that it knows the substitute name and then "forgets" it: public org.omg.uml.modelmanagement.UmlPackage <-- I got it right! getPackage(); <-- I forgot it!
Brian, it does not forget it. The UmlPackage in the return type comes from the name of the _type_ of the reference named "Package" which is where the getPackage comes from (it is the name of the reference rather than name of the class of the type of that reference). You should check whether the tag is also attached to this reference (not only to the class named Package). From what you write it seems that it is only attached to the class.
Created attachment 6901 [details] Fixed UML 1.4 metamodel diff file
The xmi diff file was trying to add the tags to the AssociationEnd and the Reference directly. But, AssociationEnds and References aren't Namespaces so these two tags ended up being "root" (getContainer() == null) objects. As a result, my tool was losing them because it expected all the roots to be packages. I could have sworn that I tried the test out with the XMIWriter and XMIReader as well. But, perhaps my testing was flawed and the flaw went unnoticed since I was only looking at the tag attached to the "Package" class, not the ones attached to the AssociationEnd and the Reference. Regardless, I have attached a new version of the 01-02-15_diff.xml file that seems to fix the problem I was having (and I fixed my tool to not assume all root-level objects are packages :). Perhaps these files should also be in CVS?
It was a bug in XMI diff for UML. Fixed by Brain Smith.
The same problem is in 01-12-02_Diff.xml. Here is a patch.
Created attachment 7194 [details] Patch for 01-12-02
The same issue is in 01-02-03_Diff.xml (CWM 1.0). Unfortunately, 01-02-03_Diff.xml seems to be using Macintosh newline conventions, and my CVS chokes on this file. So, I can't provide a patch; instead, I will just upload the new version of the file. To translate from Macintosh format to Unix format, I executed: cp 01-02-03_Diff.xml 01-02-03_Diff_mac.xml cat 01-02-03_Diff.xml | tr '\r' '\n' > 01-02-03_Diff.xml Then I made the correction to the file. The correction was changing the first occurence of 'a1320' to 'a1319'.
Created attachment 7208 [details] Whole new 01-02-03_Diff.xml
[Sorry for the spam] cp 01-02-03_Diff.xml 01-02-03_Diff_mac.xml cat 01-02-03_Diff_mac.xml | tr '\r' '\n' > 01-02-03_Diff.xml
Patches applied. thanks!