Supported Cedet Versions?

[Paul Kinnucan]

Hi,

I need to update the JDEE's CEDET version checking constants.
Meanwhile, you can work around the problem by customizing
jde-check-version-flag off. AFIK, the JDEE is compatible with
the latest version of CEDET.

Paul

exits funnel writes:
 > Hello,
 > 
 > In an effort to straighten out some problems which I
 > thought were related to semantic I just upgraded to
 > 1.0pre3 and modified my .emacs appropriately.  When I
 > open a java buffer, jde complains thusly:
 > 
 > "JDEE requires a version of CEDET between 1.0beta2 and
 > 1.0 (found 1.0pre3)"
 > 
 > I'm running jde version 2.3.5.  Is this expected? 
 > Should I back out the CEDET pre release or is there
 > some other problem?  Thanks in advance to anyone who
 > can set me straight.
 > 
 > -exits
 > 
 > 
 >  
 > __ 
 > Yahoo! Mail 
 > Stay connected, organized, and protected. Take the tour: 
 > http://tour.mail.yahoo.com/mailtour.html 
 > 

Java 1.5 Generics and Javadoc

[Paul Kinnucan]

Bill Rushmore writes:
 > --text follows this line--
 > 
 > Please enter the details of your bug report here
 > 
 > The JDEE Javadoc tool does not work on method signatures with Java 
 > 1.5 generics (i.e. List).
 > 
 > 

Hi Bill,

Thanks for reporting this problem. I plan to address this and other
problems that people have reported after I finish restructuring the
JDEE's JDEbug and jdb interfaces. I've made a lot of progress on this 
effort and expect to finish it within the next two months at which
point I will release a beta of the next JDEE release.

Paul

 > Emacs  : GNU Emacs 22.0.50.1 (sparc-sun-solaris2.10, X toolkit, Xaw3d 
 > scroll bars)
 >   of 2005-07-23 on hornet
 > Package: JDE version 2.3.5
 > Required packages: cedet-1.0beta3
 > 
 > 
 > current state:
 > ==
 > (setq
 >   jde-gen-session-bean-template '("(jde-import-insert-imports-into-buffer " 
 > "  (list \"javax.ejb.*\""
 >   "\"java.rmi.RemoteException\"))" 
 > "'>"
 >   "(jde-wiz-update-implements-clause 
 > \"SessionBean\")" "'>"
 >   "(jde-gen-method-signature" " 
 > \"public\"" "  \"void\""
 >   "  \"ejbActivate\"" "  nil" " 
 > \"RemoteException\"" " )" "'>"
 >   "(if jde-gen-k&r " " ()" " 'n)" 
 > "\"{\"'>'n" "\"}\"'>'n 'n"
 >   "(jde-gen-method-signature" " 
 > \"public\"" "  \"void\""
 >   "  \"ejbPassivate\"" "  nil" " 
 > \"RemoteException\"" " )" "'>"
 >   "(if jde-gen-k&r " " ()" " 'n)" 
 > "\"{\"'>'n" "\"}\"'>'n 'n"
 >   "(jde-gen-method-signature" " 
 > \"public\"" "  \"void\"" "  \"ejbRemove\""
 >   "  nil" "  \"RemoteException\"" " )" "'>" 
 > "(if jde-gen-k&r " " ()" " 'n)"
 >   "\"{\"'>'n" "\"}\"'>'n 'n" 
 > "(jde-gen-method-signature" "  \"public\""
 >   "  \"void\"" "  \"setSessionContext\"" " 
 > \"SessionContext ctx\""
 >   "  \"RemoteException\"" " )" "'>" "(if 
 > jde-gen-k&r " " ()" " 'n)"
 >   "\"{\"'>'n" "\"}\"'>'n 'n" 
 > "(jde-gen-method-signature" "  \"public\""
 >   "  \"void\"" "  \"unsetSessionContext\"" 
 > "  nil" "  \"RemoteException\""
 >   " )" "'>" "(if jde-gen-k&r " " ()" " 'n)" 
 > "\"{\"'>'n" "\"}\"'>'n 'n" "'>")
 >   jde-gen-beep '("(end-of-line) '&" 
 > "\"Toolkit.getDefaultToolkit().beep();\"'>'n'>")
 >   jde-complete-signature-display '("Eldoc")
 >   jde-gen-equals-parens-around-expression nil
 >   jde-project-name "default"
 >   jde-which-method-format '("[" jde-which-method-current "]")
 >   jde-run-classic-mode-vm nil
 >   jde-complete-unique-method-names nil
 >   jde-find-granularity '("Character")
 >   jde-which-method-max-length 20
 >   jde-javadoc-gen-nodeprecatedlist nil
 >   jde-imenu-include-classdef t
 >   jde-javadoc-gen-link-online nil
 >   jde-complete-display-result-type

RE: max-lisp-eval-depth error when click java menu in jde-mode

[Paul Kinnucan]

Baoliang Liu writes:
 > I noticed you have sent me a responding email but it is blank. I don't know 
 > if it is left blank intentionally. 

No. I didn't realize that I replied.

 > 
 > The problem is still exists, I redescribe my problem below:
 > 
 > My GNU¡emacs version 22.0.51.1 (i386-mingw-nt5.1.2600)£I directly compiled 
 > the emacs source from cvs with MinGW3.1.

I do not try to keep the JDEE up-to-date with development versions of Emacs. 
The latest version of the JDE was developed against Emacs 21.3.1. It is not 
guaranteed to work against any later versions of Emacs.

 >  
 > I installed elib from jde web site and cedet 1.0beta3b and jdt-latest.zp for 
 > windows, I noticed that other version of cedet couldn't work with jde on my 
 > emacs. I use Windows XP sp2.
 > 
 > When emacs startup, there are warnings as below:
 >  Note, built-in variable `x-use-old-gtk-file-dialog' not bound
 >  Note, built-in variable `x-use-underline-position-properties' not bound
 >  jde-java-font-lock: building names cache...empty
 >  
 > I installed jde according to the installation guide. When I open java source 
 > file, there are only jde and java menu, no JMaker, Senator and jdb menu
 >  
 > When I click jde or java menu, the following error occurs:
 >  Debugger entered--Lisp error: (error "Lisp nesting exceeds 
 > max-lisp-eval-depth")
 >  (fboundp (quote ange-ftp-ftp-name))
 >  (and (fboundp (quote ange-ftp-ftp-name)) (ange-ftp-ftp-name dir))
 >  (cond ((and ... ...) (ange-ftp-get-file-entry parent)) ((eq system-type 
 > ...) (or ... ... ...)) ((member system-type ...) (or ... ... ... ... ...)) 
 > (t (or ... ...)))
 >  (let ((parent ...)) (cond (... ...) (... ...) (... ...) (t ...)))
 >  jde-root-dir-p("d:/")
 >  (not (jde-root-dir-p dir))
 >  (if (not (jde-root-dir-p dir)) (jde-find-project-file (expand-file-name 
 > ".." dir)))
 >  (if file (expand-file-name file dir) (if (not ...) 
 > (jde-find-project-file ...)))
 >  (let* ((directory-sep-char 47) (file ...)) (if file (expand-file-name 
 > file dir) (if ... ...)))
 >  jde-find-project-file("d:/")
 >  (if (not (jde-root-dir-p dir)) (jde-find-project-file (expand-file-name 
 > ".." dir)))
 >  (if file (expand-file-name file dir) (if (not ...) 
 > (jde-find-project-file ...)))
 >  (let* ((directory-sep-char 47) (file ...)) (if file (expand-file-name 
 > file dir) (if ... ...)))
 >  jde-find-project-file("d:/")

It appears that the version of Emacs that you are using
breaks the code used by JDEE to search for a project
file. The search algorithm starts the search from the
directory containing the source file and proceeds
recursively up to the directory's root. The algorithm uses
some special case handling to handle the cases where the
root may be on a network file system. If the root detection
fails, the root search recurses endlessly, producing the
error that you see. 

I am spending my time at the moment restructuring the JDEE's
debugger interface. I have put all other work on hold until
I complete this task. Thus, I won't have time to investigate
this or other compatibility problems until I finish the debugger
interface updates.

Meanwhile, I suggest that you either revert to an earlier, compatible
version of Emacs or try to fix the recursion problem yourself. If you
do find a fix, please submit it to the JDEE list and I will include
it in the sources.

Paul

 > 
 > Best Regards
 > -Baoliang 
 > -Original Message-
 > From: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
 > Sent: Tuesday, June 14, 2005 10:55 PM
 > To: Baoliang Liu
 > Subject: max-lisp-eval-depth error when click java menu in jde-mode
 > 
 > 
 > 

Re: Turning off the style check for tabs

[Paul Kinnucan]

Charles Curley writes:
 > On Thu, Jun 09, 2005 at 01:19:30PM -0400, Ed Mooney wrote:
 > > I don't know. This may be relevant:
 > > 
 > >   ^H v indent-tabs-mode
 > 
 > Found that. Right now I have it set to nil (meaning no tabs, spaces
 > only, the preferred style). The problem is the client wants tabs. So
 > I'd like to be able to use tabs & not have the style checker complain
 > about them.

Hi Charles,

The JDEE is set up to use the Sun coding style by
default. The Sun coding style frowns on the use of tab
characters in Java source files. The JDEE provides a set of
customization options that allow you to specify any coding
style that you want. To use these options intelligently, you
need to know how CheckStyle works. See the doc for
CheckStyle, which is available at
http://checkstyle.sourceforge.net.

A way to do what you want would be to copy the sun_checks.xml
configuration file in the JDEE's JDEROOT/java/lib directory
to a location of your choosing, rename it to something like
my_checks.xml, and delete the line



from the copy. In effect, you've created your own custom style
that differs from the Sun style only in that you allow tabs
in source code. Finally, you should customize the jde_checkstyle_style
variable to point to my_checks.xml

Paul

 > 
 > Thanks
 > 
 > -- 
 > 
 > Charles Curley  /"\ASCII Ribbon Campaign
 > Looking for fine software   \ /Respect for open standards
 > and/or writing?  X No HTML/RTF in email
 > http://www.charlescurley.com/ \No M$ Word docs in email
 > 
 > Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB

Re: cygwin emacs path problem

[Paul Kinnucan]

Hi Ed,

I think the version of Emacs that I've been calling the A
version is actually the cygwin version of XEmacs. Thus,
the support in the JDEE for cygwin versions of Emacs is
actually geared to the cygwin version of XEmacs. This would
explain the difficulty that people are having with trying to use
the JDEE with the cygwin version of Emacs.

It's been a long time since I've dealt with this issue and
my memory is obviously fuzzy. Anyway, the bottom line is
the same. The current JDEE cygwin support was not designed
for the current cygwin version of Emacs and hence it would
not be surprising if it does not fully support it.

Paul



Paul Kinnucan writes:
 > Ed Mooney writes:
 >  > Now I'm confused. Is the version of emacs[1] you can install by running 
 >  > http://cygwin.com/setup.exe "A" or "B"? I had thought it was "A". If 
 >  > not, where can I get "A"?
 > 
 > Hi Ed,
 > 
 > I thought A was still available. My knowledge is very hazy
 > on cygwin as my own dealings with it were only to test out
 > changes to the JDEE intended to support it. Perhaps B
 > replaced A. Anyway, I believe A was developed before Cygwin
 > supported X Windows and thus included source changes to use
 > the native Windows GUI. I believe B was made possible by the
 > porting of X Windows to Cygwin. This enables Cygwin to
 > support a binary compiled directly from the Unix sources for
 > Emacs, without any Windows-specific modifications. I don't
 > know if the JDEE takes advantage of any A modifications that
 > are missing from the B version. It would help if anyone can
 > shed any light on this question as this would enable me to
 > determine how much work would be needed to enhance the JDEE
 > to support the B version.
 > 
 > Paul
 > 
 > 
 >  > 
 >  >-- Ed
 >  > 
 >  > [1] E.g.: http://mirrors.rcn.net/pub/sourceware/cygwin/release/emacs/
 >  > 
 >  > Jason Rumney wrote:
 >  > > Paul Kinnucan wrote:
 >  > > 
 >  > >> Hi Felix,
 >  > >>
 >  > >> As I understand it, there are two versions of "cygwin emacs":
 >  > >>
 >  > >>  (A) a version of Unix Emacs modified specifically to run in the  
 >  > >> Cygwin environment and
 >  > >>  (B) the standard Unix version of Emacs compiled, using cygwin
 >  > >>  gcc, to run in the Cygwin environment
 >  > >>
 >  > >>
 >  > >> JDEE supports the A version. It does not support the B
 >  > >> version.  The reason for this is that years ago, long
 >  > >> before the B-version existed, some JDEE users asked for A
 >  > >> version support and some of those users actually contributed
 >  > >> code necessary to support the A version. Meanwhile, until
 >  > >> now, there has been no demand for B-version support.
 >  > >>  
 >  > >>
 >  > > Really this is a cygwin problem. A cygwin version of Emacs needs to be 
 >  > > modified to fit its environment, as the 'A' version was. I'm not sure 
 >  > > what happened to those patches, but it is unreasonable of the Cygwin 
 >  > > maintainers to expect the maintainers of every other package to make 
 >  > > changes to accomodate Cygwin's lack of fitting in with its environment 
 >  > > so that they themselves can use unmodified code targetted at GNU/Linux.
 >  > > 
 >  > > 
 >  > 
 > 

Re: cygwin emacs path problem

[Paul Kinnucan]

Chris McMahan writes:
 > 
 > Cygwin has a version of emacs available that will run in console when
 > running the XP window manager, or run in GUI under an X environment
 > (which also comes with Cygwin). Whether GUI or console, the issues
 > with path interactions with XP remain.
 > 
 > The native XP version of Emacs does not need Cygwin to run, but it is
 > very helpful to have it installed. This provides the use of various
 > tools such as grep, ls, find and such that makes Emacs a happy camper
 > to play with.

I use the native XP version of Emacs with the Cygwin tools. This is 
the setup that I would recommend to other JDEE users for the following
reason. Both the native XP version of Emacs and the Cygwin tools understand
Windows paths. The Cygin version of Emacs on the other hand does not
understand Windows paths. This complicates the JDEE's handling of paths.


Paul 


 > 
 > I hope this helps a little to clarify.
 > 
 > - Chris McMahan
 > 
 > 
 > 
 > Paul Kinnucan writes:
 > >Ed Mooney writes:
 > > > Now I'm confused. Is the version of emacs[1] you can install by running 
 > > > http://cygwin.com/setup.exe "A" or "B"? I had thought it was "A". If 
 > > > not, where can I get "A"?
 > >
 > >Hi Ed,
 > >
 > >I thought A was still available. My knowledge is very hazy
 > >on cygwin as my own dealings with it were only to test out
 > >changes to the JDEE intended to support it. Perhaps B
 > >replaced A. Anyway, I believe A was developed before Cygwin
 > >supported X Windows and thus included source changes to use
 > >the native Windows GUI. I believe B was made possible by the
 > >porting of X Windows to Cygwin. This enables Cygwin to
 > >support a binary compiled directly from the Unix sources for
 > >Emacs, without any Windows-specific modifications. I don't
 > >know if the JDEE takes advantage of any A modifications that
 > >are missing from the B version. It would help if anyone can
 > >shed any light on this question as this would enable me to
 > >determine how much work would be needed to enhance the JDEE
 > >to support the B version.
 > >
 > >Paul
 > >
 > >
 > > > 
 > > >-- Ed
 > > > 
 > > > [1] E.g.: http://mirrors.rcn.net/pub/sourceware/cygwin/release/emacs/
 > > > 
 > > > Jason Rumney wrote:
 > > > > Paul Kinnucan wrote:
 > > > > 
 > > > >> Hi Felix,
 > > > >>
 > > > >> As I understand it, there are two versions of "cygwin emacs":
 > > > >>
 > > > >>  (A) a version of Unix Emacs modified specifically to run in the  
 > > > >> Cygwin environment and
 > > > >>  (B) the standard Unix version of Emacs compiled, using cygwin
 > > > >>  gcc, to run in the Cygwin environment
 > > > >>
 > > > >>
 > > > >> JDEE supports the A version. It does not support the B
 > > > >> version.  The reason for this is that years ago, long
 > > > >> before the B-version existed, some JDEE users asked for A
 > > > >> version support and some of those users actually contributed
 > > > >> code necessary to support the A version. Meanwhile, until
 > > > >> now, there has been no demand for B-version support.
 > > > >>  
 > > > >>
 > > > > Really this is a cygwin problem. A cygwin version of Emacs needs to be 
 > > > > modified to fit its environment, as the 'A' version was. I'm not sure 
 > > > > what happened to those patches, but it is unreasonable of the Cygwin 
 > > > > maintainers to expect the maintainers of every other package to make 
 > > > > changes to accomodate Cygwin's lack of fitting in with its environment 
 > > > > so that they themselves can use unmodified code targetted at GNU/Linux.
 > > > > 
 > > > > 
 > > > 
 > 
 > -- 
 > 
 > Chris McMahan | [EMAIL PROTECTED]
 > 
 > 

Re: cygwin emacs path problem

[Paul Kinnucan]

Ed Mooney writes:
 > Now I'm confused. Is the version of emacs[1] you can install by running 
 > http://cygwin.com/setup.exe "A" or "B"? I had thought it was "A". If 
 > not, where can I get "A"?

Hi Ed,

I thought A was still available. My knowledge is very hazy
on cygwin as my own dealings with it were only to test out
changes to the JDEE intended to support it. Perhaps B
replaced A. Anyway, I believe A was developed before Cygwin
supported X Windows and thus included source changes to use
the native Windows GUI. I believe B was made possible by the
porting of X Windows to Cygwin. This enables Cygwin to
support a binary compiled directly from the Unix sources for
Emacs, without any Windows-specific modifications. I don't
know if the JDEE takes advantage of any A modifications that
are missing from the B version. It would help if anyone can
shed any light on this question as this would enable me to
determine how much work would be needed to enhance the JDEE
to support the B version.

Paul


 > 
 >-- Ed
 > 
 > [1] E.g.: http://mirrors.rcn.net/pub/sourceware/cygwin/release/emacs/
 > 
 > Jason Rumney wrote:
 > > Paul Kinnucan wrote:
 > > 
 > >> Hi Felix,
 > >>
 > >> As I understand it, there are two versions of "cygwin emacs":
 > >>
 > >>  (A) a version of Unix Emacs modified specifically to run in the  
 > >> Cygwin environment and
 > >>  (B) the standard Unix version of Emacs compiled, using cygwin
 > >>  gcc, to run in the Cygwin environment
 > >>
 > >>
 > >> JDEE supports the A version. It does not support the B
 > >> version.  The reason for this is that years ago, long
 > >> before the B-version existed, some JDEE users asked for A
 > >> version support and some of those users actually contributed
 > >> code necessary to support the A version. Meanwhile, until
 > >> now, there has been no demand for B-version support.
 > >>  
 > >>
 > > Really this is a cygwin problem. A cygwin version of Emacs needs to be 
 > > modified to fit its environment, as the 'A' version was. I'm not sure 
 > > what happened to those patches, but it is unreasonable of the Cygwin 
 > > maintainers to expect the maintainers of every other package to make 
 > > changes to accomodate Cygwin's lack of fitting in with its environment 
 > > so that they themselves can use unmodified code targetted at GNU/Linux.
 > > 
 > > 
 > 

cygwin emacs path problem

[Paul Kinnucan]

Hi Felix,

As I understand it, there are two versions of "cygwin emacs":

  (A) a version of Unix Emacs modified specifically to run in the 
  Cygwin environment and 

  (B) the standard Unix version of Emacs compiled, using cygwin
  gcc, to run in the Cygwin environment


JDEE supports the A version. It does not support the B
version.  The reason for this is that years ago, long
before the B-version existed, some JDEE users asked for A
version support and some of those users actually contributed
code necessary to support the A version. Meanwhile, until
now, there has been no demand for B-version support.

I'd be happy to support the B version. The main problem at
the moment is that I am in the midst of revamping the JDEE's
Lisp interface to JDEbug. To keep things simple, my
intention has been not to make another JDEE release until I
finish this project. Unfortunately, it is taking more time
than I anticipated and I have less time than I anticipated
so that the next release date is stretching out longer than
I anticipated, thus holding up many smaller but worthwhile
improvements.

Thus, to provide near-term support for the B version of cygwin
Emacs, I'd have to change my release plans, which would involve
branching the CVS tree for the JDEE to preserve my JDEbug-related
changes. I'm not entirely averse to doing this, but I'd have to
be convinced that the B-version of cygwin Emacs is such a signifant
improvement over the native Windows version as to make this
disruption worthwhile. After all, it's not as if people who
want to use Emacs to develop Java code on Windows don't have
alternatives, i.e., the native Windows version and version-A
of cygwin Emacs.

I believe that I installed the B-version about a year ago and
found it buggy and slow. Anway, I'll take another look at it
to try to see for myself why some of you find it attractive.

Paul

  


Felix Dorner writes:
 > Hi,
 > 
 > motivated by the ongoing cygwin thread I installed: cygwin, cygwin 
 > emacs, jde. The jde-bsh-run command now involves:
 > 
 > cd /home/Felix/
 > /cygdrive/c/java/jdk1.5.0_02/bin/java -classpath 
 > /home/Felix/emacs/jde-2.3.5/ja\
 > va/lib/bsh.jar;/home/Felix/emacs/jde-2.3.5/java/bsh-commands;/home/Felix/emacs/\
 > jde-2.3.5/java/lib/checkstyle-all.jar;/home/Felix/emacs/jde-2.3.5/java/lib/jaka\
 > rta-regexp.jar;/home/Felix/emacs/jde-2.3.5/java/lib/jde.jar;c:\java\jdk1.5.0_02\
 > \lib\tools.jar bsh.Interpreter
 > java.lang.NoClassDefFoundError: bsh/Interpreter
 > 
 > with bsh unable tu run, the jde compile server also fails, making the 
 > whole thing almost useless.
 > 
 > The java executable obviously cannot deal with those unix style 
 > pathnames. I did not find a real "guide" on setting up the jde with 
 > cygwin emacs, so I hope someone can help me here.
 > 
 > Thanks a lot,
 > 
 > Felix

Re: Java-1.5 font-lock support?

[Paul Kinnucan]

Troy Daniels writes:
 > At 05:29 PM 4/6/2005, jeff peck wrote:
 > 
 > >Is there a version of Java font-lock that supports Java-1.5?
 > >To so something reasonable with Generics and varargs (Object... args)
 > >and other 1.5-isms?
 > 
 > While we're discussing 1.5, any idea when Semantic will support it?
 > 

Hi Troy,

Semantic includes a grammar for 1.5 but the JDEE does not currently
use the grammar. I believe the grammar is also more complete. The previous
grammar stopped at the method level. The 1.5 grammar goes down to
the expression level. I vaguely recall trying the grammar with JDEE and
having some problem. This was months ago. I'll try it again ASAP
to see if I can get it to work with the JDEE.

Paul



 > Troy
 > 
 > Troy Daniels
 > [EMAIL PROTECTED]
 > 781-273-3388 x218
 > 

Problems setting up JDEBug

[Paul Kinnucan]

Hi Hans,

I can't see anything wrong with your setup. I will try to reproduce
the error on my version of Linux, which differs from yours. Meanwhile,
please try the JDEE's interface to jdb (see jde-debugger). It is more
robust than JDEbug at the moment.

Paul


Hans Olthof writes:
 > Hello,
 > I am failing to get JDEbug running on the following configuration:
 > Java jdk 1.5.0_01
 > GNU Emacs 21.4.1
 > OS SuSE 9.2
 > JDE: 2.3.5
 > 
 > I have carefully gone through the setup ( and numerous permutations) and 
 > have finished up that when I invoke "JDE/Debug App", I get the JDE Debug 
 > 'local variables' window up, then it just seems to hang,with no imediate 
 > message. emacs will hang for about 1 minute then be available for work.
 > It seems that I have not configured correctlly to actually connect to 
 > the vm or something.
 > 
 > The JDEbug buffer has the following output:
 > 
 > cd /mnt/data/projects/busan/src/org/ho/busan/
 > /usr/java/jdk/bin/java -classpath 
 > /usr/local/share/emacs/21.4/site-lisp/jde-2.3.5/java/lib/jde.jar:/usr/java/jdk/lib/tools.jar
 >  
 > jde.debugger.Main
 > 
 > 
 > (jde-dbo-init-debug-session)
 > JDE> -1 1 launch 1 -vmexec java -classpath 
 > /mnt/data/projects/busan/build/:/usr/java/junit/junit.jar:/usr/apache/commons-dbcp/commons-dbcp.jar:/usr/hsqldb/lib/hsqldb.jar:/usr/apache/commons-pool/commons-pool.jar:/usr/apache/commons-collections/commons-collections.jar
 >   
 > org.ho.busan.view.MainApp 
 > 
 > 
 > (jde-dbo-command-error 1 "Exception during command execution: 
 > jde.debugger.JDEException: INTERNAL ERROR: an attempt was made at 
 > deregistering a valid debugger. The debugger must be shut down first.")
 > __
 > 
 > 
 > here is my prj.el
 > ___
 > (jde-project-file-version "1.0")
 > (jde-set-variables
 >  '(jde-project-name "default")
 >  '(jde-global-classpath (quote ("/mnt/data/projects/busan/build/" 
 > "/usr/java/junit/junit.jar" "/usr/apache/commons-dbcp/commons-dbcp.jar" 
 > "/usr/hsqldb/lib/hsqldb.jar" "/usr/apache/commons-pool/commons-pool.jar" 
 > "/usr/apache/commons-collections/commons-collections.jar")))
 >  '(jde-compile-option-sourcepath (quote ("/mnt/data/projects/busan/src/")))
 >  '(jde-sourcepath (quote ("/mnt/data/projects/busan/src" 
 > "/usr/java/jdk/src"
 > 
 > 
 > Here is my .gnu-emacs-custom.el
 > 
 > __
 > ;;
 > ;; set debug
 > (setq debug-on-error t)
 > 
 > (add-to-list 'load-path (expand-file-name 
 > "/usr/local/share/emacs/21.4/site-lisp/jde-2.3.5/lisp"))
 > (add-to-list 'load-path (expand-file-name 
 > "/usr/local/share/emacs/21.4/site-lisp/cedet-1.0beta3b/common"))
 > (add-to-list 'load-path (expand-file-name 
 > "/usr/local/share/emacs/21.4/site-lisp/elib-1.0"))
 > (add-to-list 'load-path (expand-file-name 
 > "/usr/local/share/emacs/21.4/site-lisp/ecb-2.31"))
 > 
 > (load 
 > "/usr/local/share/emacs/21.4/site-lisp/nxml-mode-20041004/rng-auto.el")
 > ;;
 > ;; Initialise CEDET
 > ;;
 > (load-file 
 > "/usr/local/share/emacs/21.4/site-lisp/cedet-1.0beta3b/common/cedet.elc")
 > (require 'ecb)
 > ;;
 > ;; Initialise JDEE
 > ;;
 > (require 'jde)
 > ;;(require 'jde-junit)
 > ;;)
 > 
 > ;;
 > ;; set up to use nxml-mode on all .xml files
 > ;;
 > (setq auto-mode-alist
 > (cons '("\\.\\(xml\\|xsl\\|rng\\|xhtml\\|jdnc\\)\\'" . nxml-mode)
 >   auto-mode-alist))
 > 
 > ;;
 > (custom-set-variables
 >   ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!
 >   ;; Your init file should contain only one such instance.
 >  '(browse-url-netscape-program "/usr/share/firefox/firefox")
 >  '(case-fold-search t)
 >  '(ecb-source-path (quote (("/mnt/data/projects" "projects") 
 > ("/mnt/data/projects/busan" "busan") ("/mnt/data/projects/busan/src" 
 > "busan src"
 >  '(jde-debugger (quote ("JDEbug")))
 >  '(jde-global-classpath (quote ("/usr/java/jdk/lib/tools.jar" 
 > "/usr/java/jdk/jre/lib/" "/mnt/data/projects/busan/build/" 
 > "/usr/java/junit/junit.jar" "/usr/apache/commons-dbcp/commons-dbcp.jar" 
 > "/usr/hsqldb/lib/hsqldb.jar" "/usr/apache/commons-pool/commons-pool.jar" 
 > "/usr/apache/commons-collections/commons-collections.jar")))
 >  '(jde-jdk-registry (quote (("1.5.0_01" . "/usr/java/jdk"
 >  '(jde-run-classic-mode-vm t)
 >  '(jde-sourcepath (quote ("/mnt/data/projects/busan/src" 
 > "/usr/java/jdk/src")))
 >  '(mouse-wheel-mode t nil (mwheel)))
 > 
 > (custom-set-faces
 >   ;; custom-set-faces was added by Custom -- don't edit or cut/paste it!
 >   ;; Your init file should contain only one such instance.
 >  )
 > __
 > as you can see, quite minimal.
 > 
 > here is the LD_LIBRARY_PATH: bash: :/usr/java/jdk/jre/lib/i386
 > here is $PATH: bash: 
 > /usr/java/jdk/bin:/usr/java/jdk/jre/bin:/home/hans/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:
 > 
 > The Java jdk is installed in

