Author Topic: Package Structure (Naming Conventions)  (Read 426 times)

hedgehog

  • EA Novice
  • *
  • Posts: 2
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Package Structure (Naming Conventions)
« on: July 31, 2007, 04:53:07 am »
Hello,

I'm an EA greenhorn and have a question with regards to package naming conventions.

I have been experimenting with package/sub-package naming conventions and have run into the following problem:

Lets say you need EA to track 3 projects, so you create a 'root' package called 'Common' and 2 other 'root' packages (PackageA & PackageB). Within each of these 3 packages, the naming conventions of all the Sub-Packages must be the same.

For example:

Common\Requirements\Features\
PackageA\Requirements\Features\
PackageB\Requirements\Features\

After completing the package configuration mentioned above, you now begin creating requirements under the 'Common' package and would like to reference them within either of the other 2 root packages (PackageA and/or PackageB) via 'realization' links to use cases etc.

So far so good however, when generating an 'RTF' document, it only shows the 'Package' name with which the Requirement came from (i.e. \Features) and NOT the 'path' information (i.e. Common\Requirements\Features\) therefore, the documentation cannot differentiate between identical Package names that are from a diffeent 'root' packages.

Is there way to show the 'path' information in the documentation? and if not, any suggestion on how I can leaverage EA to handle 'common' artifacts across multiple projects?

Note: when generating source code, the namespace information is qualified with file 'path' information so my package/directory structure can be used.

thanks in advance for any advice/help in this matter.

regards,
Robert.