It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,875
×1,381
×1,221

question asked: Aug 13 '14, 11:26 a.m.
question was seen: 5,831 times
last updated: Aug 20 '14, 1:55 p.m.

Related questions

create repository workspace by loading two different components from different streams

0
Ashok Sharma (32●1●11●18) | asked Aug 13 '14, 11:26 a.m.
edited Aug 20 '14, 1:55 p.m. by Stephanie Taylor (241●1●5)
Hi All,
I have a problem, my problem is related to build process. I have one stream say SourceCode_Stream which contains one component say SourceCode_Comp and i have another stream say HelpFiles_Stream which contains one component say HelpFiles_Comp. Now while creating build i want to load both the components collectively but i don't know how to do that.

Thanks in advance.

5 answers

Most liked answers ↑|Newest answers|Oldest answers

1
permanent link
Winston Enos (331●1●6) | answered Aug 13 '14, 11:42 a.m.
Ashok Sharma,

In Eclipse this is as simple as opening the workspace up, going to the Components section, and hitting 'Add' -> 'Component in another repository workspace or stream' and then add your 2 components from the different streams. Then you can optionally add those streams to your flow targets so you can subscribe to the incoming changes.

If you want to do this via the command-line as part of a headless build process:
1. Create an empty workspace using '--empty' as per https://jazz.net/help-dev/clm/topic/com.ibm.team.scm.doc/topics/create_workspace.html
2. Add the components from both streams as per https://jazz.net/help-dev/clm/topic/com.ibm.team.scm.doc/topics/add_component.html
3. Optionally add your flow targets to the workspace to subscribe to component/stream updates as per https://jazz.net/help-dev/clm/topic/com.ibm.team.scm.doc/topics/add_flowtarget.html

Another option if you don't want to script all this is to just setup your workspace in Eclipse, then simply run a load on the workspace from your build process to pull it down, this way you keep the complexity of constructing the workspace in the GUI (which is easier for many people to manage) rather than trying to convey it in scripts that people may not understand enough to augment down the line when you inevitably add more components and streams.

Another option is to use load rules covered at https://jazz.net/library/article/1015
These can capture a very complicated load setup for a workspace but make it very easy for end-users to consume and work with without knowing the specifics of the magic going on underneath.

Comments
Tim Mok commented Aug 13 '14, 3:32 p.m.
JAZZ DEVELOPER

Note that adding the components from the different streams will give you the configuration of those components at the time added. You'll still want to update the components when necessary but get the updates from the correct sources. This kind of flow with multiple flow targets for your build stream isn't supported in a way that persists the multiple flow targets.


You can add the components and even set the components to flow with the different streams. However, that information is only saved client-side. Someone else that loads the workspace won't have those flows set.

1
permanent link
Tim Mok (6.6k●3●8) | answered Aug 13 '14, 3:40 p.m.
JAZZ DEVELOPER
I would recommend using a workspace for each of the components. These workspaces update their respective components from the source streams. Then deliver any changes to a build stream where you want to perform a build. The build user will have its own workspace based on the build stream and will get the two components that way.

This is how the RTC teams work. Each team loads what is necessary (e.g. I load SCM and Work Items but a Work Items dev doesn't load SCM). The SCM team has its own stream and delivers to an integration stream that has all the components for the project. Then a build runs on the integration stream and will have all the components.

Each team is responsible for handling deliveries to the integration stream and ignoring any changes in components they don't care about.

See Multi-Stream Development, section 2.3. You'll see how there's a JUnit Integration stream that has all the components. The JUnit stream has a subset of the components and other users flowing their workspaces with it. Then you can have other workspaces flowing with JUnit Integration that have all the components.
1
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Aug 13 '14, 4:22 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
In you enable "Jazz Source Control" for your build, the "build workspace" will automatically accept from all flow targets, so you just need to declare in your build workspace that SourceCode_Comp flows with SourceCode_Stream and HelpFiles_Comp flows with HelpFiles_Stream.

0
permanent link
Ashok Sharma (32●1●11●18) | answered Aug 14 '14, 11:10 a.m.
Thanks you all for your reply.

Winston thanks a lot for the details you sent, but creating empty repository workspace and then adding components in it will not be a right choice for me since i want to create one Snapshot for each build and that should be recorded with stream itself so that will have record for past builds. 

I can do one thing that i can add HelpFiles_Comp in SourceCode_Stream and at the time of build can take updates by setting flow target with right help stream but since i have many source code streams and adding one extra component to all those streams is a right way to do that?

Thanks
Comments
Winston Enos commented Aug 14 '14, 11:40 a.m.


"i want to create one Snapshot for each build and that should be recorded with stream itself so that will have record for past builds. "

My original recommendation was just if you wanted a cheap throw-away build workspace that had components from multiple streams.

If you want snapshots recorded on this specific stream, you're going to have to go multi-stream as Tim Mok suggested.

As Tim said, you'll need some type of 'downstream' build stream that contains all these components for your build, and you'll have to flow with your 'upstream' dependencies to get the components and changesets you want for the build, in your example SourceCode_Stream would push its changesets to this build stream for the component 'SourceCode_Comp' and your other stream 'HelpFiles_Stream' would push its changesets to this build stream for the component 'HelpFiles_Comp'.

Once the build is done, the snapshot would be created in the build workspace, and you could use the CLI to reassign ownership of the snapshot (what used to be called 'promote') to the build stream to capture the configuration of all the components and their baselines.
0
permanent link
Ashok Sharma (32●1●11●18) | answered Aug 19 '14, 2:43 a.m.
Sounds good.
Winston/Tim/Geoffrey, thank you very much for sharing information.

Your answer

Register or to post 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.