Sharing projects
This topic explains the options for sharing projects between computers, as well as some of the possible problems in doing so.
- Storing them in a source repository and version control system, such as CVS or Rational® ClearCase®. This method provides the best results for development code for many reasons, including the ability to synchronize changes, resolve conflicts, and collaborate on code. See Sharing projects in a repository.
- Exporting an EGL project to the local file system. This method is appropriate when you want to share a project a single time. See Importing projects and files.
Files to share
Generally, share only the files that someone else needs to work with the project. Do not share any files that can be generated from other files.
- EGL source files
- EGL build files
- EGL deployment descriptors
- Non-derived metadata files in the project, such as
.eglpathand.eglprojectfiles - Files necessary for web projects to run on a server, including
faces-config.xml, JSP files,web.xml, and files in the Enterprise Application Resource project, if you have one
- Derived files, including the
.irfiles found in the EGLBin folder - Output files generated from EGL source files, such as
.javafiles and.classfiles
Regardless of the type of project, do not share derived
files. Derived files are generated from source files and are not
original data, so it is usually unnecessary to share them. In the
context of EGL Java™ generation,
derived files include the Java™ source
files that are created during the generation process as well as the Java™ class files created from those Java™ source files. EGL source files
and build files are not considered derived, but .ir files
created from the source files are derived.
Including derived files increases the size of the artifacts that you share. Moreover, including derived files might not be useful because they can be regenerated and overwritten when the files are imported into another workspace. However, you may want to share derived files if the person you are sharing the project with cannot generate the derived files, or if you are trying to diagnose problems with the derived files.
The
workbench maintains a flag on each file to specify whether the file
is derived or not. For example, class files created from Java™ files and .ir files created
from EGL source files are automatically marked as derived. However,
the workbench does not mark Java™ source
files as derived, even if they are generated from EGL source files.
In EGL, these Java™ source files
are still considered derived because they are created from EGL source
files.
You can see whether a file is marked as derived by right-clicking
the file in the Project Explorer view or Navigator view, clicking Properties and
moving to the Info page. (You may want to use
the Navigator view to examine derived files because the Project Explorer
view filters out some types of derived files, such as EGL .ir files.)
If the Derived check box on the file's Properties
window is selected, the file is marked as derived. However, many sharing
methods (including Project Interchange files and some types of repositories)
do not retain the derived flag. If you share a derived file and someone
else checks out the file, that file will no longer be marked as derived.
Possible errors
- Correct project dependencies, if it has other projects in its build path.
- Make sure that the project can find imported parts in the new location, if any source files use import statements to refer to other EGL parts.
- Verify that links between web pages still work.