Advantages of making components coarse-grained:

- Major point: Currently a change-set is tied to a particular component,
so although you can move files from one component to another, you cannot
apply change-sets created in one component to another component. So if
you have multiple streams working in parallel on a set of components,
you want to avoid moving files from one of those components to another,
unless you have a "move day" where all streams accept the "move" at once
(so no team is creating change-sets for a file in the original component
while other teams are creating change-sets for that file in a different
component). To avoid the move problem, you can put all the "related"
projects together in one component (where "related" in this context
means "projects between which you might want to move files").

- Minor point: Occasionally (but not all that often), you need to
manipulate the component list of a workspace/stream. The more
components there are, the more cumbersome it is to do those
manipulations (just because the lists are long, and you have to be
scrolling around in them to find the components you want).

Advantages of making components fine-grained:

- Major point: You can easily adjust the configuration of a component
independent of the configuration of the other components in your
workspace. In particular, the scope of a baseline is a single
component, so you can identify interesting component configurations with
baselines, and at any time adjust the configuration of that component to
be an arbitrary baseline that you select.

- Minor point: The GUI currently makes easy to selectively load
components, so the finer-grained the components make it easier to load
just the specific files you need. On the other hand, if there is a set
of projects you always load together, it's better to have them all in
one component, since that helps avoid forgetting to load projects that
you need. So the general guidance here is to group projects together
into a single component if they usually need to be loaded together.

Cheers,
Geoff



On 5/26/2010 4:38 AM, sanneboshuizen wrote:

Hi,

We're about to start using RTC and are at the stage of creating our
components. I guess one extreme is to put all code in one component,
and the other one component per project. I'm looking for some best
practice guidelines on this. Are there any?

What are the disadvantages of making them too fine
grained, or too coarse grained? Because I don't know
the tool yet, I can't see the consequences of how you divide them
up.

We're a small team of developers (6), with around 100+ projects of ejb
services and portlet apps.

I was thinking of creating one common component for all shared
projects (about 10 projects), and then divide up the rest into the
EJB part of the application and the portlet part. So that will be
about another 60 components, with each about 2 projects.

Is this too finegrained? Does this make sense? Thanks!