Summary: | Migrating and sharing workspaces and projects MUST be supported | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | zmangeclipse <zmang12> |
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | ||
Version: | 3.1.2 | ||
Target Milestone: | 3.3 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
zmangeclipse
2006-04-02 22:22:45 EDT
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. |