Accept changes creates undesired eclipse projects
Is there a way to turn off the "auto-create" of eclipse projects when accepting changes?
Thanks for any help! Some summary of our environment: We have many users and many eclipse projects in our stream. Users typically load the entire component(s), but only create eclipse projects for a small subset of the projects within the component(s). In this way, they can run external build tools which build all the projects and create deployable binary images and tools without concerning themselves with that code. When the users accept changes to files in projects that they have not created eclipse projects for, RTC automatically creates eclipse projects in their workspaces. Due to some setup requirements, these projects always fail to compile and users get confused until they delete the projects or do the setup required for the other projects, so we really would like to turn off the auto-create feature. |
3 answers
Ralph Schoon (63.1k●3●36●46)
| answered Feb 21 '12, 3:04 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Fred,
searching https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWelcome I found https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=196553 There seems to be no resolution yet. In the past in situations like that I have added the .project files that I did not want to the .jazzignore list. This still creates them locally, but server based builds work. What build tooling are you using? |
|
Hi Ralph,
Thanks for your response! Yes, the defect 196553 is exactly the same scenario. We have about 100 projects in our component and a typical developer uses about 10 or so of them. We use similar load steps (load a single folder, do not create eclipse projects, then the user does File -> Import later to get the ones they're interested in) For build tooling, we're using the internally created Ant derivative called Mantis. It contains ant extensions for packaging and dependency resolution and some other things. We've integrated it into the build services provided by RTC so we can do normal personal and production build processing, but it also is required to run to build locally on user workstations because many of our dependencies are jar dependancies on the other ~90 projects, so the first step is to build the world, then import the 10 projects of interest into their eclipse environment. Any recommendations? I have downloaded the RTC SDK and created a patch for a particular problem we found during migration from SVN to RTC (our users are not running with it, it was only for the migration), perhaps I'll see if I can patch this behavior. Have any interest in it or pointers to the location in the code? Thanks! I found https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=196553 |
|
Ralph Schoon (63.1k●3●36●46)
| answered Feb 21 '12, 9:14 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Fred,
I am interested in it, because this is not the first time I have heard about this. I think your feedback to the work item could lead to design changes over time. The dependency on eclipse projects is natural, since the development originates in the Eclipse team, but over time I would like to see a SCM strategy with the Eclipse Client that picks up some of the cool stuff the Visual Studio developers have created. Several sandboxes in parallel that one could switch to, better cooperation with Maven. Most of the issues I see with Eclipse projects are currently not an RTC problem. It is rather that other tools don't play the rules of Eclipse. Nevertheless I see benefit in other use cases as well if the limitation could be lifted. I have no code pointer. So far I am looking at other code, mainly to make the life of administrators in Enterprises easier. I doubt I have bandwidth to help. But I would certainly appreciate if you keep me in the loop and share experiences. |
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.