This post originated from an RSS feed registered with Java Buzz by Scott Stirling. Original Post: Managing projects: a few Eclipse recipes Feed Title: Blaug Blawg Blog Feed URL: http://users.rcn.com/scottstirling/rss.xml Feed Description: Java Testing, Tools and Engineering Latest Java Buzz Posts Latest Java Buzz Posts by Scott Stirling Latest Posts From Blaug Blawg Blog

Bob Lee is talking about managing projects in IDEA.  He has 20 sub-modules on his current project "each of which has its own build script, dependencies, etc."  Not unlike a project I am on, Bob.  Cool.

At my workplace, we have found Eclipse to be good for managing related projects each with around one dozen sub-components (a.k.a. modules) that are represented in the IDE and in our build scripts as inter-dependent projects.  Here are some of the things Eclipse supports that we take advantage of:

• Project references, which allow projects to references each other, as in:
• Exporting (sharing) elements that are in their build path, including source folders, class folders and jars.
• Importing other projects' classpaths and sourcepaths to build against their libraries and source
• Both of these features are useful for reducing redundancy (e.g., all projects inherit their logger jars and wrapper API from the platform or base project) and enforcing acyclic dependencies between components by using the inter-project configuration to define build order (**side note: one increasingly glaring problem these days is that any sophisticated project/component build and depdency configuration has to be maintained in two places -- the IDE level and the Ant build level.  Maven has a plugin to help with this by generating Eclipse project configs from Maven project.xml files, but this only gets you started -- there's still a lot of post-config required for any non-trivial project using multiple natures, non-Maven Classpath variables, and cross-project references).
• Refactoring code across projects, e.g., moving a class to a package in another project.  The refactoring support for package-related cross-project changes (Move and Rename of packages changing import statements automatically) is seamless.
• Classpath variables, which are automatically accessible to all projects in a workspace and are handy for pointing all projects to resources in a shared (via network, naming convention or SCM location) jar repository. 
• Path variables are also supported (see Window->Preferences->Workbench->Linked Resources), and are accessible via the Resources perspective, which can in turn bring in resources to be used by the Java perspective.
• Rational ClearCase integration via Rational's plugin and Eclipse's built-in CVS support (for checking out open source code).
• Pre-configuring projects with their build paths, inter-project dependencies and Classpath variables and then using the project import/export feature to share and sometimes update large changes (such as a change in directory structures or 3rd party dependencies) to projects across the development team (we check in the .project and .classpath files that configure each component's project).
• Eclipse's Workspace concept, where the workspace is an IDE container that can hold projects, folders and files.  We currently do not share workspaces, but we could.  The eclipse command can take a -data path/to/your/workscape option, which allows you to have separate Eclipse sessions with completely separate workspaces, which can help reduce clutter by componentizing large multi-project workspaces into multiple workspaces.
• I'd like to use project set files, but they don't seem to work with dynamic views in ClearCase.