[DrJava] [ drjava-Feature Requests-1425713 ] Projects mirror file system

[SourceForge.net <no...@so...>]

Feature Requests item #1425713, was opened at 2006-02-06 18:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=1425713&group_id=44253

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Project Facility
Group: Large (> 1 pair-month)
Status: Open
Priority: 5
Submitted By: Dan Smith (dlsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Projects mirror file system

Initial Comment:
I'd like to redifine and reimplement projects to match the following 
description.  It contains what might be considered a number of 
different features, but I think they ought to be treated together, with 
an overriding idea of how they all tie together.

A "project" gives the user a view of the file hierarchy, relative to the 
project file.  It allows users to browse the file system, perform file 
operations, and easily run Java-related operations on groups of files.

Creating a project: The user selects a folder from a file selector.  The 
contents of that folder appear in the tree file view.  A few files are 
hidden (grayed-out, perhaps) based on the user's default preferences 
(such as class files, Language Levels products, a build directory, etc.)  
Hidden files are sorted at the bottom of the tree, and a setting allows 
them to be completely invisible.

Adding to a project: The user clicks on "New".  A new, empty file is 
created (but not saved) at the root of the project file system (or, if a 
folder or file is selected, inside that folder or next to that file).  The 
user may edit, rename, and move it just like any other file.

Editing a file: The user clicks on the file.  It is opened in the definitions 
pane if it is in a format that DrJava understands.  Java files use Java 
syntax highlighting; other text files use a basic text editor.  Hidden 
files cannot be edited [that's open to debate].

Browsing directories: The directory tree can be expanded and collapsed 
as usual.  All files in the corresponding directories are listed.  Hidden 
directories cannot be opened [again, open to debate].  Symbolic links, 
aliases, etc., can be followed.

Manipulating files: The interface provides facilities to rename, move, 
copy, and delete files and directories.  Moving is accomplished with 
drag-and-drop.  Renaming is accomplished by clicking on a selected 
filename. (That is, as much as possible, we match the behavior of 
Windows Explorer or Apple's Finder).

Compiling: When the user clicks on "Compile [all]", all non-hidden files 
recognized by DrJava as source files are compiled.  The user can 
restrict this search to a subdirectory (or subdirectories) by specifying a 
source root for the project (preferably, this is done in and reflected by 
the file tree hierarchy -- perhaps source directory icons are colored 
differently).  If there is a build directory, class files are generated there; 
all non-source, non-hidden files under the source root are copied into 
the build directory.  (The source-root-based search may need special 
support for symbolic links to prevent infinite recursion.)

Testing, Javadoc, etc., works analogously to compilation.

Hiding files: The user can choose to specify certain patterns of files to 
hide in the project preferences.  These settings, by default, are copied 
from a DrJava setting.  To overide the pattern-matching, specific files 
can be individually "blacklisted" or "whitelisted" in the file tree 
hierarchy.  (In addition to standard pattern matching, a custom 
"pattern" matches all *.java files with corresponding Language Levels 
sources.)

External files: In addition to the tree hierarchy, the usual list view of 
files is maintained for any additional files (outside the project tree) the 
user chooses to open.  These files are *not* matched by compilation, 
etc., since the source root(s) must be at or below the level of the 
project file.  The same operations allowed by DrJava when no project is 
open are allowed here; the same settings (such as classpath for 
compilation, etc.) apply [this is open to debate].

Storing projects: The following information about projects is 
persistent: classpath (defaults to system pref), source roots (defaults to 
project file's directory), hidden file patterns (defaults to system prefs), 
the hidden file blacklists and whitelists (which should not contain 
extraneous elements, such as a file in the whitelist that is not matched 
by any hidden file patterns; empty by default), and the working 
directory (defaults to project file's directory).  As much as possible, 
changes in the file system (such as files that no longer exist) are 
accepted silently, and the references in the project file are fixed.  
Optionally, scrolling, text selections, external files, etc. can be stored 
with the project.  All file references in the project file are relative to the 
project file's directory, thus allowing complete portability.

Modifications outside DrJava: As much as is permitted by the Java APIs, 
file and directory editing, creation, deletion, and renaming that occurs 
outside of DrJava is immediately reflected by the browser.  This only 
needs to involve some sort of notification when changes from within 
DrJava conflict from outside changes (e.g., a modified file in DrJava is 
deleted by someone else).

******

The general philosophy here is that we keep projects simple but just 
making DrJava (when in project mode) a file browser.  There's no need 
to explicitly specify which files need to be "open" (which, usually, is 
*all* of them).  There's no need to go elsewhere to perform file 
operations (and then deal with all the trouble that causes when DrJava 
sees files disappearing).  It's obvious when something is excluded, for 
example, from a compilation, so there's no potential for confusion 
when something ought to compile but it just doesn't work.  I think 
those ideas gel well with the application's goals of simplicity and ease 
of use.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438938&aid=1425713&group_id=44253