[EDIT: The following posting has been edited as a result of background discussions with Sparx]I deem this defect to be serious. Hopefully, there is a simple solution. If there is, I would request that it be made available soon.I have consulted colleagues and we
all agree this appears to be a defect and that it
needs to be fixed as soon as practicable!
Setting a package to be a Namespace Root formally defines the UML fully qualified name for the classifier, in the following manner:
Package: MyPackage <-Set as Namespace Root
Classifier: MyClassifier (within MyPackage)
The UML fully qualified name for MyClassifier is:
MyClassifierIn the structure:
Package: MyPackage <-Set as Namespace Root
Package: MySubPackage (within MyPackage)
Classifier: MyClassifier (within MySubPackage)
The UML fully qualified name for MyClassifier is:
MySubPackage::MyClassifierConnection via Visual Studio is achieved by associating a single VS Project within a VS Solution with a Package in the model. Making the connection sets the selected package to be the Namespace Root.
Connection via the Visual Studio MDG link
must not not invalidate any structure created by
Import Source Directory mechanism (if the
folders are in the
same structure as the
Namespaces).
That is, given that once the connection between a package in the model and its associated VS Project is a loose coupling - so that merging of the model with the code is initiated only on user command (via the
Merge with Visual Studio menu item); it should be possible to create a new repository by
Import Source Directory then connect each imported package with its Visual Studio project (via
Connect External Project) without any changes!
Now if you have a series of overlapping VS Solutions re-using common VS Projects, setting the Namespace Root to the selected package will cause severe problems. A related thread:
Packages, Artifacts and Namespaces discusses similar, but not identical issues.
It seems to us, that the simple expedient of allowing the VS mapping to determine the Namespace Root at connection time (defaulting to the selected package - thus defaulting to the current behaviour) would allow better sharing of common packages among VS solutions.
Sparx have indicated they may look at this in a future unspecified release.
A work-around is available, but it is tiresome and potentially error prone.
Thoughts? Votes?
Paolo
[Edit: BTW: Sparx's response returned within 15 mins of reporting the bug - You gotta be impressed!]
