drjava-hackers — DrJava developers mailing list

[DrJava] [ drjava-Bugs-1543649 ] The [-config] argument does not work.

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

Bugs item #1543649, was opened at 2006-08-20 17:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1543649&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: None
Group: 4: Serious
Status: Open
Resolution: None
Priority: 5
Submitted By: dotnetted (dotnetted)
Assigned to: Nobody/Anonymous (nobody)
Summary: The [-config] argument does not work.

Initial Comment:
When a custom configuration file is specified through
the use of the [-config] option, the configuration file
specified does not load.

None of the following seem to work:
:>java -jar drjava.jar -config test.cfg
:>java -jar drjava.jar -config ./test.cfg
:>java -jar drjava.jar -config /home/test.cfg

The configuration file (test.cfg) is being loaded by
DrJava as a source file as if the -config option had
never been given.

This has been tried on:
drjava-stable-20060814-2258.jar
drjava-20060420-1406.jar

I'm probably missing something obvious but there's no
harm in submitting. =]

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

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

[DrJava] [ drjava-Bugs-1541226 ] javadoc viewing is broken in stable release

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

Bugs item #1541226, was opened at 2006-08-16 04:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1541226&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: Javadoc integration
Group: 4: Serious
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: javadoc viewing is broken in stable release

Initial Comment:
With Java 5.0 on a FC5 box, javadoc viewing is
broken:  javadoc creates the files but does not
dispaly anything. If one specifies a browser via
preferences then BOTH the built in viewer AND
the browser open to display the javadoc results.

Further, when searching for the browser command
the search window generated a NullPointer 
Exception that crashed DrJava. For students
such behaviour would be terrible.



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

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

[DrJava] [ drjava-Bugs-1541011 ] Working directory feature missing in 20060814-2258

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

