First, Eclipse is not my native IDE -- I'm barely a n00b with it. I set up a project in a workspace that was actually in the directory of another client's project (I didn't really follow the whole workspace/project thing) and, in fact, now I can't even find the Eclipse workspace file to open it.
What I'd like to do is:
Open my eclipse project (/workspace?) -- I know where all the files are on disk, just not what to open in order to see them in Eclipse -- and
Move my project to a new workspace, which I guess I will put in a generic Eclipse-y place, and have that one workspace reference all my Eclipse projects.
(Is that the right way to do it? Does Eclipse dislike me being a one-project == one-workspace kind of guy?)
Please educate me regarding The Eclipse Way so that I can get back to work writing code.
Thanks!
Roughly a workspace (which is a directory) in Eclipse contains:
configuration (installed JRE, Servers runtimes, code formatting rules, ...)
one or more projects
You can of course have as many workspaces as you want (but only one can be opened at a time) and a project can also be part of different workspaces.
If you know where your sources are and want to move them to a new workspace here is a possible solution:
Start Eclipse and when prompted for a workspace choose where you want the workspace to be created (if directory doesn't exist it will be created). For example you can choose C:/Dev/Workspace/.
If you are not prompted, go to File->Switch workspace->Other
Once you are in your workspace you can import your exisiting project with File->Import then General->Existing Projects into workspace
Navigate to the folder containing your project sources, select your project and click finish
I don't know if it's a best practice or not but what I usually do is the following:
I have one workspace for each of my customer (workspace_cust1, workspace_cust2)
Each workspace references my commons library projects and add client specific projects
This way each time I change my commons library it's up to date in every workspace.
If you want to apply
one workspace = one project
You could to the following:
1) Copy the eclipse desktop shorcut
2) Modify the shortcut by appending "-data workspaceLocation "
Related
This is how the workspace assign on an eclipse
My Web project run only when my project is at c:\Ampps\www\myProject but eclipse contains it on C:\Simple\workspace\myProject. My problem is I want to run project and the workspace is different. What is the things keep in mind before choosing the workspace. And what are the alternatives if the wrong workspace choosen ?
Eclipse does not require your projects to live under your workspace folder. Therefore you are allowed to have a project and workspace as you describe.
When creating a project, uncheck the default location checkbox in the wizard and select your truly desired location.
My only recommendation on workspace location is to have it on a local drive and don't have it as a sub directory of any project in your workspace.
I was always told that it is a best practice to create your projects outside of Eclipse's workspace.
But it gets not really convenient when you want to import an existing project or creating a new one, to each time browse to your "projects" folder instead of the default "workspace" folder that Eclipse suggests.
Is there a way to tell Eclipse "yes, my workspace is in C:\Users\David\workspace" but all my projects must be created in C:\dev\projects" ?
I'm new to programming and IDEs. I never understood the concept of a workspace in Eclipse, and I don't understand it in Aptana.
With Eclipse I just put it into my web root. Not sure if that's the way to go?
Can someone explain what a workspace is and where it should go? And if not in the web root, then how do I launch a PHP page from within the EDI?
Thanks!
An Eclipse workspace is a directory where (generally) all of the files you are working on live and that stores all of the state (like preferences and such) for a single user of Eclipse. So when you create projects, they are located in the workspace. The workspace has some metadata files that control how Eclipses behaves for you.
Eclipse keeps a representation of the workspace internally, which means the workspace can get out of sync with the underlying files. To sync them up, do a right-click Refresh in the Package/Project Explorer.
Usually the workspace goes into some directory relative to your home directory, since it's private to each developer.
Workspaces are like folders where the project's files are.
When you have a local web server you could set the workspace to a new folder in the servers directory (or web root when the project should be in the main directory!) . If you want to add a new PHP-file in Aptana studio 3 just right click the workspace and select add new file (or sth. like that). After that you will be able to enter a file-name and it's gonna be saved in the workspace (folder). But of course you can also work without workspaces, just create the the PHP-File and edit it with Aptana.
I'm trying to re-familiarize my self with the Eclipse environment and ant integration.
Question is: how to keep my sources dir + build.xml separate from the workspace?
What I have is
a small java project and its build.xml file with all the sources placed under a separate
project folder. I then started Eclipse and let it import my project via
New Project -> "Java Project from existing Ant Build File"
All went fine, until when I wanted to build the project from inside Eclipse using build.xml.
Ant starts complaining about not being able to find the source tree. After I examined
the workspace I found that Eclipse had copied the build.xml into the workspace, so it's
obvious that ant couldn't find any sources there. They are still under my project director
and I do want to keep them there, if possible.
so whats the best way so make this setup work? workspace on one side, my project on the other?
Thank!
edit: Is what I want even possible ?
Instead of using "Java Project from Existing Ant Buildfile", just create a simple "Java Project". In the wizard uncheck "use default location" and enter the path (or browse) to the top level directory of your existing project (i.e., where your build.xml is). True, eclipse will create .project and .classpath files in your project directory (if they do not already exist), but the project will remain outside the eclipse workspace.
Case in point, this setup has worked really well in a very particular situation on a standalone system where the source tree resides in a common location but each user has a workspace in a protected location. Using the method described above, each user of this system can create a project in their own eclipse workspace, execute ant targets and subsequently remove the project from their own workspace without affecting other users' workspaces.
What about using links?
Windows Symbolic Links
Linux man page for ln
I do this all the time in C++ projects (no Java, sorry, but I think the concept is portable).
I have my workspaces in ~/workspaces/{workspace_name}. I have a single shared project file in ~/{my_projects, and then the source trees (multiple versions) are in ~/proj1, ~/proj2, etc.
Within each ~/proj* directory, I put a symlink to ~/my_projects/.project and .cproject (required for C++, not used in Java). So each source tree is sharing the single project file. Then in each workspace (one for each source tree), I configure the workspace by importing the project link. For example, ~/workspaces/proj1 imports ~/proj1/.project, but ~/proj1/.project is actually a symlink to ~/my_projects/.project.
So this keeps the source separate from the workspaces. When building, there's no real configuration to do -- I just have Eclipse run make in the appropriate node of the tree -- we already have our own command-oriented build system (we're not using ant, but the same principle should apply).
I source-control the ~/my_projects folder in a private area of the SCM, so other team members don't see it or fiddle with it -- many of them don't use Eclipse at all.
There isn't really any need to try and avoid Ant and Eclipse using the same set of source files. In fact, its probably better that they do use the same set.
Bear in mind, you're not actually mixing anything. There is just one set of source files and then there are two different ways of building it; Ant and Eclipse. These builders are independent of each other, so there is no problem with being coupled to Eclipse. You can even happily commit all the eclipse files (.classpath, .project, .settings) to source control without affecting any developers who use a different IDE.
I do this all of the time (admittedly using maven, not ant), but the same principle applies.
If you have an existing project in Eclipse (with the .project in the source tree), then you can Import Project->Import Existing Project. When the dialog box comes up, you can choose to 'Copy projects into workspace'. Make sure this is unchecked, and them import.
You still store the .project in the original source tree, but thats all.
So now I have
code/xxx (which contains the .java files, which are in SVN)
code/xxx-workspace (which contains the eclipse workspace)
I'd like to manually create the folders/files on the file system that create a new project in a workspace in eclipse, and show up in the Project Explorer when eclipse is started and the workspace is selected.
What files would need to be created to do this and where would they need to be?
Please understand that I do not want to open eclipse and make a new project using eclipse. I want to make a new project without using eclipse.
I think you will need to do the following
create a .project file and whatever other files needed by your specific type of project (for example java projects need .classpath) in the project folder, you can find out what you need by looking at those files for another project.
In your workspace .metadata folder, this is where eclipse keeps information about the current workspace, I think the plugin responsible for project definition is .metadata/.plugins/org.eclipse.core.resources , you will need to create those files yourself, some of them are binary, so you will need to open up the source of that plugin to see exactly how it writes them. Depending on your project, you will need to write more .metadata plugin information (for maven for example).
There is no easy way of doing this. Each new project modifies many scattered files throughout the eclipse structure (if you want a list, make a new project and find files created/modified most recently, and/or search for the project name.)
Short of writing the files by hand, there's not much you can do. I found these links in my reseach, but they're both pretty old and seem to be dead ends:
http://www.eclipsezone.com/eclipse/forums/t107019.html
http://dev.eclipse.org/newslists/news.eclipse.tools/msg36546.html
Based on the answers of #shipmaster I think this will work.
Go the workspace and create a new folder as your new required project name.
Copy the contents like .project, .classpath, .includepath etc from any existing project and modify the same like project name, source folder, build folder etc in .project. Do the similar changes in .classpath etc as per the new project requirements.
Unfortunately this is not enough to create a project by just doing eclipse restart so we need to do an import project and point it to this folder and we are ready to use the same now and we see the new project created in eclipse!
try archiving the file .. right click on project ---> export --->archive file(in General section) ..after you archive it as a zip you can import it after.
IF you want to manually copy a pre-existing project to a new workspace,
I have a solution for you:
Copy the project folder.
Paste it into the new work space.
File > Import > General > Existing Project Into Workspace
Eclipse will now see the project you cut+pasted manually.
Why I am doing this:
I am doing this so I can build upon my scrum stories while keeping documentation via working files that each successive step was built upon.
E.g. Story #2 is built upon story#1 code. But I don't want to version them because I want to be able to open them up one after another to do a presentation on my work flow.