How do I tell eclipse on my desktop to open projects that are saved on my laptop without importing the project? I want to be able to save on one machine and pick up where I left off on the other. Thanks.
All projects are saved in the workspace (which saves additional meta data).
A simple solution for you would be to save the workspace on dropbox or similar and let eclipse load the work space from the drop-box folder.
Another option would be to use version control which is common in pratice (see http://en.wikipedia.org/wiki/Revision_control), e.g. git (github.com).
All of the details end up in the workspace itself. So the workspace needs to be in a location that is shared between the two machines.
Dropbox is a good option.
I would import the project into eclipse on my laptop as well as on my desktop, with the common dropbox folder as the workspace, so that everything is synced.
For instance, if I make changes to my code on my desktop, dropbox should automatically sync those changes. After that, when I open up the same code on my laptop using eclipse, I would make sure to go to my project explorer, click on the project and manually refresh (press F5). Be sure to refresh!
You can have a workspace on each machine linking to the same project files. The most convenient way is creating the project in a shared location (e.g. an external hard disk) rather than inside the workspace folder, then doing "import existing projects" on the other machine (with an independent Eclipse installation and workspace).
At this point you only need to keep in sync two Eclipse installation (same installations, removals and updates of plugins) and two workspaces (typically, you can set up one, export the configuration and import it in the other installation).
I would be uncomfortable sharing a workspace along with projects:
some settings might need to differ between workspaces. Common case: web proxy configuration.
Two workspaces can include different projects.
If you don't have exactly the same version of the same plugins, two Eclipse installations could fight to rewrite workspace settings to their liking.
Actually what you do it is stored in your workspace located in the user folder in the drive where OS is installed. You can find it simply here in your own pc
C:\Users\PCname\workspace\buky\bin
According to your scenario, I think the best option for you would be using a distributed version system. This way, you could have both projects on different machines under different local repositories (you don't even need to have a central repository or something similar), pushing changes as you work on them.
That being said, I would recommend you taking 30 minutes to read this Mercurial Tutorial.
The workspace saves this information, but it also saves a lot of other metadata that you may not want to share between different computers. Such as where dialogs are seen, what perspectives are open etc. If the Eclipse are of different versions, you may end up with the newer version converting the workspace to a later configuration and rendering it unusable to the older version.
The best way to share projects between computers is to use project sets. This will also work for sharing projects between different users. This in turn required a source repository, which is something you should always consider using.
Related
I have a laptop and a desktop. I prefer using my desktop when I am at home working with my school projects.
If I upload everything on GitHub with my laptop and I'm using Eclipse or Intellij, do I need to use the same IDE/IDEA to continue working on my projects at home?
No you don't need to use the same IDE. But be careful, different ide's have different files that should not go to git. IntelliJ produces .iml files and Eclipse produce .project files. Some other files might also exist and you may not want them to go git. So, you need to define your .gitignore files carefully and you are good to go.
Unless you decide to upload IDE specific configurations into your source control, or if you don't use something like Maven or Gradle to manage your source dependencies, it won't matter.
IDE has nothing to do with your code or the machine you use, there are many IDEs you can choose from based on your personal preferences like visual-studio, Atom, sublime, notepad++ e.t.c. sure few people associate an IDE with particular language/framework, then again there is no standard for this, everyone has there own preference.
You do not need to use same IDE. The two you mentioned has property of connecting git so you can just go as you want. Just import your projects from git.
Note: I don't find this being a duplicate of any question. I have done a lot of research on this (few hours, read whole Google about workspaces probably - it's a metaphor of course) but couldn't find the answer to my problem.
So I have done some programming in Java and mainly used Eclipse for it (when projects were getting more complex, before I had used Vi). I was always working in that default workspace $HOME/eclipse-workspace because I never really understood the point of workspaces.
I am back to programming in Java, installed Eclipse and get prompted to Select a directory as workspace which kindly offered me to use /home/campovski/eclipse-workspace. Before I would just hit Launch but now I started getting curious. What are these workspaces, what are they used for...?
I have done some research:
Eclipse Workspaces: What for and why? (SE)
Eclipse - Workspaces (Tutorials point)
Documentation
I also followed the links that were provided in answers to the first link but none gave me the answer to my question:
What is the difference between a directory and a workspace?
As is stated in third link: A workspace can have any number of projects, each of which can be stored in a different location in some file system. Ok, this might be useful, but what is the problem of including all projects in one parent directory which could serve instead of a workspace?
If we take Matlab for example:
There you have a directory selection menu on the left, just like in Eclipse. The current directory you are in is selected as a working directory and any Matlab function and scripts declared in this directory can be executed in the Command Window. The analogy from Eclipse would be as to import a function from different folder.
So my question to rephrase it is, is there anything else to workspaces than workspace just being a collection of projects, folders and files, just like a normal directory, except that in workspace there can be projects from different paths.
Workspace it's like user's homedir in linux.
Workspaces bind together JRE version, installed servers, and if you're using server connectors, all the data and temporary WARs, EARs are saved there (.metadata/plugins). Switching workspace is for switching context of your work: project, client, language, paradigm ... Workspace is the directory from where ECLIPSE bootstraps itself up. All local dependency resolutions ends up in workspace directory.
VisualStudio's "solution" concept is not even near to the concept of workspace, as solution is just parent folder to group one or more projects and give them some common CLR names and properties.
I'm using Eclipse for at least 10 years now... I got to this conclusion : I have same workspace for all projects that use same JRE and same APP server. I have different Eclipse versions, if I need some special tooling (Spring or CDI or PHP or some exotic plugin). All workspaces are located in my home directory.
You can paste / copy workspace to different computer, with same Eclipse version it works out of the box.
Simplified, a workspace is a special directory that is monitored by Eclipse: a change inside the workspace directory can trigger something.
For example, a Java file that will be saved will be compiled and might create error markers in a dependent Java projects. Changes made outside of Eclipse are visible inside Eclipse only after a refresh (assuming Window > Preferences: General > Workspace: Refresh using native hooks or pooling is disabled): instead of slow file accesses, Eclipse stores states of workspace files internally.
From a historical point of view, the workspace concept can be seen as a compromise between database and file system (in IBM VisualAge which can be seen as the predecessor of Eclipse the Java source code to be edited was stored in a database).
In addition:
Multiple instances of Eclipse can run concurrently, each with its own workspace.
Eclipse stores almost all preferences (Window > Preferences) in
the workspace (in the .metadata subfolder). Different workspaces can have different preferences.
The .metadata subfolder is also be used for caching to speed-up Eclipse.
I suspect that the target platform that is required to develop Eclipse with Eclipse (dogfooding) also played a role in the decision for the workspace concept (see also Eclipse bug 392652).
Think of a Java interface and a concrete class implementing that interface. It's similar for the Eclipse workspace and the underlying directory.
A workspace as a logical container for projects and configuration. That logical concept is implemented by a physical directory on your file system. The way it's designed, it would actually be possible (in theory) to implement a workspace using something other than a (local) file system (similar to what VisualAge for Java did, as referenced in #howlger's answer), although I don't know of any such implementation.
The point is, what you interact with while using Eclipse the IDE is a concept; it's best to not think about it too much as a filesystem directory. Doing so leads to some assumptions that won't always hold true, if you get deep enough into using it. Going back to the first sentence of this answer, you can sometimes get away with assuming a particular implementation of an interface, but doing so has hazards if you're not careful.
I'm trying to figure out which files to check in to version control when using Eclipse for Android development. I have a workspace with a single project. I found this which suggested that the .metadata folder did not need to be controlled (minus the comment there about launch params, however I don't mind re-picking those again on a different machine).
If I remove the .metadata folder then open Eclipse the project is no longer shown. I searched for posts on this symptom and they suggest re-importing the project. This solution doesn't make sense here, I'm trying to check in whatever is needed so another developer can open the workspace and see the project and work on it. Having them move the project then re-import it would be a bit messy.
So which files should I be version controlling so that someone else can get the latest and be able to open the project without controlling a bunch of user specific preferences?
I have had similar experience using Eclipse for version control, and decided to quit using it because it is very annoying and buggy. Now, for git, I use SourceTree, which I prefer over eclipse version control. I think you should version control the source code folders, along with configurations, and other files you program needs to function, but never the executable files. If the other person is using Eclipse, for easiness, it is good idea to include the .classpath configuration file. If not, then the other person would need to clone the repository and make the required changes so that it works with his/her IDE.
I think I've settled on the following approach. This seems to work well so far and avoids some of the headaches mentioned in my original question.
1) each developer creates an Eclipse workspace on their machine somewhere, outside of version control; only the project directory is checked into version control - the workspace is completely uncontrolled
2) developers checkout the project directory from version control (in a different directory structure than where the workspace was created) and then use File >> Import, but they leave the "copy into workspace" unchecked.
So with the above, you can checkout from version control and work with the files right where they were checked out. There's no need to move them out then import them back in. When you import with the copy option unchecked, the workspace (which itself is not controlled) is just referencing the files where they're at on disk.
The only minor downside is that any workspace stuff has to be setup individually. Other articles mention controlling the launch params, but so far this hasn't been an issue - pretty easy to pick that once the first time you launch.
So anyway, hopefully this helps someone else :) This seems to be a reasonably smooth way to do it and avoids the issues we ran into initially.
I have two computers, and want to share a java project in eclipse by saving and opening the project from my USB stick.
But I can't seem to get it to work very easily.
What steps do I need to take to set this up properly?
These things should be discouraged. My advice is using an SCM (Source Control Management)
like Git and keep a repository on the external drive (if using Git, a bare repository on the USB stick and a local repository on each machine). At the beginning you'll spend quite some time getting used to, but it will pay soon (you'll have descriptive changelogs and disaster recovery facilities)
Eclipse has support for Git via Egit, and for SVN builtin.
When you share a project like this, you may encounter troubles related to classpath references to external JARs, which may be overcome by
using a lib/ folder (thus keeping the JARs under version control)
using an environment variable like $JAVA_LIB
using some dependency manager like Maven or Ivy (again, there are lots of stuff, but will pay even in the short term)
For existing project that you don't want to put under version control, you can simply (again, there may be missing library errors) use the menu File > Import > General > Existing projects into workspace
I strongly recommend using a cvs, svn, or other version control repository for this purpose. Trying to manage it manually is eventually going to bite you.
But if you insist, the best way I know of is to create the project in Eclipse by un-selecting the Use Default Location option in the New Java Project wizard. That allows you to specify an external location for the project contents, in your case the USB drive. You'll have to make sure of a few things:
that the USB drive is always plugged in while Eclipse is running.
Refresh the entire Project each time you move the USB drive from one computer to the other.
Any references to JARs are either internal to the project (eg, in a /lib folder inside the project) or use Classpath Variables.
It's going to be quite tedious, which is why it's always recommended to not try this and use a version control repository instead.
I do this. With some projects I have in SVN or GIT. For me it's more important to have only one eclipse and one workspace. Unfortunately this limits to Windows (or one os). The trick is to ensure that it always has the same drive letter. I tried with subst first, but I forgot to often. But using the drive manager from Windows everything works fine.
I'd like to set up eclipse with a bunch of plugins and DB connection configurations, etc and re-zip it up so my team-mates and new starters can all be working on the same platform easily.
It seems that installing plugins is fine, but when I add in custom jars (e.g. ivy2, ojdbc, etc) they all save with full, absolute paths which probably dont exist on others machines (particularly if they unzip in a different location to me).
Anyway, I'm hoping that this idea is not silly and am working if this sort of process is documented somewhere or if anyone has any tips in general.
Thanks,
I would recommend against requiring all developers to place eclipse in the same location. There are times when some developers may want to try an alternate version of eclipse to explore a technology that requires a different set of plugins or a different eclipse base version.
Let developers install eclipse where they would like.
However, for jars that you need to run plugins (external dependencies that you need to configure for proper plugin usage):
Hardwire a directory for those jars (as opposed to the entire eclipse dir), like c:\eclipse-helpers or something.
To deal with third-party library dependencies (in the code you're developing), you have a few good choices:
Create project(s) to hold the third-party libs and check them into your source version control system (which you are using, right?). You can then add the libs to the build path(s) of the project(s) - make sure you mark them for export in the "order and export" tab of the build path page. You can then simply add these third-party projects as project dependencies.
Reference the third-party jars as CLASSPATH variables when adding them to the build path of your projects. This allows other developers to store the dependencies in different locations. Perhaps define a CLASSPATH variable (in eclipse's Window->Preferences->Java->Build Path->Classpath Variables) called THIRD_PARTY_JARS; each developer can map it to a different path where they want to hold their deps.
Reference the third-party jars as a "user library" (Window->Preferences->Java->Build Path->User library). This is similar to classpath variables, but acts as an explicit set of jars.
Include the third-party jars directly in your projects. Use this option only if you need the deps in a single location.
Although not exactly in line with the direction of the question, you could use Yoxos OnDemand. It allows you to "roll-your-own" Eclipse distro and download it as a zip. They add in their own perspective where you can add more plugins (direct from their repo), or update the plugins that you have.
Although I've never used the feature, you can make make your own stacks and name them, allowing anyone to go to the site later and download it (with the most up-to-date versions of the plugins). Also, dependencies for plugins are resolved automatically if need be.
In eclipse - in many places it's possible to use workspace relative paths or system environment infos to reference external files, too.
Another option could be to place your jars into a workspace project so that every team member can check it out from cvs/subversion/whatever and start working. Working like this ensures a reproducible environment for server builds or for desktops even after years.
Talking about Yoxos...
it provides "Workspace Provisioning" as well. This means you can attach Eclipse Preferences, checkstyle configurations and Mylyn setups additionally to your list of needed tools/plugins for your IDE to your yoxos profile.
This means your team could share a profile and would be able to start working with the same setup regardless of their OS or whatever. (Its possible to use multiple profiles at once, too.)
We did a similar thing with our development environment (it needed both Eclipse and our own plug-in which, in the early stages, had to run in a known location).
We just put it in c:\eclipse_<projName> and made that a requirement for the team. That's probably the easiest solution for you.
It's your team, you can dictate this as a requirement. Unless your team members are absolute idiots, they'll work with you.
I found Yoxos really good and it does very good work in determining dependencies.
Its really a good tool and worth giving a look.
I just started using git to manage my eclipse install. I did a write-up. The approach might work for you, and it's probably worth looking at.
If developers all don't have the same paths on their machine, instead of adding independent JAR files you could create what Eclipse calls a "library" and include a bunch of jars in that. Then another developer just has to change the location of the library and it'll pick up all the jars in there.