Custom client setup and configuration
Preamble: We are planning to move from a very simple single-stream configuration to a more complex multi-stream config where each stream has its own release cycle. It places a higher burden on the build system to automate cross-stream dependencies as much as possible due to the high number of developers across the products that will utilize this system. We want human error to be a minimal factor.
I am using Ant to drive a) the command-line SCM tool to download a repository workspace; b) import it into Eclipse; and c) hook it up to RTC source control. The problem is the last step: I can't get the imported project to be recognized by RTC, even though Eclipse recognizes it as imported and shared. By "recognized by RTC" I mean the Pending Changes view shows the project and its associated repo workspace, the project explorer view shows the project name with its associated workspace and component name, and when I click "Compare > Previous in repository" it works. Initially I used the RepositoryProvider to map the project to RTC, but that just marks the project as shared. Then I used the ProjectCreator internal class to import the project with exactly the same result. Any other places to look? I'm not too concerned about internal APIs at this point, I'm sure this kind of functionality isn't exposed for general-purpose use. |
8 answers
(2) Load that user's RTC workspace into that user's Eclipse workspace With the caveat that this is actually three steps: (1) Import the project into Eclipse (2) Indicate that the project is shared (3) Tell RTC's components that the project exists and update the Pending Changes view So all the configuration is done at the stream level. The team leader for the project does that once for the whole team. The other operations (create workspace, load workspace) do not involve any configuration on the part of the user, so there is nothing to script. Well, creating and loading the workspace can be scripted, but there's no need for user intervention in those cases. Or at least almost nothing to script ... in 3.0, if you want to lay out your Eclipse projects in non-default locations on disk (the default location is directly under the Eclipse workspace directory), you would either have to used the advanced Load As menu, or would need to script it. But as Heather posted, in 4.0, those non-default Eclipse project Correct, but 4.0 is half a year away with another month before the first fix pack (and our RTC hosts never upgrade without a fixpack) leaving me with a need to resolve this in 3.0 ifix 1. With that in mind, is there still something about loading files into an Eclipse workspace that you believe will need scripting, even in 4.0? Yes, in a way I still think there is. Our project is getting more complicated in terms of distribution of assets and their dependencies. It's not unthinkable that users could self-load their repo workspaces into Eclipse but having our build subsystem do it for them would eliminate the support needs for developers who are not full-time RTC-savvy users of our systems. (And that accounts for a large percentage of our developer base.) I'm asking for the APIs that are triggered by a Load operation to be available publicly (or a guide to the internals because we upgrade RTC sufficiently rarely that I'm not concerned about it) so that I can not only download their repository workspace but also set up Eclipse entirely automated. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 23 '11, 12:23 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, the overuse of terms like "workspace" and "project" can create
confusion. So it is good to always qualify them, as in "repository workspace" vs. "Eclipse workspace". Loading files from RTC into a user's Eclipse workspace can be thought of as a three step operation: (1) Configure a stream to have the right configuration (1) Create a repository workspace on that stream for a user (2) Load that user's RTC workspace into that user's Eclipse workspace So all the configuration is done at the stream level. The team leader for the project does that once for the whole team. The other operations (create workspace, load workspace) do not involve any configuration on the part of the user, so there is nothing to script. Or at least almost nothing to script ... in 3.0, if you want to lay out your Eclipse projects in non-default locations on disk (the default location is directly under the Eclipse workspace directory), you would either have to used the advanced Load As menu, or would need to script it. But as Heather posted, in 4.0, those non-default Eclipse project locations can now be configured once by the team lead for the whole team, so in 4.0 you should have no need for scripting. With that in mind, is there still something about loading files into an Eclipse workspace that you believe will need scripting, even in 4.0? Cheers, Geoff On 11/22/2011 2:38 AM, sbates wrote: gmclemmwrote: |
If you are trying to automate the association of a workspace with a I think the term "workspace" is being overloaded here. I'm referring to the Eclipse workspace, not repository workspace. It sounds like your term for Eclipse workspace is "sandbox", in which case the projects in the sandbox are what I'm trying to associate with the downloaded repository workspace, thereby updating the Pending Changes view. Does that clarify? |
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 22 '11, 12:53 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
If you are trying to automate the association of a workspace with a
stream, then this has nothing to do with "loading". To associate a workspace with a stream, you set the flow target of the workspace to be that stream ... you don't load the stream into the workspace. So you may be looking at the wrong part of the API ... "loading" is for loading files from a workspace into a sandbox, and has no effect on what stream is associated with the workspace. Cheers, Geoff On 11/21/2011 8:53 PM, sbates wrote: gmclemmwrote: |
If you are using 4.0 the new load rule support would possibly help, you can configure it to do the load and import projects into Eclipse. No need to use internals. I look forward to this great-sounding feature! If there's time to ensure this rule support would work (rather than possibly help) for my scenario that would be excellent. Otherwise try using IShareOperation, specify overwrite as true. caveat, it is internal and can/will change from release to release, even potentially within a fix pack. I understand, so far from 2.x to 3.0 internals have been pretty steady but I'm sure from 3.x to 4.x that could change. |
It sounds like your are trying to produce your own "Load" command. The difficulty is helping developers know which streams to load into their workspace. We need the assistance of automation because we have multiple projects and streams contributing to multiple flavors of products. We're not trying to make a complex setup, we're simply finding that our product requires componentization across multiple projects and teams. Is there a way to make a call simulating a Load operation? |
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 21 '11, 6:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
It sounds like your are trying to produce your own "Load" command.
What is missing from the existing Load command in the RTC plugin for Eclipse? Cheers, Geoff On 11/21/2011 12:08 PM, sbates wrote: Preamble: We are planning to move from a very simple single-stream |
If you are using 4.0 the new load rule support would possibly help, you can configure it to do the load and import projects into Eclipse. No need to use internals.
Otherwise try using IShareOperation, specify overwrite as true. caveat, it is internal and can/will change from release to release, even potentially within a fix pack. Preamble: We are planning to move from a very simple single-stream configuration to a more complex multi-stream config where each stream has its own release cycle. It places a higher burden on the build system to automate cross-stream dependencies as much as possible due to the high number of developers across the products that will utilize this system. We want human error to be a minimal factor. |
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.