I have an Eclipse project which relies on the Java Editor->Save Actions to produce correctly formatted code. The Eclipse project files are stored in repo. (It is outside of the scope of this question on how smart this practise is)
The problem is that one of the options in Save Actions is Sort Members. This is configurable only on global settings (i.e. Window->Preferences->Java->Appearance->Members Sort Order) and this project requires the "Sort members in same category by visibility" checkbox to be checked.
The default settings for Eclipse has that checkbox not checked (at least on latest versions), therefore if new developer (or existing using new fresh installation of eclipse) starts working on the project, the save actions (which is activated by default via settings from the repo) results having wrong order of methods.
I can write instructions about that in a README, but I was wondering is there any way to save that setting to the repo (also meaning it would be project-specific)?
This setting is stored in the Eclipse JDT UI preferences.
These are stored in the workspace .metadata/.plugins/org.eclipse.core.runtime/.settings folder in the org.eclipse.jdt.ui.prefs file.
In that file the settings is the org.eclipse.jdt.ui.enable.visibility.order property.
So this cannot be project specific and it is not really possible to store this in a repository.
(Source code for the settings is in org.eclipse.jdt.internal.ui.preferences.MembersOrderPreferencePage)
Related
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.
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.
Is it possible to set a "rollback point" in any Java IDE (Eclipse, NetBeans, IDEA), so that I can quickly get back to it if I don't like the change without going through the millions of Undo's?
I know that there's a best practice branch-commit quickly-merge, but that's not appropriate in current environment.
Eclipse
Eclipse keeps a local history of a file. Right-click in the file and choose Compare With -> History to view it.
It may be necessary to mark the 'Local Revisions' tool bar button in the History view to view them.
The local history can be configured via Window | Preferences, then General -> Workspace -> Local History
NetBeans
NetBeans has a local file history which acts similar to a versioning system. You can "rollback" your changes to a specific version of the file.
IntelliJ IDEA
IDEA has the similar feature, and even supports labels, which are put on the whole project tree.
NetBeans has a local file history which acts similar to a versioning system. You can "rollback" your changes to a specific version of the file.
In Eclipse, I think the Local History could help
I'm working on an Eclipse (editor) plugin and trying to change its ID. Whenever I do that, I get lots of ClassNotFoundExceptions, e.g. for my TextEditor subclass.
I did replace the PLUGIN_ID string literal in the Activator (the AbstractUIPlugin subclass), but that didn't help.
What do I have to do to change the plugin ID of an Eclipse plugin?
The plugin ID seems to be not only stored in the project, but also (temporarily) in the workspace you're developing it in, e.g. in the file ${workspace_loc}\.metadata\.plugins\org.eclipse.pde.core\Eclipse Application\dev.properties, which seems to store the path to the bin folder for each plugin you're working on. You can see that by opening your run configuration and looking at the configuration location shown on the 'Configuration' tab.
The easiest way to update this is apparently to just restart Eclipse (the one you're developing in, not the target platform). That will update these files and the plugin should then work with the new ID. You might also get away with selecting the 'Clear the configuration area before launching' on your run configuration.
So the steps are:
Open the plugin.xml editor and change the ID field on the Overview tab.
Update the string PLUGIN_ID in your Activator to the same value.
Restart Eclipse.
PS: I can no longer easily reproduce this problem. Updating the ID of my plugin now also seems to update the references in my workspace. I'll keep this around though, maybe it helps someone.
i have noticed that eclipse recently creates a .settings directory with 1 file inside and i am wondering if i should add this to version control? SVN?
also, is this new? i have been using eclipse for quite a while, but never noticed it.
the contents of the file in the directory is this:
#Sun Oct 11 14:57:03 CEST 2009
eclipse.preferences.version=1
org.eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.6
org.eclipse.jdt.core.compiler.codegen.unusedLocal=preserve
org.eclipse.jdt.core.compiler.compliance=1.6
org.eclipse.jdt.core.compiler.debug.lineNumber=generate
org.eclipse.jdt.core.compiler.debug.localVariable=generate
org.eclipse.jdt.core.compiler.debug.sourceFile=generate
org.eclipse.jdt.core.compiler.problem.assertIdentifier=error
org.eclipse.jdt.core.compiler.problem.enumIdentifier=error
org.eclipse.jdt.core.compiler.source=1.6
shouldnt these settings be workspace-wide and not project specific?
This file records project specific settings vs. workspace preferences.
I noticed that this file is usually created when you convert a regular Java project to Java EE project.
The only time I would check this file in is when the project's compiler/warning settings are different from the default workspace settings.
This may be the case when some legacy projects cannot be compiled with the latest and greatest java compiler, or when the source code generated by a 3rd party produces a lot of warnings that are benign but pollute your Problems view.
If you are going to use project specific settings, then definitely check this file in. Otherwise delete it.
The .settings folder is used by various plugins to set persistent 'Properties' as opposed to 'Preferences' to specify project specific settings that should be preserved.
This is usually a directory you most definitely want checked into svn/cvs/git etc as it will ensure that all users who check that project out into eclipse use the right project specific settings.
In our case we use it to supply a minimum compiler version of 5 since some devs are on Java 5 versus 6 etc but we want things compiled to 5 for our servers. We also use it to enforce some coding standards and auto-formaters which makes version diffs much easier to read.
In your specific case you selected 'Enable Project Specific Settings' under "Properties->Java Compiler" by right clicking on the project and choosing properties.
Those are project specific settings for eclipse. You do not need to include them in svn, as each users eclipse will create these when they checkout project, or they may even use another IDE and not need them. If you are the only one using the project then it won't matter if you include them though.