Should every team member create his or her own workspace and import project stored under source control? Or is there a way to put workspace under source control too?
How to avoid using absolute paths in workspace configuration?
Are there other bottlenecks in this task?
I would not put Workspaces into SCM; that would demand that each developer's environment be identical. Instead take care to avoid any hard-coded paths; use workspace variables.
Use Project Set Files to identify and share sets of projects that need to be imported to a Workspace. These files can/should be kept in SCM, perhaps in dedicated release projects.
My practice when doing serious work on an application is to start with a clean workspace, no extraneous projects. Populate it using the PSF.
One route people take is to generate the Eclipse projects from the build file. This has an added benefit if the development environment is designed to not have a rigid structure (e.g. the path to library X can be relatively different in environment Y than in environment Z) since the same configuration data (files, environment variables, etc) can be used to set up the Eclipse project as the non-Eclipse environment.
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.
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.
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).
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.