jde

[Paul Kinnucan]

Hi Yigal,

I tried the "what's this" feature on the class that you sent me.
It works fine for me, i.e., when point is in a method, it displays
[M:methodName], when point is in class, [C:className], and when it
is outside a class [???]. This feature uses an Emacs hook function.
If an error occurs in any of the hook functions, Emacs stops
invoking the hook functions. This would cause the feature to 
appear to stop working.

Paul

Yigal Hochberg writes:
 > 
 > Paul,
 > 
 > I started to use your jde mode for Java development in emacs.  Thank
 > you for the excellent work.
 > 
 > I would like to display the current class and method on the mode-line
 > in [].
 > 
 > Some of the times it works ok, some other times it does not display
 > anything just [???] Even when the cursor is inside a method inside a
 > class.
 > 
 > Some of the times it displays only the method but not the class it is
 > in.
 > 
 > I use a very simple file to check this feature. See below.
 > 
 > Regards,
 > 
 > 
 > -- 
 > - Yigal
 > 
 > 
 > ===File ~/java/hello.java===
 > /* Last edit: Fri Mar 25 09:34:59 2005
 >  */
 > 
 > public class hello {
 > 
 > /**
 >  * main entry
 >  */
 > public static void main(String[] args) {
 > 
 > Throwable t = new Throwable();
 > 
 > StackTraceElement thisOne = t.getStackTrace()[0];
 > String myMethod = thisOne.getMethodName();
 > String myClass = thisOne.getClassName();
 > 
 > String s = "world";
 > String arg0 = "no-args";
 > if (args.length > 0)
 > arg0 = args[0];
 > 
 > int x;
 > x = 5;
 > System.out.println("args=" +arg0 +" hello " +s +" x=" +x);
 > System.out.println("class=" +myClass +" method=" +myMethod);
 > System.out.println(getCurrentMethodName() +"hello");
 > }
 > 
 > /**
 >  * Gets the name of the class and method that called this method to 
 > stdout
 >  * 
 >  * @return String the name of the class and method that called this 
 > method.
 >  */
 > public static String getCurrentMethodName() {
 > 
 > Throwable t = new Throwable();
 > StackTraceElement thisOne = t.getStackTrace()[1];
 > String myMethod = thisOne.getMethodName();
 > String myClass = thisOne.getClassName();
 > return myClass +"/" +myMethod +"():";
 > }
 > 
 > 
 > } // class hello
 > 
 > 
 > /*
 >  * Local Variables:
 >  * compile-command: "c:\\Progra~1\\Java\\jdk1.4.2_04\\bin\\javac -g 
 > hello.java"
 >  * End:
 >  */ // end hello()
 > 
 > 
 > 

Re: Debugging errors

[Paul Kinnucan]

Which debugger are you using?


Frankie Y. Liu writes:
 > Frankie Y. Liu  gmail.com> writes:
 > 
 > > 
 > > Hello I am getting the following errors when trying to debug-run
 > > 
 > > eieio-oref: Wrong type argument: (or object-p class-p), unbound
 > > 
 > > -frankie
 > > 
 > > 
 > 
 > 
 > Sorry I got the above fixed.  I have another problem which I don't 
 > understand.
 > I have a class C which is derived from class B which is derived from class A.
 > When I start debugging C.java, the compilation buffer goes away and A.java
 > shows up in its place pointing to the initialization of a member variable in
 > A.java, I don't have any breakpoints in A.java.  Why am I being taken there?
 > 
 > Thanks,
 > 
 > -frankie
 > 

Incompatible CEDET

[Paul Kinnucan]

Frankie Y. Liu writes:
 > I get some problems compiling jde-compile-jde:

Most of these warnings result from the JDEE's support for both
Emacs and XEmacs which each define symbols not defined by
the other. It's possible to eliminate the warnings by providing
empty definitions for the XEmacs-only symbols when compiling 
under Emacs and vice versa and I've done this for many but
not all symbols and will do this for more as time permits.
It's not a high priority task as it adds nothing in the
way of functionality or performance to the JDEE.

Paul



 > 
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/beanshell.el
 > at Mon Apr  4 13:17:05 2005
 > 
 > ^L
 > Compiling file 
 > /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/efc-xemacs.el
 > at Mon Apr  4 13:17:05 2005
 >   ** The following functions are not known to be defined:
 > make-dialog-box, make-glyph, event-channel, dialog-box-finish,
 > dialog-box-cancel
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/efc.el
 > at Mon Apr  4 13:17:05 2005
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-ant.el
 > at Mon Apr  4 13:17:05 2005
 > 
 > ^L
 > Compiling file 
 > /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-autoload.el
 > at Mon Apr  4 13:17:05 2005
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-bug.el
 > at Mon Apr  4 13:17:05 2005
 > 
 > ^L
 > Compiling file 
 > /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-checkstyle.el
 > at Mon Apr  4 13:17:06 2005
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-class.el
 > at Mon Apr  4 13:17:06 2005
 > 
 > ^L
 > Compiling file 
 > /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-compat.el
 > at Mon Apr  4 13:17:06 2005
 > 
 > ^L
 > Compiling file 
 > /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-compile.el
 > at Mon Apr  4 13:17:06 2005
 > 
 > ^L
 > Compiling file 
 > /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-complete.el
 > at Mon Apr  4 13:17:06 2005
 > 
 > ^L
 > Compiling file 
 > /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-custom.el
 > at Mon Apr  4 13:17:06 2005
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-db.el
 > at Mon Apr  4 13:17:06 2005
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-dbo.el
 > at Mon Apr  4 13:17:06 2005
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-dbs.el
 > at Mon Apr  4 13:17:06 2005
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-ejb.el
 > at Mon Apr  4 13:17:06 2005
 >   ** The following functions are not known to be defined:
 > tempo-template-java-ejb-remote-buffer-template,
 > tempo-template-java-ejb-home-buffer-template,
 > tempo-template-java-ejb-local-buffer-template,
 > tempo-template-java-ejb-local-home-buffer-template
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-gen.el
 > at Mon Apr  4 13:17:06 2005
 > 
 > While compiling jde-gen-get-package-statement:
 >   ** reference to free variable jde-package-unknown-package-name
 > 
 > While compiling the end of the data:
 >   ** The following functions are not known to be defined:
 > replace-in-string, jde-package-get-package-directory,
 > jde-package-convert-directory-to-package
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-help.el
 > at Mon Apr  4 13:17:07 2005
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-imenu.el
 > at Mon Apr  4 13:17:07 2005
 > 
 > ^L
 > Compiling file 
 > /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-import.el
 > at Mon Apr  4 13:17:07 2005
 > 
 > ^L
 > Compiling file 
 > /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-java-font-lock.el
 > at Mon Apr  4 13:17:07 2005
 > 
 > ^L
 > Compiling file 
 > /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-java-grammar.el
 > at Mon Apr  4 13:17:07 2005
 > While compiling jde-parse-semantic-default-setup:
 >   ** reference to free variable global-semantic-auto-parse-mode
 >   ** semantic-auto-parse-mode is an obsolete function; use
 >  semantic-idle-scheduler-mode instead.
 > 
 > ^L
 > Compiling file 
 > /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-javadoc-gen.el
 > at Mon Apr  4 13:17:07 2005
 > 
 > ^L
 > Compiling file 
 > /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-javadoc.el
 > at Mon Apr  4 13:17:07 2005
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-jdb.el
 > at Mon Apr  4 13:17:07 2005
 > 
 > ^L
 > Compiling file /home/fl155327/Dev/emacs/site-lisp/jde-2.3.5/lisp/jde-junit.el
 > at Mon Apr  4 13:17:07 2005
 > 
 > While compiling toplevel forms:
 >   ** assignment to free variable test-jde-junit
 >   ** The following functions are not known to be defined:
 > jde-junit-test-class-internal,
 > jde-juni

Font-lock mode on

[Paul Kinnucan]

Frankie Y. Liu writes:
 > I was wondering how to setup jde-mode font locking to look the same as
 > java-mode.
 > Basically my language primitives such as int, double, public, static,
 > import don't get
 > fontified at all in jde-mode, like they do in java-mode.

The JDEE fontifies these primitives for me. Lack of fontification
is often symptomatic of a setup error that causes jde-mode
to abort before fontification.

 > 
 > I am using the 21.3.1 and the latest versions CEDET and elib.
 > 
 > I also find that easymenu and mule-util get loded up when I switch to
 > jde-mode, are they necessary?

The JDEE uses easymenu extensively. I don't know where, if anywhere,
the JDEE uses mule-util.

Paul


 > 
 > Thanks,
 > 
 > -frankie

Compiler window deletion - UI question/suggestion

[Paul Kinnucan]

Jeff Peck writes:
 > I've been wondering with frustration why my windows disappear right after i
 > move to them to start editing...

Hi Jeff,

The behavior that you describe is supposed to happen in JDEE 2.3.5 only
if the  variable jde-compile-enable-kill-buffer is on (the default is
off). I've committed a fix for this bug in jde-compile.el to the
JDEE's CVS repository. I've also updated the JDEE User's Guide to
document this behavior.

