Eclipse has projects, what's the purpose of the Workspace that appears to group projects? Projects could live in the directory tree isn't that a more natural way of organizing different projects?
When you first start up Eclipse not knowing much about it, it feels like an unnecessary layer of bloat that new users have to get accustomed to first. You're forced to set up some organizing structure that, although specific to Eclipse, wants to live in the rather general-sounding place ~/Workspace.
The workspace is a collection of projects and the metadata that cannot be included in a project because it's not portable (references paths and resources on a specific system) or because it pertains to Eclipse as a whole.
Without the workspace concept, opening a project in Eclipse would be followed by multiple steps of getting things configured. This information would be lost when Eclipse is closed or all projects you ever work on would have to share the same configuration.
Examples of metadata stored in workspace:
Locations of available JDK's and JRE's. The project references a JRE by name, the workspace metadata is needed to resolve that reference.
Locations of application servers.
Path variables.
Open perspectives, layout of views, etc. Consider one application where you need Git and app server vs another application where you need SVN and Android development tools. The views you'd want to keep open and how you'd arrange these views would be very different for two applications.
Related
I've installed Jaspersoft Studio 6.2.2 in order to edit a couple of existing Jasper reports. Unless I missed something, nowhere in Getting Started documentation do they explain the basic terms specific to this program. They do explain the generic Jasper terms (report, data adapter, field...) but, when it comes to Jaspersoft Studio, they just instruct you to launch wizards and use the defaults. That isn't optimal for me because I prefer to have my work under source control and separated by customer/client rather than having everything together in a local folder within my Windows profile. I also have the impression that they omit stuff because they assume you're familiar with Eclipse (I'm not).
Could you please provide me with a quick overview of the basic terms and some tips about how to use them to effectively organise work:
Workspace
Project
Project Folder
... and some other I might be missing?
My view:
A workspace is a group projects that share some configuration/environment. In project setting, you can use a common workspace configuration or define a project specific configuration.
In java world, e.g. you can define different JDK compatibility per workspace.
In jasper world, e.g. for Chinese projects, you can have projects that all have zh_CN default language set when executing preview. Different fonts might be used in this workspace. No need to set it up for every new project created.
Every workspace has it's own set of data adapters and JRS server connections.
I usually have sources under "Project folder", not in workspace folder. I just import a project into the workspace (do not copy).
BTW. One project can be in multiple workspaces.
What is a "safe" way to share an Eclipse workspace between two computers? I've had problems using Dropbox and I've had problems using Github. I am looking for a best practice that will "just work".
Update
I read below and many other places that sharing a workspace doesn't work. But my collection includes 50 projects, are you saying that I need to create 50 github repos? There's no way to put them all in one repo to save the repetition?
Solution (imperfect, but still improving)
My collection of projects is in a github repo called projects/ which includes 50 subdirectories, each structured appropriately as they would be for an eclipse project.The /projects directory doesn't have meta-data or any other eclipse info (AFAIK)
Separately, in ~ I create a brand new Eclipse workspace. And then I "manually" import each one with Eclipse. I do this on each machine that needs to access those projects via Eclipse.
No, the workspace will contain machine-specific information and locations. Share the projects themselves, preferably through a source code management system like git. If anything in the project refers to something outside the workspace, you'll want it changed to refer to that resource in a portable way (e.g. pick the JRE using an Execution Environment instead by name).
Look at the thread at https://stackoverflow.com/a/37799711/10235188. They describe how to share a workspace and configurations between machines. Otherwise you'll always have problems with absolute paths.
What is the best way to share project specific settings between multiple Eclipse projects?
I'm working with an application that is divided into several Eclipse projects. All of the Eclipse projects should use the same compiler settings. I could duplicate the settings in all the projects, but I'm looking for a way to avoid that.
The relevant settings are the ones that are saved in <PROJECT_LOC>/.settings, most importantly org.eclipse.jdt.core.prefs but also for example org.eclipse.jdt.ui.prefs. They are the ones that are set in Project Properties > Java Compiler, Java Code Style (and a few more places).
The solution must be version control friendly.
One possible solution use a linked resource, from org.eclipse.jdt.core.prefs or .settings of the projects to the same file, located in one of the projects. A similar solutions is to use soft file system links. I don't really like these solutions, it seems to me that they are hard to maintain, for example if the name of a project is changed.
I found this question which is different because it asks about sharing settings between developers, not between projects. (I must do both.)
How to share Eclipse project preferences between users?
I think it depends on how frequently you expect projects settings to change.
If not frequently, you shouldn't over-engineer your solution: just configure one project and copy settings to other projects, put everything under version control and you're done, except for having to perform this operation again every other year, or so.
If frequently, and if a lot of settings are involved, and if all (most) workspace projects should indeed use the same settings, then consider creating your own Oomph setup, that would include your settings as workspace settings. Then let all projects just use the workspace settings. (Of course a few projects could still deviate and use their own project settings, but once using project specific settings, changes to workspace settings will have no effect on that project).
BTW: Oomph includes capabilities to also specify once and for all: selection of plug-ins to install plus how to populate a workspace with projects from version control, and more. So I can only recommend this tool if you are really concerned about systematic configuration of working environments: create one setup - apply it automatically hundreds of times. And no, I'm not an author of Oomph, just a happy user.
Sharing your workspace setup using Project Sets
Your workspace setup may consist of several projects from one or more repositories. Once you have setup your workspace, you can share it with others by exporting a Team Project Set. A project set is a text file that contains a pointer to each of the projects contained in the project set.When a project set is imported, these pointers are used to fetch the projects from the repository.
http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-cvs-project-set.htm
A long time afterwards I got an idea about how to solve this:
Set up a multi-module Maven project.
Configure the settings in the parent pom file.
Import the projects into Eclipse as Maven projects.
Disclaimer: I haven't actually tested this, so I don't know how well it's working...
I'm looking for advice regarding best practices for sharing an Eclipse project among developers.
It seems clear to me that each developer should have his/her own Eclipse workspace. However, projects seem to loan themselves better for many users to use the same project, e.g., if several users are working on a particular component, they are all likely to need to use the component's project, since if they each had their own project, they'd each have to set up and maintain the same project dependencies, etc. Looking to see if this is what other folks do or if their are reasons to give each developer his own project for a particular component.
Also, if the recommendation is to share a project, what are recommendations for configuration managing an Eclipse project? In the past we have used ClearCase, but we are now looking to change to Git or SVN. In the ClearCase world, it would seem advisable to do frequent checkins and merges to help the team stay up to date. Again, I'm looking for opinions from folks who have already lived this.
Thanks for any recommendations or external "how to" books or websites!
Thanks,
Ken
Sharing an Eclipse project doesn't cause any problem. Just put the .classpath, .project files and the .settings directory (and any project-related config file/directory that Eclipse generates at the root of the project) under source control.
Also, avoid using absolute paths in your project (for external libraries, for example), since all the developers don't necessarily have the same setup and use the same locations.
Git, SVN or ClearCase : it doesn't matter : all allow sharing Eclipse files.
We put the entire eclipse project folder under version control (with an svn:ignore for the directory containing the compiled classes).
This allows us to share not only the build configuration, but also launch configurations (with the proper VM-parameters), the configuration for compiler warnings the team considers relevant, and the formatter configuration for the coding conventions in use. We can also set text file encodings that way.
...avoid using absolute paths in your project
Good point.
We've had some issues with this in ClearCase. Our third party libs were placed in a different part of the filesystem under version control. So to avoid absolute paths to the libs we added an ant script. The script would copy the libs to a view private directory that was directly under the project root.
We then added a builder to the project to make sure that the script was run first at every clean + rebuild.
If I want to use eclipse for projects in different environments,
what is the recommended way to work?
Install multiple instances of eclipse each configured differently?
No ... the typical why is you have for each of your projects a separate workspace.
All configurations are collected in this workspace. The only exceptions is if you need different plugin for the different environments, but usually this is not the case.
There is a nice tool from a google developer
http://code.google.com/a/eclipselabs.org/p/workspacemechanic
which help you to sync some general settings between different workspace.
Basically yes - things that make it easier for me are the Eclipse Workspace Mechanic (I have a folder with config files on my Dropbox, and reference that from the Workspace Mechanic preferences in the different Eclipse instances, so I automatically have them configured) and Mylyn (with which the data is usually stored centrally anyway and the settings can be exported and imported in a different Eclipse instance - I keep such an export on my Dropbox again).