Sharing projects

This topic explains the options for sharing projects between computers, as well as some of the possible problems in doing so.
There are two main ways of transferring projects or files to another computer or workspace:

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.

Share the following files, unless you have a reason not to do so:
  • EGL source files
  • EGL build files
  • EGL deployment descriptors
  • Non-derived metadata files in the project, such as .eglpath and .eglproject files
  • 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
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 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.

For more information on which files are considered derived and why you would or would not want to include them, see Derived resources.

Possible errors

When sharing projects, dependencies and links within the projects can break as the projects are moved to different locations. The following are some common tasks that you might need to perform to correct errors that you encounter while sharing projects:
  • 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.

Feedback