Hierarchical component organization
William Byrne (55●4●5)
| asked Feb 13 '10, 4:22 a.m.
edited Jul 11 '16, 10:39 a.m. by David Lafreniere (4.8k●7)
Hierarchical component organization - does it exist?
I'm looking to import a few projects and it seems like they'll appear as a flat list within the Components node of the RTC client. If I accumulate a few dozen projects, each with a handful of components, will I end up with a flat list of a few hundred component entries? If it is indeed flat, would it make sense to adopt the Directory Service paradigm where objects are uniquely identified; yet, free to be located in arbitrary directories? Similar concerns exist for streams. |
Accepted answer
8 other answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Feb 13 '10, 10:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Currently, there is no way to define a hierarchical structure of
components. The work item requesting this functionality is 2127. Please feel free to add your interest/support via a comment on this work item. Note though that many projects will share components, so that a few dozen components, each with a handful of components, does not necessarily result in hundreds of components. Also note that the number of components is significantly affected by the granularity of your components (i.e. how many files/projects are in each component). Because files do not move across components as smoothly as they move within components, there is semantic motivation not to make your components too fine-grained. Cheers, Geoff williambyrne wrote: Hierarchical component organization - does it exist? |
Currently, there is no way to define a hierarchical structure of Thank you. The Composite concept referenced in 2127 is interesting though not necessarily a byproduct of Directory structured components. Groups would probably be better notation than Composites in the world of Directory structures since I imagine compositing is a function of Streams. There should be no additional processing rules to accommodate Directory structured component organization other than the logic required to locate a specific component (e.g., LDAP, NDS path notation). Groups are simply dumb containers that simplify the organization of Components. |
That's debatable. The shop might be managing a few hundred projects with some degree of component share, but not with a broad range of commonality between the projects. Not only could the component list get large, but also Maybe I'm looking at the RTC incorrectly. I have some expectations with respect to the traditional software project layout on disk, and the many SVN/CVS repositories available for a given host. I could be wrong, but it seems like RTC was designed to host a minimal set of projects and components. Regardless of this issue, We're committed to using RTC. It's an awesome product with great potential. |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Feb 14 '10, 10:38 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Comments below:
williambyrne wrote: gmclemmwrote: I didn't mean to imply that in all cases, many projects will share components, but rather that in many cases, projects will share components, either because the company explicitly encourages re-use between projects, or because there are many projects working in parallel on a common system. But that is an observation across a wide range of customers ... it can easily not be the case for a particular customer. Maybe I'm looking at the RTC incorrectly. I have some expectations Yes, that would be wrong (:-). RTC is designed to host a large number of projects and components in a single repository (and in each release, we increase the scalability of the RTC repository). In particular, you will commonly find that you would import all of your SVN and CVS repositories into a single RTC repository. (And as above, that is a general observation ... there will always be exceptions where more than one RTC repository would be used). Regardless of this issue, We're committed to using RTC. It's an That's great to hear! Cheers, Geoff |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Feb 14 '10, 10:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
To clarify, workitem 2127 is not stream-based component composition, but
rather a way to treat a group of components semantically as a single component. I agree that it is much simpler to just provide a hierarchical namespace for components, without the semantics of composition. One of the main reasons is that with composition, it is important that two different composite components be able to contain a commmon sub-component. But with a hierarchical namespace, each component has a single parent. Cheers, Geoff williambyrne wrote: gmclemmwrote: |
Geoff, I'm not aware of any way to move files across components (smoothly or otherwise), at least not "move" in the SCM sense. Is there any way to move files across components (and preserve version history)?
thanks, -Sky Currently, there is no way to define a hierarchical structure of |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Feb 16 '10, 9:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You can use the standard Eclipse "refactor -> move" operation to move a
file across components. The history isn't moved, but a back pointer is created from the new history back to the old history. So history is reasonably well preserved, but note that change-sets with changes of the file at it's old location are not applied to the file at its new location. Cheers, Geoff sky wrote: Geoff, I'm not aware of any way to move files across components |
|
Thanks Geoff, I thought only refactor at the Eclipse project level worked, so good to know about the pointer. I'll have to experiment, but that should work for me for now.
-Sky You can use the standard Eclipse "refactor -> move" operation to move a Geoff, I'm not aware of any way to move files across components |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.