Packages, Artifacts and Namespaces

[PaulH]

Hi

I'm not sure how to go about this in EA...

I have a classes which are contained in a set of hierarchic namespaces. Now to allow round-tripping between VS and EA I create a number of packages, each of which corresponds to a project name in my solution.

When I synchronize, the MDG link creates sub-packages underneath my node, one for each namespace.

The problem with that is that now all of my packages, have the duplicated namespaces (the top 2-3 tiers of the namespace tree).

If I create a unified view, then I'm going to lose my linkage to the code, but otherwise I'm left with a rather odd hierarchy.

Any ideas, or am I approaching this in the wrong way.

[PaulH]

I'd like a response to this - the reverse engineering is fairly useless without being able to control this properly.

[Eve]

I don't think there's anything you can do about this, at least not on the EA side.  Each package can only link to one project, and requires the packages representing namespaces below it.

My question though is why is this a problem?  All you're seeing in EA is the structure you have in your overall solution.  If it shouldn't be structured that way in EA, should it be structured that way in Visual Studio?  Perhaps this is just the first way that EA can help you recognise something that needs reworking.

[PaulH]

As far as I'm concerned, the package hierarchy is already correctly structured.

For example, the I have Ontologyx.Parsing and Ontologyx.Import which correspond to the Parser and Import projects.

What I thought should happen is that I create a package called Ontologyx, then create two sub-packages Parsing and Import and attach the projects to those nodes, but if I do so, the reverse engineering creates the root namespace again underneath the nodes.

Am I doing this incorrectly?

[Mitch]

This may have something to do with the "namespace root" of your folders in the EA project browser.

To set the namespace root: Right click the folder->Code engineering->Set as Namespace root,

Or if the folder is already the namespace root, the menu item says "clear namespace root.

The only way to determine which IS the namespace root is to look at all the context menus for each folder, then infer from the test of the menu item.

BTW, the namespace root also effects the namespaces that are created when generating code. That's how I discovered this feature.

I don't know if this is your exact problem, but it gives you something to experiment with. Unfortunately, in EA feature addition takes a back seat to user interface. EA is a good tool, but I constantly find myself "looking" for stuff in menus and context menus.

Mitch

[Aaron B]

The only way to determine which IS the namespace root is to look at all the context menus for each folder, then infer from the test of the menu item.

You can also try using "Settings | Model Namespaces" to see what namespace roots are declared in your model.  From here you can easily locate any namespace roots in the project view.

Regarding the package linking behaviour, this sounds like it is to be expected.  When you link a package with MDG, it should construct the classes and namespace hierarchy beneath the linked package.  Each linked project has no awareness of any other project.  If you have two projects which deal with the same namespace in code, you will simply have two linked packages with similar namespace definitions beneath them.

You could use "Project | Source Code Engineering | Import Source Directory" to import the two projects into the one package for the purposes of documentation if that's what you need, but maintaining two projects within the one package is not compatible with the way MDG Link works.

[Philipp]

Unfortunately, with the current solution in EA, you're stuck as soon as you have two packages in your model that contain objects of the same namespace.

It would make much more sense if we could actually define the root namespace of a package, e.g.

EA Package Model with Namespace: MyApp.Core
EA Package Implementation with Namespace: MyApp.Core
EA Package Utils with Namespace: MyApp.Util


If you have a fairly complex solution, you automatically want to organize your models in packages. However, this structure does not reflect the namespace hierarchy at al. (Just imagine the namespaces of the .NET framework represented in EA: Each package contained hundreds of classes and interfaces - you could never work with that...).

Currently, you can synchronize your EA models with code in individual folders with individual namespaces. However, forward engineering completely screws the source as it creates additional classes in the source files with the namespace of the EA package hierarchy.

Would love to get a feedback from EA on this :-)

Cheers,
Philipp