Best practice: Do not split a namespace across projects

A single namespace should not be used in two dependent projects; each module or library requires its own set of unique namespaces.

You are likely to encounter problems if you use the same namespace for multiple modules or libraries. Consider this example. A module depends on two libraries that have artifacts with a common namespace. The module references Artifact A in one of the libraries and Artifact B of the same type in the other library. (Artifacts A and B could both be business objects, WSDL files, maps, or some other element.) If the library containing Artifact A is listed first in the dependency editor, the program can find Artifact A but not Artifact B. If the libraries are listed in the reverse order, the program will find Artifact B but not Artifact A.

The same problem will occur if a module that depends on a library has artifacts that have the same type and namespace as artifacts in the library. The program will find the artifacts in the module or in the library, but not both.

WebSphere Integration Developer and WebSphere Process Server require that all artifacts with the same namespace reside in the same library. The same namespace should not be used by artifacts in two libraries. WebSphere Integration Developer generates unique namespaces by default when artifacts are created.

Do not create artifacts with the same namespace in different projects. If you encounter this condition, use the refactoring actions to either move the artifacts to the same project or to assign the artifacts different namespaces. It is a good practice to ensure that the namespace for an artifact shows the actual location of the artifact.

A shared namespace can easily result if you create an artifact in one module or library and then move it to another library. When moving an artifact, first change the namespace to reflect the new location, or at least change the namespace to one that is not being used by the original project.

Feedback
(C) Copyright IBM Corporation 2005, 2006. All Rights Reserved.