Working with Projects and a Large Code Base

Benefits of using projects

Micro Focus recommends that you create and use Eclipse projects for your source code. There is a number of benefits to using projects, such as:

  • Projects take full advantage of the numerous time-saving and productivity features of the IDE. Features such as Content Assist proposals and syntax checking in the editor are not fully available if you are using the files without a project.
  • Project files store the details of any changes you make in the IDE.
  • The .cobolBuild and .pliBuild project files are Ant files. You can use them to build the files in the project outside of Eclipse - at the command line, in your build scripts or in a CI system.

The following sections include recommendations on how to create and configure your projects, especially when you are working with a large number of files.

Large projects

The definition of a large code base and a large project depends on various factors such as the number and size of files that comprise your application, the complexity and dependencies of the code base as well as the capacity of your machine. A large project could include hundreds or thousands of files and typically you experience performance issues when using Eclipse to load the projects, navigate the source code and when editing, compiling and debugging.

This section of the product help includes a number of recommendations and best practices to help you structure your code in the best possible way and optimize the performance of the IDE when you are working with a large code base.

Structuring your projects

The following list gives tips on how to structure your projects, especially if your applications consist of a large number of files:

Recommendation Benefits
Create multiple smaller projects and make them dependent on each other, rather than keeping all the code in one very big project.

Smaller projects are:

  • easier to manage
  • quicker to load into the IDE
  • quicker to compile

In addition, keeping your projects smaller helps achieve quicker response times in the editor.

Create projects only for the source files you are working on. This helps keep your projects smaller.
Create one project per functional area of your application and create dependencies as required. This helps keep the projects smaller, making it easier to understand the logical structure of your application and edit only those areas that require a change.
Store copybooks and include files outside of the projects for the source code in copybook and include projects You can then add these projects as dependent projects to the build path of other projects that include the source files. Copybook projects are not compiled, thus saving processing time and resources.
  • This improves performance because the IDE does not have to process the copybooks and resolve the file dependencies.
  • This helps keep the project size smaller.
Close projects not in use (click Project > Close Project) This helps reduce the amount of memory Eclipse uses.
Do not use source files and copybooks from a network drive. Network drives are remote folders that are mapped to virtual local drives. This is associated with the NFS/Samba connection type which contributes to a slower performance compared with RSE connections. You should either use files from local folders or, if the files are located on a remote machine, create remote projects using the RSE connection type.
Use folders and packages for COBOL JVM applications to organise code within a project This helps organize and make navigation of the files in your projects easier by creating a hierarchical structure.
Use paths relative to the project location in the project's properties - for example, for paths for the build output, or for linked resources. This helps make the project portable to other machines.

Limit the number of files stored in a single project

It is hard to provide a strict recommendation for the maximum number of files to store in a single project. This number will depend on many factors related to your particular development scenario such as:

  • Size of the files and of the programs, and their complexity and interdependency
  • Number and size of any copybooks
  • Number of people working on the same project
  • Whether the project is a managed or a native one
  • Whether your applications use incremental linking
  • The existing structure of the source code

Keeping the size of your projects smaller helps avoid various performance issues. As the size of a project increases:

  • The poorer the user experience inside Eclipse
  • The more difficult the project is to manage
  • The longer the times to load and rebuild projects
  • The longer the times to perform background syntax checking, code analysis, or to scan files for Compiler directives (using Determine Directives).

Limit the number of projects stored in a workspace

Micro Focus recommends that you avoid having a large number of projects in your workspace. The reasons are the same as the ones for limiting the number of files within a single project.

It is hard to provide a strict recommendation for the maximum number of projects to store in the workspace. Keeping the number of projects smaller helps avoid various performance issues and improves the times for:

  • Loading the projects in Eclipse
  • Rebuilding the projects, especially when there are dependencies
  • Performing background syntax checking
  • Resolving any references
  • Scanning files for Compiler directives (using Determine Directives)

Use working sets

Create and use working sets within Eclipse to work on and only see a smaller number of projects in your workspace. Working sets enable you to work on and only see a selected number of projects in Eclipse.

You can select to build only the projects that are in the current working set although this will build any project which has a file present in the working set.

See Working Sets for more information.

Make your projects portable

Ensure your projects are easy to share between different development teams:

  • Use relative paths in order to avoid hardcoded paths to the local machines in your projects.
  • Import existing projects into Eclipse with Copy projects into workspace disabled. For example, if you are using a Source Control System (SCM), you will be editing the project in the sandbox rather than a copy of it in the workspace. This helps to ensure you are committing all changes back into the SCM repository.
  • Share any run and debug configurations, and breakpoints - this ensures consistency across the environments of different users. You can keep these in an SCM and share with your development teams.

    To export configurations or breakpoints:

    • Click File > Export > Run/Debug > Launch Configurations or click File > Export > Run/Debug > Breakpoints.

    To import breakpoints

    • Click File > Import > Run/Debug > Launch Configurations or click File > Import > Run/Debug > Breakpoints.

    You can also export a run or a debug configuration in your workspace as follows:

    1. Click Run > Run Configurations.
    2. On the Common tab in the run or debug configuration click Shared file.
    3. Specify the folder in which you want to save the launch configuration and click Apply.

Only link individual files and folders

If linking sources into a project, only link individual source files and folders that will be used and not all of the available source files.

When using linked files, Micro Focus recommends that you create your project in a physical folder which is close on disk to the source files. This reduces the complexity of any relative paths used for linking and makes the projects more portable. Alternatively, create workspace variables that substitute the path to a project to make the configuration easier.

For example, if your source files are in /path/source then create any projects in /path/projects.

Use a Source Control Management system

Micro Focus recommends that you use a source control system, SCM, to store and share your application's sources. Using an SCM has various benefits:

  • It enables multiple users to work on the same code base independently.
  • You are checking out and working on the source code on your local machine. This helps avoid the need to connect to another machine to make changes over a remote connection which might affect the performance.
  • Your projects in the SCM sandbox will be imported in the Eclipse workspace. When you update the sandbox, any changes are directly reflected in the workspace.

See the recommendations for making the projects portable to make working in a shared environment easier.

Parent topic: Working With a Large Code Base