Programmatically extracting files to a remote file system
Given a list of IFileItem objects (which may come from a mix of various workspaces and streams), I'd like to extract them from the RTC repository directly to a plain file system (maintaining their full paths, of course) on a remote machine. I don't need to do any other build-related tasks here, just extract the files.
Performance is very critical. i.e., we would need to extract directly from the RTC server to the remote machine without having to first extract to the RTC client. Our Java code that will be triggering this runs as a client process, but we could write/install server-side code for it to call if necessary. For those familiar with CMVC, this would be akin to using the -node option on a file/track/level extract. What are the best options for accomplishing this? |
5 answers
|
FWIW, I've considered using the Jazz Build Engine, but that tool seems to operate more as a client, in that it associates itself at startup with a single repository, build definition, and userid, whereas our situation would need to work for a vast number of users across potentially many repositories, and wouldn't really need to be driven by (or even associated with) a particular build definition (of which a single user may have many).
The Rational/BuildForge Build Agent looks like it might be more server-oriented, but I'm not sure if there's direct access to it via a Java API, and if so how granular/specific requests can be. I've only found cursory docs on this service so far, and only from an install/config POV. Otherwise, I'm guessing that one would have to write some sort of FTP-oriented code as a server-side plugin. Thoughts? |
|
My mistake on the JBE restriction being to a single build definition (that would be extremely limiting)...it's actually to a single build *engine*.
Either way, if we take a build-based approach to file extraction, we can rely on the user creating (and running) the Build Engine themselves for our tool to use, whether it be the Build Agent or JBE or something else. But I have no idea how I'd programmatically create a bare-bones Build Definition that can simply feed the file list I've devised to the engine. Is there any literature on doing something of this nature, or at least some hints on classes I'd need to look into? I've looked at the internal BuildFactory, BuildDefinition, and related classes, but it's not clear how I would customize such stuff to do what I want. Even from the RTC client, the "Jazz Source Control" tab on most build definitions is extremely limited as to where the source files come from (can't even specify a particular snapshot, e.g.). |
FWIW, I've considered using the Jazz Build Engine, but that tool seems to operate more as a client, in that it associates itself at startup with a single repository, build definition, and userid, whereas our situation would need to work for a vast number of users across potentially many repositories, and wouldn't really need to be driven by (or even associated with) a particular build definition (of which a single user may have many). I think it's a little bit hard to configure JBE for specific needs. But you can develop an application with api that you run on your desktop and download the files to any remote system. But i think you need shared places on the remote server otherwise you have to run application on remote server. You can find login and load component sample in snippets. Also it's possible to search workspaces - components with entering name. Just search for api in the forum. One attention: Because of versioning you can only get IFileItems's current version on the workspace. It can be a little bit hard if you have to select different versions. |
My First suggestion is to try accomplishing something like what you want using an Ant-based build as the surrounding build definition. Such a build could then invoke custom Ant tasks (written in Java) to do whatever you wanted - be that interact more with the RTC server, or do custom command invocations, or invoke a compiler or assembler that RTC-assisted builds have no knowledge of.
This format should allow your build to take advantage of RTC's file movement smarts but then invoke your specific build algorithms' smarts after the files are placed onto the target system where the build is performed. The other feature of this is that the build logs will get funneled through RTC build log processing, making them available as appropriate to either the users that requested the builds or the teams that are running these builds on a scheduled or triggered basis. FWIW, I've considered using the Jazz Build Engine, but that tool seems to operate more as a client, in that it associates itself at startup with a single repository, build definition, and userid, whereas our situation would need to work for a vast number of users across potentially many repositories, and wouldn't really need to be driven by (or even associated with) a particular build definition (of which a single user may have many). |
My First suggestion is to try accomplishing something like what you want using an Ant-based build as the surrounding build definition. Such a build could then invoke custom Ant tasks (written in Java) to do whatever you wanted - be that interact more with the RTC server The downside is this adds yet another layer of coding/complexity (writing custom Ant tasks) on top of programmatically creating a build definition...we would not want to force the user to create a definition themselves just so we can extract code. And which build definition template we use isn't that important, ultimately...whatever we use would need to override the pre-build step that exports the files so that it uses our list instead of a specified workspace, and then stop running any other steps. So either way, we're still going to need to write the code that feeds the desired files to the engine...and I honestly have no idea where to start with that. Note also that we would not be using this operation to do any further build-type steps...just dump the files and quit. It's too bad the "scm" commandline tool doesn't have a "remote dir" option for the load action (and a way to specify other means of source input instead of just a workspace, like a change set or a snapshot etc.). |
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.