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.
When generating the Java interface for a MOF Package, the current JavaMapper writes accessors for classes, associations, imported packages, etc. in the order they appear in the metamodel. In the JMI specification, the prescribed mapping has all imports grouped together, all classes grouped together, all associations grouped together, etc. I propose that JavaMapper follow the ordering/grouping used in the JMI specification. Obviously, the resultant classes will be semantically the same. However, the current ungrouped order makes it more difficult to compare the interfaces generated from models that were created by different tools using simple tools like "diff". Some tools will likely not have a well-defined ordering between, e.g. imports and classes. In particular, the tool I am writing does not preserve the ordering between imports and the rest of the contents of a package. If people are going to use SMN with MDR then it would be more convenient to use the JMI spec. ordering because then they can verify that XMI and SMN representations of a metamodel generate the same JMI interfaces using Unix diff. Without this change, the get<importedNamespaceName>() methods appear on different lines and diff reports these spurious differences. Additionally, I suppose somebody could construe the JMI spec. to require that the contents of package interfaces are written out exactly in the order given, which would make this a "defect" instead of an "enhancement." But that is perhaps an extreme viewpoint. BTW, I do not want to change the SMN syntax so that it can preserve this (IMO useless) ordering information. But, I can also understand if you don't want to implement this particular change too. But, if you do, I already have a patch that implements it (since I need this for automated tests of my SMN module).
Created attachment 8162 [details] Patch to implement the ordering in the JMI spec
Hi Brian, I am confused about why the diff is not usable with the current generation mechanism. IMO the order of methods is defined - it is the order in which the corresponding elements appear in the namespace. Could you explain, why the orders differ from one generation to another?
I agree that the ordering is defined in a MOF model. However, it is likely not so well defined in concrete representations of the model except for XMI. For example, if you are creating a MOF model using the UML profile for MOF, the UML diagramming tool will not preserve the relative ordering of imports and classes because UML has seperate associations for imports and classes in a MOF model. In the UML Profile for MOF, there is a statement "The order of MOF Package.contents are not fully preserved when rendered using the profile because UML has seperate associations for ownedElement and taggedValue." A similar thing happens in my SMN module. SMN cannot full preserve the ordering between imports and other elements contained by the package. For example, if you have a package that contains, in the XMI reprsentation: 1. Class C 2. Import P 3. Assocation X 4. Class D 5. Association Y 6. Import Q And you convert it to SMN representation, you get: 1. Import P 2. Import Q 3. Class C 4. Association X 5. Class D 6. Association Y I.e. the relative order of the imports are preserved, the relative order of everything else is preserved, but the ordering between imports and everything else is _not_ presevered (imports always come first). A graphical tool is likely to do something very similar. In fact, a graphical UML editor may not even guarentee the order between Class C and class D or the associations X and Y. That is because UML 1.4's "ownedElement" association is not ordered. My patch does not help in that case. The primary reason I wrote the patch is to make it easier to compare SMN documents to XMI documents, since SMN does not preserve order 100% of the time, due to two artifacts of the syntax (that I happen to enjoy): * imports are always grouped together * the "return" parameter of an operation always appears last BTW, The rationale for this "lossiness" is to support a more natural syntax, and these particular "lossy" cases are harmless AFAICT (UML is much more lossy with respect to the order things appear in). - Brian
To clarify further, one way I compare SMN documents to XMI documents is to go through a process like this: 1. Convert foo.xmi -> foo.smn 2. Generate JMI interfaces from foo.xmi to dir jmi-xmi 3. Generate JMI interfaces from foo.smn to dir jmi-smn 4. diff -r jmi-xmi jmi-smn With this patch, the diff is empty (an exact match). Without the patch, the diff reports spurious differences because the accessors for clustered/imported packages appear in a different order w.r.t. the other accessors in the interfaces for packages.
OK, I see. I liked the patch anyway. I have just commited it into the CVS. Thanks!