Using same Jazz workspace for multiple Eclipse workspaces
In our development environment, our product (as most) has different components - some Eclipse, some classic web, some Flex. When a developer is working on a particular component, at the least he/she will either have a different Target Platform, or possible even different Eclipse tooling.
Is it possible for that developer to use the same RTC SCM workspace for ALL of those different development environments? (assuming that RTC 3.0 client tooling installs nicely into all of them). If it is possible, will the developer be bombarded with out-of-sync messages the whole time? Thanks, Hayden |
4 answers
In our development environment, our product (as most) has different components - some Eclipse, some classic web, some Flex. When a developer is working on a particular component, at the least he/she will either have a different Target Platform, or possible even different Eclipse tooling. Hi I may have misunderstood your intentions - so apologies in advance. I think you need everything pointing to the same Stream, not repository workspace. Create workspaces for each different tool - and use the Component model (mapping a Component to an Eclipse project) to load or leave an irrelevant component to that particular tool unloaded. The key idea is to allow developers to be able to check in as often as they like. This does imply that each of the tools in a different Eclipse shell - which may or may not bne what you want. Perhaps it would help if we knew what your Eclipse project structure looks like. anthony |
|
Let me elaborate with a simple example. I am a developer on Product X which is a client/server application, the client being a set of Eclipse plugins, and the server being Java EE based - js, jsps, server side java logic (probably similar to Jazz I guess). When I fix a defect, there might be some Eclipse plugin code to be changed, in which I have set up my Eclipse workspace with a particular Target Platform. I then will be changing some dojo widgets and jsp code for the rest of the 'defect' fix. I would like to Check in and Deliver both the changes in the Eclipse client AND the server in one change set.
I think that I will probably need different Eclipse workspaces for these 2 development environments, though I would have thought that I could still a single RTC Workspace. Ah, 1 minute, I guess that the code changes would span multiple RTC Components since they are in different parts of the product . Does a Change Set have to be tied to a particular Component? If that's the case, then I guess I might be forced to have more than 1 Change Set for this single defect fix. My question is how do I go about doing that, wrt setting up my RTC Workspaces etc..., Components...? Is there a recommended way of doing this? There also might be 2 cases here - Case 1: Where all the code changes are in a single component, and Case 2: Where the code changes span multiple components. I hope I've clarified things. Thanks, Hayden In our development environment, our product (as most) has different components - some Eclipse, some classic web, some Flex. When a developer is working on a particular component, at the least he/she will either have a different Target Platform, or possible even different Eclipse tooling. Hi I may have misunderstood your intentions - so apologies in advance. I think you need everything pointing to the same Stream, not repository workspace. Create workspaces for each different tool - and use the Component model (mapping a Component to an Eclipse project) to load or leave an irrelevant component to that particular tool unloaded. The key idea is to allow developers to be able to check in as often as they like. This does imply that each of the tools in a different Eclipse shell - which may or may not bne what you want. Perhaps it would help if we knew what your Eclipse project structure looks like. anthony |
In our development environment, our product (as most) has different components - some Eclipse, some classic web, some Flex. When a developer is working on a particular component, at the least he/she will either have a different Target Platform, or possible even different Eclipse tooling.It sounds like it would be better to have a different repository workspace for each development environment. You would likely get out-of-sync messages quite often. There's not much overhead to creating a new repository workspace. It's encouraged to have multiple repository workspaces so you can configure each one for a particular task. |
Let me elaborate with a simple example. I am a developer on Product X which is a client/server application, the client being a set of Eclipse plugins, and the server being Java EE based - js, jsps, server side java logic (probably similar to Jazz I guess). When I fix a defect, there might be some Eclipse plugin code to be changed, in which I have set up my Eclipse workspace with a particular Target Platform. I then will be changing some dojo widgets and jsp code for the rest of the 'defect' fix. I would like to Check in and Deliver both the changes in the Eclipse client AND the server in one change set.If the code you're changing lives in different components, you'll need separate change sets. A change set is tied to a component. It's ok to have the client and server code in separate change sets. The work item will show that the two are related. I would say you should have separate repository workspaces. If your regular work flow is to have multiple dev environments running at the same time, you'll definitely want to have separate repository workspaces. Plus, the client side fix isn't required in your server dev environment. Work on them separately. When you're ready to deliver, you can either deliver one after the other from each dev environment or deliver/accept the changes to one repository workspace before delivering to stream. |
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.