Project Build Path Visibility and Working Set Constraints

Question

The Eclipse IDE utilizes .classpath and .project files to manage resource visibility and build dependencies. While Working Sets allow for the logical grouping of projects to reduce UI clutter in the Project Explorer, they operate independently of the actual build path configuration.

A design uncertainty arises when attempting to restrict the visibility of referenced projects or external libraries specifically for certain Working Sets without modifying the global build path of the project. Since Filtered Resources only hide files from the UI and do not impact the internal Eclipse Compiler (ECJ) process, there is a disconnect between what is visually grouped and what is functionally available for compilation.

Does Eclipse provide a mechanism to tie build path visibility to a specific Working Set?
  Can resource filters be configured to prevent specific build path entries from appearing in the UI without removing them from the .classpath?

Tasadduq Burney · Answer

Direct Answer
No. Eclipse does not provide a mechanism to tie build path visibility to a specific Working Set. Working Sets are UI-only groupings, and resource filters cannot hide individual .classpath entries from the interface while keeping them active for compilation.

Confirmed Facts

Working Sets organize projects in views such as Project Explorer and Package Explorer; they do not alter the Java build path.
  .classpath entries define compile-time and runtime dependencies for the whole project. ECJ uses them regardless of Working Set membership.
  Resource filters hide files or folders from the UI but do not remove build path entries, hide referenced libraries, or affect what ECJ compiles.

Likely Explanation
The disconnect exists because Working Sets control presentation while the build path controls compilation. Eclipse treats them as independent concepts, so a project can appear in a focused Working Set while every library on its .classpath remains available to the compiler and to other views.

Steps for This Case

Open Project Explorer and note the active Working Set.
  Right-click the project, choose Properties > Java Build Path, and confirm entries are unchanged across Working Set selections.
  If compilation scope must be restricted, move the affected code into a separate project or adjust the launch configuration instead of editing .classpath for one UI grouping.

Verification
Apply a resource filter to .classpath or a source folder, then open Referenced Libraries and run a build. The entry should still appear and compilation should still succeed, confirming that filters are UI-only.

Assumptions and Uncertainty
This assumes standard Eclipse JDT without third-party Project Explorer extensions. Behavior may differ across Eclipse versions or with plugins that extend the UI. Manually editing .classpath changes compilation for all users and all Working Sets, not only the current view. Verify your Eclipse version before adopting project-splitting workarounds.

Missing diagnostic detail: Are you trying to hide entries from the Package Explorer only, or also from the Java Build Path dialog and Referenced Libraries view? This determines whether a UI-only workaround is sufficient or whether separate projects are required.

Project Build Path Visibility and Working Set Constraints

1 answer

Direct Answer

Confirmed Facts

Likely Explanation

Steps for This Case

Verification

Assumptions and Uncertainty

Your perspective belongs here.

0 question comments