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
Related
I have an Eclipse RCP GUI application and I've been trying to redirect all files needed at run-time to a folder in the users home directory.
My issue arises when trying to move the configuration folder using the "-configuration" program argument.
When I just use data it works, my app starts up normally, but when I add in the configuration argument this thing opens when I run the app instead:
This is likely because Subclipse's default policy for usage statistics is set to 'ask'. Now that you are changing the configuration area to a location where no configuration settings are stored, Subclipse - when activated - shows this dialog.
Though Subcipse is violating Eclipse UI guidelines here, the maintainers probably won't change this any time soon.
If your RCP application does not depend on Subclipse, you should remove the respective plug-ins or features form your target platform and the problem will go away.
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 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)
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.
When I change some interface things in Java, like the contents of a menu item, and save them, the commit option does not enable. NetBeans does not know that changes have been produced so I cannot commit them. How can I commit them?
Can you commit from the console?
try svn stat in the root directory of your project, that should show you the files that have been modified with an M near the name of the file. if you can see them, run svn ci to commit all changes.
Maybe (and just maybe), svn is ignoring those files on purpose, to check if this is true, run from the console svn propedit svn:ignore .(<- this dot is necesary) in your project root to check if that directory/file/file extension is being ignored.
Good luck!
Are you using Netbeans 6 or higher? If not, you need to tell Netbeans where the svn executable is (see the link and the associated FAQ).
Are you sure that your subversion repository is running on a machine that is in sync with your workstation's view of the current time (e.g., synch-ed via ntp)? If the time is enough out of sync, it's possible that the subversion module is missing the update and, therefore, not flagging the change.
Also, you should check to make sure that you have an active valid connection to the subversion repository. You can easily do this for the file you just edited: right click on the editor tab for that file and choose Subversion -> Diff or Show Changes or Search History. If any of those fail, your IDE has lost its connection to SVN for some reason.
Another possibility is that you didn't succeed with a real checkout: if the .svn subdirectories aren't properly configured, the menu item will definitely be disabled. I would recommend that you right click on the project (under Projects) and try Show Changes. If that doesn't succeed, you don't have a valid Subversion checkout and the Netbeans options definitely won't work.
If for whatever reason netbeans isn't allowing you to commit, I would suggest either doing it from the commandline, or using a program like TortoiseSVN
It is Subversion's responsibility to know what has changed since the last commit/update. If NetBeans' Subversion interface doesn't allow to commit, then it may be a bug in Netbeans. Technically, there should be no reason to disable commit button - Subversion doesn't prevent you from committing even if nothing has been changed.
Right Click the file which is marked as red color, select resolve confilcts
and try to commit now...