I got a task about replacing Workspace Mechanic in Eclipse since there are no commits since 2014 and sometimes it doesn't work without reason.
I could create and configure a installation.setup file successfully on my local machine with some code clean-up formatting and save actions preferences which are loaded each start automatically. :)
The last step is to centralize the setup-file on a network drive.
Workspace mechanics enables to configue a directory with the settingfiles inside.
Oomph may not support the way I thougt. There is a way to synchronize to Eclipse.org but we want to keep the information inside the company due to policy reason.
Is there any way to store a central (Oomph) setup-file which synchronizes to each Eclipse client at start up?
You can use the Eclipse plugin yatta. It "manages your Eclipse setups – for yourself, your team, or within the community.". Of course, you can simply share the Preferences - other options it provides is share repos and projects.
https://www.yatta.de/profiles/help
With yatta you will create an Eclipse Installer, that can be installed on different clients. The clients will receive Updates of the 'master-settings' and there is the option to fork as well. Settings will be not be saved in local network but in the clould. From scratch, your profile will be private, you can share it with single persons, a group (*#yourcompany.com) or you can share it to public as well.
While Yatta is a handy to use plugin, it is based on Oomph, which is the complex way (you have several 'ontop' configurations for product, project, installation & workspace). In fact, both can do what you want.
Related
I would like to use Eclipse in an intro programming class. Is there some way I can make some kind of preferences file or some such that I can distribute with it that would set defaults for:
which buttons are in the toolbar
which menus are enabled in the application
which context-menus are enabled
what kinds of completions are available
I'd like it to start with only completing words from the current document
that is no Java API completions or code generation or whatever
This can be done using Eclipse Preferences File. All you need to do is import preferences into your workspace.
You can also export the workspace folder itself & publish Eclipse together with a default workspace folder, which will contain all the preferences.
Then create a shortcut to start eclipse with -data <path to your workspace> parameter
I'd try the following:
Install Eclipse
Put the configuration files and workspace under version control and commit.
Configure Eclipse as required.
Check all the changes in the version control to understand what configuration files are relevant to my changes.
Continue as Zilvinas is suggesting.
Look into Eclipse Oomph. It essentially automates all the tasks that you need to do to set up a fresh dev environment.
Also of interest are Yatta profiles which do a similar thing based off Oomph.
They're pretty easy to set up and publish. Get your local eclipse working, record to a profile, publish the profile, get your students to consume said profile. We've used these in a professional environment to more easily on-board new devs!
I want to know if there is some good way to automatically configure Eclipse workspace of newly checked out project.
I've got a project where I use gradle to both build and configure all of its subprojects. Since I want to enforce some good practices I also use e.g. FindBugs plugin, and tweaked Eclipse configuration (more/better compiler warnings, formatting, favorites, save actions and so on).
I think that storing .metadata directory in git is not a good idea - a lot of settings works only for certain version and breaks after update, some settings are stored in binary files and so on.
Build-in import/export tool handles only some settings - AFAIK it leaves e.g. save actions, favorites and formatting alone and don't handle them.
Then there's Workspace Mechanic plugin that allows to record settings change - but it doesn't allow to update existing record, only create new file or override old one, which leaves me with a lot of tasks to run - and it's not bug free: several times file_export_version=3.0 line was placed in a wrong place, so some settings couldn't be imported until I fixed that manually, and few times after import installation stopped working correctly... (even though I imported settings that I just exported!).
Do you have some good, automated, portable solution? Perhaps some tweaked way of using already mentioned tools? It might be more complicated that just running one script - I just want to make sure that all of changes are applied, I didn't miss anything, I don't have to change each and every option manually and it will still work when I apply it to an upgraded Eclipse.
There's a Workspace Preferences Transferrer that might help you. It allows you to transfer pretty much all (yeah, not just all) of the current workspace preferences to the new one when switching.
For my personal case it misses only one setting (look'n'feel) - so all in all it saves a lot of time compared to doing it manually.
Based on my understanding on your query
Clone a new git repo and point the same repo location as your eclipse workspace . Import your projects by referring to the same git repo itself. By this way all the changes in your code will automatically be reflected in the local git repo and you can push the code to remote later
Hope this is what you require
I would like to use Eclipse and Spring Tool Suite at the same time using the same workspace.
Is there a way to do that?
PS: I've tried deleting .lock file in .metadata directory. But after I open Eclipse again, it's regenerated.
Thanks in advance!
No, it is not possible. The workspace stores several piece of information that both IDEs require (e.g. the Eclipse file system model that stores the list of all projects).
There are two things you could do (if you really require to work with both components):
Install every plug-in of one of your IDEs into the other (presumably it would be easier to install your Eclipse plug-ins into STS, but it very much depends on what you have installed). Then, if you need, you can open two windows (Window / New Window from the main menu), and then manage your stuff as needed.
Maintain two installations with two different workspaces, that share a set of projects stored outside the workspace. However, I would not recommend this approach because
You have to refresh the projects in the other workspace (where you were not editing)
The automatic builders registered in both workspaces would execute much often, and even worse, they could be conflicting with each other.
If you only need to work with the same set of versioned projects in the Eclipse instances, then maybe it would be a better idea to create a Team Project Set of your projects, and check them out into both workspaces, and share your changes through the version control system.
All,
I have a 20 member dev team working on a development project.
To provide greater control we have created a workspace with necessary projects and configurations (like project preferences, set-ups etc) in IBM RAD.
The idea is to have the pre-configured project in subversion so that when the dev team members checkout the project they get a complete workspace, so that they do not have to configure setups them selves.
However the problem is everytime someone checks out the workspace IBM RAD will also edit the .metadata (and some other folders and properties file) folder that has been checked in.
Idea is the developer should not have to change anything except the source code folders or application specific files.
I think many other teams might have faced situations like this.
Can anybody provide the best practices/process/references on how this is done in development projects?
Thanks
I think svn ignore will solve your problem.
check http://svnbook.red-bean.com/en/1.1/ch07s02.html
The svn:ignore property contains a
list of file patterns which certain
Subversion operations will ignore.
Perhaps the most commonly used special
property, it works in conjunction with
the global-ignores run-time
configuration option (see the section
called “Config”) to filter unversioned
files and directories out of commands
svn status, svn add, and svn import.
You cannot stop IBM RAD from updating .metadata folder and Eclipse doesn't support splitting workspace folder as it does for the configuration folder.
The best solution would be to setup your build scripts to be able to setup your workspace based on some .zip file(s), where you've captured the required settings for the workspace. This will give the closest thing to automatic workspace setup without having to deal constantly with changed files in .svn.
Whenever I switch workspaces/Eclipse installs I need to copy/redo the preferences:
compiler settings;
font sizes/families;
code formatter;
java code templates;
editor templates;
code clean-ups;
I would like to maintain these settings in an unitary way, preferrably under source control. How can I do that?
I know about 'copy settings' when creating a new workspace, but it does not keep updated copies.
You could of course export/import those settings.
The other approach is to enable project specific settings for some settings.
We have a very small Git repository with those kind of files:
.settings/org.eclipse.jdt.core.prefs (compiler problem settings and formatter rules)
.settings/org.eclipse.jdt.ui.pref (cleanup rules, common code templates)
The common settings are just copied/merged in each projects .settings directory, ensuring common rules amongst all projects, whatever the workspace.
You could also try Workspace Mechanic. It works perfect for this.
http://code.google.com/a/eclipselabs.org/p/workspacemechanic/
Eclipse now ships with a tool called Oomph Setup. This tool can be used to record the preference changes that happen in your workspace, synchronize those preferences across multiple machines using an online service, and apply the preferences to both new and existing workspaces.
"Oomph" is actually a broader set of tools and low-level frameworks that are used throughout the Eclipse installation process, and it provides for very powerful automation possibilities, so the documentation is sometimes hard to follow for an end user who's just interested in simple preference synchronization. Here are a collection of links about Oomph Setup that I found helpful:
Oomph: A Matter of Preference -- Blog post providing overview of preference tool
Oomph Setup Documentation -- Official documentation
Automating Project-specific Eclipse Setups with Oomph -- Walks through how to set up Eclipse to have default settings for new workspaces and automatically update the settings for existing workspaces
You now have a good example of a separate project maintaining Eclipse preferences, as plugin.
See the saneclipse project from Lars Vogel.
You also have the associated vogellacompany/com.vogella.saneclipse repo, which will tweak and fine-tune the settings of:
com.vogella.saneclipse.preferences/.settings/org.eclipse.jdt.core.prefs
com.vogella.saneclipse.preferences/.settings/org.eclipse.core.runtime.prefs
com.vogella.saneclipse.preferences/.settings/org.eclipse.core.resources.prefs
com.vogella.saneclipse.templates/.settings/org.eclipse.jdt.core.prefs
com.vogella.saneclipse.fileextensions/.settings/org.eclipse.jdt.core.prefs
com.vogella.saneclipse.fileextensions/.settings/org.eclipse.pde.core.prefs
Check out Pulse Freelance Edition. It has the ability to sync workspaces (commercial).