Paul


 > Then i read: jde-compile-finish-kill-buffer, and lo! it intentionally waits
 > 2 seconds after a compile,
 > then sneaks in and destroys the window that contains the compiler output!
 > Two seconds is about the time it takes me to type C-xC-o, C-xC-b "buffer i
 > want to edit"
 > and magically i've been reduced from 2 windows to 1 window,
 > so now I have to C-x2 can again C-xC-b to get back to the buffer
 > 
 > Yikes! Kill the compiler buffer, or bury the compile buffer;
 > but don't wait 2 seconds and then mess the window configuration!
 > [IMHO: changing my window configuration asynchronously goes way beyond the
 > principle of least astonishment.]
 > Ok, flame off;
 > Maybe you all use Emacs in the multi-frame pop-up mode and this is not a
 > problem?
 > If so, tell me how you make that work, just setting pop-up-frames makes more
 > and more frames...
 > 
 > 
 > 
 > 
 > Or maybe there is some confusion about deleting the window and killing the
 > buffer:
 > The function called "jde-compile-kill-buffer" un-conditionally deletes a
 > window,
 >  and only conditionally kills a buffer!
 > If the function was re-named "jde-compile-delete-window", then its function
 > and the [IMHO] severe consequences would be more clearly identified.
 > 
 > Can we at least move the (if  jde-compile-enable-kill-buffer ...) test
 > to include the (delete-winodws-on buf) or put *inside*
 > jde-compile-finish-kill-buffer?
 > so it controls not just the 'kill' of the buffer, but also the
 > delete-window-on aspect also?
 > [surely, there is little incentive to kill the compile buffer when compile
 > succeeds...?
 >  it is so small, what is the point of killing it?
 > 
 > Alright, i'm hacked it to work like this:
 > 
 > ;;; redefine jde-compile-enable-kill-buffer to be the time to wait...
 > (defun jde-compile-finish-kill-buffer (buf msg)
 >   "Removes the jde-compile window after a few seconds if no errors."
 >   (save-excursion
 > (set-buffer buf)
 > (if (null (or (string-match ".*exited abnormally.*" msg)
 >   (string-match ".*BUILD FAILED.*" (buffer-string))
 > (not (numberp jde-compile-enable-kill-buffer
 > ;;no errors, make the compilation window go away in a few seconds
 > (lexical-let ((compile-buffer buf))
 >   (run-at-time (format "%d secs" jde-compile-enable-kill-buffer)
 >  nil 'jde-compile-kill-buffer
 >compile-buffer)
 >   (message "No compilation errors"))
 >   ;;there were errors, so jump to the first error
 >   (if jde-compile-jump-to-first-error (next-error 1)
 > 
 > (defun jde-compile-kill-buffer (buf)
 >   (kill-buffer buf))
 > 
 > (defcustom jde-compile-enable-kill-buffer 1
 >   "* Number of seconds to wait before 'jde-compile-finish-kill-buffer
 > will kill the compilation output buffer, or nil to not kill the buffer."
 >   :group 'jde-compile-options
 >   :type 'integer)
 > 

Run directory

[Paul Kinnucan]

It's not clear to me what you want. However, perhaps the
answer to your question lies somewhere in the following
explanation of the JDEE usage model.


The usage model on which the JDEE is based is that all
commands operate on either the current source file, the
current application, or the current project, depending
on the command. The JDEE defines the current source file 
as the source file displayed in the current buffer and
the current application or project as the application 
or project that owns the source file displayed in the 
current buffer.

Thus, for example, if you want to run the current
application, you select the JDE->Run App command from the
Emacs menubar. To run the application, this command needs to
know the source file that contains the application's main
method. This may or may not be the source file in the
current buffer.  Therefore, the JDEE provides the variable
jde-run-application-class to allow you to specify the source
file that contains the main method for the current
application. If this variable is set, the JDEE runs the vm on
the specified class. Otherwise, it assumes that the current
source file contains the main method and runs the vm on the
source file in the current buffer.

The question arises: in which directory does the application
start. The application starts in the working directory of
the process that launched it, which, in this case, is Emacs.
By default the Emacs working directory is the directory
containing the file displayed in the current buffer. Thus by
default applications launched by the JDEE, i.e., Emacs,
start in the directory of the current source file. However,
the JDEE provides you with a means to specify a working
directory for a project, i.e., the jde-run-working-directory
variable. If you set this variable, the JDEE switches the
Emacs working directory to the specified directory before
launching the application.

Paul


Frankie Y. Liu writes:
 > How to run from a particular directory?
 > 
 > Basically I would like to debug from a particular directory.  All my
 > source code resides
 > on different directories, and I specify paths relative to the root
 > directory, where there are
 > no source files.
 > 
 > A work around that is painful to use, is to open any file in the root
 > directory, and enter
 > jde-mode and starting debuging from there.
 > 
 > In more detail:
 > 
 > Root/src/org/me/subdir/sourcefile.java
 > 
 > Where root is the root directory, and where the main file is located
 > in sourcefile.java.
 > I specify the source directory as Root/src and all the source files
 > are found by jde.
 > 
 > The problem is that everytime I have to start debugging from the root
 > directory and
 > I have to switch back and forth between the compilation windows and the 
 > source
 > windows.  It seems it would be better to be able to starting debugging from 
 > any
 > source file, and have a jde-run(debug)-starting-path variable that would be 
 > used
 > as the starting directory where debugging would start.
 > 
 > Thanks,
 > 
 > -frankie

BeanShell Class Browser

[Paul Kinnucan]

Abner Ballardo writes:
 > Hi,
 > 
 > I installed jde 2.3.5 this weekend,... everything works fine but I
 > couldn't use BeanShell Class Browser because jde-browse-class-at-point
 > (jde.el) calls a function jde-open-get-path-prefix-list that was not
 > defined.
 > 
 > Searching in CVS, I found that it was deleted from jde-open-source.el
 > [1] then I added that definition in jde-open-source.el and the problem 
 > was fixed. 
 > 
 > Is there another way?

Yes. jde-open-get-path-prefix-list is obsolete and the reference to it
should have been deleted from jde-browse-class-at-point. In fact,
jde-browse-class-at-point does not even use the "prefix list" returned
by jde-open-get-path-prefix-list. I will update jde-browse-class-at-point
in the next release.

Thanks for reporting this problem.

Paul


 > 
 > [1]
 > http://cvs.sunsite.dk/viewcvs.cgi/jde/lisp/jde-open-source.el.diff?r1=1.14&r2=1.15
 > 
 > friendly,
 > 
 > -- 
 > -
 > Abner Ballardo Urco Debian GNU/LiNUX User
 > --- Module Lost ---http://www.modlost.net
 > 1024D/450EDFF0:E928 1E16 C9E6 1F2F 4D2E  9E33 ADBF BE90 450E DFF0
 > -

Re: Regexp on sourcepath possible?

[Paul Kinnucan]

Jason Baker writes:
 > Paul Kinnucan <[EMAIL PROTECTED]> writes:
 > 
 > > I think the directory-files function requires an argument that
 > > specifies a directory. This highlights the advantage of using the
 > > "awkward" customization interface; no programming errors. Also, I've
 > > never understood the big attraction of having to manually find and
 > > open a project file, edit it, and then save it, an error-prone and
 > > tedious process.  Not my idea of a good time but, heck, to each
 > > his own.
 > 
 > I'm using JDE in a system that is built using autoconf and make.  The
 > canonical way to invoke javac is by running make, so the makefile in
 > the main java directory contains a rule to generate the prj.el file.
 > For me, this is a lot easier than going through the "awkward"
 > customization interface each time I set up a new working tree.

On the other hand, I use David Ponce's JMaker to generate the makefiles for my
projects from the JDEE's customization variables (i.e., the prj.el file). No
handwritten code involved at all.

Paul

RE: JDE-2.5.3 SemanticDB: too much of a good thing?

[Paul Kinnucan]

Raul Acevedo writes:
 > On Fri, 2005-03-25 at 16:46 -0500, Paul Kinnucan wrote:
 > 
 > > Semantic by default builds index menus for entire directories and
 > > builds and stores parse data in files on your disk drive (the
 > > $,1r|(Bsemantic database$,1r}(B). I find the first feature annoying 
 > > and always
 > > turn it off. 
 > 
 > How do you do that?

I'm tempted to say ... but I won't.

Uncheck 

  Senator->Imenu Config->List other files

or

  Senator->Imenu Config->Auto-rebuild other buffers
  
 > 
 > > The JDEE does not use the semantic database feature. So you can try
 > > turning that off, too. 
 > 
 > That one too?  :)

Customize semanticdb-global-mode off.

Paul

 > 
 > Thanks!
 > 
 > Raul
 > 
 > > 
 > 

Re: JDE-2.5.3 SemanticDB: too much of a good thing?

[Paul Kinnucan]

John Russell writes:
 > >   
 > > I have always loved the responsiveness of Emacs, but this background
 > > semantic parsing is ruining the experience. 
 > 
 > My biggest problem is having it cache stuff to files when I try to
 > shut down.  This can take 30+seconds for lots of big files while its
 > saving the cached parse output or whatever its doing.  Semantic does
 > seem like a lot of overhead these days.


Hi John,

Have you tried turning off the caching feature, i.e., setting
semanticdb-minor-mode to nil? I'm not sure how much time, if
any, this feature saves when loading a Java file into Emacs.
I've run with this feature off and not noticed any big difference.
But then I don't notice much of a difference when the feature
is on, either.

Paul

RE: JDE-2.5.3 SemanticDB: too much of a good thing?

[Paul Kinnucan]

Hi Jeff,

 

First off, I don’t experience any of
the problems you are having. I’m using Emacs 21.3.1 on Windows

XP with a fairly recent, low-end machine.  Emacs
is quite responsive. I’m only aware of the reparsing

because of the messages in the minibuffer.

 

Semantic by default builds index menus for
entire directories and builds and stores parse data in files

on your disk drive (the “semantic
database”). I find the first feature annoying and always turn it off. The


JDEE does not use the semantic database
feature. So you can try turning that off, too. Maybe that will make a
difference. Semantic has a variable that determines the threshold that it uses for
deciding when Emacs is idling. The default is

2 seconds. You could try increasing the threshold.
Semantic also has a variable that causes it not to automatically reindex a
buffer every time you make a change, if the buffer is larger than a size that
you specify. By default, the setting is 0, which means that it always rebuilds
the index. You could try setting this to 1. This would cause it to never
rebuild automatically. You’d then have to trigger the rebuilds yourself
after changing files (by clicking Rescan on the Functions menu), which is not
much of burden.

 

Paul

 

 









From: Jeff Peck
[mailto:[EMAIL PROTECTED] 
Sent: Friday, March 25, 2005 3:48
PM
To: jde@sunsite.dk
Subject: JDE-2.5.3 SemanticDB: too
much of a good thing?



 



I just upgraded to NT Emacs 21.3.1 (i386-mingw-nt5.1.2600)
and JDEE 2.3.5





Plenty of new features, but i'll need to read a bunch to
learn to appreciate them.





 





My current concern is with semantic and its continuous
background parsing.





Which would not be so bad, but contrary to the
documentation, it does not 'break'





when there is keyboard input. on the contrary the kbd/gui
freezes (1-20 secs) while semantic does its thing.





And it does it (parsing/freezing) more or less continously/asynchronously
while i'm editing... painful.





 





In *Messages* are comments like:





Wrote c:/Data/Programs/java/util/Arg.java
Update Tag Table: Invoke [2 times]
Building Arglist.java Semantic directory index imenu [2 times]
Building Arglist.java.~2~ Semantic directory index imenu [2 times]
Building NArglist.java Semantic directory index imenu [2 times]
Building Reflect.java Semantic directory index imenu [2 times]
Mark set





Sometimes the series of "Building ... index
imenu[]" repeats every minute or so





 





Note: Each line appears [2 times], is it really parsing
twice? or just sending the message twice?





Note: Even non-modified buffers (like the read-only
Arglist.java.~2~) are being rescanned repeatedly...





 





Is this normal/expected? or am I badly configured? Where to
I look to improve this?





[this didn't seem to be a problem in my previous JDEE 1.x.x
installation]





The semantic docs talk about how to enable only partial
features, but i don't do any of that,





i assume it is all setup by jde-mode; can i tune/modify
without breaking everything?





 





My underlying grump is that i'm an old-dog, all i really
want is the syntax coloring, compile/run/debug key bindings





and for Meta-. to
work;  All the semantic analysis does not seem to link into M-. so what is
the point of that CPU hog?





And how do i get things like Arglist.java.~2~ *out* of the
semantic db/cache/parsing?





 





I have always loved the responsiveness of Emacs, but this
background semantic parsing is ruining the experience.

if completion

[Paul Kinnucan]

Hi John,

Abbreviations are turned off by default. You must turn
them on explicitly. See "Abbreviations" in the JDEE User's
Guide for more info.

Paul


John Russell writes:
 > The last time I used JDEE if I typed "if" or "for" it generated the
 > appropriate block of code.  This no longer happens.  I see the
 > corresponding jde-gen* variables for these, but how are they called? 
 > I know I can do the ol' Alt-x type solution, but that takes almost as
 > long as typing the block.  How do people usually do this now.  Thanks.
 > 
 > John

Re: Regexp on sourcepath possible?

[Paul Kinnucan]

Ole Arndt writes:
 > Hi Lars,
 > 
 > Lars Degerstedt <[EMAIL PROTECTED]> writes:
 > 
 > > I wonder if it is possible to express the fact that I have multiple 
 > > sourcepaths using a regexp (since my enumeration varies). The
 > > expression
 > > I would like to handle is:
 > >
 > > */src/java
 > >
 > > or similar. I have not been able to find anything on this in the 
 > > documents. Is this possible?
 > 
 > It is not recommended by Paul, but you can edit your prj.el files by
 > hand and not use this awkward customization interface. You can then
 > use lisp code to set the project variables, like this:
 > 
 > (jde-set-variables
 >  '(jde-sourcepath (mapcar (lambda (path) 
 > (expand-file-name "src/java" path))
 > (directory-files

I think the directory-files function requires an argument that
specifies a directory. This highlights the advantage of using the
"awkward" customization interface; no programming errors. Also, I've
never understood the big attraction of having to manually find and
open a project file, edit it, and then save it, an error-prone and
tedious process.  Not my idea of a good time but, heck, to each
his own.

Of course, there's always the alternative of proposing a change to the
JDEE to enhance the customization interface to support features
that you need, e.g., providing the option to specify a function
to compute jde-sourcepath or as in this case regular expressions.

But I'm curious as to what kind of a project structure would
make regular expressions in source paths useful. 

Where I work,  all of our Java source files
are in a directory named src (actually, of course, in subdirectories
of the src directory corresponding to packages).

I also set up my personal projects so that for each project, the 
source files are under a project named src. Thus, for me the typical
"awkward" customization interface reads as follows:

Jde Sourcepath: Hide
INS DEL Path: ./src
INS DEL Path: c:/java/jdk-1.5/src
INS
   State: you have set this option, but not saved it for future sessions.

This is all that's necessary for most projects that I deal with, including
enhancing MATLAB.

The nice thing about this is I let Emacs do my project file
programming for me. I never have to worry about creating bugs in my
project files by, for example, forgetting function arguments, omitting
parentheses, or assigning a string to a variable that requires a list
of strings.

Finally, to handle a path specification like:

*/src/java

the JDEE would have to cycle through every directory on your system,
appending /src/java to it, testing whether such a directory exists,
and then searching that directory for the source file? Seems
like a pretty time-consuming operation that might make finding
and opening source files a very slow process.

Paul


 > 
 > Just be sure to never save your project files with jde-save-project,
 > or you will lose your changes.
 > 
 > I have written myself a small module for a related purpose: Read the
 > dependencies from a maven project.xml file and build the
 > jde-global-classpath from this information. My .prj.el files now typically
 > look like this: 
 > 
 > (setq pom (pom-read-pom))
 > (jde-set-variables
 >  '(jde-global-classpath (pom-get-classpath pom))
 >  '(jde-project-name (pom-get-project-id pom))
 >  '(jde-sourcepath (quote ("./src/java" "./src/test"
 > 
 > I have, of course, also a prj.el file for all my default settings in
 > my top level source directory.
 > 
 > Ole
 > -- 
 > Ole Arndt http://www.sugarshark.com
 > 

main abbrev and compiling

[Paul Kinnucan]

John Russell writes:
 > I just starting writing java code again after a long time off so I'm
 > trying to get my JDE setup working again.  I have JDE 2.3.5 and
 > cedet-1.0beta3a.
 > 
 > I wrote a simple hello world program and run jde-compile. The frame is
 > split between my file and the *JDEE Compile Server* buffer which has
 > nothing in it. The message bar says
 > 
 > Buffer is read-only: #
 > 
 > and nothing gets compiled.  My jdk registry is set up right and
 > jde-compiler is set to server. Any ideas?

This sounds like a known incompatibility between the JDEE and the
developmental version of Emacs. The CVS version of jde-compile.el
contains a fix. Please note that I continue to develop the JDEE 
against the current production version of Emacs and am making
no attempt to ensure that the JDEE tracks changes in the developmental
version. I'll be glad to merge fixes supplied by users into the JDEE
sources as long as they don't break backwards compatibility with previous
versions of Emacs.

 > 
 > Also, when I type the word "main" and hit space no space is inserted
 > and the message bar says
 > 
 > Template for abbreviation main not found!

I think I removed main as an abbrev for some reason. The main
template still exists, however. You can invoke it by selecting
JDE->Code Generation->Templates->Other... or by M-x jde-gen-main-method.

Paul


 > 
 > Is my setup wrong?  Thanks for the help.
 > 
 > John

Re: Project settings...

[Paul Kinnucan]

Ping Liang writes:
 > > there is no dialog associated with these options so I'm a bit puzzled by 
 > > your
 > > description of your problem.
 > 
 > One of the things I noticed when I first used the latest nqmacs build
 > is that it pops up with the dialog when I do File->New File... or
 > File->Open File...  Why wouldn't/shouldn't  jdee pop up a dialog when
 > it is prompting the user for file names?  I think this is a good thing
 > (too bad jdee does not work with it). You may not have explicitly
 > programmed this; maybe you implicitly turn that feature off in your
 > environment?

I have use-dialog-box set to nil usually. I set it to t to verify
the problem you reported the other night and still did not get the
dialog box on nqmacs. I tried again this evening and this time
I do get the dialog box and the problem you reported. However, the
problem is not in the JDEE but in nqmacs. The JDEE uses a standard
Emacs Lisp feature, the (interactive Dprompt) option, to prompt the
user for the directory in which to store the project file. I verified
that even when use-dialog-box is turned on in a previous verion, 
this option does not display a dialog box. Apparently, the Emacs
developers decided to update the (interactive Dprompt) option to
use the dialog box but did not check to ensure that it actually works.
I will report this bug.


 > 
 > > may I suggest that it is not the best strategy to
 > > try to learn to use the JDEE with a developmental version of
 > > Emacs.
 > 
 > This is exactly the reason why I only recently upgraded to nqmacs from
 > the gnu production windows build, after "learning" jdee everyday for
 > several years. I have no choice. The combination of all dependancies
 > of jdee including gnu emacs windows build itself is relatively buggy. 
 > Things wouldn't work after a while, like a busy half of a day; I have
 > to restart emacs to make things work again.  (I thought this trick is
 > needed only for Windows.)  Besides, there are good features in nqmacs,
 > including things outside of jdee. Also, I only tried this for around a
 > week and I feel that it is more stable already.
 > 
 > By the way, I am always wondering how big a project jdee can handle. 
 > I wouldn't think a couple of thousand of java class files and half
 > dozen projects to switch in between would be a big deal for
 > emacs/jdee, but it seems to show limitation already.

What limitations?  

 > When I test with
 > jdee, I use some dummy class files and one simple project file, it
 > almost always works (except the dialog thing above, of course).
 > 
 > > In fact, some incompatibilities have already surfaced.
 > 
 > I think I just posted one of these problems a couple of days ago (it
 > has to do with jde-run-option-classpath), so this is not new to me. I
 > don't think I can affort to wait for the announcement that everything
 > is OK before I use it.  Emacs is the only thing I use, for java or
 > else.  As long as the bugs (or imcompatibilities) are not impacting my
 > productivity so much as to miss the deadlines, I don't a problem with
 > it.
 > 
 > > A very bad idea.
 > 
 > For better or worse, it sometimes was the only way I can put a prj.el
 > in the directory I wanted. I don't have much of problem with emacs'
 > customization feature per se. I will try to adjust my habit a bit in
 > the future.

jde-ant-build's seperator problem

[Paul Kinnucan]

[EMAIL PROTECTED] writes:
 > 
 > I'm using nqmacs+jdee2.3.5 on winxp without cygwin. When I use
 > jde-ant-build, I encounter the compilation buffer that say
 > "...build.xml does not exist". After I traced jde-ant.el. I found the
 > problem that file seperator should be " ,not '.

The single quote works for me with nqmacs on Windows XP:

-*- mode: compilation; default-directory: "~/jde-dev/jmath/src/jmath/" -*-
ant -Dant.home=c:/java/apache-ant-1.6.2 -buildfile 
'c:/home/jde-dev/jmath/build.xml' -emacs clean 
Buildfile: c:\home\jde-dev\jmath\build.xml

clean:
Deleting directory C:\home\jde-dev\jmath\classes

BUILD SUCCESSFUL
Total time: 0 seconds

Compilation finished at Fri Mar 11 23:50:33


Paul


 > 
 > *** d:/emacs-22/site-lisp/jde-2.3.5/lisp/jde-ant.el  Wed Mar  9 11:17:09 2005
 > --- d:/emacs-22/site-lisp/jde-2.3.5/lisp/jde-ant.org.el  Fri Dec 17 
 > 12:29:38 2004
 > ***
 > *** 250,257 
 >(string= (car jde-ant-invocation-method) "Java")
 >(and (string= (car jde-ant-invocation-method)
 >  "Script")
 > !   (not (featurep 'xemacs))
 > !  (not (eq system-type 'windows-nt;;;zhangyin's 
 > hack
 >   "'"
 > "\""))
 >(ant-program (if (or (string-match "" jde-ant-program)
 > --- 250,256 
 >(string= (car jde-ant-invocation-method) "Java")
 >(and (string= (car jde-ant-invocation-method)
 >  "Script")
 > !   (not (featurep 'xemacs
 >   "'"
 > "\""))
 >(ant-program (if (or (string-match "" jde-ant-program)

Project settings...

[Paul Kinnucan]

Ping Liang writes:
 > I noticed that with nqmacs and jdee-2.3.5, the menu project->project
 > file->* (most of them) does not work.  It brings up the directory
 > dialog (which is nice), but the dialog always has "open" and "cancel"
 > buttons, even if you want to create new or save the project file. 
 > "load" seems to work fine, simply because it does not need to bring up
 > the dialog.

The options 

JDE->Project->Project File->Create New
Save
Open
OpenAll

all work for me with JDEE 2.3.5 and nqmacs. Further, there is no
dialog associated with these options so I'm a bit puzzled by your
description of your problem.

Also, Ping, may I suggest that it is not the best strategy to
try to learn to use the JDEE with a developmental version of
Emacs. JDEE 2.3.5 was developed against the latest production
version of Emacs and hence is not guaranteed to work with the
development versions. In fact, some incompatibilities have
already surfaced. By using the developmental version, you make
it difficult for yourself and for me to determine whether the
problem is with the JDEE, your setup, or with the developmental
version.

 > 
 > I have been manually maintaining prj.el file so this does not impact
 > me. 

A very bad idea.

Paul 

 > But I think it would be nice to have it working when I am trying
 > to convince my co-workers to switch to jdee...

running programs inside jdee...

[Paul Kinnucan]

Hi Ping,

Please post a complete problem report.

Paul


Ping Liang writes:
 > Hi,
 > 
 > I have been running java programs within jdee for a while and it
 > worked fine.  Since I installed 2.3.5, jde-run does not work anymore. 
 > With the exact setting I had with 2.3.4beta5, running jde-run would
 > yield the following stack trace.  Any hints?
 > 
 > Debugger entered--Lisp error: (wrong-type-argument stringp
 > ("/path/to/classes/one" "/path/to/classes/two"))
 >   jde-run-vm([object jde-run-vm-1-4 "JDK 1.4 vm" "1.4"
 > "c:/j2sdk1.4.2/bin/javaw.exe" unbound "my.main.class.MainClass"])
 >   apply(jde-run-vm [object jde-run-vm-1-4 "JDK 1.4 vm" "1.4"
 > "c:/j2sdk1.4.2/bin/javaw.exe" unbound "my.main.class.MainClass"])
 >   eieio-generic-call(jde-run-classpath-arg ([object jde-run-vm-1-4
 > "JDK 1.4 vm" "1.4" "c:/j2sdk1.4.2/bin/javaw.exe" unbound
 > "my.main.class.MainClass"]))
 >   jde-run-classpath-arg([object jde-run-vm-1-4 "JDK 1.4 vm" "1.4"
 > "c:/j2sdk1.4.2/bin/javaw.exe" unbound "my.main.class.MainClass"])
 >   jde-run-vm-1-4([object jde-run-vm-1-4 "JDK 1.4 vm" "1.4"
 > "c:/j2sdk1.4.2/bin/javaw.exe" unbound "my.main.class.MainClass"])
 >   apply(jde-run-vm-1-4 [object jde-run-vm-1-4 "JDK 1.4 vm" "1.4"
 > "c:/j2sdk1.4.2/bin/javaw.exe" unbound "my.main.class.MainClass"])
 >   eieio-generic-call(jde-run-get-vm-args ([object jde-run-vm-1-4 "JDK
 > 1.4 vm" "1.4" "c:/j2sdk1.4.2/bin/javaw.exe" unbound
 > "my.main.class.MainClass"]))
 >   jde-run-get-vm-args([object jde-run-vm-1-4 "JDK 1.4 vm" "1.4"
 > "c:/j2sdk1.4.2/bin/javaw.exe" unbound "my.main.class.MainClass"])
 >   jde-run-vm([object jde-run-vm-1-4 "JDK 1.4 vm" "1.4"
 > "c:/j2sdk1.4.2/bin/javaw.exe" unbound "my.main.class.MainClass"])
 >   apply(jde-run-vm [object jde-run-vm-1-4 "JDK 1.4 vm" "1.4"
 > "c:/j2sdk1.4.2/bin/javaw.exe" unbound "my.main.class.MainClass"])
 >   eieio-generic-call(jde-run-vm-launch ([object jde-run-vm-1-4 "JDK
 > 1.4 vm" "1.4" "c:/j2sdk1.4.2/bin/javaw.exe" unbound
 > "my.main.class.MainClass"]))
 >   jde-run-vm-launch([object jde-run-vm-1-4 "JDK 1.4 vm" "1.4"
 > "c:/j2sdk1.4.2/bin/javaw.exe" unbound "my.main.class.MainClass"])
 >   jde-run(1)
 >   call-interactively(jde-run)
 >   recursive-edit()
 >   byte-code(...)
 > 
 > 
 > Regards,
 > 
 > Ping

code completion from noncompiled classes

[Paul Kinnucan]

Fredrik Skeel Loekke writes:
 > is it possible to use code completion from noncompiled classes?
 > 

It's possible but it would require a major coding effort to enhance
the JDEE to do this.

Paul

Help on installation

[Paul Kinnucan]

Yuri Tijerino writes:
 > OK,
 > 
 > I am a bit frustrated and would like to get some help getting my JDEE up 
 > and running on xemacs.
 > 
 > Here is my configuration.
 > * Xemacs 21.4.15 on cygwin
 > * Windows XP professional
 > 
 > Here is what I did:
 > * Deleted the 'jde' directory from /usr/share/xemacs/xemacs-packages

You have to delete the XEmacs/xemacs-packages/etc/jde directory. If you don't, 
the JDEE will try to load old jar files from the etc/jde directory. See the 
installation instructions on the JDEE website for more info.

 > * I downloaded the Arthur Hefcyc's install-jde.sh and changed some paths 
 > to make it run on my environment.  Here is the result of that run.  I 
 > think it fiinishes without errors, but when I restart Xemacs and try to 
 > run the command 'jde-jdb' and I get the error on the mini-edit window: 
 > invalid slot type:  jde-db-jdb-1.4 :path, string, nil
 > 
 > I am kind of lost. Can you help, please?

Try running this command again. Then use the JDE->Help->Submit Problem Report 
to create a snapshot of your system and post it to this list.

Paul


 > 
 > Yuri
 > 
 > $ source install-jde.sh
 > 
 >  Warning! Please note, this script now uses CEDET - all in one packages
 >  instead of separate packages for additional tools like:
 >  EIEIO, SEMANTIC and SPEEDBAR.
 >  Don't forget to change load-path settings to include
 >  'cedet/package' instead of separate 'package'.
 >  You can do it just to replace existings setting with one simple:
 >  (load-file "~/.xemacs/site-lisp/cedet/common/cedet.el")
 > 
 > 00:09:03 URL:http://jdee.sunsite.dk/jde-latest.tar.gz [3699059/3699059] 
 > -> "jde-tmp/jde.tar.gz" [1]
 > 00:09:09 URL:http://jdee.sunsite.dk/elib-1.0.tar.gz [58335/58335] -> 
 > "jde-tmp/elib.tar.gz" [1]
 > 00:09:26 
 > URL:http://heanet.dl.sourceforge.net/sourceforge/cedet/cedet-1.0beta3b.tar.gz
 >  
 > [1268732/1268732] -> "jde-tmp/cedet.tar.gz" [1]
 > 00:09:32 URL:http://www.beanshell.org/bsh-2.0b2.jar [280737/280737] -> 
 > "jde-tmp/bsh.jar" [1]
 > tar (GNU tar) 1.13.25 Copyright (C) 2001 Free Software Foundation, Inc. 
 > This program comes with NO WARRANTY, to the extent permitted by law. You 
 > may redistribute it under the terms of the GNU General Public License; 
 > see the file named COPYING for details. Written by John Gilmore and Jay 
 > Fenlason.
 > 
 >  Warning! Please note, this script now uses CEDET - all in one packages
 >  instead of separate packages for additional tools like:
 >  EIEIO, SEMANTIC and SPEEDBAR.
 >  Don't forget to change load-path settings to include
 >  'cedet/package' instead of separate 'package'.
 >  You can do it just to replace existings setting with one simple:
 >  (load-file "~/.xemacs/site-lisp/cedet/common/cedet.el")
 > 
 > $

Re: jde-findbugs.el -- use findbugs from JDE

[Paul Kinnucan]

Suraj Acharya writes:
 > Hi Len,
 > 
 > I've tried it and it works well.
 > 
 > I had to change one thing though, customizing jde-findbugs-directory
 > gave me errors on windows cvs emacs until I changed the default value
 > of this variable to the empty string instead of nil.

Same here.

Also, the findbugs buffer disappears even when it contains error messages.

I'd be happy to included findbugs in the JDEE distribution if people think
it's worthwhile.

Paul


 > 
 > Suraj
 > 
 > 
 > On Tue, 08 Feb 2005 12:57:11 +1300, Len Trigg <[EMAIL PROTECTED]> wrote:
 > > 
 > > Hi all,
 > > 
 > > I have put together an initial version of a jde-findbugs.el, which
 > > lets you call the most excellent findbugs package
 > > (http://findbugs.sourceforge.net/) from within JDE.
 > > 
 > > I took jde-checkstyle.el as the starting point.  The most important
 > > functionality seems to be working, so I thought I'd flick it out for
 > > interested people to try.  See the limitations section of the lisp for
 > > which bits don't currently work.
 > > 
 > > Cheers,
 > > Len.
 > > 
 > > 
 > >

Re: error in getting jde started

[Paul Kinnucan]

Hi Surendra,

I suspect that you have not fully removed the copies of cedet and the JDEE 
thatcome with XEmacs. Unless you do this, XEmacs will load its own, obsolete 
copies of the JDEE and cedet first and then load the copies specified in your 
init file over these, resulting in a mixture of old and new code that produces 
wierd errors.

Note that the version of the JDEE that comes with XEmacs is divided across two 
directories, with the lisp code in the xemacs-packages directory and the rest 
of the code in, I think, the etc directory. If you do not delete BOTH of these 
directories as instructed in the JDEE installation guide for XEmacs, the JDEE 
will not be loaded correctly.

Paul



Surendra Singhi writes:
 > Paul Kinnucan wrote:
 > > Surendra Singhi writes:
 > >  > Hello,
 > >  >I recently installed the latest version of jdee and I am using 
 > > Xemacs 
 > >  > 21.4.13/windows and I have cedet-1.0beta3b installed.
 > >  > The problem is that whenever I open a *.java file the jde mode doesn't 
 > >  > starts up and when I explicilty do "M-x jde-mode" I get the following 
 > >  > error.
 > >  > What is the problem and what should I do to get rid of it?
 > >  > 
 > > 
 > > Did you remove the copy of the JDEE that comes with XEmacs from the XEmacs 
 > > load path as specified in the JDEE installation instructions?
 > > 
 > > Please copy the contents of your messages buffer after trying to open a 
 > > Java source file and post the contents to the JDEE mailing list.
 > 
 > Yes I have removed the copy of JDE which comes with xemacs.
 > When I open a Java source file a java and senator menu option appears. 
 > But JDE is inot started. Then when I explicitly start JDE by using "M-x 
 > jde-mode" I get the error.
 > My .init file contains
 > ; jde
 > ;;(autoload 'speedbar-frame-mode "speedbar"
 >   ;; "Popup a speedbar frame" t)
 > ;;(autoload 'speedbar-get-focus "speedbar"
 > ;;  "Jump to speedbar frame" t)
 > ;;(global-set-key [(f4)] 'speedbar-get-focus)
 > 
 > ;;(add-to-list 'load-path "C:\\Program 
 > Files/XEmacs/xemacs-packages/cedet-1.0beta3b/common")
 > 
 > (load-file "C:\\Program 
 > Files/XEmacs/xemacs-packages/cedet-1.0beta3b/common/cedet.el")
 > ;;(require 'cedet)
 > (add-to-list 'load-path "C:\\Program 
 > Files/XEmacs/xemacs-packages/lisp/jde-2.3.5/lisp")
 > ;; Enabling SEMANTIC minor modes.  See semantic/INSTALL for more ideas.
 > (semantic-load-enable-code-helpers)
 > (require 'jde)
 > 
 > 
 > 
 > Below is the content of my message-buffer.
 > 
 > >  > 
 > >  > Debugger entered--Lisp error: (wrong-type-argument extent-live-p 
 > >  > #)
 > >  >semantic-overlay-end(#)
 > >  >(if (semantic-overlay-p o) (semantic-overlay-end o) (aref o 1))
 > >  >(let ((o ...)) (if (semantic-overlay-p o) (semantic-overlay-end o) 
 > >  > (aref o 1)))
 > >  >semantic-tag-end(("Globals" type (:members (... ... ... ... ... ... 
 > >  > ... ... ... ... ...) :type "class") (unlink-hook 
 > >  > (semantic--tag-unlink-secondary-overlays) link-hook 
 > >  > (semantic--tag-link-secondary-overlays)) #))
 > >  >(- (semantic-tag-end tag) (semantic-tag-start tag))
 > >  >(> (- (semantic-tag-end tag) (semantic-tag-start tag)) 150)
 > >  >(and (or (eq c ...) (and ... ...)) (> (- ... ...) 150) t)
 > >  >(let ((c ...)) (and (or ... ...) (> ... 150) t))
 > >  >semantic-tag-boundary-p-default(("Globals" type (:members (... ... 
 > >  > ... ... ... ... ... ... ... ... ...) :type "class") (unlink-hook 
 > >  > (semantic--tag-unlink-secondary-overlays) link-hook 
 > >  > (semantic--tag-link-secondary-overlays)) #))
 > >  >(if override (funcall override tag) (semantic-tag-boundary-p-default 
 > >  > tag))
 > >  >(let ((override ...)) (if override (funcall override tag) 
 > >  > (semantic-tag-boundary-p-default tag)))
 > >  >semantic-tag-boundary-p(("Globals" type (:members (... ... ... ... 
 > >  > ... ... ... ... ... ... ...) :type "class") (unlink-hook 
 > >  > (semantic--tag-unlink-secondary-overlays) link-hook 
 > >  > (semantic--tag-link-secondary-overlays)) #))
 > >  >funcall(semantic-tag-boundary-p ("Globals" type (:members (... ... 
 > >  > ... ... ... ... ... ... ... ... ...) :type "class") (unlink-hook 
 > >  > (semantic--tag-unlink-secondary-overlays) link-hook 
 > >  >

error in getting jde started

[Paul Kinnucan]

Surendra Singhi writes:
 > Hello,
 >I recently installed the latest version of jdee and I am using Xemacs 
 > 21.4.13/windows and I have cedet-1.0beta3b installed.
 > The problem is that whenever I open a *.java file the jde mode doesn't 
 > starts up and when I explicilty do "M-x jde-mode" I get the following 
 > error.
 > What is the problem and what should I do to get rid of it?
 > 

Did you remove the copy of the JDEE that comes with XEmacs from the XEmacs load 
path as specified in the JDEE installation instructions?

Please copy the contents of your messages buffer after trying to open a Java 
source file and post the contents to the JDEE mailing list.

Paul


 > Thanks in advance.
 > 
 > Debugger entered--Lisp error: (wrong-type-argument extent-live-p 
 > #)
 >semantic-overlay-end(#)
 >(if (semantic-overlay-p o) (semantic-overlay-end o) (aref o 1))
 >(let ((o ...)) (if (semantic-overlay-p o) (semantic-overlay-end o) 
 > (aref o 1)))
 >semantic-tag-end(("Globals" type (:members (... ... ... ... ... ... 
 > ... ... ... ... ...) :type "class") (unlink-hook 
 > (semantic--tag-unlink-secondary-overlays) link-hook 
 > (semantic--tag-link-secondary-overlays)) #))
 >(- (semantic-tag-end tag) (semantic-tag-start tag))
 >(> (- (semantic-tag-end tag) (semantic-tag-start tag)) 150)
 >(and (or (eq c ...) (and ... ...)) (> (- ... ...) 150) t)
 >(let ((c ...)) (and (or ... ...) (> ... 150) t))
 >semantic-tag-boundary-p-default(("Globals" type (:members (... ... 
 > ... ... ... ... ... ... ... ... ...) :type "class") (unlink-hook 
 > (semantic--tag-unlink-secondary-overlays) link-hook 
 > (semantic--tag-link-secondary-overlays)) #))
 >(if override (funcall override tag) (semantic-tag-boundary-p-default 
 > tag))
 >(let ((override ...)) (if override (funcall override tag) 
 > (semantic-tag-boundary-p-default tag)))
 >semantic-tag-boundary-p(("Globals" type (:members (... ... ... ... 
 > ... ... ... ... ... ... ...) :type "class") (unlink-hook 
 > (semantic--tag-unlink-secondary-overlays) link-hook 
 > (semantic--tag-link-secondary-overlays)) #))
 >funcall(semantic-tag-boundary-p ("Globals" type (:members (... ... 
 > ... ... ... ... ... ... ... ... ...) :type "class") (unlink-hook 
 > (semantic--tag-unlink-secondary-overlays) link-hook 
 > (semantic--tag-link-secondary-overlays)) #))
 >(and (cdr style) (fboundp pred) (funcall pred tag) (fboundp high) 
 > (funcall high tag))
 >(let ((pred ...) (high ...)) (and (cdr style) (fboundp pred) (funcall 
 > pred tag) (fboundp high) (funcall high tag)))
 >(while --dolist-temp--81317 (setq style (car --dolist-temp--81317)) 
 > (let (... ...) (and ... ... ... ... ...)) (setq --dolist-temp--81317 
 > (cdr --dolist-temp--81317)))
 >(let ((--dolist-temp--81317 semantic-decoration-styles) style) (while 
 > --dolist-temp--81317 (setq style ...) (let ... ...) (setq 
 > --dolist-temp--81317 ...)) nil)
 >(catch (quote --cl-block-nil--) (let (... style) (while 
 > --dolist-temp--81317 ... ... ...) nil))
 >(cl-block-wrapper (catch (quote --cl-block-nil--) (let ... ... nil)))
 >(block nil (let (... style) (while --dolist-temp--81317 ... ... ...) 
 > nil))
 >(dolist (style semantic-decoration-styles) (let (... ...) (and ... 
 > ... ... ... ...)))
 >(while --dolist-temp--81288 (setq tag (car --dolist-temp--81288)) 
 > (when (semantic-decorate-tag-decoration tag) (message "Decorations still 
 > on %s" ...) (semantic-decorate-clear-tag tag)) (dolist (style 
 > semantic-decoration-styles) (let ... ...)) 
 > (semantic-decorate-add-decorations 
 > (semantic-tag-components-with-overlays tag)) (setq --dolist-temp--81288 
 > (cdr --dolist-temp--81288)))
 >(let ((--dolist-temp--81288 tag-list) tag) (while 
 > --dolist-temp--81288 (setq tag ...) (when ... ... ...) (dolist ... ...) 
 > (semantic-decorate-add-decorations ...) (setq --dolist-temp--81288 ...)) 
 > nil)
 >(catch (quote --cl-block-nil--) (let (... tag) (while 
 > --dolist-temp--81288 ... ... ... ... ...) nil))
 >(cl-block-wrapper (catch (quote --cl-block-nil--) (let ... ... nil)))
 >(block nil (let (... tag) (while --dolist-temp--81288 ... ... ... ... 
 > ...) nil))
 >(dolist (tag tag-list) (when (semantic-decorate-tag-decoration tag) 
 > (message "Decorations still on %s" ...) (semantic-decorate-clear-tag 
 > tag)) (dolist (style semantic-decoration-styles) (let ... ...)) 
 > (semantic-decorate-add-decorations 
 > (semantic-tag-components-with-overlays tag)))
 >semantic-decorate-add-decorations((("weka.classifiers.Classifier" 
 > include nil nil #) ("weka.classifiers.lazy.IBk" 
 > include nil nil #) ("weka.classifiers.rules.Ridor" 
 > include nil nil #) ("weka.classifiers.trees.*" include 
 > nil nil #) ("weka.core.*" include nil nil # extent>) ("weka.classifiers.*" include nil nil #) 
 > ("weka.classifiers.meta.*" include nil nil #) 
 > ("weka.classifiers.bayes.*" include nil nil #) 
 > ("weka.classifiers.functions.*" inclu

Re: Buffer is read-only: #

[Paul Kinnucan]

Hi Martin,

I applied your patch to the CVS version of jde-compile.el.

Thanks,

Paul

Martin Schwamberger writes:
 > 
 > Javier S. Lopez wrote:
 > > Paul Kinnucan <[EMAIL PROTECTED]> writes:
 > > 
 > > There are probably a few ways to work around the problem
 > > 1. Set the inhibit-read-only flag
 > > 2. Make our compiles a minor mode or rewrite the way we use it. There is a 
 > > new
 > >method compile-setup that takes a flag that allows you to control this
 > >behavior.
 > 
 > Hi Javier,
 > 
 > I've changed jde-compile.el
 > according to your first idea.
 > See diff below.
 > 
 > > 
 > > I will point you to the email thread where Richard Stallman talks about 
 > > it. I
 > > don't agree with him, I think Stefan Monnier is right on this one.  
 > > http://lists.gnu.org/archive/html/emacs-devel/2004-11/msg8.html
 > 
 > IMHO, RMS is right here.
 > Programs can easily change read-only compilation buffers
 > and users shouldn't.
 > 
 > Martin
 > 
 > > 
 > > Javier
 > > 
 > > 
 > >>Javier S. Lopez writes:
 > >> > "Anderson, Timothy K" <[EMAIL PROTECTED]> writes:
 > >> > 
 > >> > > Hi,
 > >> > > Using GNU Emacs CVS, JDE 2.3.4, CEDET 1.0beta3b.
 > >> > >
 > >> > > When trying to compile code with C-C C-V C-C,  I am getting the
 > >> > > following error:
 > >> > >
 > >> > > save-excursion: Buffer is read-only: #
 > >> > 
 > >> > This looks familiar...
 > >> > 
 > >> > I had the problem when running the latest emacs from cvs. All the 
 > >> > compilation
 > >> > buffers are read only, I don't know what a good fix for this is. I just 
 > >> > changed
 > >> > the compile.el file to avoid making the buffers readonly. But we 
 > >> > probably need
 > >> > a better fix for this.
 > >> > 
 > >>
 > >>How can the compilation buffers be read-only and allows error and other 
 > >>messages
 > >>to be written into them? This sounds like a bug in the CVS version of 
 > >>Emacs.
 > >>
 > >>Paul
 > >>
 > >> > 
 > >> > Javier
 > >> > 
 > >> > >
 > >> > > This happens every time - I think I have tried almost every 
 > >> > > combination
 > >> > > of customize variables (at least, it feels that way).
 > >> > > Has anyone else seen this?  What should I do to find the cause?
 > >> > >
 > >> > > Thanks for any help.
 > >> > >
 > >> > >
 > >> > > Tim Anderson
 > >> > >
 > >> > >  
 > >> > >
 > >> > >
 > >> > >
 > >> > >
 > >> > > 
 > >> > > CONFIDENTIALITY
 > >> > > This e-mail and any attachments are confidential and also may be 
 > >> > > privileged.
 > >> > > If you are not the named recipient, or have otherwise received this
 > >> > > communication in error, please delete it from your inbox, notify the 
 > >> > > sender
 > >> > > immediately, and do not disclose its contents to any other person,
 > >> > > use them for any purpose, or store or copy them in any medium.
 > >> > > Thank you for your cooperation.
 > >> > > 
 > >> > >
 > >> > >
 > >> > >
 > >> > >
 > >> > 
 > >> > -- 
 > >> > Javier S. Lopez
 > >> > Software Developer
 > >> > Forum Systems, Inc.
 > >> > 95 Sawyer Road, Suite 110, Waltham, MA 02453
 > >> > http://www.forumsys.com
 > >> > 
 > >> > 
 > >> > The information contained in this electronic mail and any attached
 > >> > document is the confidential and proprietary business information of
 > >> > Forum Systems, Inc. It is intended solely for the addressed recipient
 > >> > listed above. It may not be distributed in any manner without the
 > >> > express written consent of Forum Systems, Inc.
 > >>
 > > 
 > > 
 > 
 > diff -u jde-compile.el.old jde-compile.el
 > --- jde-compile.el.old   2004-12-17 05:29:36.0 +0100
 > +++ jde-compile.el   2005-01-25 13:14:

java folding

[Paul Kinnucan]

Guy Thomas writes:
 > I have never used emacs or jde-folding. Is it available? 

 Yes.

 > Is it easy to 
 > use? 

 Yes.

 > Do I have to install extra packages, do I have to add something to 
 > my .emacs file?

 No.

See Hideshow in the Editing Programs section of the Emacs editor
documentation.

Paul


 > 
 > -- 
 > Guy Thomas[EMAIL PROTECTED]
 > fks bvba - Formal and Knowledge Systems   http://www.fks.be/
 > Stationsstraat 108Tel:  ++32-(0)11-21 49 11
 > B-3570 ALKEN  Fax:  ++32-(0)11-22 04 19
 > 

Jde-plugin-minor-mode and jde-jdb-minor-mode only xemacs?

[Paul Kinnucan]

Timothy Babin writes:
 > Okay, I don't know these frameworks really well but I was trying to shorten
 > my mode-line information and came across this.
 > 
 > 
 > 
 > Are the jde-plugin-minor-mode and jde-jdb-minor modes only for xemacs?
 > 

Hi Timothy,

I believe these modes are only for XEmacs to enable addition of
a menu. However, it's been a long time since I visited this code
so I want to check before adopting your suggestions.

Paul

 > If so can we wrap there loading in jde-mode with a check for xemacs?
 > 
 > (if (featurep 'xemacs)
 > (progn
 >   ;; Install debug menu.
 >   (if (string= (car jde-debugger) "JDEbug")
 >   (jde-bug-minor-mode 1)
 > (jde-jdb-minor-mode 1))
 > 
 >   ;; Install plugin menu.
 >   (jde-plugin-minor-mode 1))
 >   )
 > 
 > 
 > Also, what about a call to semantic mode line update at the end of
 > jde-jdb-minor-mode and jde-plugin-minor-mode to remove the modes from the
 > modeling
 > 
 >   (if (featurep 'xemacs)
 >   (let ((menu-spec (jde-plugin-make-menu-spec)))
 >  (if menu-spec
 >  (if jde-plugin-minor-mode
 >  (easy-menu-add menu-spec jde-plugin-mode-map)
 >(easy-menu-remove menu-spec)
 >  (semantic-mode-line-update)
 > ) 
 > 
 > 
 > 
 > 
 > 
 > Jde-plugin-minor-mode and jde-jdb-minor-mode only xemacs?
 > 
 > 
 > 
 > Okay, I don't know these frameworks really well but I 
 > was trying to shorten my mode-line information and came across 
 > this.
 > 
 > 
 > 
 > Are the jde-plugin-minor-mode and jde-jdb-minor modes 
 > only for xemacs?
 > 
 > 
 > If so can we wrap there loading in jde-mode with a 
 > check for xemacs?
 > 
 > 
 >     (if 
 > (featurep 'xemacs)
 >  FACE="Arial">   
 >  (progn
 >  FACE="Arial"> 
 >  ;; Install debug menu.
 >  FACE="Arial"> 
 >  (if (string= (car jde-debugger) "JDEbug")
 >  FACE="Arial"> 
 >  (jde-bug-minor-mode 1)
 >  FACE="Arial">   
 >  (jde-jdb-minor-mode 1))
 > 
 > 
 >  FACE="Arial"> 
 >  ;; Install plugin menu.
 >  FACE="Arial"> 
 >  (jde-plugin-minor-mode 1))
 >  FACE="Arial">  )
 > 
 > 
 > 
 > Also, what about a call to semantic mode line update 
 > at the end of jde-jdb-minor-mode and jde-plugin-minor-mode to remove the 
 > modes from the modeling
 > 
 >   (if (featurep 'xemacs)
 >   (let ((menu-spec 
 > (jde-plugin-make-menu-spec)))
 >     (if 
 > menu-spec
 >      FACE="Arial">    (if jde-plugin-minor-mode
 >     
 >     (easy-menu-add 
 > menu-spec jde-plugin-mode-map)
 >      FACE="Arial">  (easy-menu-remove 
 > menu-spec)
 >  (semantic-mode-line-update)
 > ) 
 > 
 > 
 > 
 > 

[ANN] jde-lint

[Paul Kinnucan]

Hi Nascif,

I have added jde-lint.el to the Contributed Software page
on the JDEE website. I think it would be a good idea for you to
add it to the JDEE Wiki page as well to make sure that JDEE
users are aware of it. 

If you don't mind, I'd like to consider the jde-lint.el package
for inclusion in the JDEE distribution as well.

Thanks for providing this valuable contribution.

Regards,

Paul

Nascif Abousalh-Neto writes:
 > Hi,
 > 
 > I created a small packaged called jde-lint.el that provides an interface 
 > between JDEE (http://jdee.sunsite.dk/), and Lint4j (http://www.jutils.com/). 
 > 
 > Lint4j ("Lint for Java") is a static Java source code analyzer that detects 
 > locking and threading issues, performance and scalability problems, and 
 > checks complex contracts such as Java serialization by performing type, data 
 > flow, and lock graph analysis.
 > 
 > This package uses the information from your JDE project (sourcepath, 
 > classpath and package name) to run the lint4j tool and present the result in 
 > a compilation buffer.
 > 
 > You can get it at: http://home.nc.rr.com/nascifandelaine/emacs.html
 > 
 > Regards,
 >   Nascif
 > 
 > PS: Paul, what would you recommend as the best way to keep links for 
 > contributed packages like this one? Is it OK to add a new page under the 
 > JDEE page in the Emacs Wiki? I think it would be better to have it all under 
 > the official JDEE page but using the EmacsWiki decentralize the efforts.
 > 

Re: Increasing memory for JDEbug

[Paul Kinnucan]

Troy Daniels writes:
 > At 03:59 PM 1/18/2005, Paul Kinnucan wrote:
 > 
 > >Troy Daniels writes:
 > >  > Hello,
 > >  >
 > >  > Is it possible to allocate more memory for the debugger process?  I'm
 > >  > running into a problem where jde.debugger.Main is running out of
 > >  > memory.  One of my local variables is a very long string (about 10 Mb) 
 > > and
 > >  > the debugger process runs out of memory when it tries to display it.
 > >  >
 > >
 > >Hi Troy,
 > >
 > >Try increasing jde-db-option-heap-size. If this doesn't work, let me know.
 > 
 > The maximum is already set at 1000 Mb.  Looking at the *JDEbug* buffer, I 
 > don't think that's the right option for the problem I'm having.  A partial 
 > excerpt of the *JDEbug* buffer:
 > 
 > cd 
 > d:/dev/logging_reorg_import/KBR_ISD_VOB/Jaguar_Plan_Generator_Component/products/PGTest/test
 > c:/j2sdk1.4.2_04/bin/javaw.exe -classpath 
 > d:/Programs/emacs-21.2/site-lisp/jde/java/lib/jde.jar;c:/j2sdk1.4.2_04/lib/tools.jar
 >  
 > jde.debugger.Main
 > 
 > JDE> -1 1 launch 1 -vmexec javaw -classpath  -Xms400m 
 > -Xmx1000m  junit.textui.TestRunner 
 > com.alphatech.kbr.jaguar.pgtest.test.NightlyTests
 > 
 > I don't need to change the values in the launch command, I want to add them 
 > to the javaw ... jde.debugger.Main command.  The program creates a 
 > StringBuffer for a 10 Mb string.  That works fine.  When I step a few lines 
 > further and stringBuffer.toString is assigned to a local String variable, I 
 > get an java.lang.OutOfMemory message in the JDEbug buffer and the local 
 > variable window starts to act funky.  (It sometimes leaves portions drawn 
 > in solid grey.)

Hi Troy,

Try setting jde-db-option-vm-args to the vm command line option for
the heap size. Unfortunately, I don't remember the option name. I
think this will set the heap for the debugger as opposed to the heap
for the process being debugged. Let me know what happens.

Paul

 > 
 > Troy
 > 
 > >Paul
 > >
 > >  > Troy
 > >  > 
 > >  > Troy Daniels
 > >  > [EMAIL PROTECTED]
 > >  > 781-273-3388 x218
 > >  >
 > 
 > 
 > Troy Daniels
 > [EMAIL PROTECTED]
 > 781-273-3388 x218
 > 

Increasing memory for JDEbug

[Paul Kinnucan]

Troy Daniels writes:
 > Hello,
 > 
 > Is it possible to allocate more memory for the debugger process?  I'm 
 > running into a problem where jde.debugger.Main is running out of 
 > memory.  One of my local variables is a very long string (about 10 Mb) and 
 > the debugger process runs out of memory when it tries to display it.
 > 

Hi Troy,

Try increasing jde-db-option-heap-size. If this doesn't work, let me know.

Paul

 > Troy
 > 
 > Troy Daniels
 > [EMAIL PROTECTED]
 > 781-273-3388 x218
 > 

Re: JDE debugging problems

[Paul Kinnucan]

Hi Henry,

I've changed variables named assoc to assoc-x in the
JDEE Lisp code. Thanks for suggesting this fix.

Paul

Henry S. Thompson writes:
 > So this is an _old_ thread, I just hit the problem again, just thought
 > I'd get the workaround on the record if anyone hits it again as I just
 > did:
 > 
 > To fix the "Symbol's value as variable is void: old-assoc" problem
 > when debugging with JDE in xemacs/cygwin, edit the file jde-dbs.el,
 > and replace the six uses of 'assoc' as a _variable_ with some other
 > symbol.
 > 
 > Then load jde into your xemacs and do (jde-compile-jde), and the
 > problem will be fixed.
 > 
 > Or rather, that for sure fixes the problem when it occurs when trying
 > to clear a breakpoint, which is the way I hit it.
 > 
 > I observe that the string old-assoc also appears in the following elc
 > files:
 > 
 >   jde-bug.elc, jde-db.elc, jde-jdb.elc
 > 
 > which all also use 'assoc' as a local variable.
 > 
 > It may well be that these should also be edited.
 > 
 > ht
 > -- 
 >  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
 >  Half-time member of W3C Team
 > 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
 > Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED]
 >URL: http://www.ltg.ed.ac.uk/~ht/
 > [mail really from me _always_ has this .sig -- mail without it is forged 
 > spam]

Running Junit tests from JDE

[Paul Kinnucan]

Magnus > Hi,
(B
(BMagnus > I'm trying to run Junit tests directly from JDEE using 
(Bjde-junit-run, but 
(BMagnus > all I get is this message in the message buffer:
(B
(BMagnus > jde-run-vm: Invalid function: (macro . #[(&rest body) "ÁÂBB‡" 
(B[body let 
(BMagnus > ((win32-start-process-show-window t) 
(B(w32-start-process-show-window t) 
(BMagnus > (w32-quote-process-args 34) (win32-quote-process-args 34) 
(BMagnus > (windowed-process-io t) (process-connection-type nil))] 3 
(BMagnus > ("c:/home/ljung/.emacs.d/site-lisp/jde/lisp/jde-run.elc" . 36363)])
(B
(BMagnus > Anybody knows what's going on?
(B
(BIt appears to be that the compiler did not see or did not like the macro
(Bsave-w32-show-window when compiling  jde-run.elc, which is odd, considering
(Bthat save-w32-show-window is defined in jde-run.el. I will investigate. 
(BMeanwhile,
(Btry running jde-run.el uncompiled.
(B
(BPaul
(B
(BP.S. It would help knowing what version of the JDEE, Emacs, etc. you are using.
(BPlease file a complete problem report when asking for tech support.
(B
(BMagnus > I was also wondering if it is possible to run just one test case 
(Bfrom a test
(BMagnus > suite using JDE?
(B
(BMagnus > Thanks for the help, 
(BMagnus > /Magnus

JDE : Unable to get Code Completion to work...

[Paul Kinnucan]

viraj purang writes:
(B > I am relatively new to JDEE and while I find emacs very useful, I
(B > don't know much about LISP either. My problem is that I am unable to
(B > get "Code Completion" to work.
(B > 
(B > If I I try something as small as 
(B > ==
(B > // LoanBean.java
(B > 
(B > imp(want this to be completed to import to start with)
(B > ==
(B > M-x jde-complete says . "No completion at this point"
(B > M-x jde-complete-inline says . "No completion at this point"
(B > M-x jde-complete-minibuf says . "No completion at this point"
(B > M-x jde-complete-pop-message says . call-interactively: Wrong number
(B > of arguments: #[(message buffer-or-name) ",AF(B!,AG(B!p,AH(B 
(B > ,AI(B!,AJ(B$,1!R(B!
(B > 
(B > Can you someone please help me ...
(B > FYI, I am also using ecb in this installation.
(B
(BPlease read the JDEE user's guide where you will discover that
(B
(B* jde-complete is for completing user-defined Java symbols, e.g., class and 
(Bclass member names.
(B
(B* To complete Java keywords, such as import, turn on abbrev-mode (JDE->Code 
(BGeneration->Modes->Abbrev).
(B
(B* The JDEE has a very nice facility for generating a complete import 
(B  statement for the class at point or all classes in the current buffer.
(B
(BPaul

Re: JDE and Java 1.5

[Paul Kinnucan]

Wolfgang Pausch writes:
 > Hello,
 > 
 > > I have no recollection or record of receiving your email. I may have
 > > missed it in all the junk I get, especially as over Christmas, always
 > > a busy time personally, I was involved in a high priority project at work
 > >  and was not able to winnow the email wheat from the chaff with as much
 > > care as usual. Or your email may have triggered my employer's spam
 > > filter.
 > 
 > Is it correct that the adress [EMAIL PROTECTED] instead of the one you wrote 

[EMAIL PROTECTED] is not my personal address.

Paul

 > from now is inserted into the problem-report (as of jde 2.3.4beta6, I am not 
 > on the system with 2.3.5 currently)?
 > 
 > > Please, if I don't respond in a few days, send me another email.
 > >
 > >  > If no, when can we expect that? Is there some workaround? How much code
 > >  > needs to be added in order to add support for running a 1.5 Java-VM?
 > >
 > > I have 1.5 installed on my Windows XP machine and have no problems using it
 > > with the JDEE.
 > >
 > > The error trace that you sent indicates that the code is expecting a
 > > string and is getting a list of strings. This suggests that you have
 > > set a customization variable incorrectly.
 > 
 > I now found the reason: I reused my old prj.el-file, with 
 > jde-run-option-classpath set. However, jde-run-option-classpath seems to 
 > have 
 > changed to be a value-menu with options global, local, none.
 > 
 > Removing it manually from prj.el and setting it again worked.
 > 
 > Thanks,
 > 
 > Wolfgang

JDE and Java 1.5

[Paul Kinnucan]

Wolfgang Pausch writes:
 > Hello,
 > 
 > I currently try to set up JDE 2.3.5 with emacs on a Debian-amd64-system with 
 > Java 1.5.
 > 
 > Installing was no problem, however I again run into problems when trying to 
 > execute run for my project. It simply says "wrong-type-argument stringp" (I 
 > have attached the backtrace).
 > 
 > I have looked a bit into the mentioned functions and noticed that 
 > jde-run-get-vm-args is a generic function with implementations for - if I 
 > read that right - Java 1.1 to Java 1.4.

The JDEE lisp code that supports the JDK is object-oriented in order
to allow reuse of code for earlier JDK versions in the code for later
versions. In particular, the lisp class for 1.5 inherits its methods,
including jde-run-get-vm-args, from the class for 1.5. I have not
yet gotten around to examining whether there are any vm arguments
particular to 1.5 that would require a 1.5-specific implementation
of jde-run-get-vm-args.

 > 
 > So does JDE support Java 1.5 at all at the moment? 

Yes, it supports the Java 1.4 features in 1.5. It does not support some
of the new syntactic features, such as generics and assertions.

 > 
 > (I already sent a problem-report to Paul about a similar problem several 
 > weeks 
 > ago, when I couldn't set jde-jdk to a 1.5-jdk for longer than the current 
 > session, but got no answer --- however, the current problem is a bit more 
 > annoying than the old one).

I have no recollection or record of receiving your email. I may have
missed it in all the junk I get, especially as over Christmas, always
a busy time personally, I was involved in a high priority project at work
 and was not able to winnow the email wheat from the chaff with as much
care as usual. Or your email may have triggered my employer's spam
filter.

Please, if I don't respond in a few days, send me another email.

 > 
 > If no, when can we expect that? Is there some workaround? How much code 
 > needs 
 > to be added in order to add support for running a 1.5 Java-VM?

I have 1.5 installed on my Windows XP machine and have no problems using it with
the JDEE.

The error trace that you sent indicates that the code is expecting a
string and is getting a list of strings. This suggests that you have
set a customization variable incorrectly.

Please submit a complete problem report so that I can see how you have 
configured
the JDEE.

Paul

 > 
 > Thanks for answers,
 > 
 > Wolfgang
 > 
 > Debugger entered--Lisp error: (wrong-type-argument stringp 
 > ("~/Programmieren/CivQuest/civquest" 
 > "~/Programmieren/CivQuest/civquest/classes" "~/Programmieren/SwiFu/swifu" 
 > "~/Programmieren/SwiFu/swifu/classes"))
 >   jde-run-vm([object jde-run-vm-1-5 "JDK 1.5 vm" "1.5" 
 > "/usr/local/lib/jdk1.5.0/bin/java" unbound "civquest.swing.CivQuest"])
 >   apply(jde-run-vm [object jde-run-vm-1-5 "JDK 1.5 vm" "1.5" 
 > "/usr/local/lib/jdk1.5.0/bin/java" unbound "civquest.swing.CivQuest"])
 >   eieio-generic-call(jde-run-classpath-arg ([object jde-run-vm-1-5 "JDK 1.5 
 > vm" "1.5" "/usr/local/lib/jdk1.5.0/bin/java" unbound 
 > "civquest.swing.CivQuest"]))
 >   jde-run-classpath-arg([object jde-run-vm-1-5 "JDK 1.5 vm" "1.5" 
 > "/usr/local/lib/jdk1.5.0/bin/java" unbound "civquest.swing.CivQuest"])
 >   jde-run-vm-1-4([object jde-run-vm-1-5 "JDK 1.5 vm" "1.5" 
 > "/usr/local/lib/jdk1.5.0/bin/java" unbound "civquest.swing.CivQuest"])
 >   apply(jde-run-vm-1-4 [object jde-run-vm-1-5 "JDK 1.5 vm" "1.5" 
 > "/usr/local/lib/jdk1.5.0/bin/java" unbound "civquest.swing.CivQuest"])
 >   eieio-generic-call(jde-run-get-vm-args ([object jde-run-vm-1-5 "JDK 1.5 
 > vm" "1.5" "/usr/local/lib/jdk1.5.0/bin/java" unbound 
 > "civquest.swing.CivQuest"]))
 >   jde-run-get-vm-args([object jde-run-vm-1-5 "JDK 1.5 vm" "1.5" 
 > "/usr/local/lib/jdk1.5.0/bin/java" unbound "civquest.swing.CivQuest"])
 >   jde-run-vm([object jde-run-vm-1-5 "JDK 1.5 vm" "1.5" 
 > "/usr/local/lib/jdk1.5.0/bin/java" unbound "civquest.swing.CivQuest"])
 >   apply(jde-run-vm [object jde-run-vm-1-5 "JDK 1.5 vm" "1.5" 
 > "/usr/local/lib/jdk1.5.0/bin/java" unbound "civquest.swing.CivQuest"])
 >   eieio-generic-call(jde-run-vm-launch ([object jde-run-vm-1-5 "JDK 1.5 vm" 
 > "1.5" "/usr/local/lib/jdk1.5.0/bin/java" unbound "civquest.swing.CivQuest"]))
 >   jde-run-vm-launch([object jde-run-vm-1-5 "JDK 1.5 vm" "1.5" 
 > "/usr/local/lib/jdk1.5.0/bin/java" unbound "civquest.swing.CivQuest"])
 >   jde-run(1)
 > * call-interactively(jde-run)

Problems with some jde-javadoc-gen customizations

[Paul Kinnucan]

Lenz, Georg writes:
 > Hei
 > 
 > under NTEmacs (with cygwin) I experiencing various problems with 
 > jde-gen-javadoc settings:
 > 
 > ;; Does not work on windows (works under Linux?!)
 > jde-javadoc-gen-doc-title "Some API"
 > jde-javadoc-gen-window-title "Some API"
 > jde-javadoc-gen-overview "some url"

This was caused by inadvertent double quoting, first by the JDEE and
then by Emacs, of string arguments passed by Emacs to the javadoc
process. I have fixed this in the latest version of the source
for jde-javadoc-gen.el, which you can download from the JDEE's
source repository.

 > 
 > ;; Does not work at all ! e.g.  increasing the memory with -J-
 > jde-javadoc-gen-args (quote ( "-J-Xmx180m"))

In what sense does this not work? I tried this option exactly as
you specifed and it works fine on NTEmacs, i.e., the option
appears on the command line as -J-Xmx180m and javadoc does not
complain.

Paul

 > 
 > The last one is really bad because it is almost always needed 
 > and renders jde-javadoc-make useless for all but the smallest projects.
 > 
 > The versions of NTEmacs is latest JDE latest but one.
 > Any fixes available
 > 
 > Regards
 > Georg Lenz
 > 
 > 

Re: cannot read files in zip file after installing jde 2.3.5

[Paul Kinnucan]

Yoon Kyung Koo writes:
 > Thanks, Paul and Ed.
 > 
 > In my case, adding both archive-zip-use-pkzip and archive-zip-extract works.
 > 
 > ;; use unzip instead of pkunzip
 > (setq archive-zip-use-pkzip nil)
 > (setq archive-zip-extract (quote ("unzip" "-qq" "-c")))

The second is redundant because arc-mode.el defines archive-zip-extract  
as follows:

(defcustom archive-zip-extract
  (if archive-zip-use-pkzip '("pkunzip" "-e" "-o-") '("unzip" "-qq" "-c"))
  "*Program and its options to run in order to extract a zip file member.
Extraction should happen to standard output.  Archive and member name will
be added.  If `archive-zip-use-pkzip' is non-nil then this program is
expected to extract to a file junking the directory part of the name."
  :type '(list (string :tag "Program")
    (repeat :tag "Options"
:inline t
(string :format "%v")))
  :group 'archive-zip)

Paul



 > 
 > 
 > Paul Kinnucan wrote:
 > 
 > >Ed Mooney writes:
 > > > I had the same problem. The symptom is that after you open an archive, 
 > > > you can't extract a member to its own buffer.
 > > > 
 > > > Under 2.3.4, archive-zip-extract gets set to ("unzip" "-qq" "-c"). 
 > > > Undert 2.3.5, it gets set to ("pkunzip" "-e" "-o-"). (In my environment, 
 > > > anyway. I don't know which extraction utility is the default, but I 
 > > > don't seem to have customized it.) A related difference between the two 
 > > > JDE versions is that jde-util.el uses archive-zip-extract in 2.3.5, but 
 > > > not in 2.3.4. I don't understand elisp well enough to know if it's being 
 > > > called or defined.
 > > > 
 > > > I fixed things by:
 > > > 
 > > >  M-x customize-apropos RET archive-zip-extract
 > > > 
 > > > Enter "unzip" for "Program:" and "-qq" and "-c" as options. Then, "Save 
 > > > for Future Sessions".
 > >
 > >Hi Ed,
 > >
 > >JDEE 2.3.5 adds some infrastructure to support navigation of zip and
 > >jar files in jde-sourcepath. The infrastructure loads arc-mode on
 > >JDEE startup. When arc-mode is loaded on Windows, it sets the
 > >value of archive-zip-extract to ("pkunzip" "-e" "-o-") if 
 > >archive-zip-use-pkzip is nonnil (the default). Otherwise, it sets the value
 > >to ("unzip" "-qq" "-c"). In short, arc-mode is set up to use pkunzip
 > >by default on Windows. If you want to avoid this, customize
 > >archive-zip-use-pkzip to be off (nil).
 > >
 > >Paul
 > >  
 > >
 > 
 > -- 
 > 
 >  Java Architect yoonforh at tmax dot co dot kr (ICQ #21382429)
 >  Building on One Span Ahead Technology
 >  Process Engineer From Software Development To Business Modeling
 >  PGP  http://www.javadom.com/personal/yoonforhatyahoodotcom.asc
 > 
 > 

Re: cannot read files in zip file after installing jde 2.3.5

[Paul Kinnucan]

Ed Mooney writes:
 > I had the same problem. The symptom is that after you open an archive, 
 > you can't extract a member to its own buffer.
 > 
 > Under 2.3.4, archive-zip-extract gets set to ("unzip" "-qq" "-c"). 
 > Undert 2.3.5, it gets set to ("pkunzip" "-e" "-o-"). (In my environment, 
 > anyway. I don't know which extraction utility is the default, but I 
 > don't seem to have customized it.) A related difference between the two 
 > JDE versions is that jde-util.el uses archive-zip-extract in 2.3.5, but 
 > not in 2.3.4. I don't understand elisp well enough to know if it's being 
 > called or defined.
 > 
 > I fixed things by:
 > 
 >  M-x customize-apropos RET archive-zip-extract
 > 
 > Enter "unzip" for "Program:" and "-qq" and "-c" as options. Then, "Save 
 > for Future Sessions".

Hi Ed,

JDEE 2.3.5 adds some infrastructure to support navigation of zip and
jar files in jde-sourcepath. The infrastructure loads arc-mode on
JDEE startup. When arc-mode is loaded on Windows, it sets the
value of archive-zip-extract to ("pkunzip" "-e" "-o-") if 
archive-zip-use-pkzip is nonnil (the default). Otherwise, it sets the value
to ("unzip" "-qq" "-c"). In short, arc-mode is set up to use pkunzip
by default on Windows. If you want to avoid this, customize
archive-zip-use-pkzip to be off (nil).

Paul


 > 
 >-- Ed
 > 
 > Paul Kinnucan wrote:
 > > Yoon Kyung Koo writes:
 > >  > After installing jde 2.3.5 I cannot read files embedded in zip or jar 
 > > file.
 > >  > The error message is as follows :
 > >  > 
 > >  > Searching for program: no such file or directory, pkunzip
 > >  > 
 > >  > I use unzip instead of pkunzip.
 > >  > ;;  use unzip instead of pkunzip
 > >  > (setq archive-zip-use-pkzip nil)
 > >  > 
 > > 
 > > The JDEE does not set this variable, as far as I know.
 > > 
 > > Paul
 > > 
 > 
 > -- 
 > Ed Mooney |Sun Microsystems, Inc.|Time flies like
 > Java Web Services |UBUR02-201|an arrow, but
 > [EMAIL PROTECTED] |1 Network Drive   |fruit flies like
 > 781-442-0459  |Burlington, MA  01803 |a banana. Groucho

Re: bsh-exit doesn't work in JDE 2.3.4

[Paul Kinnucan]

Jon Schewe writes:
 > On Tue, 2004-12-21 at 22:06, Paul Kinnucan wrote:
 > 
 > > Jon Schewe writes:
 > >  > 
 > >  > Please enter the details of your bug report here
 > >  > 
 > >  > Calling bsh-exit results in the following stack trace.
 > > 
 > > Jon,
 > > 
 > > Starting in JDEE 2.3.4, to terminate the JDEE's instance of
 > > the beanshell, execute M-x jde-bsh-exit.
 > > 
 > 
 > Thanks.  It might be a good idea to remove bsh-exit then...

No. As the JDEE release notes stated at some point, I restructured
beanshell.el so that it is a package in its own right that can be used
independently of the JDEE. The package includes the ability for the
user to start an instance of the beanshell, using bsh-exit, interact
with it, and then shut it down, using bsh-exit.

This made it necessary to create equivalent commands for starting and
terminating, the JDEE's instance of the beanshell, which has additional
functionality not necessary and hence not included in the standalone
instance.

Paul



 > 
 > 
 > 
 > 
 > Your mouse has moved.
 > Windows must restart for change to take effect.
 > Reboot now? [OK]
 > http://web-unix.htc.honeywell.com/people/jschewe [Honeywell Intranet
 > Only]
 > *My views may not represent those of my employers
 > 
 > 
 > 
 >   
 >   
 > 
 > 
 > On Tue, 2004-12-21 at 22:06, Paul Kinnucan wrote:
 > 
 > Jon Schewe writes:
 >  > 
 >  > Please enter the details of your bug report here
 >  > 
 >  > Calling bsh-exit results in the following stack trace.
 > 
 > Jon,
 > 
 > Starting in JDEE 2.3.4, to terminate the JDEE's instance of
 > the beanshell, execute M-x jde-bsh-exit.
 > 
 > 
 > Thanks.  It might be a good idea to remove bsh-exit then...
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > Your mouse has moved.
 > Windows must restart for change to take effect.
 > Reboot now? [OK]
 >  HREF="http://web-unix.htc.honeywell.com/people/jschewe";>http://web-unix.htc.honeywell.com/people/jschewe
 >  [Honeywell Intranet Only]
 > *My views may not represent those of my employers
 > 
 > 
 > 
 > 
 > 
 > 

cannot read files in zip file after installing jde 2.3.5

[Paul Kinnucan]

Yoon Kyung Koo writes:
 > After installing jde 2.3.5 I cannot read files embedded in zip or jar file.
 > The error message is as follows :
 > 
 > Searching for program: no such file or directory, pkunzip
 > 
 > I use unzip instead of pkunzip.
 > ;;  use unzip instead of pkunzip
 > (setq archive-zip-use-pkzip nil)
 > 

The JDEE does not set this variable, as far as I know.

Paul

Re: Problems with the bean shell

[Paul Kinnucan]

Prof. Dr. Jobst Hoffmann writes:
 > On thursday, 16.12.2004, 16:23 -0500 Paul Kinnucan wrote:
 > > Jobst Hoffmann writes:
 > >  > I've worked succesfully with the jde.2.3.4betas. Now I switched over to
 > >  > released jde 2.3.4 and can't do anything besides editing .java-files.
 > >  > When I call the compiler, I get the following messages (excerpt from the
 > >  > log):
 > > 
 > > The only change I can think of that might have affected the beanshell
 > > is the one that sets the process-connection-type to nil. Search 
 > > beanshell.el
 > > for this variable and change the code to set it to t. See if that works.
 > > If it does, let me know. Otherwise file a complete problem report.
 > > 
 > > Paul
 > > 
 > In the meantime I've installed jde 2.3.5 with the same result. Then I
 > replaced the contents of the directory java by the contents of the same
 > directory from jde-2.3.4beta6 and all worked fine (only replacing
 > jde.jar was not sufficient). What are the differences between the
 > versions, is there anybody with the same problem?
 > 

Hi, 

I upgraded the JDEE to the latest version of beanshell in JDEE
2.3.4. It's possible there is some imcompatibility. To confirm, please
try just replacing the version of bsh.jar in JDEE 2.3.5 with the
version from 2.3.4beta6.

Paul


 > Jobst
 > 
 > PS. In the installation guide should be mentioned that the file
 > attributes for the documentation should be set depending where the files
 > are stored and who installed the files. It's trivial but as a simple
 > reminder it could be valuable.
 > -- 
 > Prof. Dr. Jobst HoffmannTel:   +49-2461-99-3159
 > Fachhochschule Aachen Abt. Jülich   Fax:   +49-2461-99-3189
 > Fachbereich 3   email: [EMAIL PROTECTED]
 > 
 > 
 > 

RE: [ANNOUNCEMENT] JDEE 2.3.5 available at ...

[Paul Kinnucan]

Raul Acevedo writes:
 > In the face of world hunger, poverty, and a Republican administration,
 > it is a small issue I can live with.  :)
 > 
 > On Fri, 2004-12-17 at 18:18 -0500, Latchezar Dimitrov wrote:
 > > Is it too big a problem for you to rename it the way you like most after
 > > d/l?

If nobody has an objection, I could do the following.

Provide the latest distribution under two names 

  * jde-VERSION
  * jde-latest

with the link on the Web page to jde-VERSION.

This assumes that it doesn't matter to people who have automatic
download scripts (if there still are any) that the web page is not
linked to jde-latest.

Paul

 > > 
 > > Thanks,
 > > Latchezar 
 > > 
 > > > -Original Message-
 > > > From: Raul Acevedo [mailto:[EMAIL PROTECTED] 
 > > > Sent: Friday, December 17, 2004 2:24 PM
 > > > To: Paul Kinnucan
 > > > Cc: Britton, Chris; [EMAIL PROTECTED]
 > > > Subject: RE: [ANNOUNCEMENT] JDEE 2.3.5 available at ...
 > > > 
 > > > Actually, it would be nice if the download file were called 
 > > > jde-2.3.5.zip instead of always being jde-latest.zip.  It 
 > > > makes it easier to track versions I have downloaded and installed.
 > > > 
 > > > Raul
 > > > 
 > > > On Fri, 2004-12-17 at 12:56 -0500, Paul Kinnucan wrote:
 > > > > Britton, Chris writes:
 > > > >  > Hi Paul.
 > > > >  >
 > > > >  > I'm still getting JDE 2.3.4 from jde-latest.zip at this 
 > > > location.  
 > > > > Can you  > please confirm if jde-latest.zip contains 2.3.5?
 > > > >  >
 > > > > 
 > > > > Hi Chris,
 > > > > 
 > > > > I just downloaded jde-latest.zip and verified that it 
 > > > contains 2.3.5.
 > > > > 
 > > > > It seems that at least one person has this problem shortly 
 > > > after every 
 > > > > release. Apparently, there's some kind of caching of download files 
 > > > > going on somewhere.
 > > > > 
 > > > > I'm posting this reply to the JDEE mailing list as well as 
 > > > to Chris in 
 > > > > the hopes that somebody who is more knowledgable about the Internet 
 > > > > than I am can explain this phenomenon and suggest a 
 > > > solution to keep 
 > > > > it from happening or recovering from it if it does happen.
 > > > > 
 > > > > Regards,
 > > > > 
 > > > > Paul
 > > > >  
 > > > >  > Thanks.
 > > > >  >
 > > > >  > --
 > > > >  > Chris Britton
 > > > >  > [EMAIL PROTECTED]
 > > > >  >
 > > > >  >
 > > > >  > -Original Message-
 > > > >  > From: Paul Kinnucan [mailto:[EMAIL PROTECTED]  > 
 > > > Sent: Friday, 
 > > > > December 17, 2004 8:07 AM  > To: [EMAIL PROTECTED]  > Cc: 
 > > > > [EMAIL PROTECTED]  > Subject: [ANNOUNCEMENT] JDEE 2.3.5 
 > > > > available at ...
 > > > >  >
 > > > >  > http://jdee.sunsite.dk/rootpage.html#Downloading
 > > > >  >
 > > > >  > JDE 2.3.5
 > > > >  >
 > > > >  > ***
 > > > >  > * PLEASE READ *
 > > > >  > ***
 > > > >  > * *
 > > > >  > * This release requires cedet 1.0beta2 or later. cedet*
 > > > >  > * includes semantic, eieio, speedbar, and senator, all*
 > > > >  > * packages required by the JDEE. You can obtain cedet *
 > > > >  > * at http://cedet.sourceforge.net *
 > > > >  > * *
 > > > >  > * Please note that your .emacs file must "load" cedet.el, *
 > > > >  > * not "require" cedet. See the installation instructions  *
 > > > >  > * that come with the cedet package for more information.  *
 > > > >  > * *
 > > > >  > * This release requires version 1.2.2 (or later) of the   *
 > > > >  > * JDK.*
 > > > >  > *   

RE: [ANNOUNCEMENT] JDEE 2.3.5 available at ...

[Paul Kinnucan]

Raul Acevedo writes:
 > I'm sure you mean sourceforget.net right?   :)
 > 
 > On Fri, 2004-12-17 at 19:30 +, Matthew Kurjanowicz wrote:
 > > It may also be nice (if its possible/allowed) to mirror this in a project
 > > at slashdot.  I like sunsite.dk and am very appreciative, but if they
 > > don't want to host multiple versions then slashdot would do that (as well
 > > as keeping track of every release and when it was made).  I'm not saying
 > > move the whole project to slashdot, just mirror the releases there.

It's not Sunsite. It's JDEE users who many years ago asked that I switch
to always using jde-latest in order to accommodate automatic updating
to the latest release.

Paul

 > > 
 > > $0.02,
 > > -Matt
 > > 
 > > > Actually, it would be nice if the download file were called
 > > > jde-2.3.5.zip instead of always being jde-latest.zip.  It makes it
 > > > easier to track versions I have downloaded and installed.
 > > >
 > > > Raul
 > > >
 > > > On Fri, 2004-12-17 at 12:56 -0500, Paul Kinnucan wrote:
 > > >> Britton, Chris writes:
 > > >>  > Hi Paul.
 > > >>  >
 > > >>  > I'm still getting JDE 2.3.4 from jde-latest.zip at this location.
 > > >> Can you
 > > >>  > please confirm if jde-latest.zip contains 2.3.5?
 > > >>  >
 > > >>
 > > >> Hi Chris,
 > > >>
 > > >> I just downloaded jde-latest.zip and verified that it contains 2.3.5.
 > > >>
 > > >> It seems that at least one person has this problem shortly after
 > > >> every release. Apparently, there's some kind of caching of download
 > > >> files going on somewhere.
 > > >>
 > > >> I'm posting this reply to the JDEE mailing list as well as to Chris in
 > > >> the hopes that somebody who is more knowledgable about the Internet
 > > >> than I am can explain this phenomenon and suggest a solution to keep
 > > >> it from happening or recovering from it if it does happen.
 > > >>
 > > >> Regards,
 > > >>
 > > >> Paul
 > > >>
 > > >>  > Thanks.
 > > >>  >
 > > >>  > --
 > > >>  > Chris Britton
 > > >>  > [EMAIL PROTECTED]
 > > >>  >
 > > >>  >
 > > >>  > -Original Message-
 > > >>  > From: Paul Kinnucan [mailto:[EMAIL PROTECTED]
 > > >>  > Sent: Friday, December 17, 2004 8:07 AM
 > > >>  > To: [EMAIL PROTECTED]
 > > >>  > Cc: [EMAIL PROTECTED]
 > > >>  > Subject: [ANNOUNCEMENT] JDEE 2.3.5 available at ...
 > > >>  >
 > > >>  > http://jdee.sunsite.dk/rootpage.html#Downloading
 > > >>  >
 > > >>  > JDE 2.3.5
 > > >>  >
 > > >>  > ***
 > > >>  > * PLEASE READ *
 > > >>  > ***
 > > >>  > * *
 > > >>  > * This release requires cedet 1.0beta2 or later. cedet*
 > > >>  > * includes semantic, eieio, speedbar, and senator, all*
 > > >>  > * packages required by the JDEE. You can obtain cedet *
 > > >>  > * at http://cedet.sourceforge.net *
 > > >>  > * *
 > > >>  > * Please note that your .emacs file must "load" cedet.el, *
 > > >>  > * not "require" cedet. See the installation instructions  *
 > > >>  > * that come with the cedet package for more information.  *
 > > >>  > * *
 > > >>  > * This release requires version 1.2.2 (or later) of the   *
 > > >>  > * JDK.*
 > > >>  > * *
 > > >>  > * This release also requires avltree.el, which is part of the *
 > > >>  > * elib 1.0 package. You can obtain elib at the JDE web site   *
 > > >>  > * in compressed tar (http://jdee.sunsite.dk/elib.tar.gz)  *
 > > >>  > * or zip (http://sunsite.dk/jde/elib.zip) format.

RE: [ANNOUNCEMENT] JDEE 2.3.5 available at ...

[Paul Kinnucan]

Britton, Chris writes:
 > Hi Paul.
 > 
 > I'm still getting JDE 2.3.4 from jde-latest.zip at this location.  Can you
 > please confirm if jde-latest.zip contains 2.3.5?
 > 

Hi Chris,

I just downloaded jde-latest.zip and verified that it contains 2.3.5.

It seems that at least one person has this problem shortly after
every release. Apparently, there's some kind of caching of download
files going on somewhere.

I'm posting this reply to the JDEE mailing list as well as to Chris in
the hopes that somebody who is more knowledgable about the Internet
than I am can explain this phenomenon and suggest a solution to keep
it from happening or recovering from it if it does happen.

Regards,

Paul
 
 > Thanks.
 > 
 > -- 
 > Chris Britton
 > [EMAIL PROTECTED]
 > 
 > 
 > -Original Message-
 > From: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
 > Sent: Friday, December 17, 2004 8:07 AM
 > To: [EMAIL PROTECTED]
 > Cc: [EMAIL PROTECTED]
 > Subject: [ANNOUNCEMENT] JDEE 2.3.5 available at ...
 > 
 > http://jdee.sunsite.dk/rootpage.html#Downloading
 > 
 > JDE 2.3.5
 > 
 > ***
 > * PLEASE READ *
 > ***
 > * *
 > * This release requires cedet 1.0beta2 or later. cedet*
 > * includes semantic, eieio, speedbar, and senator, all*
 > * packages required by the JDEE. You can obtain cedet *
 > * at http://cedet.sourceforge.net *
 > * *
 > * Please note that your .emacs file must "load" cedet.el, *
 > * not "require" cedet. See the installation instructions  *
 > * that come with the cedet package for more information.  *
 > * *
 > * This release requires version 1.2.2 (or later) of the   *
 > * JDK.*
 > * *
 > * This release also requires avltree.el, which is part of the *
 > * elib 1.0 package. You can obtain elib at the JDE web site   *
 > * in compressed tar (http://jdee.sunsite.dk/elib.tar.gz)  *
 > * or zip (http://sunsite.dk/jde/elib.zip) format. *
 > * *
 > * JDEbug runs on Windows 2000 only if Service Pack 2 (or  *
 > * later) is installed.*
 > * *
 > * If syntax-coloring does not work, download and install  *
 > * overlay-fix.el from the semantic web site.  *
 > * *
 > ***
 > 
 > * On XEmacs, Use efc-xemacs-query-options, i.e., a GUI dialog box
 >   instead of a text dialog box, only if use-dialog-box is nonnil.
 > 
 > * Fixes bug in ProjectClasses to avoid duplicate entries of imports.
 > 
 > * Updated JDEE's Ant interface to force use of pipes to interact
 >   with external Ant process.
 > 
 > * Fixed regression that caused jde-help-class-member to issue a
 >   Lisp error.
 > 
 > * Fixed regression in jde-wiz-update-class-list command.
 > 
 > * Fixed regression that caused JDEbug to issue a Lisp error
 >   when launching an application.
 > 
 >   Thanks to Martin Schwamberger.
 > 
 > * Revise the following templates to conform to CheckStyle
 >   requirements:
 > 
 >   - jde-gen-deep-clone-template
 >   - jde-gen-to-string-method-template
 >   - jde-gen-bean-template
 > 
 >   Thanks to Martin Schwamberger.
 > 
 > * Added the following code generation templates:
 > 
 >   - jde-gen-exception
 > 
 > Generates an exception class in the current buffer.
 > 
 >   - jde-gen-exception-buffer
 > 
 > Generates a buffer containing an exception class.
 > 
 >   - jde-gen-hashcode-method
 > 
 > Generates a hashcode method at point.
 > 
 >   - jde-gen-equals-method
 > 
 > Generates an equals method at point.
 > 
 >   - jde-gen-tostring-method
 > 
 > Generates a toString method that uses Apache's
 > ToStringBuilder class. 
 > 
 >   Thanks to Ole Arndt.
 > 
 > * Enhanced jde-run-option-classpath to allow you to
 >   specify that the JDEE should omit the classpath
 >   argument when running the class or application in
 >   the current buffer, regardless of the setting of
 >   jde-global-classpath.
 > 
 

[ANNOUNCEMENT] JDEE 2.3.5 available at ...

[Paul Kinnucan]

http://jdee.sunsite.dk/rootpage.html#Downloading

JDE 2.3.5

***
* PLEASE READ *
***
* *
* This release requires cedet 1.0beta2 or later. cedet*
* includes semantic, eieio, speedbar, and senator, all*
* packages required by the JDEE. You can obtain cedet *
* at http://cedet.sourceforge.net *
* *
* Please note that your .emacs file must "load" cedet.el, *
* not "require" cedet. See the installation instructions  *
* that come with the cedet package for more information.  *
* *
* This release requires version 1.2.2 (or later) of the   *
* JDK.*
* *
* This release also requires avltree.el, which is part of the *
* elib 1.0 package. You can obtain elib at the JDE web site   *
* in compressed tar (http://jdee.sunsite.dk/elib.tar.gz)  *
* or zip (http://sunsite.dk/jde/elib.zip) format. *
* *
* JDEbug runs on Windows 2000 only if Service Pack 2 (or  *
* later) is installed.*
* *
* If syntax-coloring does not work, download and install  *
* overlay-fix.el from the semantic web site.  *
* *
***

* On XEmacs, Use efc-xemacs-query-options, i.e., a GUI dialog box
  instead of a text dialog box, only if use-dialog-box is nonnil.

* Fixes bug in ProjectClasses to avoid duplicate entries of imports.

* Updated JDEE's Ant interface to force use of pipes to interact
  with external Ant process.

* Fixed regression that caused jde-help-class-member to issue a
  Lisp error.

* Fixed regression in jde-wiz-update-class-list command.

* Fixed regression that caused JDEbug to issue a Lisp error
  when launching an application.

  Thanks to Martin Schwamberger.

* Revise the following templates to conform to CheckStyle
  requirements:

  - jde-gen-deep-clone-template
  - jde-gen-to-string-method-template
  - jde-gen-bean-template

  Thanks to Martin Schwamberger.

* Added the following code generation templates:

  - jde-gen-exception

Generates an exception class in the current buffer.

  - jde-gen-exception-buffer

Generates a buffer containing an exception class.

  - jde-gen-hashcode-method

Generates a hashcode method at point.

  - jde-gen-equals-method

Generates an equals method at point.

  - jde-gen-tostring-method

Generates a toString method that uses Apache's
ToStringBuilder class. 

  Thanks to Ole Arndt.

* Enhanced jde-run-option-classpath to allow you to 
  specify that the JDEE should omit the classpath
  argument when running the class or application in
  the current buffer, regardless of the setting of 
  jde-global-classpath.


* Fixed regression that caused the JDEE to switch 
  projects during debugging when stepping into
  code that does not belong to the project being
  debugged.

* Updated regular expressions used by the JDEE's interface
  to jdb to accommodate non-English punctuation styles 
  for numeric expressions in debugger messages, e.g., 
  1.200 for a line number where the English would
  write 1,200. 

  Thanks to Morten B. Isaksen.

* In previous releases, building javadoc caused
  all future uses of compilation mode to try to
  display the javadoc. This release fixes the problem.
 
  Thanks to David Evers.

* Updated the submit-problem-report command to include
  an XEmacs user's init.el file.

Re: WELCOME to jde@sunsite.dk

[Paul Kinnucan]

Hi Abner,

Please upgrade to the latest JDEE (2.3.4). If the problem
persists, post a complete problem report.

Paul

Abner Ballardo Urco writes:
 > hi,
 > 
 > I have a problem, when I open a java file (C-x C-f file.java) jde starts
 > ok. I can see the classes,jde,java,jdb,senator menus, and the sintax
 > highlight works fine but when I open another file (C-x C-4 f or C-x C-5
 > f) I only see the jde,java,jdb menus and the sintax highlight doesn't
 > work. 
 > 
 > I was searching the web but I cannot find something to fix this, any
 > suggestions are welcome. I think it is something with emacs
 > 
 > This is what I use:
 > Emacs 21.3+1-8
 > JDE 2.3.3-2
 > Debian Sarge
 > 
 > thanks,
 > 
 > P.D.: sorry for my bad english
 > 
 > -- 
 > Abner Ballardo Urco
 > 
 > -
 > "Un informatico es alguien que soluciona un problema que nunca creiste
 > tener de una manera que nunca entenderas" - Anonimo
 > -
 > 
 > Fingerprint: 1024D/450EDFF0:E928 1E16 C9E6 1F2F 4D2E  9E33 ADBF BE90
 > 450E DFF0

Problems with the bean shell

[Paul Kinnucan]

Jobst Hoffmann writes:
 > I've worked succesfully with the jde.2.3.4betas. Now I switched over to
 > released jde 2.3.4 and can't do anything besides editing .java-files.
 > When I call the compiler, I get the following messages (excerpt from the
 > log):

The only change I can think of that might have affected the beanshell
is the one that sets the process-connection-type to nil. Search beanshell.el
for this variable and change the code to set it to t. See if that works.
If it does, let me know. Otherwise file a complete problem report.

Paul

 > ...
 > Loading semantic-edit...
 > Loading semantic-edit...done
 > Loading semanticdb-file...
 > Loading semanticdb-file...done
 > Loading jde-javadoc...
 > Setting customized JDE variables to startup values...
 > Loading jde-javadoc...done
 > Loading semantic-decorate...
 > Loading semantic-decorate...done
 > Starting the BeanShell. Please wait...
 > Starting the BeanShell. Please wait...
 > Starting the BeanShell. Please wait...
 > # after several minutes
 > Process not open for writing: #
 > ...
 > Any task that is working with the beanshell ends up in long waiting for
 > a response and an error message. What can I do, can you give me some
 > hints?
 > 
 > Thanks in advance
 > Jobst
 > -- 
 > Prof. Dr. Jobst HoffmannTel:   (0049)-2461-99-3159
 > Fachhochschule Aachen Abt. Jülich   Fax:   (0049)-2461-99-3189
 > Fachbereich 3   email: [EMAIL PROTECTED]
 > 
 > 

attaching jdb to tomcat on localhost

[Paul Kinnucan]

Hi Emory,

It would be nice to try to isolate the problems that you are
experiencing, in particular, to try to determine if the problems
are with jdb or with Emacs/JDEE or with the two in combination.
A way to do this is to try a few debugging sessions, using
the jdb command line interface alone. My suspicion is that the
problem is with jdb on the Macintosh and that you'll experience
the same problems if you try using jdb standalone.

Paul

Emory Smith writes:
 > hi,
 > 
 > ive been using jde for some time to debug webapps deployed locally on a 
 > tomcat server and have consistently had a couple of annoying problems.
 > 
 > i set things up like so:
 > 
 > * start tomcat in listen mode ... open browser
 > * start emacs ... build and deploy to tomcat using jde-ant-build
 > * attach using jde-jdb-attach-via-socket
 > * set a breakpoint and refresh browser
 > 
 > at this point, everything works great -- breakpoint is hit, and jdb 
 > runs without a hitch ... i do my stuff and then "cont" ... the browser 
 > page finishes loading ...
 > 
 > 9 times out of 10, thats the extent of my debugging session ... if i 
 > want it to work again, i will have to quit tomcat at the least to get 
 > any of it to work again (usually i have to actually kill off all 
 > running java processes before tomcat will be able to connect to the 
 > listen port again).  and even if tomcat connects, i can no longer set 
 > breakpoints in any of my source files -- jdb will say "unable to set 
 > breakpoint ... no code at line xxx".  ive tried everything i can think 
 > of (clearing breakpoints, quiting jdb, detaching, closing browser, etc 
 > ) and in every possible order ... but it practically never works a 
 > second time.  and when it does, jdb will invariably end up stepping 
 > into some obscure java or tomcat class and i can type cont 200 times 
 > without ever getting back to my own code ...
 > 
 > but as soon as i save files, quit jde, quit emacs, close my browsers, 
 > quit tomcat, grep top for java and kill off any running java processes 
 > (which are often very high cpu usage), wait for a little while, start 
 > tomcat back up, start emacs, run ant remove/compile/install, start jdb 
 > and attach to tomcat, set my breakpoint again, open the browser back up 
 > and return to the page ... boom - it hits the breakpoint and i can 
 > debug once again...
 > 
 > it seems like there should be a more efficient way to go about this, so 
 > i was hoping someone might be able to point me in the right direction.  
 > i apologize if this has been explained/discussed here already (though i 
 > couldnt find anything like it in the archives).
 > 
 > also, im running mac os10.3.6 (though this has happened since 10.2.x) 
 > on a powerbook g4.
 > (carbon) emacs 21.3.5, jdee 2.3.4, tomcat 5.0.27, jre 1.4.2, ant 1.6.1,
 > 
 > thanks for any suggestions anyone might have,
 > emory
 > 

RE: _Long_ pause after each new directory is noticed. . .

[Paul Kinnucan]

Nascif Abousalh-Neto writes:
 > I am having a similar problem, but it is not deterministic. Had it yesterday 
 > but can't reproduce today.

On the face of it, it would appear that this is a problem with ecb as
it tries to build lists of what's in directories whereas the JDEE does
not. The first thing I would do is try to pinpoint the problem to one
package or the other and to one file type another, i.e., to use the
JDEE and ECB separately to determine if the problem occurs with one
but not the other, with Java files but not other types of files, or
with both packages and only Java files, both packages and nonJava
files, etc.

Paul


 > Using ECB 2.30 and JDE 2.3.4.
 > 
 > Debug-on-error doesn't work for this one, and the long breaks are *very* 
 > disruptive.
 > 
 > Any idea on how to debug something like that?
 > 
 > > -Original Message-
 > > From: Henry S. Thompson [mailto:[EMAIL PROTECTED] 
 > > Sent: Tuesday, December 07, 2004 10:34 AM
 > > To: jde
 > > Subject: _Long_ pause after each new directory is noticed. . .
 > > 
 > > Just upgraded both jde and ecb (can't tell which is the problem,
 > > sorry) to latest versions (ecb 2.30.1 and jcb 2.3.4)
 > > 
 > > Whenever I read or save a .java file to a particular package 
 > > directory for the first time in a given session, xemacs goes 
 > > away for a long (several minutes) time.  It's not responsive 
 > > to Ctrl-G during this time.
 > > 
 > > Not sure this is new, but it seems worse. . .
 > > 
 > > Any clues?
 > > 
 > > ht
 > > --
 > >  Henry S. Thompson, HCRC Language Technology Group, 
 > > University of Edinburgh
 > >  Half-time member of W3C Team
 > > 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 
 > > 131 650-4440
 > > Fax: (44) 131 650-4587, e-mail: [EMAIL PROTECTED]
 > >URL: http://www.ltg.ed.ac.uk/~ht/ [mail 
 > > really from me _always_ has this .sig -- mail without it is 
 > > forged spam]
 > > 

How do I submit my patch for non-english locale jdb debugging?

[Paul Kinnucan]

Morten writes:
 > Hi
 > 
 > I once wrote this list regarding a problem debugging code with more than
 > 999 lines with the jdb mode in JDE, using the danish locale.  I ended up
 > being able to construct a patch for the code myself, by asking a lot of 
 > questions in #Emacs on the freenode IRC-network.
 > 
 > I wonder if the proposed patch I posted earlier has been incorporated 
 > into JDE in some way.  "cvs diff" suggests otherwise, so I wonder how
 > to submit the patch.  Obviously I would be interested in the patch
 > making it to the official release, so I don't have to patch the code
 > myself on subsequently updates.
 > 

Hi Morten,

I saved your email with the patch and plan to incorporate it into the JDEE for 
the next release.

Paul
 

Re: jde-checkstyle and Emacs 21.50.3

[Paul Kinnucan]

Christian Plate writes:
 > 
 > >  > How do i set this in my .emacs? I dont know any lisp, sorry for this
 > >  > stupid question.
 > >
 > > (setq compilation-enter-directory-regexp-alist nil)
 > 
 > Thanks, Paul. Ive done this. However now it says:
 > save-excursion: Buffer is read-only: #

Hi Christian,

This is the result of another recent change to the CVS (i.e.,
development) version of compilation mode in Emacs that I am not sure
how to fix. As a rule, I prefer not to try to change the JDEE to track
changes to development versions of Emacs. I prefer to wait wait until
the changes are are officially released. So, unless you are willing
and able to change the JDEE yourself (and, ideally, provide the fixes
to me so I can incorporate them into the JDEE sources), I recommend
that you use the latest production version of Emacs as I do.

Paul

Re: jde-checkstyle and Emacs 21.50.3

[Paul Kinnucan]

Christian Plate writes:
 > 
 > > Yes, recent CVS versions of Emacs have changed compilation mode,
 > > which checkstyle uses. One of the changes eliminates
 > > compilation-enter-directory-regexp-alist. I will eventually
 > > get around to updating checkstyle to handle this change. Meanwhile,
 > > just define the variable yourself in your .emacs file.
 > 
 > Ok emacs 21.3 says:
 > compilation-enter-directory-regexp-alist's value is 
 > ((".*: Entering directory `\\(.*\\)'$" 1))
 > 
 > How do i set this in my .emacs? I dont know any lisp, sorry for this stupid 
 > question.

(setq compilation-enter-directory-regexp-alist nil)

Paul

jde-checkstyle and Emacs 21.50.3

[Paul Kinnucan]

Christian Plate writes:
 > 
 > Hello,
 > 
 > with GNU Emacs 21.3.50.2 and JDE 2.3.4 I get following error with 
 > jde-checkstyle:
 > 
 > let: Symbol's value as variable is void: 
 > c
 > 
 > Any ideas?

Yes, recent CVS versions of Emacs have changed compilation mode,
which checkstyle uses. One of the changes eliminates 
compilation-enter-directory-regexp-alist. I will eventually
get around to updating checkstyle to handle this change. Meanwhile,
just define the variable yourself in your .emacs file.

Paul

 > 
 > TIA,
 >   Christian

Re: Debugging remote 1.4.2 jvm

[Paul Kinnucan]

Paul Kinnucan writes:
 > Ed Mooney writes:
 >  > I couldn't get attach mode to work, either[1].
 > 
 > Attaching to a running process works for me as documented in the JDEE's jdb 
 > user's
 > guide.
 > 
 > JDEE version: 2.3.4
 > XEmacs version: 21.4 (patch 13) "Rational FORTRAN [Lucid] (i586-pc-win32) of 
 > Sun May 25 2003.
 > Windows version: Windows XP

Here are the steps I used:

1. Set jde-sourcepath for my project to 
   
   ./src

2. Set jde-run-option-debug as follows:

   Jde Run Option Debug: * [Value Menu] Connect:
   Mode: [Value Menu] Server
   Data Transport: [Value Menu] Shared Memory
   Shared Memory Name: [Value Menu] javadebug
   Socket Host: [Value Menu] nil
   Socket Port: [Value Menu] 
   Suspend?: [Value Menu] No

3. Put point on the line where I wanted to set
   a breakpoint and selected Toggle Breakpoint
   from the Jdb menu.

   The JDEE highlighted the line in red.

4. Pressed C-c C-v C-r to run my program.

   My program ran to the point where it prompted
   me for input in the run buffer in Emacs.

5. Opened a new frame on the source buffer for
   the program. 

6. Selected External Process->Attach Via Shared Memory
   from the buffer's Jdb menu.

   The JDEE started jdb and passed the breakpoint to
   it. Jdb responded with the following messages in
   the jdb buffer.
   
   Initializing jdb ...
   > stop at jmath.Test:27
   Set breakpoint jmath.Test:27

   The breakpoint turns red to signify that it is enabled.

7. I selected Continue from the Jdb menu.

   Jdb responds:

   > cont
   Nothing suspended.


7. I switched to my program's run buffer and entered
   some text and hit return.

   The debugger runs my program to the breakpoint and pauses. 
   
   Breakpoint hit: "thread=main", jmath.Test.main(), line=27 bci=163
   27LinearSystem s = new LinearSystem(A);

8. I displayed the value of a local variable by entering a print
   command in the jdb buffer:

   main[1] print B[1]
   B[1] = 5.0

I then stepped a few lines and selected Continue from the Jdb menu to 
run the program to completion.


Paul


   


 > 
 > Paul
 > 
 >  > 
 >  >-- Ed
 >  > 
 >  > [1] http://article.gmane.org/gmane.emacs.jdee/4017
 >  > 
 >  > Karr, David wrote:
 >  > > 
 >  > >>-Original Message-
 >  > >>From: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
 >  > >>Sent: Friday, December 03, 2004 8:05 AM
 >  > >>To: Karr, David
 >  > >>Cc: Paul Kinnucan; [EMAIL PROTECTED]
 >  > >>Subject: RE: Debugging remote 1.4.2 jvm
 >  > >>
 >  > >>Karr, David writes:
 >  > >> > I assume "attach" mode is further down the road, for 
 >  > >>either jdb or  > Jdebug mode?  > 
 >  > >>
 >  > >>I don't know why I bother writing documentation for the JDEE.
 >  > > 
 >  > > 
 >  > > I read the documentation.  I couldn't get Attach mode to work.  Since
 >  > > you replied saying you were using "listen" mode, I assumed you meant
 >  > > that Attach mode isn't working yet.  If that's not the case, then I'll
 >  > > continue trying to get Attach working with jdb mode.
 >  > > 
 >  > > 
 >  > >>Paul
 >  > >>
 >  > >> > 
 >  > [ ... ]
 > 

Re: Debugging remote 1.4.2 jvm

[Paul Kinnucan]

Ed Mooney writes:
 > I couldn't get attach mode to work, either[1].

Attaching to a running process works for me as documented in the JDEE's jdb 
user's
guide.

JDEE version: 2.3.4
XEmacs version: 21.4 (patch 13) "Rational FORTRAN [Lucid] (i586-pc-win32) of 
Sun May 25 2003.
Windows version: Windows XP

Paul

 > 
 >-- Ed
 > 
 > [1] http://article.gmane.org/gmane.emacs.jdee/4017
 > 
 > Karr, David wrote:
 > > 
 > >>-Original Message-
 > >>From: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
 > >>Sent: Friday, December 03, 2004 8:05 AM
 > >>To: Karr, David
 > >>Cc: Paul Kinnucan; [EMAIL PROTECTED]
 > >>Subject: RE: Debugging remote 1.4.2 jvm
 > >>
 > >>Karr, David writes:
 > >> > I assume "attach" mode is further down the road, for 
 > >>either jdb or  > Jdebug mode?  > 
 > >>
 > >>I don't know why I bother writing documentation for the JDEE.
 > > 
 > > 
 > > I read the documentation.  I couldn't get Attach mode to work.  Since
 > > you replied saying you were using "listen" mode, I assumed you meant
 > > that Attach mode isn't working yet.  If that's not the case, then I'll
 > > continue trying to get Attach working with jdb mode.
 > > 
 > > 
 > >>Paul
 > >>
 > >> > 
 > [ ... ]

RE: Debugging remote 1.4.2 jvm

[Paul Kinnucan]

Karr, David writes:
 > I assume "attach" mode is further down the road, for either jdb or
 > Jdebug mode?
 > 

I don't know why I bother writing documentation for the JDEE.

 > One question about functionality: In either debugger, is it possible
 > now, or expected, that if you get to a point where you're viewing the
 > value of a ByteArrayOutputStream, to be able to dynamically view the
 > contents as String (essentially view "new String(baos.toByteArray())")?

Ditto the above.

Paul

 > 
 > > -Original Message-
 > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
 > > Sent: Thursday, December 02, 2004 10:15 AM
 > > To: Karr, David
 > > Cc: [EMAIL PROTECTED]
 > > Subject: Debugging remote 1.4.2 jvm
 > > 
 > > 
 > > Karr, David writes:
 > >  > I've decided to try experimenting with the jde debugger to 
 > > see if it has  > features that make it worth using over netbeans.  > 
 > >  > I first set "jde-debugger" to "Jdebug" in customize.  
 > > Should I be using  > Jdebug for this, or "jdb"?  > 
 > > 
 > > I'd start with using the JDEE's interface to jdb. I revised 
 > > the JDEE's debug infrastructure recently and ported jdb to 
 > > use the new infrastructure. Still to be done is to port 
 > > JDEbug. The jdb interface appears to be pretty solid based on 
 > > my use of it.
 > > 
 > > I've been using it to debug an XML application. This requires 
 > > putting the debugger in listen mode and then starting the 
 > > other application. It works very nicely. I am able to step 
 > > through the code and examine variable values.
 > > 
 > > Paul
 > > 
 > > 
 > >  > I'm not certain exactly what I'm supposed to set up now.
 > >  > 
 > >  > I see the user guide mentions setting the "location of the 
 > > JPDA  > libraries".  It has examples for JDK 1.3 and 1.2.2, 
 > > but not 1.4.x.  The  > customize info for that variable 
 > > specifically says you only need to set  > this variable for a 
 > > 1.2 JVM.  > 
 > >  > The "jre home" variable seems to be needed if I start the 
 > > debuggee  > through the debugger.  I'm not.  I'm only going 
 > > to be remotely  > connecting, so it appears that I wouldn't 
 > > set that variable.  > 
 > >  > I set the "Server Socket" variable to the JPDA port my 
 > > debuggee is  > configured for.  The customize info for this 
 > > variable seems ambiguous  > whether this is the correct 
 > > variable to set.  > 
 > >  > At this point, the contents of the "Attach Process" menu 
 > > is grayed out,  > so I can't select a server to connect to.
 > > 
 > > 

Debugging remote 1.4.2 jvm

[Paul Kinnucan]

Karr, David writes:
 > I've decided to try experimenting with the jde debugger to see if it has
 > features that make it worth using over netbeans.
 > 
 > I first set "jde-debugger" to "Jdebug" in customize.  Should I be using
 > Jdebug for this, or "jdb"?
 > 

I'd start with using the JDEE's interface to jdb. I revised the JDEE's
debug infrastructure recently and ported jdb to use the new
infrastructure. Still to be done is to port JDEbug. The jdb
interface appears to be pretty solid based on my use of it.

I've been using it to debug an XML application. This requires 
putting the debugger in listen mode and then starting the other
application. It works very nicely. I am able to step through the
code and examine variable values.

Paul


 > I'm not certain exactly what I'm supposed to set up now.
 > 
 > I see the user guide mentions setting the "location of the JPDA
 > libraries".  It has examples for JDK 1.3 and 1.2.2, but not 1.4.x.  The
 > customize info for that variable specifically says you only need to set
 > this variable for a 1.2 JVM.
 > 
 > The "jre home" variable seems to be needed if I start the debuggee
 > through the debugger.  I'm not.  I'm only going to be remotely
 > connecting, so it appears that I wouldn't set that variable.
 > 
 > I set the "Server Socket" variable to the JPDA port my debuggee is
 > configured for.  The customize info for this variable seems ambiguous
 > whether this is the correct variable to set.
 > 
 > At this point, the contents of the "Attach Process" menu is grayed out,
 > so I can't select a server to connect to.

RE: custom-autoload

[Paul Kinnucan]

Hi Mehta,

 

This is an Emacs/XEmacs autoload
incompatibility problem with recent versions of cedet. The makefile for recent
versions of cedet generates a file called loaddefs.el that contains among other
things autoload definitions for custom variables defined by cedet. These
definitions use a function named custom-autoload that is defined by recent
versions of Emacs but not by older versions, which did not support autoloading
of custom variables, and possibly not by any version of XEmacs. In theory, the
only way the problem could arise is if you or someone else built  cedet on
a version of Emacs/XEmacs that supports autoloading of custom variables and
then you use the built cedet on a version of Emacs/XEMacs that does not support
autoloading of custom variables and hence does not define custom-autoload. The
solution in this case would be to ensure that you are using a version of cedet
that was built by the version of Emacs or XEmacs that you are using. If all else
fails, you can create a dummy definition of custom-autoload in your .emacs file
as follows:

 

(defun custom-autoload(&rest args))

 

Paul

 









From: Mehta, Miten
(IM) [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 02, 2004
6:23 AM
To: [EMAIL PROTECTED]
Subject: custom-autoload



 





hello,





 





Let me know how to fix this.





 





My system is:





 







Xemacs 21.4.10, cedet-1.0beta3a, elib-1.0, jde-2.3.4





SunOS pisdb40 5.7 Generic_106541-20 sun4u sparc
SUNW,Ultra-Enterprise





 





I have startup error:







 





symbol's function definiton is void: custom-autoload





 





with .emacs as:





 





(add-to-list 'load-path (expand-file-name
"~/emacs/site/jde/lisp")) 
(add-to-list 'load-path (expand-file-name
"~/emacs/site/cedet/common")) 
(load-file (expand-file-name "~/emacs/site/cedet/common/cedet.el")) 
(add-to-list 'load-path (expand-file-name "~/emacs/site/elib")) 
 
(require 'jde) 
 



Miten Mehta 





 

















NOTICE: If received in error, please destroy and notify sender.
Sender does not waive confidentiality or privilege, and use is prohibited.

Investigating quickfix functionality

[Paul Kinnucan]

Kai Grossjohann writes:
 > I had been using Eclipse for some time a year ago.  One thing I really
 > liked about it was the quickfix functionality.  When the compiler
 > found an error in your source code, you could hit Ctrl+1 to pop up a
 > little menu which suggested some remedies.
 > 
 > Because I missed it so much, I investigate whether it would be
 > possible to get this in Emacs, as well.  It seems it would be possible
 > in principle.
 > 
 > This version only knows two kinds of errors: unreported exception, and
 > cannot resolve symbol class Foo.
 > 
 > I'd appreciate any comments or help or patches.

Hi Kai,

A quick fix capability would be a nice addition to the JDEE. If you'd
like to pursue this, I suggest that you integrate what you have into
the JDEE immediately to encourage others to try it out and thereby
provide you with feedback. Integrating it into the JDEE means among
other things, prefixing symbols with jde-. I suggest you use the
prefix: jde-qfix- for quick fix symbols, that you rename your package
jde-qfix.el, and that you sent me the updated file. I will add the
necessary require statement to jde.el and submit the source code to
the JDEE CVS repository. If you would like write access to the CVS
repository, provide me with a user name and encrypted password (see
Developer's Corner on the JDEE website).

Paul


 > 
 > What do people think?
 > 
 > Kai
 > 

Request hint on error message

[Paul Kinnucan]

Torsten Geise writes:
 > Hi folks,
 > 
 > since I updated my JDEE to the latest version I always get the error message 
 > "error in process sentinel: file-truename: Apparent cycle of symbolic links 
 > for .". For more information I attached the "Submit problem report"-content 
 > to this mail.
 > 
 > Thanks for any hints, I'm looking for the solution since almost 2 weeks. 
 > Torsten.

It's possible that this is a problem with file-truename on your
operating system. file-truename is used by jde-root-dir-p, which is in
turn used by the JDEE to terminate its search up the directory tree
looking for project files. The error message suggests there might be
symbolic links in the directory tree containing a Java source file
that you are trying to load and that file-truename cannot handle the
symbolic links.

I've never encountered this problem but then I work mainly on Windows
and I do not use symbolic links on my Linux system.

Paul

Preconfigure align.el?

[Paul Kinnucan]

Kai Grossjohann writes:
 > I have this in ~/.emacs:
 > 
 > (eval-after-load "align"
 >   '(add-to-list 'align-c++-modes 'jde-mode))
 > 
 > (java-mode is already listed there by default.)
 > 
 > WIBNI this happened automatically?

Perhaps because Emacs does not support the notion of mode inheritance,
i.e., the value of major-mode in a jde-mode buffer is 'jde-mode, not
'(cc-mode java-mode jde-mode) so align has no way of knowing that
jde-mode is a subclass of java-mode.

Paul

XAE still viable?

[Paul Kinnucan]

Karr, David writes:
 > On a matter somewhat related to JDEE, I happened to notice the XAE package 
 > (that you wrote) associated with EIEIO. I hope you don't mind a direct 
 > question about this, but the mailing list seemed decidely inactive (I see 
 > more spam than real notes). It looks like this was developed quite a while 
 > ago (in web time). The information page about it doesn't actually say what 
 > it does. 

Actually, it does. It says it allows you to use Emacs to create,
transform, and display XML documents, which is exactly what it
does. The XAE website also explains my motivation for creating the
XAE, which is to help others avoid the hassle of downloading and
integrating all the tools one needs to create, transform, and display
XML documents, using Emacs. The XAE download includes psgml, Docbook
(the DTD and style sheets most widely used to create software doc),
and Saxon, a stylesheet processor. psgml turns Emacs into a
context-sensitive XML editor that ensures that you create a valid XML
document.  The XAE provides a menu of commands for applying style
sheets to the xml document in the current buffer (for example, to
generate PDF, HTML, or tex output), and for displaying the XML
document in the current buffer in an XML-capable browser, such as
Internet Explorer, or, for Docbook docs, that converts the XML
document in the current buffer to HTML, using Saxon and an XML->HTML
stylesheet, and displays it in an HTML browser.

>I noticed that when I tried to install it, it fails to find "psgml-maint" 
>(executing the byte-compile step). I'm guessing it was most recently updated 
>with a version of psgml prior to what's installed in my XEmacs (1.3.1, 
>apparently). The latest available version of XAE appears to be labeled a 
>"beta" version.  Do you believe this package is still viable?

I believe the XAE is viable. I use it regularly to maintain the doc
for the JDEE.  There haven't been any changes because I haven't found
it necessary to make any changes. It works great for me as it is.

>  Do you know what the "psgml-maint" problem is?

No.

Paul

patch for gnu emacs

[Paul Kinnucan]

Sam Steingold writes:
 > the appended patch is necessary to use JDEE with GNU Emacs.
 > 

Hi Sam,

This problem has already been fixed in the latest CVS version of jde.el.

Thanks,

Paul

 > -- 
 > Sam Steingold (http://www.podval.org/~sds) running w2k
 >   
 >  
 > Marriage is the sole cause of divorce.
 > 
 > diff -u -b -w -i -B "d:/gnu/sitelisp/jde/lisp/jde.el.old" 
 > "d:/gnu/sitelisp/jde/lisp/jde.el"
 > --- d:/gnu/sitelisp/jde/lisp/jde.el.old  2004-10-28 23:43:02.0 
 > -0400
 > +++ d:/gnu/sitelisp/jde/lisp/jde.el  2004-11-23 15:04:54.351027400 -0500
 > @@ -1247,12 +1247,12 @@
 >  (when (fboundp 'add-submenu) 
 >(add-submenu '("File") val "Insert File...")))
 >  (let* ((mb (assq 'menu-bar global-map))
 > -   (files (assq 'files mb))
 > +   (file (assq 'file mb))
 > (menu (if (fboundp 'easy-menu-create-menu)
 >   (easy-menu-create-menu 
 >(car val) (cdr val
 > (menu-name (car val)))
 > -  (define-key-after (cdr (cdr files)) [jde-new]
 > +  (define-key-after (cdr (cdr file)) [jde-new]
 >  (cons menu-name menu)
 >  'open-file)
 >  
 > 
 > Diff finished.  Tue Nov 23 15:11:56 2004
 > 

Re: Why does JDEE look for tools.jar

[Paul Kinnucan]

Suraj Acharya writes:
 > JDE also looks for tools.jar to check if a directory is a JDK
 > directory or not. Try creating
 > an empty tools.jar in the lib directory of your JDK. You will be able
 > to use the compile server, but it might let you used JDE with other
 > jdks.

The JDEE currently assumes that you are using Sun's toolset. I will
look into supporting other tool sets as time permits.

Paul


 > 
 > Suraj
 > 
 > 
 > On Mon, 22 Nov 2004 23:25:05 -0500, Matt Kurjanowicz
 > <[EMAIL PROTECTED]> wrote:
 > > The tools.jar is the file that contains the compiler.  This way JDEE can 
 > > run
 > > the compiler directly using the classpath that JDEE sets.
 > > -Matt
 > > 
 > > 
 > > 
 > > On Monday 22 November 2004 03:15 pm, Shyamal Prasad wrote:
 > > > Hi,
 > > >
 > > > I'm having trouble running JDEE (with both Emacs and XEmacs) on a
 > > > Debian GNU/Linux system. The problem is with finding the tools.jar
 > > > file. Since I'm using runtimes not licensed from Sun (sablevm, kaffe
 > > > etc.) this file is missing.
 > > >
 > > > Could some one explain to me (just a hint) why tools.jar is so
 > > > important to JDEE? I can run beanshell without it, and I'm not sure
 > > > what else might be needing it.
 > > >
 > > > Best regards,
 > > > Shyamal
 > > >
 > > > PS: I read this list via the web, so I would never complain about a Cc 
 > > > :-)
 > > 
 > > --
 > > Matthew Kurjanowicz
 > > [EMAIL PROTECTED]
 > > CS 2110 TA
 > > College of Computing
 > > GEORGIA Institute
 > > of TECHnology
 > >

Re: Buffer is read-only: #

[Paul Kinnucan]

Javier S. Lopez writes:
 > "Anderson, Timothy K" <[EMAIL PROTECTED]> writes:
 > 
 > > Hi,
 > > Using GNU Emacs CVS, JDE 2.3.4, CEDET 1.0beta3b.
 > >
 > > When trying to compile code with C-C C-V C-C,  I am getting the
 > > following error:
 > >
 > > save-excursion: Buffer is read-only: #
 > 
 > This looks familiar...
 > 
 > I had the problem when running the latest emacs from cvs. All the compilation
 > buffers are read only, I don't know what a good fix for this is. I just 
 > changed
 > the compile.el file to avoid making the buffers readonly. But we probably 
 > need
 > a better fix for this.
 > 

How can the compilation buffers be read-only and allows error and other messages
to be written into them? This sounds like a bug in the CVS version of Emacs.

Paul

 > 
 > Javier
 > 
 > >
 > > This happens every time - I think I have tried almost every combination
 > > of customize variables (at least, it feels that way).
 > > Has anyone else seen this?  What should I do to find the cause?
 > >
 > > Thanks for any help.
 > >
 > >
 > > Tim Anderson
 > >
 > >  
 > >
 > >
 > >
 > >
 > > 
 > > CONFIDENTIALITY
 > > This e-mail and any attachments are confidential and also may be 
 > > privileged.
 > > If you are not the named recipient, or have otherwise received this
 > > communication in error, please delete it from your inbox, notify the sender
 > > immediately, and do not disclose its contents to any other person,
 > > use them for any purpose, or store or copy them in any medium.
 > > Thank you for your cooperation.
 > > 
 > >
 > >
 > >
 > >
 > 
 > -- 
 > Javier S. Lopez
 > Software Developer
 > Forum Systems, Inc.
 > 95 Sawyer Road, Suite 110, Waltham, MA 02453
 > http://www.forumsys.com
 > 
 > 
 > The information contained in this electronic mail and any attached
 > document is the confidential and proprietary business information of
 > Forum Systems, Inc. It is intended solely for the addressed recipient
 > listed above. It may not be distributed in any manner without the
 > express written consent of Forum Systems, Inc.

Re: Problems debugging files with more than 1000 lines.

[Paul Kinnucan]

Hi Morten,

It's possible there is a regression. I will take a look
this evening to see if I can reproduce the problem. 

Just to be sure, which debugger are you using? The JDEE's
interface to jdb or JDEbug?

Paul

Morten writes:
 > fre, 2004-11-19 kl. 08:40 skrev Morten:
 > > tor, 2004-11-18 kl. 08:23 skrev Morten / Datagruppen MultiMED:
 > > > ons, 2004-11-17 kl. 22:21 skrev Javier S. Lopez:
 > > > > Morten <[EMAIL PROTECTED]> writes:
 > > > > 
 > > > > > ons, 2004-11-17 kl. 14:05 skrev Javier S. Lopez:
 > > > > >>   This has been fixed since version 2.3.4beta4
 > > 
 > > > 
 > > > > Not sure what to to tell you. Is is possible that the old version is 
 > > > > getting
 > > > > loaded somehow.
 > > > 
 > > > I would be rather surprised if that was the case.  When I click the jde
 > > > menu, and hold the mouse over "help", it displays "jde 2.3.4".
 > > 
 > > Is there another way of testing which version of JDE I am running?  It
 > > seems strange that I get the error that has been fixed ...
 > > 
 > > Morten .
 > 
 > Now I have deleted all other other versions of CEDET and JDE that I 
 > could find.  I tried to remove the path in .emacs, and jde refused to 
 > load.  I checked the sourcecode, and there are comments in the changelog
 > about the problem with linenumber > 999.  I wonder if a specific version
 > of java or something else might be required?  I use j2sdk 1.4.2_01.
 > 
 > I'm running GNU/Linux Debian sarge (and I purged both CEDET and jde from
 > the system, so that I only use the files I downloaded).
 > 
 > Please tell me what I can do to find out whats wrong with my system, 
 > since Javier seems to have no problem, I assume its my setup!
 > 
 >  Kind regards,
 >  Morten .
 > 
 > 
 > 
 > 

Synchronization issues in JDEbug

[Paul Kinnucan]

Hi Troy,

Thanks for pointing out these problems. I will try to fix them
ASAP.

Paul

Troy Daniels writes:
 > Hello,
 > 
 > It looks like JDEbug needs to have some methods synchronized.  I tried 
 > setting a breakpoint while the process was running, and got the following 
 > in the Message window:
 > 
 > >Setting breakpoint at line 85 in 
 > >d:/jaguar_te1.2/KBR_ISD_VOB/Jaguar_Plan_Generator_Component/source/PhysicalNetworkBuilder/com/alphatech/kbr/jaguar/networkbuilder/SpatialSpec.java.
 > >Error: evaluating debugger output caused a Lisp error.
 > >   See *messages* buffer for details.
 > >Error: evaluating output from the debugger caused a Lisp error.
 > >Debugger output: it.framework.TestSuite" "TestSuite.java" 208 "runTest")
 > >(list 25 "junit.framework.TestSuite" "TestSuite.java" 203 "run").
 > >Lisp error: (void-variable it.framework.TestSuite)
 > >Breakpoint set at line 85 in class 
 > >d:/jaguar_te1.2/KBR_ISD_VOB/Jaguar_Plan_Generator_Component/source/PhysicalNetworkBuilder/com/alphatech/kbr/jaguar/networkbuilder/SpatialSpec.java.
 > 
 > It also appears that, at least with JDK 1.4.2, there is a lot of useless 
 > traffic going from Java to emacs.   My *JDEBug* buffer is full of output 
 > that looks like
 > 
 > >(jde-dbo-event-set 1 "none"
 > >  (list "Thread" 1 "main" "runnable" "suspended by debugger"
 > >(list
 > >)))
 > 
 > Since jde-dbo-event-set is a no-op if the optional fourth arg is omitted, 
 > this slows down the debugger considerably.  If the java side checked for 
 > the fourth argument, is could avoid a lot of toString calls, bandwidth to 
 > Emacs and parsing of the string by Emacs.
 > 
 > Troy
 > 
 > 
 > 
 > Troy Daniels
 > [EMAIL PROTECTED]
 > 781-273-3388 x218
 > 

Re: Problem with JDEE 2.3.4

[Paul Kinnucan]

Jason Baker writes:
 > I have an idea for speeding up jde-open-source and
 > jde-find-and-import.  I'd like to see them read classes of the form
 > : from the minibuffer with standard emacs
 > completion.
 > 
 > Suppose you are trying to import the name C where p1.p2.p3.C and
 > p1.p4.p5.C are defined.  jde-find-and-import should prompt with.
 > `Choose a class to import: C:'  From there, one can type the first
 > letter of p1, , the first letter of p4, , , and get
 > an import of p1.p4.p5.C.  This is a lot faster than reaching for a
 > mouse, or any other option jde currently provides.

What happens if p2 and p4 begin with the same letter? In any event,
I'd be happy to see tab completion when a user has to choose 
among qualified class names. I've a lot of other things I'd
rather do at the moment, however, so it won't happen soon unless
someelse contributes the necessary Lisp.

Paul

RE: How to use Semantic Class Browser & conflict with "Source Files" browser

[Paul Kinnucan]

Karr, David writes:
 > Related to this, I noticed that the JDEE documentation on the web site
 > refers to a "Speedbar" menu item in the "JDE" menu.  I don't see that.
 > Is the documentation out of date wrt this version, or is there still
 > something wrong with my configuration?

The doc is out of date. JDE->Browse->Source Files
opens the speedbar.

Paul

 > 
 > > -Original Message-
 > > From: Karr, David 
 > > 
 > > I may be gettng into areas that are better asked on a list 
 > > specific to "semantic", but I'll start this here.
 > > 
 > > I've been using the "Source Files" mode of Speedbar, which 
 > > works pretty well.  I then tried selecting the "Speedbar 
 > > Class Browser" item under "Senator"->"Analyze" (or 
 > > right-clicking on the speedbar and selecting that display).  
 > > When I do this, the speedbar frame displays "Empty display" 
 > > (while I'm viewing a Java source file).  I'm not sure what 
 > > this feature is supposed to do.  I tried perusing the 
 > > Semantic documentation on the web site, but it doesn't really 
 > > say (afaict) what this is supposed to do.

jde stop working with cvs emacs

[Paul Kinnucan]

Dan Pomohaci writes:
 > Hi,
 > 
 > I upgraded my emacs from savannah.gnu.org cvs and jde doesn't work
 > anymore. The error is 
 > "(wrong-type-argument keymapp nil)"
 > 
 > I look in the jde.el and the problem is due to jde-new-buffer-menu:
 > ...
 >  (let* ((mb (assq 'menu-bar global-map))
 > (files (assq 'files mb))
 > (menu (if (fboundp 'easy-menu-create-menu)
 > ...
 > in menu-bar "files" is now "file":
 > ...
 >  (let* ((mb (assq 'menu-bar global-map))
 > (files (assq 'file mb))
 > (menu (if (fboundp 'easy-menu-create-menu)
 > ...
 > 
 > After this small modif jde work ok.

Thanks, somebody else already posted this problem and a patch and I have
applied the patch to the JDEE source for jde.el.

Paul

 > 
 > Best regards,
 > Dan
 > 
 >  

Re: jde-complete generates imports I don't want

[Paul Kinnucan]

Kai Grossjohann writes:
 > Paul Kinnucan <[EMAIL PROTECTED]> writes:
 > 
 > > Kai Grossjohann writes:
 > >  > Paul Kinnucan <[EMAIL PROTECTED]> writes:
 > >  > 
 > >  > > Kai Grossjohann writes:
 > >  > >  > Then position point after "this." and invoke jde-complete (in one 
 > > of
 > >  > >  > its flavors).  Observe how it adds an import statement for
 > >  > >  > javax.swing.Action.
 > >  > >
 > >  > > This is because javax.swing.Action is the only class on the classpath
 > >  > > at this point. Compile your Action class and then retry the 
 > > completion.
 > >  > > The JDEE should then prompt you to choose one of the Action classes
 > >  > > to import.
 > >  > 
 > >  > Hm.  I just invoked "javac Action.java", then tried again.  Now I get
 > >  > "no completion".  The environment variable $CLASSPATH starts with
 > >  > ".:", and Action.class is in the current working directory, together
 > >  > with Action.java and BTest.java.
 > >
 > > What is the setting of jde-resolve-relative-paths-p?
 > 
 > t

I asked this to determine whether the JDEE on your project was treating the
. character as meaning the current directory or the directory of the project
file for the current project.

The default setting of jde-resolve-relative-paths-p is t, which means
that the JDEE replaces the . in a path with the path of the directory
containing the project file for your project. If your project does not
have a project file, then the JDEE replaces the . with the path of the
current directory. I don't know whether you are using a project file
so I don't know how . is being resolved on your system.

In any case, I performed the following experiment

1. I created an environment variable CLASSPATH equal to a single . (period).

2. I restarted Emacs.

3. I created a directory named test.

4. In test, I created a file called Action.java containing

   public class Action {
public int foo() {
return 42;
}
   }

5. In test, I created a filed called BTest.java containing

   public class BTest extends Action {
public int bar() {
return this.
}
   }

6. I tried to complete 

 return this.

   The JDEE imported

javax.swing.Action;

   This is because the JDEE noticed that BTest extends a class named
   Action and the only class of that name on the classpath at this
   point is javax.swing.Action.

   The JDEE also signaled a no completion error. That is because
   BTest.java has not yet been compiled and hence is not on the classpath
   and hence cannot be completed because the JDEE only knows about classes
   that are on the classpath, i.e., that have been compiled.

7. I erased the import statement in BTest.java and changed 

   return this;
 
   to 

   return 1;

   so that BTest.java could be compiled.

8. I compiled Action.java and BTest.java.

9. In BTest.java, I changed the line

 return 1;

   to 

 return this.

10. I tried to complete

 return this.
 ^

The JDEE, as I expected, displayed a menu of the default members
that BTest class inherits from Class class for completion.

Based on this experiment, I believe that JDEE 2.3.4 handles the test case
that you presented correctly within its limitations, i.e., that it only
imports and completes things that are on the classpath.

Paul

Re: jde-complete generates imports I don't want

[Paul Kinnucan]

Kai Grossjohann writes:
 > Paul Kinnucan <[EMAIL PROTECTED]> writes:
 > 
 > > Kai Grossjohann writes:
 > >  > Then position point after "this." and invoke jde-complete (in one of
 > >  > its flavors).  Observe how it adds an import statement for
 > >  > javax.swing.Action.
 > >
 > > This is because javax.swing.Action is the only class on the classpath
 > > at this point. Compile your Action class and then retry the completion.
 > > The JDEE should then prompt you to choose one of the Action classes
 > > to import.
 > 
 > Hm.  I just invoked "javac Action.java", then tried again.  Now I get
 > "no completion".  The environment variable $CLASSPATH starts with
 > ".:", and Action.class is in the current working directory, together
 > with Action.java and BTest.java.

What is the setting of jde-resolve-relative-paths-p?

Paul

 > 
 > But this was just a test case, in the real code that I've got, I see
 > the same behavior I described originally, even though the code has
 > been compiled many times on this machine already, and a corresponding
 > *.jar file is mentioned in $CLASSPATH.
 > 
 > Originally, I thought that the problem comes from the "import foo.*"
 > statements in the *.java file -- I normally don't use asterisks in
 > import statements but the author of the file in question doesn't want
 > me to expand them.  Then I made this test case and observed the same
 > error.
 > 
 > What can I do to track down the problem?  Something weird must be
 > going on, but I don't know where to start looking.
 > 
 > Kai
 > 

RE: Any way to customize where import generates the import statement?

[Paul Kinnucan]

Karr, David writes:
 > > -Original Message-
 > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
 > > 
 > > Karr, David writes:
 > >  > Nope, that didn't help.  I first tried just renaming the 
 > > "semantic"  > directory in the xemacs tree, which didn't 
 > > help, so then I tried  > specifically uninstalling that 
 > > package from the Xemacs installer, and  > that also didn't 
 > > help.  It still inserts the imports at the top of the  > file.
 > > 
 > > David,
 > > 
 > > Does the Classes menu appear in the Java source buffer into 
 > > which you are trying to import classes. If so, does this 
 > > message correctly display the variables and methods of the 
 > > classes in that buffer?
 > > 
 > > Does the senator menu?
 > 
 > I'm not sure where to look for either of those menus.  I don't see
 > either "classes" or "senator" as either a top-level or second-level menu
 > item.

The fact that these menus are missing means that semantic is not
operative in JDEE buffers on your system, which in turn explains why
imports don't work correctly. There is something wrong with your
setup. A full problem report should reveal what is wrong.
 
> 
 > > Also please post a complete problem report so that we don't 
 > > have to guess what your setup is.
 > 
 > Send it to "[EMAIL PROTECTED]" as it specifies?

No, post it to the list. The more eyes on your problem, the better.

Paul


 > 
 > > 
 > > Paul
 > > 
 > >  
 > >  > 
 > >  > > -Original Message-
 > >  > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
 > >  > > Sent: Monday, November 15, 2004 2:44 PM
 > >  > > To: Karr, David
 > >  > > Cc: [EMAIL PROTECTED]
 > >  > > Subject: RE: Any way to customize where import generates the 
 > >  > > import statement?
 > >  > > 
 > >  > > 
 > >  > > Karr, David writes:
 > >  > >  > Note that my setup did not "replace" the version of 
 > >  > > Semantic, I just put  > it in the load-path before other 
 > >  > > instances of Semantic (and I verified  > that by inspecting 
 > >  > > the value after startup).  The User Guide  > specifically 
 > >  > > says to REMOVE the older instances.  Is there any reason to  
 > >  > > > expect this might be my problem?
 > >  > > 
 > >  > > Yes. XEmacs seems to always load packages included in the 
 > >  > > distribution before any packages on the load-path.
 > >  > > 
 > >  > > Paul
 > >  > > 
 > >  > > 
 > >  > >  > 
 > >  > >  > > -Original Message-
 > >  > >  > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
 > >  > >  > > Sent: Sunday, November 14, 2004 10:02 PM
 > >  > >  > > To: Karr, David
 > >  > >  > > Cc: [EMAIL PROTECTED]
 > >  > >  > > Subject: RE: Any way to customize where import 
 > > generates the 
 > >  > >  > > import statement?
 > >  > >  > > 
 > >  > >  > > 
 > >  > >  > > Karr, David writes:
 > >  > >  > >  > I see now that the user guide just says it 
 > > inserts at the 
 > >  > >  > > head of the  > buffer, but the code appears to be a little 
 > >  > >  > > more sophisticated, where it  > tries to figure out 
 > > where it 
 > >  > >  > > should insert the import  > 
 > >  > >  > > (jde-import-get-import-insertion-point).  However, 
 > > the result 
 > >  > >  > > is the  > same.  It just inserts the new import before the 
 > >  > >  > > package statement.  I  > guess I'll try a little 
 > > debugging of 
 > >  > >  > > that function.
 > >  > >  > > 
 > >  > >  > > Hi David,
 > >  > >  > > 
 > >  > >  > > The import statements are supposed to be inserted AFTER the 
 > >  > >  > > package statement. That's how it's always worked for me and 
 > >  > >  > > how it worked when I just tested it by creating:
 > >  > >  > > 
 > >  > >  > > file Foo.java
 > >  > >  > > package jmath;
 > >  > >  > > 
 > >  > >  > > class Foo {
 > >  > >  > >  JButton button;
 

another bug in JDEE 2.3.4

[Paul Kinnucan]

Jon Schewe writes:
 > You did a nice job of making sure pipes are used when executing java for
 > everything, except ant.  Below is the advice required to fix it.
 > 
 > 
 > (defadvice jde-ant-build (around fix-for-process-connection-type-2)
 >   "Fix process type to be pipes for java"
 >   (let ((process-connection-type nil))
 > (setq ad-return-value ad-do-it)))
 > 

Hi John,

I've updated jde-ant.el to force use of pipes. I also simplified the
code for jde-ant-build, which was unnecessarily prolix. Would you
please download the updated file from the JDEE's CVS repository and
test it to make sure that I did not introduce any regressions.

Paul

 > 
 > -- 
 > Jon Schewe | http://mtu.net/~jpschewe
 > GPG signature at http://mtu.net/~jpschewe/gpg.sig.html
 > For I am convinced that neither death nor life, neither angels 
 > nor demons, neither the present nor the future, nor any 
 > powers, neither height nor depth, nor anything else in all 
 > creation, will be able to separate us from the love of God that 
 > is in Christ Jesus our Lord. - Romans 8:38-39
 > 
 > 
 > 
 > 
 >   
 >   
 > 
 > 
 > You did a nice job of making sure pipes are used when executing java for 
 > everything, except ant.  Below is the advice required to fix it.
 > 
 > (defadvice jde-ant-build (around fix-for-process-connection-type-2)
 >   "Fix process type to be pipes for java"
 >   (let ((process-connection-type nil))
 >     (setq ad-return-value ad-do-it)))
 > 
 > 
 > 
 > 
 > -- 
 > Jon Schewe | http://mtu.net/~jpschewe
 > GPG signature at http://mtu.net/~jpschewe/gpg.sig.html
 > For I am convinced that neither death nor life, neither angels 
 > nor demons, neither the present nor the future, nor any 
 > powers, neither height nor depth, nor anything else in all 
 > creation, will be able to separate us from the love of God that 
 > is in Christ Jesus our Lord. - Romans 8:38-39
 > 
 > 
 > 
 > 
 > 
 > 
 > 

Problem with JDEE 2.3.4

[Paul Kinnucan]

Jon Schewe writes:
 > Can you please not override efc-query-options-function with a function
 > that creates a dialog box even if the user has asked XEmacs not to
 > display them under any circumstances?  Please rewrite this to pay
 > attention to the use-dialog-box variable.
 > 
 > `use-dialog-box' is a variable declared in Lisp.
 >   -- loaded from "/usr/share/xemacs/21.4.15/lisp/minibuf.elc"
 > 
 > Value: nil
 > 
 > Documentation:
 > *Variable controlling usage of the dialog box.
 > If nil, the dialog box will never be used, even in response to mouse
 > events.

The documentation for this variable has the archaic clarity of an
oracle. However, I have made the requested change to efc-xemacs.el.

Paul

 > 
 > -- 
 > Jon Schewe | http://mtu.net/~jpschewe
 > GPG signature at http://mtu.net/~jpschewe/gpg.sig.html
 > For I am convinced that neither death nor life, neither angels 
 > nor demons, neither the present nor the future, nor any 
 > powers, neither height nor depth, nor anything else in all 
 > creation, will be able to separate us from the love of God that 
 > is in Christ Jesus our Lord. - Romans 8:38-39
 > 
 > 
 > 
 > 
 >   
 >   
 > 
 > 
 > Can you please not override efc-query-options-function with a function that 
 > creates a dialog box even if the user has asked XEmacs not to display them 
 > under any circumstances?  Please rewrite this to pay attention to the 
 > use-dialog-box variable.
 > 
 > `use-dialog-box' is a variable declared in Lisp.
 >   -- loaded from 
 > "/usr/share/xemacs/21.4.15/lisp/minibuf.elc"
 > 
 > Value: nil
 > 
 > Documentation:
 > *Variable controlling usage of the dialog box.
 > If nil, the dialog box will never be used, even in response to mouse 
 > events.
 > 
 > 
 > 
 > 
 > -- 
 > Jon Schewe | http://mtu.net/~jpschewe
 > GPG signature at http://mtu.net/~jpschewe/gpg.sig.html
 > For I am convinced that neither death nor life, neither angels 
 > nor demons, neither the present nor the future, nor any 
 > powers, neither height nor depth, nor anything else in all 
 > creation, will be able to separate us from the love of God that 
 > is in Christ Jesus our Lord. - Romans 8:38-39
 > 
 > 
 > 
 > 
 > 
 > 
 > 

RE: Any way to customize where import generates the import statement?

[Paul Kinnucan]

Karr, David writes:
 > Nope, that didn't help.  I first tried just renaming the "semantic"
 > directory in the xemacs tree, which didn't help, so then I tried
 > specifically uninstalling that package from the Xemacs installer, and
 > that also didn't help.  It still inserts the imports at the top of the
 > file.

David,

Does the Classes menu appear in the Java source buffer into which you
are trying to import classes. If so, does this message correctly
display the variables and methods of the classes in that buffer?

Does the senator menu?

Also please post a complete problem report so that we don't have to
guess what your setup is.

Paul

 
 > 
 > > -Original Message-
 > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
 > > Sent: Monday, November 15, 2004 2:44 PM
 > > To: Karr, David
 > > Cc: [EMAIL PROTECTED]
 > > Subject: RE: Any way to customize where import generates the 
 > > import statement?
 > > 
 > > 
 > > Karr, David writes:
 > >  > Note that my setup did not "replace" the version of 
 > > Semantic, I just put  > it in the load-path before other 
 > > instances of Semantic (and I verified  > that by inspecting 
 > > the value after startup).  The User Guide  > specifically 
 > > says to REMOVE the older instances.  Is there any reason to  
 > > > expect this might be my problem?
 > > 
 > > Yes. XEmacs seems to always load packages included in the 
 > > distribution before any packages on the load-path.
 > > 
 > > Paul
 > > 
 > > 
 > >  > 
 > >  > > -Original Message-
 > >  > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
 > >  > > Sent: Sunday, November 14, 2004 10:02 PM
 > >  > > To: Karr, David
 > >  > > Cc: [EMAIL PROTECTED]
 > >  > > Subject: RE: Any way to customize where import generates the 
 > >  > > import statement?
 > >  > > 
 > >  > > 
 > >  > > Karr, David writes:
 > >  > >  > I see now that the user guide just says it inserts at the 
 > >  > > head of the  > buffer, but the code appears to be a little 
 > >  > > more sophisticated, where it  > tries to figure out where it 
 > >  > > should insert the import  > 
 > >  > > (jde-import-get-import-insertion-point).  However, the result 
 > >  > > is the  > same.  It just inserts the new import before the 
 > >  > > package statement.  I  > guess I'll try a little debugging of 
 > >  > > that function.
 > >  > > 
 > >  > > Hi David,
 > >  > > 
 > >  > > The import statements are supposed to be inserted AFTER the 
 > >  > > package statement. That's how it's always worked for me and 
 > >  > > how it worked when I just tested it by creating:
 > >  > > 
 > >  > > file Foo.java
 > >  > > package jmath;
 > >  > > 
 > >  > > class Foo {
 > >  > >  JButton button;
 > >  > > }
 > >  > > 
 > >  > > and doing C-c C-v C-z with point on JButton. The result is  > > 
 > >  > > package jmath;
 > >  > > 
 > >  > > import javax.swing.JButton;
 > >  > > 
 > >  > > public class Foo {
 > >  > >   JButton button;
 > >  > > }
 > >  > > 
 > >  > > 
 > >  > > I'm mystified that it works differently for you. Please send 
 > >  > > a test case that I can use to reproduce the bug.
 > >  > > 
 > >  > > Paul
 > >  > > 
 > >  > > 
 > >  > >  > 
 > >  > >  > > -Original Message-
 > >  > >  > > From: Karr, David 
 > >  > >  > > 
 > >  > >  > > Is there any way to customize where import statements are 
 > >  > >  > > generated?  It presently inserts them at the head of the 
 > >  > >  > > buffer, which means I still have to move them after they're 
 > >  > >  > > generated.  I always put imports in a block with no blank 
 > >  > >  > > lines, after the "package" statement, with a blank line 
 > >  > >  > > before and after the block.  I see there are options for 
 > >  > >  > > specifying how imports are grouped, but I assume that's 
 > >  > >  > > separate from where they're initially inserted.
 > >  > > 
 > >  > > 
 > > 
 > > 

jde-complete generates imports I don't want

[Paul Kinnucan]

Kai Grossjohann writes:
 > Create a file A.java with the following contents:
 > 
 > public class A {
 > public static int main(String[] args)
 > {
 > A a = new A();
 > a.@
 > }
 > }
 > 
 > Position point on "@", delete the character, then hit C-c C-v . and
 > observe how it adds "import org.apache.ecs.xhtml.a;" to the beginning
 > of the file.

Because there is a class named a on hyour classpath, the JDEE assumes
that you are trying to complete a static member of that class and
therefore creates an import statement for class a. As it is unlikely
that you will ever intend to use class a in your programs, you can
easily deal with this problem by excluding the org.apache.ecs class
from importation via jde-import-excluded-classes.


 > 
 > Or this one: create a file Action.java that looks like this:
 > 
 > public class Action {
 > public int foo() {
 > return 42;
 > }
 > }
 > 
 > Then create a file BTest.java that looks like this:
 > 
 > public class BTest extends Action {
 > public int bar() {
 > return this.
 > }
 > }
 > 
 > Then position point after "this." and invoke jde-complete (in one of
 > its flavors).  Observe how it adds an import statement for
 > javax.swing.Action.

This is because javax.swing.Action is the only class on the classpath
at this point. Compile your Action class and then retry the completion.
The JDEE should then prompt you to choose one of the Action classes
to import.

Paul

 > 
 > Is it pilot error?
 > 
 > Is it just me?
 > 
 > Kai
 > 
 > PS: Using jde 2.3.4 on GNU Emacs 21.3.50.1 (i386-pc-linux-gnu, X
 > toolkit, Xaw3d scroll bars) of 2004-11-02 on ketchup, modified by
 > Debian.
 > 

RE: Any way to customize where import generates the import statement?

[Paul Kinnucan]

Karr, David writes:
 > Note that my setup did not "replace" the version of Semantic, I just put
 > it in the load-path before other instances of Semantic (and I verified
 > that by inspecting the value after startup).  The User Guide
 > specifically says to REMOVE the older instances.  Is there any reason to
 > expect this might be my problem?

Yes. XEmacs seems to always load packages included in the distribution
before any packages on the load-path.

Paul


 > 
 > > -Original Message-
 > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED] 
 > > Sent: Sunday, November 14, 2004 10:02 PM
 > > To: Karr, David
 > > Cc: [EMAIL PROTECTED]
 > > Subject: RE: Any way to customize where import generates the 
 > > import statement?
 > > 
 > > 
 > > Karr, David writes:
 > >  > I see now that the user guide just says it inserts at the 
 > > head of the  > buffer, but the code appears to be a little 
 > > more sophisticated, where it  > tries to figure out where it 
 > > should insert the import  > 
 > > (jde-import-get-import-insertion-point).  However, the result 
 > > is the  > same.  It just inserts the new import before the 
 > > package statement.  I  > guess I'll try a little debugging of 
 > > that function.
 > > 
 > > Hi David,
 > > 
 > > The import statements are supposed to be inserted AFTER the 
 > > package statement. That's how it's always worked for me and 
 > > how it worked when I just tested it by creating:
 > > 
 > > file Foo.java
 > > package jmath;
 > > 
 > > class Foo {
 > >  JButton button;
 > > }
 > > 
 > > and doing C-c C-v C-z with point on JButton. The result is
 > > 
 > > package jmath;
 > > 
 > > import javax.swing.JButton;
 > > 
 > > public class Foo {
 > >   JButton button;
 > > }
 > > 
 > > 
 > > I'm mystified that it works differently for you. Please send 
 > > a test case that I can use to reproduce the bug.
 > > 
 > > Paul
 > > 
 > > 
 > >  > 
 > >  > > -Original Message-
 > >  > > From: Karr, David 
 > >  > > 
 > >  > > Is there any way to customize where import statements are 
 > >  > > generated?  It presently inserts them at the head of the 
 > >  > > buffer, which means I still have to move them after they're 
 > >  > > generated.  I always put imports in a block with no blank 
 > >  > > lines, after the "package" statement, with a blank line 
 > >  > > before and after the block.  I see there are options for 
 > >  > > specifying how imports are grouped, but I assume that's 
 > >  > > separate from where they're initially inserted.
 > > 
 > > 

RE: Any way to customize where import generates the import statement?

[Paul Kinnucan]

Karr, David writes:
 > I see now that the user guide just says it inserts at the head of the
 > buffer, but the code appears to be a little more sophisticated, where it
 > tries to figure out where it should insert the import
 > (jde-import-get-import-insertion-point).  However, the result is the
 > same.  It just inserts the new import before the package statement.  I
 > guess I'll try a little debugging of that function.

Hi David,

The import statements are supposed to be inserted AFTER the package
statement. That's how it's always worked for me and how it worked when I just 
tested it by creating:

file Foo.java
package jmath;

class Foo {
 JButton button;
}

and doing C-c C-v C-z with point on JButton. The result is

package jmath;

import javax.swing.JButton;

public class Foo {
  JButton button;
}


I'm mystified that it works differently for you. Please send a test case that I 
can use to reproduce the bug.

Paul


 > 
 > > -Original Message-
 > > From: Karr, David 
 > > 
 > > Is there any way to customize where import statements are 
 > > generated?  It presently inserts them at the head of the 
 > > buffer, which means I still have to move them after they're 
 > > generated.  I always put imports in a block with no blank 
 > > lines, after the "package" statement, with a blank line 
 > > before and after the block.  I see there are options for 
 > > specifying how imports are grouped, but I assume that's 
 > > separate from where they're initially inserted.

Import generation problems

[Paul Kinnucan]

Karr, David writes:
 > For the longest time, I've only barely used the features of JDE.  I'm
 > now looking at it a little closer.
 > 
 > I'm using version 2.3.2, in Xemacs/Cygwin.
 > 
 > I set up a "prj.el" file, and I set the "jde-global-classpath" there, so
 > I could get import generation (jde-import-find-and-import) working.  I
 > find that this works much of the time, but fails to find some classes,
 > but I'm not sure why.
 > 
 > In fact, it almost seems like it doesn't find any classes that would
 > have been reached by my setting of jde-global-classpath.  It finds
 > classes in the JDK, but none in my related projects or jar files.
 > 
 > Here is my "prj.el" contents:
 > 
 > -
 > (setq jde-global-classpath
 >  (quote
 >   ("common/cmcmbeans/build/cmcmbeans.jar"
 >"common/serviceregistry/build/esbserviceregistry.jar"
 >"CMC/common/cmcgui/build/cmcgui.jar"
 >"lib/weblogic.jar"
 >)))
 > -
 > 
 > These jar files all exist, relative to the directory the "prj.el" file
 > is in.

You should update to the latest version of the JDEE that is several years
old. A lot of water has flowed under the bridge since then. 

You should also read the section on project-relative paths in the JDEE
user's guide. The reason the JDEE cannot find that classes in your
projects is that you have incorrectly specified the paths. To specify
a path relative to the project file directory, you must use the period
(.) character, e.g.,

  ./common/cmcmbeans/build/cmcmbeans.jar

Paul

Patch: File menu in recent CVS Emacs no longer called 'files

[Paul Kinnucan]

Jason Rumney writes:
 > 
 > The File menu has recently been renamed from 'files to 'file in Emacs
 > CVS. This has revealed a dependancy in JDEE that can easily be fixed
 > by using menu-bar-file-menu (which has existed since at least 19.27)
 > which also simplifies the code a little:
 > 

Hi Jason,

I have applied your patch to the JDEE source. Thanks for providing a
fix for this problem.

Paul

 > 
 > *** jde.el-orig Fri Oct 29 00:43:02 2004
 > --- jde.el  Wed Nov 10 23:09:59 2004
 > ***
 > *** 1247,1258 
 > (when (fboundp 'add-submenu)
 >   (add-submenu '("File") val "Insert File...")))
 > (let* ((mb (assq 'menu-bar global-map))
 > -  (files (assq 'files mb))
 >(menu (if (fboundp 'easy-menu-create-menu)
 >  (easy-menu-create-menu
 >   (car val) (cdr val
 >(menu-name (car val)))
 > ! (define-key-after (cdr (cdr files)) [jde-new]
 > (cons menu-name menu)
 > 'open-file)
 > 
 > --- 1247,1257 
 > (when (fboundp 'add-submenu)
 >   (add-submenu '("File") val "Insert File...")))
 > (let* ((mb (assq 'menu-bar global-map))
 >(menu (if (fboundp 'easy-menu-create-menu)
 >  (easy-menu-create-menu
 >   (car val) (cdr val
 >(menu-name (car val)))
 > ! (define-key-after menu-bar-file-menu [jde-new]
 > (cons menu-name menu)
 > 'open-file)

Add capability to jdee to read source file in jar file

[Paul Kinnucan]

Christophe writes:
 > I have made a couple of modification to jdee to have the capability to
 > open source file directly from jar file (if jar file is specified in
 > jde-sourcepath)
 > 
 > this modification are based on code found in arc-mode.
 > 
 > I have modified the function "jde-find-class-source-file"
 > and re-write the function "jde-search-src-dirs"
 > 
 > Maybe it is possible to add this modification to jdee for future release.
 > I'm not an expert lisp coder, if something is wrong, tou can mdofiy this
 > code without hesitating

Hi Christophe,

Thanks for contributing this useful enhancement. I have updated
jde-util.el to include your contribution, making a few changes to
simplify the code. Your contribution will require a similar
enhancement to be made to the command for finding the definition of
the symbol at point so that it supports symbols defined in source code
stored in jar and zip files. I plan to make this enhancement as soon
as possible. Users who want to get your enhancement can do so by
downloading the latest version of jde-util.el from the JDEE CVS
repository.

Paul


 > 
 > Christophe
 > 
 > ; jde-search-src-dirs ;;;
 > (defun jde-find-class-source-file (class)
 >   "*Find the source file for a specified class.
 > CLASS is the fully qualified name of the class. This
 > function searchs the source file paths specified by
 > `jde-sourcepath' for the source file
 > corresponding to CLASS. If it finds the source file,
 > it returns the file's path. Otherwise, it returns nil."
 >   (let* ((class (jde-remove-inner-class class))
 >  (source-dir (jde-search-src-dirs class))
 >  (file-name
 >   (concat (jde-parse-get-unqualified-name class)
 >   ".java")))
 >  (if source-dir
 >  (if (not (string= source-dir "jar-src"))
 >   (expand-file-name file-name source-dir)
 > )
 >(message "JDE error: Could not find source for \"%s\". See
 > `jde-sourcepath' for more information." class)
 >nil)))
 > ;
 > 
 > ; jde-search-src-dirs ;;;
 > (defun jde-search-src-dirs(class)
 > ;;(interactive)
 > ;;(setq class (read-buffer "CLASS: "))
 >(let ((file (concat
 >  (jde-parse-get-unqualified-name class)
 >  ".java"))
 >   (package (jde-parse-get-package-from-name class))
 >   )
 > (catch 'found
 >   (loop for dir in jde-sourcepath do
 >  (progn
 >(setq dir(jde-normalize-path dir 'jde-sourcepath))
 >(setq extractor nil)
 >(if (and (or (string-match "\.jar$" dir)
 > (string-match "\.zip$" dir)
 > )
 > (file-exists-p dir))
 >(progn
 >  (let* ((other-window-p nil)
 > (pkg-path (subst-char-in-string ?. ?/ package))
 > (view-p (eq other-window-p 'view))
 > (class-file-name (concat  pkg-path "/" file))
 > (bufname (concat file " (" (file-name-nondirectory 
 > dir) ")"))
 > (buffer (get-buffer bufname))
 > (just-created nil)
 > exit-status success)
 >(if buffer
 >(progn
 >  (or (not (buffer-name buffer))
 >  (progn
 >(if view-p
 >(view-buffer buffer (and just-created 
 > 'kill-buffer))
 >  (if (eq other-window-p 'display)
 >  (display-buffer buffer)
 >(if other-window-p
 >(switch-to-buffer-other-window buffer)
 >  (switch-to-buffer buffer)))
 >  )))
 >  )
 >  (setq buffer (get-buffer-create bufname))
 >  (setq just-created t)
 >  (save-excursion
 >(set-buffer buffer)
 >(setq buffer-file-name (expand-file-name (concat dir 
 > ":"
 > class-file-name)))
 >(setq buffer-file-truename file)
 >(setq default-directory (file-name-directory dir))
 >(setq exit-status (archive-extract-by-stdout dir 
 > class-file-name
 > archive-zip-extract))
 >(message "status:%s" exit-status)
 >(if (and (numberp exit-status) (= exit-status 0))
 >(progn
 >  (message "found");
 >  (setq buffer-read-only t)
 >  (goto-char (point-min))
 >

[ANNOUNCEMENT] JDEE 2.3.4 available at ...

[Paul Kinnucan]

http://jdee.sunsite.dk/rootpage.html#Downloading

JDE 2.3.4

***
* PLEASE READ *
***
* *
* This release requires cedet 1.0beta2 or later. cedet*
* includes semantic, eieio, speedbar, and senator, all*
* packages required by the JDEE. You can obtain cedet *
* at http://cedet.sourceforge.net *
* *
* Please note that your .emacs file must "load" cedet.el, *
* not "require" cedet. See the installation instructions  *
* that come with the cedet package for more information.  *
* *
* This release requires version 1.2.2 (or later) of the   *
* JDK.*
* *
* This release also requires avltree.el, which is part of the *
* elib 1.0 package. You can obtain elib at the JDE web site   *
* in compressed tar (http://jdee.sunsite.dk/elib.tar.gz)  *
* or zip (http://sunsite.dk/jde/elib.zip) format. *
* *
* JDEbug runs on Windows 2000 only if Service Pack 2 (or  *
* later) is installed.*
* *
* If syntax-coloring does not work, download and install  *
* overlay-fix.el from the semantic web site.  *
* *
***

* After compiling a class, the JDEE updates its class info database
  from the directory containing the compiled class instead
  of from the entire project classpath.

  Thanks to Martin Schwamberger.

* Fixed regression that caused JDEbug to issue a Lisp error
  when launching an application.

* Fixed bug in the JDEE's dynamic class loader caused by assuming 
  that only one read operation is needed to read a class from the 
  file system. This was causing class load errors that were
  suppressed by exception handling in the dynamic class loader.

  Thanks to Suraj Acharya.

* Configured Emacs to always use pipes to interact with
  the BeanShell. This fixes code 129 errors that occur on some 
  Linux systems.

Installation Help Requested

[Paul Kinnucan]

fred astaire writes:
 > Howdy,
 > 
 > I have just installed emacs version 21.2.1 on Windows
 > 2000.  I then installed Cygwin and ran the
 > install-jde.sh script with the following results:
 > 
 >  Warning! Please note, this script now uses CEDET -
 > all in one packages
 >  instead of separate packages for additional tools
 > like:
 >  EIEIO, SEMANTIC and SPEEDBAR.
 >  Don't forget to change load-path settings to include
 >  'cedet/package' instead of separate 'package'.
 >  You can do it just to replace existings setting with
 > one simple:
 >  (load-file
 > "~/.emacs.d/site-lisp/cedet/common/cedet.el")
 > 
 > 10:13:37 URL:http://jdee.sunsite.dk/jde-beta.tar.gz
 > [3675721/3675721] -> "jde-tmp/jde.tar.gz" [1]
 > 10:13:40 URL:http://jdee.sunsite.dk/elib-1.0.tar.gz
 > [58335/58335] -> "jde-tmp/elib.tar.gz" [1]
 > 10:14:15
 > URL:http://heanet.dl.sourceforge.net/sourceforge/cedet/cedet-1.0beta3a.tar.gz
 > [1270296/1270296] -> "jde-tmp/cedet.ta
 > r.gz" [1]
 > 10:14:22 URL:http://www.beanshell.org/bsh-2.0b2.jar
 > [280737/280737] -> "jde-tmp/bsh.jar" [1]
 > tar (GNU tar) 1.13.25 Copyright (C) 2001 Free Software
 > Foundation, Inc. This program comes with NO WARRANTY,
 > to the extent pe
 > rmitted by law. You may redistribute it under the
 > terms of the GNU General Public License; see the file
 > named COPYING for det
 > ails. Written by John Gilmore and Jay Fenlason.
 > 
 >  Warning! Please note, this script now uses CEDET -
 > all in one packages
 >  instead of separate packages for additional tools
 > like:
 >  EIEIO, SEMANTIC and SPEEDBAR.
 >  Don't forget to change load-path settings to include
 >  'cedet/package' instead of separate 'package'.
 >  You can do it just to replace existings setting with
 > one simple:
 >  (load-file
 > "~/.emacs.d/site-lisp/cedet/common/cedet.el")
 > 
 > 
 > I then copied the contents of ~/.emacs.d/site-lisp to
 > /emacs/addons
 > 
 > Finally, I created the minimal .emacs file:
 > 
 > (load-file "c:/emacs/addons/cedet/common/cedet.el")
 > (add-to-list 'load-path "c:/emacs/addons/elib")
 > (add-to-list 'load-path "c:/emacs/addons/jde/lisp")
 > 
 > (require 'jde)
 > 
 > and when I start emacs, I get:
 > 
 > Debugger entered--Lisp error: (void-function
 > custom-autoload)

Hi Fred,

I've never encountered this problem myself on either Linux or
Windows. However, a colleague had the same problem on his
Linux machine. I searched but could not find any package
on his machine that defines a symbol named custom-autoload. 
It was very frustrating.

Anyway, in desperation, I suggested that
my colleague try putting the following dummy function
in his .emacs file:

(defun custom-autoload (&rest args))

That seemed to work.

I hope somebody else can shed some light on this phantom
function. I've grepped through all the Lisp files on
my Windows machine and cannot find any Lisp file that defines this
function.  It's very bizarre.


Paul 


 >   (custom-autoload (quote
 > global-semantic-decoration-mode)
 > "semantic-decorate-mode")
 >   eval-buffer(#> nil
 > "semantic-loaddefs" nil t)
 >  
 > load-with-code-conversion("c:/emacs/addons/cedet/semantic/semantic-loaddefs.el"
 > "semantic-loaddefs" nil t)
 >   load("semantic-loaddefs" nil t)
 >   require(semantic-fw)
 >   eval-buffer(#> nil "semantic-load"
 > nil t)
 >  
 > load-with-code-conversion("c:/emacs/addons/cedet/semantic/semantic-load.el"
 > "semantic-load" nil t)
 >   require(semantic-load)
 >   eval-buffer(#> nil "jde" nil t)
 >  
 > load-with-code-conversion("c:/emacs/addons/jde/lisp/jde.el"
 > "jde" nil t)
 >   require(jde)
 >   eval-buffer(# nil "~/.emacs" nil t)
 >   load-with-code-conversion("c:/.emacs" "~/.emacs" t
 > t)
 >   load("~/.emacs" t t)
 >   #[nil " (*followed by control characters*)
 > command-line()
 >   normal-top-level()
 > 
 > The messages buffer reads:
 > (C:\emacs\bin\emacs.exe --debug-init)
 > Loading c:/emacs/addons/cedet/common/cedet.el
 > (source)...
 > "c:/emacs/addons/cedet/common/" added to `load-path'
 > Loading cl-macs...done
 > "c:/emacs/addons/cedet/cogre" added to `load-path'
 > "c:/emacs/addons/cedet/ede" added to `load-path'
 > "c:/emacs/addons/cedet/eieio" added to `load-path'
 > "c:/emacs/addons/cedet/semantic" added to `load-path'
 > "c:/emacs/addons/cedet/speedbar" added to `load-path'
 > "c:/emacs/addons/cedet/contrib" added to `load-path'
 > Setting up cedet...done
 > Setting up cogre...done
 > Setting up ede...done
 > Setting up eieio...done
 > Setting up semantic...
 > Loading derived...done
 > Loading advice...done
 > Loading font-lock...
 > Loading regexp-opt...done
 > Loading font-lock...done
 > Loading c:/emacs/bin/fns-21.2.1.el (source)...done
 > eval-buffer: 
 > Symbol's function definition is void: custom-autoload
 > Setting up speedbar...done
 > Setting up cedet-contrib...done
 > Loading c:/emacs/addons/cedet/common/cedet.el
 > (source)...done
 > Loading image...done
 > Loading easymenu...done
 > eval-buffer: 
 > Loading debug...done
 > Entering debugger...
 >  [2 times]
 >

Getting method name?

[Paul Kinnucan]

Brian O'Connell writes:
 > 
 > Sorry if this has been hashed out before in previous mailing list 
 > threads..  But I have been unable to find it in the archives.
 > 
 > Is there a proper way to get the current method name?  I am trying to 
 > use it in a temp-template that I have for automatically generating 
 > logging entering and exit lines.

Try:

(defun jde-get-method-name ()
  "Get the name of the method at point."
  (cdar (jde-parse-get-method-at-point)))

 > 
 > I have written the following:  (excuse my patently poor lisp 
 > programming... I am new to it)
 > 
 > ;; Get the method name for the current method
 > (defun jde-get-method-name ()
 >   "Insert entering and exiting logging lines."
 >   (let (name
 > (jde-parse-get-method-at-point))
 >   
 >(if name
 >   (let* ((name-pair (car name))
 > (class (car name-pair)) )
 > (cdr name-pair)
 >   )
 >)
 >  )
 > )
 > 
 > 
 > 
 > It often returns nothing..  
 > 
 > I appreciate any ideas
 > 
 > 
 > Thanks!

jdee debug error: Comint exited abnormally with code 129

[Paul Kinnucan]

patrick duval writes:
 > Hello,
 > 
 > On linux fedora-core-2 I get a "Comint exited abnormally with code 129"
 > error message when trying to debug any java app with jdee:
 > 
 >   Comint exited abnormally with code 129
 > 
 > NB: the same jdb command submitted in a shell runs fine.
 > 
 > NB: I don't get this error on MacOS X using the same versions of emacs
 > and jdee.
 > 
 > I found a message on this issue in the mail archive, but no answer to
 > it (http://www.mail-archive.com/[EMAIL PROTECTED]/msg07772.html).
 > 
 > Any progress on that issue?

Try JDEE 2.3.4beta5.

Paul

 > 
 > This error arises in the following environment:
 > 
 > platform: linux fedora-core-2
 > jdee version: 2.3.3
 > emacs version:  21.3.1
 > *Backtrace* buffer: none
 > *JDEEbug* buffer: none
 > prj.el: none
 > 
 > jdee debug buffer:
 > 
 > cd /home/der_gi/duval/hello/
 > /usr/local/java/bin/jdb -launch -classpath /home/der_gi/duval/hello HelloYou
 > Comint exited abnormally with code 129
 > 
 > 
 > *compile* buffer:
 > 
 >   cd /home/der_gi/duval/hello/
 >   /usr/local/java/bin/javac -classpath /home/der_gi/duval/hello -g HelloYou.java
 >   Compilation finished at ...
 > 
 > 
 > emacs startup file:
 > 
 > (setq debug-on-error t)
 > (setq load-path (append load-path (list "~/elisp")))
 > (if (and (boundp 'window-system) window-system)
 > (if (string-match "XEmacs" emacs-version)
 >  (require 'sym-lock)
 >   (require 'font-lock)))
 > ;; font-lock colorized minor modes
 > (global-font-lock-mode t)
 > ;; jde mode for Java
 > (cond
 >  (window-system
 >   ;; nb: the order of semantic and jde invocations below is mandatory
 >   ;; (setq semantic-load-turn-everything-on nil) makes jde bug
 >   (setq semantic-load-turn-useful-things-on t)
 >   (add-to-list 'load-path "/usr/share/emacs/site-lisp/jde/lisp")
 >   (add-to-list 'load-path "/usr/share/emacs/site-lisp/semantic")
 >   (add-to-list 'load-path "/usr/share/emacs/site-lisp/speedbar")
 >   (add-to-list 'load-path "/usr/share/emacs/site-lisp/elib")
 >   (add-to-list 'load-path "/usr/share/emacs/site-lisp/eieio")
 >   (require 'jde)
 >   ;; get rid of semantic's header-line and deco
 >   (global-semantic-stickyfunc-mode -1)
 >   (global-semantic-decoration-mode -1)
 >   ;; Set c-basic-offset to 2 for indents in java-mode
 >   (add-hook 'jde-mode-hook (lambda () (setq c-basic-offset 2)
 > 
 > ;; Set JDE default classpath to "." for java, and use javac -g option
 > (custom-set-variables
 >  ;; custom-set-variables was added by Custom -- don't edit or cut/paste it!
 >  ;; Your init file should contain only one such instance.
 >  '(jde-compiler (quote ("javac" "")))
 >  '(jde-global-classpath (quote (".")))
 >  '(jde-sourcepath (quote (".")))
 >  '(jde-compile-option-debug (quote ("all" (t nil nil
 >  )
 > 
 > 
 > *Messages* Buffer:
 > 
 > (emacs -q -l .emacs-jde.el)
 > Loading disp-table...done
 > Loading tool-bar...done
 > Loading image...done
 > Loading tooltip...done
 > Loading /usr/share/emacs/site-lisp/site-start.d/lang-coding-systems-init.el 
 > (source)...done
 > Loading /usr/share/emacs/site-lisp/site-start.d/mew-init.el (source)...
 > Loading /usr/libexec/emacs/21.3/i386-redhat-linux/fns-21.3.1.el (source)...done
 > Loading /usr/share/emacs/site-lisp/site-start.d/mew-init.el (source)...done
 > Loading /usr/share/emacs/site-lisp/site-start.d/php-mode-init.el (source)...done
 > Loading /usr/share/emacs/site-lisp/site-start.d/po-mode-init.el (source)...done
 > Loading /usr/share/emacs/site-lisp/site-start.d/psgml-init.el (source)...done
 > Loading /usr/share/emacs/site-lisp/site-start.d/python-mode-init.el (source)...done
 > Loading /usr/share/emacs/site-lisp/site-start.d/rpm-spec-mode-init.el 
 > (source)...done
 > Loading /usr/share/emacs/site-lisp/site-start.d/ruby-mode-init.el (source)...done
 > Loading regexp-opt...done
 > Loading easymenu...done
 > Loading derived...done
 > Loading semantic-idle...done
 > Loading semanticdb...done
 > Loading semantic-decorate-mode...done
 > Loading senator...done
 > Loading mule-util...done
 > jde-java-font-lock: building names cache...empty
 > Loading wisent-java-tags...done
 > Loading cl-seq...done
 > Setting JDE variables to startup values...
 > Loading semantic-edit...done
 > Loading semanticdb-file...done
 > Mark set [2 times]
 > Loading jde-javadoc...
 > Setting JDE variables to startup values...
 > Loading jde-javadoc...done
 > (No files need saving)
 > No compilation errors
 > Flushed completion cache.
 > Mark set [2 times]
 > 
 > 
 > *Buffer List* buffer:
 > ---

Re: JDEE Wiki?

[Paul Kinnucan]

Hi,

I think a Wiki page is a good idea. I'm not sure, however, that EmacsWiki
is the best host for JDEEWiki. I want to give it some thought. If we
decide that EmacsWiki is the best place, we will need to clean up
and reorganize the existing page. I would put a link from the JDEE
website to the JDEE Wiki page at EmacsWiki.

Paul


Andrew Hyatt writes:
 > Yeah, I second the motion of using the Emacs Wiki - that would be the 
 > most natural place for it.   A lot of things that come up are related 
 > to other Emacs packages, so the cross-referencing would be useful.
 > 
 > On Oct 18, 2004, at 5:05 PM, Ole Arndt wrote:
 > 
 > > Hi Nascif,
 > >
 > > "Nascif Abousalh-Neto" <[EMAIL PROTECTED]> writes:
 > >
 > >> Have you considered hosting a Wiki for the JDEE? I think it would cut
 > >> a lot on basic questions, as it would be a more friendly way for JDEE
 > >> users to share and organize their knowledge, tips, etc. It would
 > >> definetely be more effective than browsing the mailing list.
 > >
 > > Why don't you use the EmacsWiki? [http://emacswiki.org]. Hey, you have
 > > a user page there,so you know it. There is already a page for JDEE:
 > > http://www.emacswiki.org/cgi-bin/wiki/JavaDevelopmentEnvironment
 > > Let's extend it.
 > >
 > >> A Wiki with attachments capabilities (like JSPWiki) would also make it
 > >> easier for users to post their own patches, plugins, etc.
 > >
 > > Ok, binaries are not possible on the EmacsWiki, but do we need it?
 > > code snippets or pointers to supplementary packages should suffice.
 > >
 > > -- 
 > > Ole Arndt http://www.sugarshark.com
 > >
 > >
 > 

Re: [PATCH] Jikes bootclasspath

[Paul Kinnucan]

[EMAIL PROTECTED] writes:
 > Len Trigg <[EMAIL PROTECTED]> writes:
 > 
 > > Sending this to the main jde list for more discussion. Background: I
 > > wrote this patch so that the system classes (rt.jar) would be added to
 > > jikes command line using -bootclasspath rather than -classpath. This
 > > was to prevent a conflict in versions between any inherited
 > > BOOTCLASSPATH environment variable (see jikes manpage), and the rt.jar
 > > located by jde (which can depend on the jde-jdk variable for
 > > targetting different JVM versions). (I encountered this problem which
 > > is why I wrote the patch). The question is, what is the best way to
 > > add the system classes when using jikes. Javier indicates that using
 > > -bootclasspath may interfere with people using it for other purposes
 > > (but at this point I'm not sure how)
 > 
 > Mainly I don't like messing around with users settings. The particular case I
 > was referring was if the rt.jar gets appended before any of the user customized
 > bootclasspath. The classes could get compiled against the wrong class files,
 > causing problems at runtime. Your patch does not have this problem since rt.jar
 > gets appended to the bootclasspath.
 > 
 > >
 > >
 > > Javier S. Lopez wrote:
 > >> Could you send me the patch? The attachment you sent seems to be empty.
 > >
 > > Sure, here it is, inlined:
 > >
 > >
 > > Thus jikes gets the non-overridden definition of
 > > jde-compile-classpath-arg, and the inferred system classes are added
 > > using -bootclasspath
 > >
 > >
 > >> I took a look at Ant and I was mistaken about its behavior. Ant does not add
 > >> anything at all to the classpath or boot class path. Perhaps we should do the
 > >> same.
 > >
 > > As in, using the jikes compiler doesn't require either
 > > classpath/bootclasspath parameters in the build.xml or environment
 > > variables to be set in order to work?  Then they must be adding an
 > > implicit rt.jar to jikes somehow when they invoke it (otherwise jikes
 > > wouldn't be able to compile it).
 > 
 > Originally I thought that they were adding rt.jar either to the classpath or
 > bootclasspath. This is not the case though, users need to add rt.jar to the
 > claspath or bootclasspth in build.xml
 > 
 > 
 > A good solution for this is something along this lines:
 > jde-compile-option-jikes-classpath
 > Location to add system classes:
 > (*) bootclasspath
 > ( ) classpath
 > ( ) none
 > 
 > Classes:
 > INS DEL: /jre/lib/rt.jar
 > INS

I don't see the need for the () none option as you can simply
delete all entries. I suggest the following:

jde-jikes-system-classpath

Compiler option used to specify system classpath:
 (*) -bootclasspath
 ( ) -classpath
 
 System classpath:
 INS DEL: /jre/lib/rt.jar
 INS


Paul


 > 
 > This will allow users to choose the location or disable the functionality
 > altogether. In addition it will allows users to add other jar files like:
 > jce.jar and jsse.jar
 > 
 > Javier
 > >
 > > Cheers,
 > > Len.
 > >
 > 

Re: [PATCH] jde-junit.el

[Paul Kinnucan]

Ole Arndt writes:
 > Paul Kinnucan <[EMAIL PROTECTED]> writes:
 > 
 > > This command will also use a customization variable that I plan to
 > > implement named,
 > >
 > >   jde-junit-test-case-directory
 > >
 > > that will allow you to specify where test cases are located for
 > > a project. My thought is to allow you to specify one of two locations:
 > >
 > >   - same directory as the classes to be tested
 > >   - a specified directory beneath the classes to be tested,
 > > e.g., unittest.
 > >
 > > Please let me know if you know of other places that people 
 > > commonly store test cases.
 > 
 > A very common scheme is to have the java source files of a project
 > under one top directory and to use a parallel directory hierarchy for
 > the test sources.  All projects managed with maven follow this scheme
 > for example.

Thanks. I will include a parallel directory option to 
jde-junit-test-case-directory option and an option to specify
a custom test-case storage scheme. I think I'll change the name
to something like

jde-junit-test-case-storage-scheme

to reflect the fact that what you are really specifying is a rule for
determining the location of test cases based on the location of classes
to be tested. 

Paul


 > 
 > Example:
 > 
 > project/src/net/java/project/Source.java
 > project/test/net/java/project/SourceTest.java
 > 
 > or:
 >  
 > project/src/java/net/java/project/Source.java
 > project/src/test/net/java/project/SourceTest.java
 > 
 > -- 
 > Ole Arndt http://www.sugarshark.com
 > 

Re: [PATCH] jde-junit.el

[Paul Kinnucan]

Paul Kinnucan writes:
 > Ole Arndt writes:
 >  > Hi Paul, Len, 
 >  > 
 >  > Paul Kinnucan <[EMAIL PROTECTED]> writes:
 >  > 
 >  > > Len Trigg writes:
 >  > >  > JDE. I've had some functions for ages that I use for running test
 >  > >  > classes ...
 >  > 
 >  > > I am planning to provide a command like this. However, I want to make
 >  > > the JDEE's support of unit testing more flexible. 
 >  > 
 >  > Here is the plugin I use for switching forth and back between Class
 >  > source and test file and running tests. It uses some customisation
 >  > variables, perhaps you can use it as a base. The mapping from class
 >  > source to test source can surely be improved.
 >  > 
 >  > It is based on some code from the list, I don't remember whose work it
 >  > was, shame on me.
 > 
 > I committed an updated jde-junit.el file last night. It adds a
 > customization variable
 > 
 >jde-junit-tester-name-tag
 >

Hmm, on second thougth, I might rename this to

  jde-junit-test-case-name-tag

Paul
 
 > variable that allows you to specify a tag for generating JUnit class
 > names from testee class names. You can specify whether to prefix or
 > append the tag to the testee class name. The default tag is the prefix
 > T, i.e., it generates TFoo as the name for a JUnit class that tests
 > Foo. I added functions that use this variable to determine a test case
 > name from a testee class and vice-versa. I plan to use these functions
 > to provide a command that switches you from a testee class to the test
 > case that tests it and vice versa.
 > 
 > This command will also use a customization variable that I plan to
 > implement named,
 > 
 >   jde-junit-test-case-directory
 > 
 > that will allow you to specify where test cases are located for
 > a project. My thought is to allow you to specify one of two locations:
 > 
 >   - same directory as the classes to be tested
 >   - a specified directory beneath the classes to be tested,
 > e.g., unittest.
 > 
 > Please let me know if you know of other places that people 
 > commonly store test cases.
 > 
 > 
 > I plan to add a customization variable 
 > 
 >   jde-junit-generic-test-case-class
 > 
 > that allows you to specify the parent class for all test case
 > classes. This allows you to create your own subclass of JUnit's
 > TestCase and use this as the parent for all test cases. The
 > default value will be TestCase. The JDEE test case class template
 > will use this variable to generate skeleton test cases.
 > 
 > 
 > Paul
 > 
 >  > 
 >  > See attachment. This is only the lisp file from the plugin. The only
 >  > other file in the plugin is junit.jar in java/lib/junit.jar.
 >  > 
 >  > -- 
 >  > Ole Arndt http://www.sugarshark.com
 >  > 
 > 

Re: [PATCH] jde-junit.el

[Paul Kinnucan]

Ole Arndt writes:
 > Hi Paul, Len, 
 > 
 > Paul Kinnucan <[EMAIL PROTECTED]> writes:
 > 
 > > Len Trigg writes:
 > >  > JDE. I've had some functions for ages that I use for running test
 > >  > classes ...
 > 
 > > I am planning to provide a command like this. However, I want to make
 > > the JDEE's support of unit testing more flexible. 
 > 
 > Here is the plugin I use for switching forth and back between Class
 > source and test file and running tests. It uses some customisation
 > variables, perhaps you can use it as a base. The mapping from class
 > source to test source can surely be improved.
 > 
 > It is based on some code from the list, I don't remember whose work it
 > was, shame on me.

I committed an updated jde-junit.el file last night. It adds a
customization variable

   jde-junit-tester-name-tag

variable that allows you to specify a tag for generating JUnit class
names from testee class names. You can specify whether to prefix or
append the tag to the testee class name. The default tag is the prefix
T, i.e., it generates TFoo as the name for a JUnit class that tests
Foo. I added functions that use this variable to determine a test case
name from a testee class and vice-versa. I plan to use these functions
to provide a command that switches you from a testee class to the test
case that tests it and vice versa.

This command will also use a customization variable that I plan to
implement named,

  jde-junit-test-case-directory

that will allow you to specify where test cases are located for
a project. My thought is to allow you to specify one of two locations:

  - same directory as the classes to be tested
  - a specified directory beneath the classes to be tested,
e.g., unittest.

Please let me know if you know of other places that people 
commonly store test cases.


I plan to add a customization variable 

  jde-junit-generic-test-case-class

that allows you to specify the parent class for all test case
classes. This allows you to create your own subclass of JUnit's
TestCase and use this as the parent for all test cases. The
default value will be TestCase. The JDEE test case class template
will use this variable to generate skeleton test cases.


Paul

 > 
 > See attachment. This is only the lisp file from the plugin. The only
 > other file in the plugin is junit.jar in java/lib/junit.jar.
 > 
 > -- 
 > Ole Arndt http://www.sugarshark.com
 >