Community
Participate
Working Groups
PRECONDITION: * checked out project Yang (in svn subfolder is YangModel but in .project file the name is Yang) into empty folder named FFF => FFF/YangModel * checked out project is checked out into folder YangModel * folder YangModel contains after checkout the file .project * .project file contains this content: <?xml version="1.0" encoding="UTF-8"?> <projectDescription> <name>Yang</name> <comment></comment> <projects> </projects> <buildSpec> <buildCommand> <name>org.eclipse.jdt.core.javabuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>org.eclipse.jdt.core.javanature</nature> </natures> </projectDescription> * FFF was not workspace before and only contains fresh checked out project folder ACTION: * Eclipse with FFF as worpspace * Menu File=>Import=>General=>Existing Projects into Workspace => Browse * select in folder search dialog the folder name FFF (workspace folder) * click ok EXPECTATION: * Projects list contains project called Yang OBSERVATION: * project list contains project called YangModel (as folder name) RESULTING PROBLEM: * Because in Keppler it was working correct, users in Keppler and Luna can not work together when folder name and project name are different. Every svn checkin the .classpath files of other projects inside same workspace FFF has another project dependency. In Keppler the project dependency is called "Yang" (as project name of Yang project in .project file) and in Luna "YangModel" (as folder name of project Yang). So Keppler and Luna User, are checking in every times a changed .classpath for dependend projects. <classpathentry combineaccessrules="false" kind="src" path="/Yang"/> versus <classpathentry combineaccessrules="false" kind="src" path="/YangModel"/> Probably similar bug report: Bug225754
Created attachment 252634 [details] Screenshot .projects and folder structure
Your .classpath shouldn't include the project directory — it's relative to the project directory. Something's strange with your setup. Can you create an example that doesn't include any of your proprietary files?
Created attachment 252732 [details] Screenshots and example projects for import I attached 4 screenshots and 2 example projects * about dialogs from compared keppler and luna * screenshots how the import dialogs are shown by luna and keppler * 2 example projects PjA and PJB PjA is in folder PjA and its project name in .project is PjAAAA PJB has class path entry from PjA In this setting the person who imorts this projects in Keppler will have the problem, that PjA is unknown (I created the projects in Luna). The guy with Keppler will correct the dependency and checkin .classpath from PJB (change classpath entry from PjA to PjAAAA). Then the Luna user imports (or svn up) the projects. Again he has the problem, because for him PjAAAA is unknown and sets it back to PjA. When the Luna user now checks in again the endless annoying cycle is complete. Annotation: I have also a Keppler version. My kepplyer eclipse (Version: Kepler Release, Build id: 20130523-2011) works like my luna. Is there a configuration flag with says how projects are importet? (by project name or by folder name)
Are these projects normally in your workspace? If so, you're hitting bug 344337: projects in the workspace must have the same name as their directory. It's an internal workspace limitation. Otherwise, I tested importing these projects on 4.3.2 and 4.4.2 from outside of the workspace and the project names are fine.
I tested at on mac at home, now : Version: Kepler Service Release 2 Build id: 20140224-0627 Here I have the same problem. Here I have another workspace. The answer to your first question is therefore : NO, these project are normally not in my workspace. Therefore this project name PjAAAA is not reserved in this workspace. On import it imports the project with project name PjA instead of PjAAAA. (Project folder placed inside workspace folder) I can not respond to your second sentence because you don’t write what is fine for you. But indead I have exactly the same problem of Rick Herrick 2011-07-08 10:46:21 EDT in Bug 344337. Now I tried something different. I putted PjAAA in /tmp/PjAAAA and imported the project into workspace located in /home/…./workspaces/testWorkspace and then it uses the project name PjAAAA as expected. I don’t know why the project name PjAAAA is not used if I put the project folder inside its workspace. This makes no sense for me. A project name duplication avoidance does not require such a behavior. Because if I want assure that a project name is unique in a workspace I could throw an error while importing another project with same project name and inside this error message I could propose to rename the project name according folder name or something else. How it is realized now, it doesn't work fine in a teams which works with different eclipse versions, holds project folders inside workspace and using scm (svn). My consequence of this is to put the projects outside of the workspace to be sure that eclipse uses the project name foreseen by other developers and to maintain project dependencies inside workspace.
(In reply to Maik Wodarz from comment #5) > Here I have the same problem. Here I have another workspace. The answer to > your first question is therefore : NO, these project are normally not in my > workspace. Therefore this project name PjAAAA is not reserved in this > workspace. On import it imports the project with project name PjA instead of > PjAAAA. (Project folder placed inside workspace folder) It sounds like you imported a project with "Copy projects into workspace" enabled? What matters is here is that the copy is inside the workspace. > My consequence of this is to put the projects outside of the workspace to be > sure that eclipse uses the project name foreseen by other developers and to > maintain project dependencies inside workspace. That's my standard mode of practice. I use separate workspaces for each target environments, and import code from checkout locations. I agree that this silent renaming is bewildering; it happened to me too. I'm retitling this bug so that the Import Project wizard provides a notice when a project rename has occurred.
