Adding Java Nature to an RTC project
Using RTC 1.0, the projects that RTC creates in my local workspace are not Java aware, i.e. the .project file does not include a java builder or the java nature.
I can't see how to add the java nature to such a project using RTC client. I can hack it by editing the .project file (see below). But I assume there is a way to add natures and builders to RTC projects without such hacking. Could you point me to it? .project BEFORE <projectDescription> .project AFTER <buildSpec> |
18 answers
|
I notice this long open Eclipse enhancement request https://bugs.eclipse.org/bugs/show_bug.cgi?id=102527.
Assuming that converting one project type to another within RTC is not supported, what would be useful is if RTC prompted the user for the type of project to create when a project is loaded into the local workspace. In RTC 1.0 there is no prompt. Maybe it is there in 2.0? |
echalmer wrote:
Using RTC 1.0, the projects that RTC creates in my local workspace are Was the directory that you are loading initially created as an Eclipse project? If so, then the .project file is under source control just like any other file. Whoever created the project initially and put it under source control created it without a Java nature. If the directory was not initially an Eclipse project (for example it was checked in using the SCM command-line tool), then the .project file you are seeing was automatically created by Eclipse when the project was loaded into Eclipse. It seems a little suspect that you would want to take a Java project that was created outside of Eclipse and start using it in Eclipse without going through some sort of import process. |
|
We have made an initial import of components from ClearCase (source code snapshots) into RTC 1.0. I am the first end-user of the system in RTC.
Was the directory that you are loading initially created as an Eclipse project? If so, then the .project file is under source control just like any other file. Whoever created the project initially and put it under source control created it without a Java nature. Our current development practise (of many years, using ClearCase and another version control system before that) is that IDE-specific artifacts are not checked in to version control. We do not currently check in .project files to version control. If the directory was not initially an Eclipse project (for example it was checked in using the SCM command-line tool), then the .project file you are seeing was automatically created by Eclipse when the project was loaded into Eclipse. Exactly. The project was imported to RTC as a pure source code project without Eclipse-specific artifacts such as .project, .classpath. The .project files are auto-created as part of the RTC "load" operation which creates the projects in the local Eclipse workspace. It seems a little suspect that you would want to take a Java project that was created outside of Eclipse and start using it in Eclipse without going through some sort of import process. What is suspect? We have big products comprising multiple subprojects for which the primary builds are done with Ant which has nothing to do with Eclipse. Developer X may use Eclipse; Developer Y may use Netbeans or whatever. The IDE used by a particular developer should have no effect on content of the project in version control. However, unless RTC 2.0 provides more user control over how local Eclipse projects are created (prompt user for project type when creating) then we may have to revisit this development practise and include Eclipse .project files in version control. I think that would be a retrograde step. I think it would be preferable if RTC gave the user control over what type of project(s) are created during the load operation. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 13 '09, 7:49 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
My general advice to folks using an SCM system and Eclipse is to put
your .project files under source control. There is lots of information in the .project file which is used to configure the builds, and by having each developer manually enter all of that information in my experience leads to a variety of subtle build problems because one developer is using different build parameters from another developer. The problem of different developers using different IDE's on the same project is an interesting one. I'll mull that one over for a bit (:-). Cheers, Geoff echalmer wrote: We have made an initial import of components from ClearCase (source |
|
echalmer wrote:
David Olsen wrote: I see this as an Eclipse issue, not an RTC issue. You would have this same problem when using Eclipse as your IDE no matter what your SCM system is. Eclipse expects Java projects to be set up properly, with a Java nature in the .project file and a properly configured .classpath file. If the projects haven't gone through that setup, Eclipse can't treat them like Java projects. I think that would be a retrograde step. I think it would be The load operation isn't designed to create Eclipse projects. It is designed to load existing projects into your Eclipse workspace. If you want the load operation to create a project on the fly in a user-configurable way (if a .project file doesn't already exist), then open an enhancement request against RTC. (Despite my arguments defending the current behavior, I don't think it is an unreasonable request.) |
I see this as an Eclipse issue, not an RTC issue. You would have this same problem when using Eclipse as your IDE no matter what your SCM system is. I see it as an RTC issue ;-) Eclipse is the primary IDE in our development team. There is no issue using Eclipse in our ClearCase SCM enviroment. The issue arises with RTC specifically because RTC creates Eclipse projects when you load source components/projects from the repository. Using ClearCase: * I load the source tree to my PC by creating a snapshot view from ClearCase client. * I point Eclipse into that source tree to create Eclipse projects as I require for development. * The SCM and Eclipse environments are separate and do not clash. * (BTW I use ClearCase plugin in Eclipse IDE for check/checkout/show history, etc.) Using RTC: * I load the source tree to my PC using "Load Repository Workspace". * This creates Eclipse projects within my RTC Eclipse workspace. * I cannot load source code projects to my PC from SCM without creating Eclipse projects. * The SCM environment is an Eclipse environment. Eclipse expects Java projects to be set up properly, with a Java nature in the .project file and a properly configured .classpath file. If the projects haven't gone through that setup, Eclipse can't treat them like Java projects. But Eclipse allows you to create whatever kind of project you want. If you select New Project, you are first prompted for project type, then asked where you want to create the project, at which point you can choose to point to an existing source code (non-Eclipse) project. The load operation isn't designed to create Eclipse projects. But that's what it does. It creates either a default project if a .project does not exist or a custom one using the metadata in the file if it does. If you want the load operation to create a project on the fly in a user-configurable way (if a .project file doesn't already exist), then open an enhancement request against RTC. (Despite my arguments defending the current behavior, I don't think it is an unreasonable request.) Thanks, I may do that. I haven't had a chance to test in RTC 2.0 but based on your feedback, I assume this behaviour is not supported in that release. The problem of different developers using different IDE's on the same project is an interesting one. I'll mull that one over for a bit (:-). Some thoughts on why you might want to reconsider checking in .project files to version control always being a good idea... * Developer_A is a Java developer. She requires the Java nature and Java builder. Her Eclipse instance has only Java tools/plugins installed. The natures section of her .project file might look like this: <natures> * Developer_B is a Web developer. He requires web development natures and builders. His Eclipse instance has web development tools/plugins installed (and may or may not have java tools installed). His .project file might include this: <natures> * Eclipse "Linked resources" are a handy feature. Developer_A might add one to a project. Should that change be checked in to version control? </natures> I'm sure having .project in version control may work nicely for some teams, but I don't think you should consider it a universally accepted or good idea. |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 14 '09, 1:30 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Comments interspersed below ...
echalmer wrote: David Olsenwrote: That was true in RTC-1.0, but is no longer true in RTC-2.0. In RTC-2.0, you can load source code project to your PC without creating Eclipse projects (it is one of the load options). So the RTC SCM environment works well when you use Eclipse as your IDE, but does not require it. In particular, you can use Eclipse as just your SCM GUI, and not use that instance of Eclipse as your IDE. The only real change when you don't use Eclipse as your IDE is that you will have to select the "Refresh Sandbox" operation in the Pending Changes view in order for it to see any changes you have made to any files since the last time you refreshed the Pending Changes view. Note that there are a couple of reasons why you wouldn't use the same instance of Eclipse as both your RTC SCM GUI and as your IDE: - you aren't using Eclipse as your IDE - you need to use a version of Eclipse that is not compatible with the version of Eclipse compatible with your current RTC server. gmclemmwrote: This I would classify as clearly an Eclipse issue. There should be <java> and <web> XML elements in the .project file, and the user should be able to configure the project to be either "java" or "web", and then pick up the appropriate depenedencies. There is no reason to have the SCM system become involved in this at all (i.e. you should be able to get this functionality from Eclipse, even when no SCM system is in use, and how you get this functionality should not depend on which SCM system you use). * Eclipse "Linked resources" are a handy feature. When Eclipse stores both "personal" information and "shared" information in the same file, I consider that an Eclipse bug. It should be stored in two separate files, so that you can tell the SCM system which files to ignore. But you shouldn't have to write custom extraction tools that have to pick up the "shared" information embedded in the various dot-files, and have to upgrade those extraction tools each time the IDE comes up with some new interesting meta-data. I'm sure having .project in version control may work nicely for some The reason I'd consider it universally good (although clearly not yet universally accepted :-) is that anything else would involve coming up with a custom/redundant way of storing project configuration information. And and as mentioned above, every time the IDE introduces a new kind of shared meta-data, you would have to update the extraction mechanism in each SCM system to handle this new kind of meta-data. With the usual disclaimer that I may be missing something here (:-). Cheers, Geoff |
Geoffrey Clemm wrote:
The reason I'd consider it universally good (although clearly not yet A little off topic, but NetBeans offers builtin support for working with Eclipse metadata. In other words, they've recognized that they're going to have to coexist in mixed environments with Eclipse, such as the OP describes, and they've got a plugin to sync between Eclipse and NB project metadata. Here's a quote from <http>: <i> When you import a project, the IDE analyzes the Eclipse project metadata and then creates a NetBeans project based on that metadata. The project import does not impose changes on the Eclipse project structure, so it does not interfere with the way the project works in Eclipse. Once you have the project imported, you can use either or both the NetBeans and Eclipse IDEs to edit, build, run, debug, and profile the project. If you make a configuration change in the Eclipse project, you can resynchronize the NetBeans project. This enables you to work on projects in NetBeans even if everybody else on your team is working with Eclipse. The build path that you set in Eclipse remains the master build path for the project. </i> Thus, as long as the only two IDEs involved are these two, keeping Eclipse data in source control and generating NB from it should work. MK |
Which load option is that? I have RTC-2.0 installed now. The ones I see are * Find and load Eclipse projects * Load the root folders of the components as projects * Browse the components to select the folders to be loaded * Do not load anything. The workspace will be tracked by the Pending Changes view. * Reload projects that our out of sync. Local changes will be overwritten. ... none of which appear to copy source to my PC without creating an Eclipse project. |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 17 '09, 4:56 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Select the "browse the components to select the folders to be loaded"
option, and you'll get a second dialog box. Open the "Advanced" section of that second dialog box, and you'll get the additional load options. I agree it would have been better to have that on the first dialog box .... otherwise how are you to guess where to go find the Advanced Dialog? Submitted work item 90392 to make this easier to find. Cheers, Geoff echalmer wrote: That was true in RTC-1.0, but is no longer true in RTC-2.0. In |
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.