Community
Participate
Working Groups
We have been JBuilder users for a real long time and are considering switching to eclipse. Have been trying out 3.1.2. Here's one major stumbling block: It appears that eclipse was NEVER designed to be used in a team environment. We use clearcase for source mgmt. I am aware of the clearcase plugin from rational. The plugin DOES address the issue of sharing source code. I am also aware of the ablity to export preferences and projects from the "export..." menu option and the use of "import ..." to import these settings into anew workspace. Here's the litany of problems with this approach: 1) It DOES NOT work very well. The preferences are selectively imported. I had set up tasks for running, ant views with build files from various projects in my "source" workspace. When imported into the "target" workspace, most preferences are there. the ant viewsand the tasks have to be recreated. 2) In JBuilder - a project consisted of a .jpx file, a .jpx.local file, one or more user libraries. The great thing about this was that a) Each of these was sharable by checking into clearcase b) user libraries could be shared and updated in each view/config spec as development proceeded. c) Hence a team lead could setup projects, with preferences down to the "java coding" standards, say, and have it shared across the entire team with the jpx file still checked in. The equivalent would be to checkin the .metadata diretory with all of its contents into clearcase and have it shared across the team - this is simply NOT possible since eclipse writes back into the work space frequently. What is needed: 1) Give the user the ability to share workspaces - i.e. have the .metadata directory be separable into sections that CAN be shared, are strictly for the platform, etc. 2) Or give user ability to selectively import ANY or ALL of the preferences set including views and perspectives from ANOTHER workspace. Thanks ahead of time. p.s.: Please let me know if these features do exist in current versions.
This feature does exist. For any project you can set project specific properties for the Java compiler in the Properties dialog. These settings will be placed in files inside the .settings directory and can be shared with the project. Most Eclipse components do this to ensure that their teams use a consistent set of compiler settings. In the future, could you please ask questions on the eclipse-platform newsgroup and only log a bug if a feature you are looking for is missing.
(In reply to comment #0) The feature you are talking about can set the following: - Builders - Builder path - Code Style - Compilers - Javadoc and depending on plugins maybe more. However, there are several more settings that can be set through the Window->Preferences menu item - these (global) settings for the workspace also include the libraries, compiler settings, etc. I'd like to have these be shared across projects AND across developers. Here's an usecase: 1) I set up the UserLibrary for ssay, Jakarta Commons HttpClient - th elibraries includers jars from version 2.0 in the current scenario. Next week I'd like to upgrade to 3.0. I change the jars and the library is updated. If the library or the .metadata specific settings/prefs file is symlinked/checkedin then ALL developers on that view get to see the change. If not, they have to be given instructions to do so. This was possible in JBUilder since the library file there was a file that could be symlinked across projejcts and checked in. Hence any change was immediately picked up. 2) After the GA of a product, we might branch off in clearcase to start new development, New development implies I start from current state and possibly upgrade one or more jars, upgrade build files, workspace settings, etc. I'd like these to be picked up by the rest of the team by virtue of simply using the same config spec in clearcase. Again - easily done in JBuilder because all one had to do was make the changes to the corersponding jpx file for each project. Add to the above - db settings, tomcat versions, ant home properties, ant build settings (vm sizez, etc.) (In reply to comment #1) > This feature does exist. For any project you can set project specific > properties for the Java compiler in the Properties dialog. These settings will > be placed in files inside the .settings directory and can be shared with the > project. Most Eclipse components do this to ensure that their teams use a > consistent set of compiler settings. > > In the future, could you please ask questions on the eclipse-platform newsgroup > and only log a bug if a feature you are looking for is missing. > I did scan bugzilla and found several open and duplicated bugs on similar issues. I'll try what you are stating - does that work for the following conditions: 1) (In reply to comment #1) > This feature does exist. For any project you can set project specific > properties for the Java compiler in the Properties dialog. These settings will > be placed in files inside the .settings directory and can be shared with the > project. Most Eclipse components do this to ensure that their teams use a > consistent set of compiler settings. > > In the future, could you please ask questions on the eclipse-platform newsgroup > and only log a bug if a feature you are looking for is missing. >
For specific settings, please log bug reports against the component that provides the setting since, as you say, it is the fact that the setting is not stored in the project directory that is the problem. I'm moving this to JDT/Core since your scenario mentions the sharing of JAR configurations.
User libraries are not shareable for the current time being. One of the reasons is that multiple projects could contribute their own definition for a library. Which one would win ? Do we randomly pick one ? Other reasons range from the fact that user libraries likely denote external JARs, for which the absolute path is not shareable on a team in general. So a better option is to place the JARs in a shared project, and thus use a project instead of a library... Will likely reconsider post 3.2, since sharing this data is useful anyway.
(In reply to comment #4) > User libraries are not shareable for the current time being. > One of the reasons is that multiple projects could contribute their own > definition for a library. Which one would win ? Do we randomly pick one ? > I think you are missing the point. The point is that I'd like to have a predefined set of libraries (I am using libraries as an example - this could apply to ANY setting in .metadata except say runtime indexing, etc.), say HttpClient1.0 HttpClient2.0 HttpClient3.0 Oracle9.0 Oracle10.0 Tapestry3.0 Tapestry3.0 Xerces2.5 Xerces2.7, etc. The project definition will pick the right ones to use. As development proceeds and upgrades are to be made, the project definition will be changed to pick the upgraded version. The last thing I want is to have these choices made on a daily basis by developers across branches across projects acros releases, patches, etc. You need to rethink the notion of .metadata, .settings, etc. across the workspace and for projects FROM THE POINT OF VIEW of sharing. For example - apply the DRY (Don't repeat yourself) principle to a usecase that involves > 2 developers; > 2 projects; > 2 release streams but using library definitions, ant build definitions (NOT the files itself); tomcat settings, db settings, (pretty much anything in the workspace). Now try to do this WITHOUT replicating/duplicating the same information. So first setup everything in one clearcase view for one deveoper, one project and one workspace and one release. Now try to do the same for another project; workspace; developer. Try to see if simply starting eclipse gives you EVERYTHING YOU need as with the first setup. What's the min. you need to setup/change. That'll give you the perspective from which I am coming. > Other reasons range from the fact that user libraries likely denote external > JARs, for which the absolute path is not shareable on a team in general. So a > better option is to place the JARs in a shared project, and thus use a project > instead of a library... > > Will likely reconsider post 3.2, since sharing this data is useful anyway. > Thanks - its really important you consider this - so that eclipse is treated as a mature product that can be MORE widely used in commercial settings. It has the potential, but for these glitches.
Agreed.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