Bugs item #1541011, was opened at 2006-08-15 20:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1541011&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: User interface
Group: 2: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: rlh (rhalterman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Working directory feature missing in 20060814-2258

Initial Comment:

Pre-20060814-2258, one could set the working directory in the 
preferences dialog.  This option is now missing in 20060814-2258
(although it still listed in the Help dialogs).  Setting the working.directory 
option in the .drjava configuration file does not help (and it gets 
overwritten anyway).

The annoying result is that every time I start DrJava and wish to open a 
file I must navigate to my DrJava sources directory (four levels down for 
me).  Before 20060814-2258 I could start DrJava, select open, and the 
directory presented immediately was my DrJava sources directory. 

This behavior is exhibited on both OS X and Windows platforms.

DrJava version: 20060814-2258
Java version: 1.5.0_06 (OS X)
Platforms: Mac OS X and Microsoft Windows

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

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

[DrJava] [ drjava-Bugs-1538328 ] Project menu options not greyed out

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

Bugs item #1538328, was opened at 2006-08-10 16:38
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1538328&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: User interface
Group: 1: Would be nice if fixed ...
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Smith (dlsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Project menu options not greyed out

Initial Comment:
When I open DrJava, the "Run Main" and "Test" items in the Project menu 
are greyed out.  But after opening and then closing a project, they 
become selectable.  A reasonable error message occurs when I select one 
of them.

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

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

[DrJava] [ drjava-Bugs-1538304 ] 1.4.2_08 tools.jar

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

Bugs item #1538304, was opened at 2006-08-10 13:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1538304&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: Compiler integration
Group: 4: Serious
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 1.4.2_08 tools.jar

Initial Comment:
It looks like java-beta-20060729-1410 will not accept
the 1.4.2_08 tools.jar.  


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

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

[DrJava] [ drjava-Bugs-1536793 ] General "Find All" Bugginess

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

Bugs item #1536793, was opened at 2006-08-08 10:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1536793&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: User interface
Group: 3: Ugly
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Smith (dlsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: General "Find All" Bugginess

Initial Comment:
I've noticed a few bugs in the "Find All" interface:

- When there are no results found, "Find Next" prints a message at the 
bottom of the screen; "Find All" jumps to a (sort of) random tab -- usually 
the "Compiler Output" tab -- and gives no indication that nothing was 
found.

- The highlights (underlines) in the document are robust to document 
changes, but the text in the results tab is not.  Just about any document 
editing seems to mess the results tab up.  Often, it enters a strange state 
in which two lines of text are squeezed into the single allotted line, thus 
clipping off the top and bottom.

- I find the "context" popup windows are often in my way, and rarely 
useful.  If I can immediately jump to the specific text by double-clicking, 
what use is there in waiting three seconds for a popup to appear?  And 
then when the popups do appear, they just won't go away so that I can 
read what's underneath.  If there is a compelling need for more context 
without actually going there, maybe a widget to change the amount of 
context displayed inline is a better alternative?

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

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

[DrJava] [ drjava-Feature Requests-1536189 ] Single-line/multi-line bracket switching

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

Feature Requests item #1536189, was opened at 2006-08-07 12:51
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=1536189&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: Definitions (source editor)
Group: None
Status: Open
Priority: 5
Submitted By: Dan Smith (dlsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Single-line/multi-line bracket switching

Initial Comment:
I spend far too much of my editing time doing mundane formatting.  In 
the absense of a full-fledged automatic line-wrapping facility (as has 
been suggested previously), it would be nice if there were just a quick way 
to turn this:

public void myMethod() { doSomething(); }

into this:

public void myMethod() {
  doSomething();
}

and vice-versa.

This follows in the spirit of auto-indenting: I've provided the text, and I 
want the computer to adjust the white space for me.  A keyboard shortcut 
when the cursor is within the relevant brackets -- as easy as hitting "tab" 
on a line -- would be ideal.

It may be that this problem is unique to my coding style.  I make it a habit 
to always use brackets where they are optional (such as after an "if"), and 
to always put a bracketed statement on a single line if it will fit.  It's worth 
discussing whether this style is adhered to generally enough to make this 
feature addition worthwhile.

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

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

[DrJava] [ drjava-Feature Requests-1531047 ] Alllow users to monitor text files as code is interpreted

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

Feature Requests item #1531047, was opened at 2006-07-29 21:23
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=1531047&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: None
Group: None
Status: Open
Priority: 5
Submitted By: Robert Cartwright (rcartwright)
Assigned to: Nobody/Anonymous (nobody)
Summary: Alllow users to monitor text files as code is interpreted

Initial Comment:
When I run a program with debug logging turned on, the
log output is directed to a file rather than standard
output or standard error (which are treated specially
by JUnit and other testing harnesses).  I would like
for DrJava to support opening a new interactions pane
containing the current contents of the file, much as 

tail -f <filename> 

shows the current tail of a file.  As it stands I have
to run the tail command in a separate OS window.

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

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

[DrJava] [ drjava-Bugs-1525433 ] Quick Switch (Ctrl `) Inserts ` on MacOS

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

Bugs item #1525433, was opened at 2006-07-19 12:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1525433&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: UI: MacOS X-specific
Group: 2: Annoying
Status: Open
Resolution: None
Priority: 5
Submitted By: Mathias Ricken (mgricken)
Assigned to: Nobody/Anonymous (nobody)
Summary: Quick Switch (Ctrl `) Inserts ` on MacOS

Initial Comment:
The quick switch feature (Ctrl ` and Ctrl-Shift `)
inserts the ` character when I run it on the MacBook
with MacOS 10.4.7.

That character should not be inserted.

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

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

[DrJava] [ drjava-Feature Requests-1523170 ] Line/Word Wrapping in Definitions Pane

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

Feature Requests item #1523170, was opened at 2006-07-15 16:09
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=1523170&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: Definitions (source editor)
Group: Medium (< 1 pair-month)
Status: Open
Priority: 5
Submitted By: Moez A. Abdel-Gawad (moez)
Assigned to: Nobody/Anonymous (nobody)
Summary: Line/Word Wrapping in Definitions Pane

Initial Comment:
When opening files with deeply nested code (and urls 
in comments) the text of a Java program can easily go 
beyond view limits.

Supporting line wrapping in the definitions pane of 
DrJava would make viewing that code easier.

An easy conceptual model of line wrapping is to think 
of them as making the code be a 3-dimensional entity, 
rather than the 2-dimensional one. Code, stored 
typically in a file, is 1-dimensional (can be accessed 
using 1 number: byteoffset). "Newline" characters make 
it 2-dimensional (characters accessed using line 
number and column). "Long" lines (with length longer 
the user-defined limit, say 80) make it 3D. This third-
dimension would be used only for display purposes. The 
compiler does need to be aware of it. It also changes 
dynamically according to the width of the current 
user's view width, and can be disabled/enabled.

(Getting this to work with the earlier feature I 
requested (Collapse/Expand Code) may be challenging, 
so probably both would be allowed at the same time).

TextPad, and many text editors, offer a similar 
capability for the sort of line wrapping I'm looking 
for in DrJava.

(This is somewhat similar to, but more general than, 
feature request #1008787)

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

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

[DrJava] [ drjava-Feature Requests-1523166 ] Collase/Expand Classes Members and Methods Code

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

Feature Requests item #1523166, was opened at 2006-07-15 15:56
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=1523166&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: User interface
Group: Medium (< 1 pair-month)
Status: Open
Priority: 5
Submitted By: Moez A. Abdel-Gawad (moez)
Assigned to: Nobody/Anonymous (nobody)
Summary: Collase/Expand Classes Members and Methods Code

Initial Comment:
When looking at a large Java file, I'd like to see a 
summary of the whole file in one screen, while having 
a piece of code of interest in full view.

Adding the ability to collapse/expand classes and 
methods (top-level ones at least) would be very close 
to what I need. A collapsed class/method would only 
display its name (and signature for methods) while 
hiding details like fields and methods, for classes, 
and code and local variables for methods, while 
keeping the rest of code in the Java file in its 
original collapsed or uncollapsed form.

A tree (or forest) view of the file (only 2 levels 
deep) would be enough for most practical purposes. 
JSwat, a Java debugger, is a good example. It presents 
very similar functionality to the one I am looking for 
in DrJava.

(This is similar to feature request #1366157)

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

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

[DrJava] [ drjava-Feature Requests-1518709 ] Interface to open files into an existing DrJava instance.

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

Feature Requests item #1518709, was opened at 2006-07-07 05:46
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=1518709&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: User interface
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interface to open files into an existing DrJava instance.

Initial Comment:
I use the Windows compiled executable of DrJava, but
this should presumably apply to the .jar file as well.
There should be a way to open the files passed to the
.jar file (and, hence, to the Windows executable)
preferentially in an existing running instance of DrJava.

If that didn't make sense, let me try a different
method of explanation.

How it works now: You double-click a .java file, it
opens an instance of DrJava, which in turn opens the
file. Fine. But now suppose you double-click a new
.java file; then it opens a second instance of DrJava,
which in turn opens the file.

How it should work: You double click a .java file. It
gets sent to an intermediary application/method that
checks whether an instance of DrJava is running
already. If one isn't, then it opens a new instance of
DrJava, which can then open the file. If one is, then
it tells the preexisting instance of DrJava to open the
file.

This is a rather standard functionality for Windows
programs, but I don't know how you'd implement it in a
Java program. Separate instances of the JVM, as far as
I know, don't know about each other and each other's
components in Java.

Submitted by Chris Drost
http://kentox.livejournal.com/
cr...@co...

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

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

[DrJava] [ drjava-Bugs-1511641 ] working directory not quite right yet

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

Bugs item #1511641, was opened at 2006-06-23 18:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1511641&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: User interface
Group: 3: Ugly
Status: Open
Resolution: None
Priority: 5
Submitted By: hperkins (hperkins)
Assigned to: Nobody/Anonymous (nobody)
Summary: working directory not quite right yet

Initial Comment:
The working directory setting in the latest beta still
is a bit confusing.  If I have a file named, say,
test.txt in the same directory as my main Java program
and the program opens the file using "new Scanner(new
File("test.txt"))", this will almost always work. 
However, this can fail if I run the program immediately
after opening it, because the default working directory
is the folder containing DrJava, not the one containing
the main program.  If the main program is simply
recompiled, things now work because running the
compiler resets the working directory.

There's too much of a surprise here.  If I've got a
program that is able to successfully open files, then
it ought to behave the same if I quit DrJava, restart
it, open the same main program file, and run it again.

Setup: DrJava beta 20060610-0349, latest Java 5, both
Windows XP and OS X.

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

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

[DrJava] [ drjava-Bugs-1511630 ] Java 6 compiler not found

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

Bugs item #1511630, was opened at 2006-06-23 17:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1511630&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: Compiler integration
Group: 3: Ugly
Status: Open
Resolution: None
Priority: 5
Submitted By: hperkins (hperkins)
Assigned to: Nobody/Anonymous (nobody)
Summary: Java 6 compiler not found

Initial Comment:
I installed Java 6 beta 2 on top of Java 5 (1.5.0_07)
on a windows XP box.  When I launch DrJava after that,
the compiler output tab says "no compiler available",
as does the compiler popup menu at the bottom right of
the screen.  I can't find any way to select the 6.0
compiler or to revert to 5.0.  It ought to at least be
possible to select Java 5 if it is installed,
particularly to advise over-eager students who install
the Java 6 beta and then can't get DrJava to work.

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

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

[DrJava] [ drjava-Bugs-1510943 ] Horizontal Scroll Bar disappears in Definitions Pane

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

Bugs item #1510943, was opened at 2006-06-22 21:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1510943&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Cartwright (rcartwright)
Assigned to: Nobody/Anonymous (nobody)
Summary: Horizontal Scroll Bar disappears in Definitions Pane

Initial Comment:
If you open the attached file in a Definitions Pane
that is too narrow to display the two wides lines in
this file, a horizontal scroll bar appears.  If you
insert a newline (<Enter>) before MockFilterChain on
the first line, splitting the line, the horizontal
scroll bar disappears even though the third line of the
original file (now the fourth line) still spills over
the end of the screen.

This bug was communicated to me by Michael Jensen.

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

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

[DrJava] [ drjava-Feature Requests-1506832 ] Interactions commands

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

Feature Requests item #1506832, was opened at 2006-06-15 11:15
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=1506832&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: Interactions
Group: None
Status: Open
Priority: 5
Submitted By: Dan McCuaig (dmccuaig)
Assigned to: Nobody/Anonymous (nobody)
Summary: Interactions commands

Initial Comment:
Possibly add some more O/S like interaction commands:

pwd - print working directory
cd [path] - change working directory to new path
shell [path] - open a shell window to either the
working directory, or an optional path

Some other possibilities:

javac file - compile java file
exec path - run an OS command

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

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

[DrJava] [ drjava-Bugs-1505569 ] "Clean Build Directory" breaks "Compile"

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

Bugs item #1505569, was opened at 2006-06-13 13:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1505569&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: None
Status: Open
Resolution: None
Priority: 9
Submitted By: Dan Smith (dlsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Clean Build Directory" breaks "Compile"

Initial Comment:
When "Clean Build Directory" is invoked, the build directory (not just its 
contents) is deleted.  That's fine -- I think I prefer it, in fact.  But then 
when I attempt to compile, the compiler generates strange errors that 
stem from the fact that the build directory doesn't exist.

I'd like to have the build directory be created immediately before 
compilation.  If that change is made, there are other things that may 
assume that the build directory always exists that should be modified as 
well -- "Project Properties", for example, doesn't allow the build directory 
to be set to a nonexistent directory (touching the text box after a clean, 
then, generates an error message); jarring and testing may make similar 
assumptions.


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

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

[DrJava] [ drjava-Bugs-1505566 ] Build directory text box value changes on error

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

Bugs item #1505566, was opened at 2006-06-13 13:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1505566&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: User interface
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Smith (dlsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build directory text box value changes on error

Initial Comment:
If the "Build Directory" in the "Project Properties" dialog is empty, and an 
error occurs in an attempt to set it (for example, typing "fdasf" into the 
box, then tabbing out of it), the value of the text box is changed to the 
default value.  If I hit "Cancel" and reopen the dialog, the text box is once 
again blank.  If I hit "OK" and reopen the dialog, the text box shows that 
the value has been explicitly set.

This isn't a serious error semantically, but it's ugly from a user interface 
standpoint.  There's *is* real difference between the value being set to 
[default] and the value being set to [the current value of default] -- once 
the default value changes, that difference becomes evident.


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

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

[DrJava] [ drjava-Bugs-1505560 ] Inconsistent use of project root in classpath

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

Bugs item #1505560, was opened at 2006-06-13 12:57
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1505560&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: None
Status: Open
Resolution: None
Priority: 9
Submitted By: Dan Smith (dlsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inconsistent use of project root in classpath

Initial Comment:
To reproduce:

- Create a new project Proj.  Set the working directory and the project 
root to some directory Proj.
- Create a new file "SomeClass.java".  Define it in package "pkg".  Save it 
in location "Proj/src/pkg".
- Compile.  Compilation succeeds.
- Type "SomeClass c" in the interactions.  An "Undefined class" error 
occurs.  The interactions classpath contains "Proj", but not "Proj/src".

I don't know if the intended behavior is to allow the source root to be a 
subdirectory of the root (as is done during compilation), or to force it to 
be the same (as is done in the interactions pane).  But that choice should 
be consistent.

Other operations that depend on a classpath (like Javadoc) should be 
made consistent as well.


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

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

[DrJava] [ drjava-Bugs-1505515 ] Javadoc with long classpaths

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

Bugs item #1505515, was opened at 2006-06-13 10:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1505515&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: Javadoc integration
Group: 4: Serious
Status: Open
Resolution: None
Priority: 5
Submitted By: R. Matt Barnett (rmbarnett)
Assigned to: Nobody/Anonymous (nobody)
Summary: Javadoc with long classpaths

Initial Comment:
When trying to preview javadoc:

1 error found:
File: (no associated file)  [line: (no source location)]
Error: CreateProcess: "C:\Program
Files\Java\j2re1.4.2_08\bin\javaw.exe" -classpath
"C:\Ariba\app\Buyer\Server\classes\extensions\extensions;C:\java\unstable;C:\Program
Files\Research In Motion\BlackBerry JDE
4.0.2\bin\com\coair\applications\geconsole\model;C:\Program
Files\Research In Motion\BlackBerry JDE
4.0.2\bin;C:\Program
Files\Cup;C:\Ariba\app\ACM\Server\classes\xt.jar;C:\Ariba\app\ACM\Server\classes\xsltc.jar;C:\Ariba\app\ACM\Server\classes\xp.jar;C:\Ariba\app\ACM\Server\classes\xmlsec.jar;C:\Ariba\app\ACM\Server\classes\wsdl4j.jar;C:\Ariba\app\ACM\Server\classes\US_export_policy.jar;C:\Ariba\app\ACM\Server\classes\tools.jar;C:\Ariba\app\ACM\Server\classes\sunjce_provider.jar;C:\Ariba\app\ACM\Server\classes\soap.jar;C:\Ariba\app\ACM\Server\classes\sax.jar;C:\Ariba\app\ACM\Server\classes\saaj.jar;C:\Ariba\app\ACM\Server\classes\mpxj.jar;C:\Ariba\app\ACM\Server\classes\mcharts.jar;C:\Ariba\app\ACM\Server\classes\mail.jar;C:\Ariba\app\ACM\Server\classes\log4j-1.2.8.jar;C:\Ariba\app\ACM\Server\classes\local_poli”

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

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

[DrJava] [ drjava-Bugs-1504830 ] JUnit Classes not Tested

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

Bugs item #1504830, was opened at 2006-06-12 09:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1504830&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: JUnit integration
Group: 4: Serious
Status: Open
Resolution: None
Priority: 5
Submitted By: R. Matt Barnett (rmbarnett)
Assigned to: Nobody/Anonymous (nobody)
Summary: JUnit Classes not Tested

Initial Comment:
I am running into a recurring problem when creating new
JUnit tests from the DrJava file menu.  Why I try to
test the class with the test button, I am informed that
no JUnit tests are open / compiled (even though they
are test cases and are compiled).  Normally this means
that the package statement does not follow the files
system structure (which really should have a different
error message) but in all these cases the structure is
correct, and I am also able to manually invoke the test
methods from the interactions pane.  I can also confirm
that these "untestable" test cases test fine when
invoked by ant.

Sometimes the problem can be resolved by doing a "Save
As" and renaming the class (leaving all other aspects
of the class unchanged).  Sometimes not.

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

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

[DrJava] [ drjava-Bugs-1504827 ] "getenv no longer supported, use prop"

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

Bugs item #1504827, was opened at 2006-06-12 09:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1504827&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: Other
Group: 6: Crashes
Status: Open
Resolution: None
Priority: 5
Submitted By: R. Matt Barnett (rmbarnett)
Assigned to: Nobody/Anonymous (nobody)
Summary: "getenv no longer supported, use prop"

Initial Comment:
C:\Documents and Settings\g9053\Desktop>java -jar
drjava-beta-20060510-2133.jar
Exception in thread "main" java.lang.Error: getenv no
longer supported, use prop
erties and -D instead: ProgramFiles
        at java.lang.System.getenv(Unknown Source)
        at
edu.rice.cs.util.classloader.ToolsJarClassLoader.getToolsJarFiles(Too
lsJarClassLoader.java:71)
        at
edu.rice.cs.util.classloader.ToolsJarClassLoader.getToolsJarURLs(Tool
sJarClassLoader.java:149)
        at
edu.rice.cs.util.classloader.ToolsJarClassLoader.<init>(ToolsJarClass
Loader.java:54)
        at
edu.rice.cs.drjava.DrJava.<clinit>(DrJava.java:95)

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

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

[DrJava] [ drjava-Feature Requests-1504566 ] "Find Again" for "Find All"

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

Feature Requests item #1504566, was opened at 2006-06-11 22:47
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=1504566&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: Definitions (source editor)
Group: None
Status: Open
Priority: 5
Submitted By: Mathias Ricken (mgricken)
Assigned to: Nobody/Anonymous (nobody)
Summary: "Find Again" for "Find All"

Initial Comment:
There should be a "Find Again" button on the right of
the a "Find: xxx" tab (the tab that contains the "Find
All" results). When pressed, the "Find Again" button
runs the search with exactly the same settings again
and updates the contents of the pane.

For this to happen a "Find: xxx" tab would have to
store the settings of the "Find/Replace" panel at the
time the original "Find All" operation was done.

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

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

[DrJava] [ drjava-Bugs-1501897 ] Running program in debug mode resets interactions

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

Bugs item #1501897, was opened at 2006-06-06 14:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1501897&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: User interface
Group: 1: Would be nice if fixed ...
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan McCuaig (dmccuaig)
Assigned to: Nobody/Anonymous (nobody)
Summary: Running program in debug mode resets interactions

Initial Comment:
When in debug mode, if the user clicks the Run button
or presses F2, interactions are reset and debug mode is
exited.

The program then runs outside of debug mode.

If the user runs the program from the interactions pane

ex:

> java MyProg

then this does not happen.


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

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

[DrJava] [ drjava-Bugs-1501227 ] Reloading file upsets Find all panel

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

Bugs item #1501227, was opened at 2006-06-05 15:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=438935&aid=1501227&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: Definitions (source editor)
Group: 1: Would be nice if fixed ...
Status: Open
Resolution: None
Priority: 2
Submitted By: bjwhitfield (bjwhitfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reloading file upsets Find all panel

Initial Comment:
This bug occurs whenever a file is reloaded from disk
that contains the string that was searched for within a
find all panel that is still open.

1) Highlighting within the file is cleared (which is to
be expected)

2) Each entry in the findall listing changes to list
the first line of the document as one of the search results

3) If a number of matches were returned within the
file, swing can display the listing inconsistently.

This is more of an aesthetic problem since it's only
natural that this would put the search results in an
inconsistent state.  Perhaps upon a documents change
the file can be searched again or omitted from the list.

DrJava Version : 20060605-0408

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

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