Before you decide to share projects between computers,
consider your sharing options and the effects of sharing.
You can transfer projects or files to another computer or workspace
in two ways:
- Storing them in a source repository and version control system,
such as CVS or IBM® Rational® ClearCase®.
This method provides the best results for development code because
you can use it to synchronize changes, resolve conflicts, and collaborate
on code. For more information, 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 for one time only.
For more information, see “Importing and exporting projects.”
Files to share
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.
You might share the
following files:
- EGL source files
- EGL build files
- EGL deployment descriptors
- Non-derived metadata files in the project, such as .eglpath and .eglproject files
- Files that are necessary for Web projects to run on a server,
including web.xmland
files in the Enterprise Application Resource project, if you have
one
Do not share the following files in a repository unless
you have a reason to do so:
- Derived files, including the .ir files found
in the EGLBin folder
- Output files generated from EGL source files, such as .java files
and .class files
Regardless of the type of project, do not share derived
files. Derived files are generated from source files and are not
original data, so you usually do not need to share them. In the context
of EGL Java™ generation, derived
files include the Java source
files that are created during the generation process and the Java class files that are 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.
When you include
derived files, the size of the artifacts that you share increases.
Moreover, including derived files might not be useful because they
can be regenerated and overwritten when the files are imported into
another workspace. However, 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, you might want to share derived files.
The
workbench flags each file to specify whether the file is derived or
not. For example, class files created from Java files and .ir files that
are 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.
To see whether a file is marked as derived:
- In the Project Explorer or Navigator views, right-click the file
and click Properties. TheInfo page
is displayed.
Tip: You might 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.
- On the Properties window of the file, if the Derived check
box is selected, the file is marked as derived.
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
When you share projects,
dependencies and links within the projects can break as the projects
are moved to different locations. To correct errors that you encounter
while sharing projects, you might need to complete the following tasks:
- If the project has other projects in its build path, correct the
project dependencies.
- If any source files use import statements
to refer to other EGL parts, make sure that the project can find imported
parts in the new location.
- Verify that links between Web pages still work.