RE: JDE tools to validate Tomcat's web.xml?
Michael, XML editing is handled by a completely different set of modes than those that comprise the JDEE. From emacs' standpoint, Tomcat's web.xml file is just another XML file -- no special role or relation to java, jdee, etc. So, you'll need to figure out what's wrong with your emacs configuration vis-a-vis XML editing, and that's not a JDEE issue. To take a wild guess, you probably have an error in your load path that is preventing emacs from finding psgml mode. If you're not experienced with emacs lisp, I suggest that you approach the problem incrementally: comment out most (all?) of your .emacs file and gradually add things back in to the point where they stop working correctly. You don't need to keep starting and stopping emacs: you can just mark a region that you'd like to evaluate and M-x evaluate-region. Or you can post your .emacs file to comp.emacs and ask for help -- that's a general purpose newsgroup and this list is for JDEE problems exclusively. Good luck, Eric -Original Message- From: Michael Coughlan [mailto:[EMAIL PROTECTED] Sent: Friday, December 19, 2003 6:38 AM To: [EMAIL PROTECTED] Subject: JDE tools to validate Tomcat's web.xml? Hello all, What emacs JDE tools are availble for validating a Tomcat web.xml file? Yesterday, I could edit my web.xml file and see the emacs JDE color coding the tags blue and data black. Hurray! As of today, I seem to have lost the pretty colors. : ( I treied to explicity set xml-mode, but that didn't fix the trouble. A test edit of foo.java shows that java-mode is still working for java files. (more pretty colors) I would love it if my JDE could help to validate my web.xml in some way. It's a pain to restart tomcat and parse the logs every time. I'd at least like to get my color coding back. Thanks, MPC Versions: I am running a Cignys Xwindows Server on Windows XP to connect to a Red Hat linux box running both the X Client Tomcat 5. On lunix... # rpm -qa | grep emacs emacs-21.2-33 eieio, speedbar, etc are all latest versions, but not the singular beta install
RE: Implement interface wizard.
Sounds good to me. -Original Message- From: Paul Kinnucan [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2003 10:16 AM To: Ole Arndt Cc: jde Subject: Re: Implement interface wizard. Ole Arndt writes: Andy, Eric, Paul, [EMAIL PROTECTED] writes: I'd like to point out that if a method from an interface has no javadoc, the javadoc program will copy the documentation from the interface itself. Consequently, it might be a reasonable default to generate no javadoc at all in the implement interface wizard, or at least to make it optional. an alternative is to use the [EMAIL PROTECTED] inline tag. A combined solution would look like this: /** * [EMAIL PROTECTED] * * @see package.Class#origMethod */ The @see tag seems redundant to me. Also please note that @inheritDoc will not work for JDK releases earlier than JDK 1.4. So I'd like to offer an alternative proposal: If the JDK version used to generate the skeleton method implementation is earlier than 1.4, generate the skeleton without a comment. Otherwise, generate the skeleton with the following comment: /** * [EMAIL PROTECTED] */ - Paul
aspectj jde
Has there been any discussion/interest with the AspectJ folks about pulling their JDE extensions into the main JDE distro? I know they forked something called AJDE a while back, but now that they're off in eclipse-land, that's probably not a huge priority (I am speculating, with no information either way). In any event, I find myself writing aspectj code in emacs and wishing that JDE groked the syntax and keywords. Does anyone else feel my pain? More productively, I'm curious to hear Paul's thoughts on how JDE should (not) accomodate language extensions of this kind. There've been a lot of these over the years and JDE has wisely ignored most of them, but it's my opinion that AspectJ is likely to survive longer than some of the niche-extensions, like SQLJ. Is it possible to shovel everything associated with an extension of this kind into a minor mode? I'm guessing it won't work with semantic unless someone puts together a grammar for the bovinator, but could keywords and indentation be done that way? Apologies for the disconnected thoughts -- I'm not really sure what the right thing to do is in this case. Eric
RE: jde.sunsite.dk site
Apropos -- perhaps if the JD Edwards acquisition goes through we can drop the extra 'e' again. Only half kidding, Eric -Original Message- From: Sprenger, Karel [mailto:[EMAIL PROTECTED] Sent: Thursday, June 05, 2003 11:41 PM To: Jeff Jensen; [EMAIL PROTECTED] Subject: RE: jde.sunsite.dk site Jeff, Try http://jdee.sunsite.dk/. The 'e' was added a few month ago. Cheers, Karel -Original Message- From: Jeff Jensen [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 04:55 To: [EMAIL PROTECTED] Subject: jde.sunsite.dk site Hi - Has the site been down for days or is it just me (and the only page that is not working!)? I have not seen any messages nor updates on the sunsite.dk page.
Re: Extending JDE using Java (WAS: Gosling interview)
Daniel, If you read Paul's note, the problem he's trying to solve arises precisely because it is too expensive to have a lot of chatter across I/O between emacs and an external java process. The solution he's considering -- put the display logic into the java process so as to avoid the I/O -- addresses the problem. Your proposal - a different window layout managed by ECB - adds more complexity (by bringing ECB into the mix) without doing anything to reduce the high cost of I/O between the debugger and its display. Eric In message [EMAIL PROTECTED], Daniel Hegyi writes: : I think it is practical to use Java to extend Emacs where not much : interaction is required between Emacs and the extension, the wizards : and the debugger are examples. It may even be possible to provide : those extensions with a Java GUI. Pettar Maehlen and I have been : discussing the possibility of creating a Java window for JDEbug to display : local variable values when stepping through a program. Currently : displaying local variables slows down stepping significantly because : it involves sending significant amounts of text across the : standard I/O channel to Emacs. A separate local variable window : that lives in the debugger process instead of the Emacs process would : eliminate this bottleneck. : I think this would be great! JDE is already a very powerful IDE, that is, it : has a great deal of functionality. But I'm concerned with the UI aspect of : it. Emacs-ers are used to doing M-x all the time, however, I think it could : benefit much from some GUI components instead of having to memorize so many : functions. : : Regarding the inspection of local vars you may also want to consider : displaying them in an ECB window. (Although ECB is not a mandatory component : of JDE, it seems like a natural fit for the problem.) Maybe having the : option of having either Java GUI or ECB inspection view? : : : Regards, : Daniel : : _ : MSN Photos is the easiest way to share and print your photos: : http://photos.msn.com/support/worldwide.aspx :
Re: jde.el and tramp
Dug a little deeper: On linux, PATH_MAX is 4095; on Solaris it's 1024.
In message [EMAIL PROTECTED], Eric D. Friedma
n writes:
:
: This sounds like a bug that should be fixed in tramp, not in JDE.
:
: Directory *entry* length maximums are file system dependent too, which
: means that a correct implementation of this hack would require looking at
: the different filesystems that can be mounted on unix and windoze (both of
: which can be nfs clients, of course, and so can mount other filesystems
: through NFS or natively). A quick look at the header files on my linux
: machine (which includes ufs_fs.h known to work with Solaris and HP/UX,
: as well as ext{2,3}_fs.h, reiser_fs.h etc.) shows that 255 is a popular
: (smile) maximum length for directory entries.
:
: If the question being asked is what's the longest legal *path* name --
: well, on unix that can be very, very large. I don't know how big exactly,
: but you can definitely create paths that are much bigger than the thread
: below would allow. To illustrate: I ran this script on my linux machine
: (ext2 filesystem). Starting at /home/eric, it happily created a directory
: structure /home/eric/0/1/2/3/../4096. Note also that it had no trouble
: traversing the structure as it went. Note also that each of the nodes
: in this path *could* have been up to 255 characters long. In sum,
: (255 * 4097) 100.
:
: Obviously this is an edge case (although anyone with ClearCase experience
: knows that you can end up dealing with some mighty big pathnames once
: you start poking around in mvfs' view extended pathnames), but I
: think it shows why it would be better to solve this problem through some
: other means. Perhaps the original poster could describe the specific
: issue with tramp in more detail? Perhaps the folks on the tramp mailing
: list could be enlisted to help resolve it?
:
: #!/usr/bin/perl
:
: for my $n (0 .. 4096) { # upper limit chosen at random (note: *inclusive*)
: system 'mkdir', $n;
: if ($?) { exit 1; }
: chdir $n;
: }
:
: In message [EMAIL PROTECTED], Paul Kinnucan writ
es
: :
: :
: : Can anyone help with the question raised in the following
: : thread?
: :
: : Paul
: :
: : Jose M Vidal writes:
: :
: : Yup, 100 is a hack that works for me. I don't know what the actual
: : maximums are.
: :
: : On the other hand, we just need to pick a number bigger than the most
: : unreasonably long file name but smaller than infinity. H. What is
: : 1024?
: :
: : Sorry,
: : Jose
: :
: :
: : On Mon, 22 Oct 2001, [EMAIL PROTECTED] wrote:
: :
: :Jose M Vidal writes:
: :
: : jde 1.17 will not work with tramp because of the way it keeps
: : trying to go up the directory hierarchy assuming ange-ftp
: : usage. It would get into an infinite loop. I fixed this by simply
: : constraining the length of the directory to 100 characters. I
: : think this makes the code much
: :
: :Hi Jose,
: :
: :Why did you choose 100 characters? How do you know that there won't
: :be a valid path somewhere that is more than 100 characters.
: :I'm very leery of hacks like this based on someone's estimate
: :of what is a reasonable maximum for some value. I'd rather have
: :the maximum be greater than the maximum of the maximum paths
: :supported by Windows and Unix. Is there such a maximum? I vaguely
: :recall reading somewhere that the limit for Windows paths is
: :256 characters. If Unix and Windows have constraints on path sizes,
: :I'd be much more comfortable adopting this hack.
: :
: :- Paul
: :
: : more robust. Here is the changed function (from jde.el):
: :
: :
: : (defun jde-find-project-file (dir)
: :Finds the next project file upwards in the directory tree
: : from DIR. Returns nil if it cannot find a project file in DIR
: : or an ascendant directory.
: :(let ((file (find jde-project-file-name
: : (directory-files dir) :test 'string=)))
: : (if file
: : (expand-file-name file dir)
: :(if ( (length dir) 100)
: :(if (not (jde-root-dir-p dir))
: :(jde-find-project-file (concat dir ../)))
: :
: : Cheer, and thanks for a *great* product,
: : Jose
: :
: : --
: : Jose M. Vidal [EMAIL PROTECTED] http://jmvidal.cse.sc.edu
: : University of South Carolina http://www.multiagent.com
: :
: :
: : --
: : Jose M. Vidal [EMAIL PROTECTED] http://jmvidal.cse.sc.edu
: : University of South Carolina http://www.multiagent.com
: :
: :
:
Re: RFE?: Suppress abbrv mode in comments
Actually jde-gen's default cflow templates are comment/quote aware.
That is, the tempo-templates include a hook that expands the abbrev
with a control flow template everywhere except when point is inside
of a comment or a double quoted string.
The problem is that the tempo-templates are activated by abbrev-mode,
which is not case sensitive and which doesn't make the text that
triggered the abbrev expansion available to the expander of that text.
There's also no mecahnism through which a template can say oh wait,
cancel the expansion and leave the text unmolested.
So, abbrev-mode expands abbrevs without regard to case, and the
jde cflow templates are forced to choose one case or the other to
use in contexts (quotes and strings) when the full expansion is not
appropriate.
In sum, this is a minor annoyance, but I'm sure you'll agree that it's
much better than getting if () { } inserted when you're trying to compose
a comment (which is what earlier versions of the templates did before I
added the quote-or-string hook).
Eric
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes:
:
: Hi,
:
: Is it possible to suppress abbreviation mode for comments? For example, if
: I want to start a sentence in my comment with the word If, abbreviation
: mode always kicks in and changes it to lowercase if, thinking that I am
: entering a java keyword. I can of course Type If C-q SPC every time, but
: considering that most often in a comment I one is not typing code, but
: comments, it would be nice if abbreviation was disabled for this. I suppose
: if you wanted to be really fancy abbreviation mode could ignore everything
: except text inside code/code blocks.
:
: Ian
:
: .
:
Re: Sorting methods
It should be pretty easy to do this with JavaCC. Just use one of the Java grammars that are included with JavaCC and write the parse tree back out in whatever order you need. This will make it possible to preserve javadoc too. You didn't mention where Visual Age puts field declarations, but JavaCC should be able to help there too. You might also want to search the comp.compilers.tools.javacc newsgroup to see if anyone has already done something similar -- it seems like the sort of code beautifying tool that a compulsive neat freak must have been inspired to write at some point. You could also look at ANTLR for the same stuff: it's a different parser generator, and its adherents may have done something that would be helpful to you. Eric In message [EMAIL PROTECTED], Perkens-Golomb, Burkhard writes: : I'm looking for a tool to arrange methods in Java sources : alphabetically. : : I've given away sources to a customer. They've worked with them in : Visual Age and I want to look at their changes. They don't remember : all changes they've made so I have to do a diff. But Visual Age stores : the sources in a database, not in flat files, and if you want normal : Java files from Visual Age you get them terrible formatted and the : methods are arranged alphabetically. A diff with my sources is futile. : : I'm looking for a tool to arrange the methods in my sources : alphabetically. Of course I could load my sources in Visual Age and : get them back terrible formatted, too :-) . But I don't have Visual : Age and I don't want to use it if it's possible without it! : : Could Emacs do it (with semantic, senator etc.)? Or other tools? Any : ideas or hints? : : TIA, : : Burkhard :
Re: ANN: JDE 2.2.9beta2 available... (correct URL)
I got two errors while compiling this release: 1. While compiling toplevel forms in file /home/eric/emacs/jde/lisp/jde-bug.el: !! error ((Given parent class jde-db-debugger is not a class)) and 2. While compiling toplevel forms in file /home/eric/emacs/jde/lisp/jde.el: !! Malformed property list (((:initarg :version :version string Compiler version.) (Compiler version.))) In message [EMAIL PROTECTED], Paul Kinnucan writes: : http://jde.sunsite.dk/rootpage.html#Downloading : : JDE 2.2.9beta2 : : *** : * PLEASE READ * : *** : * * : * This release requires semantic 1.4beta10 (or later),* : * speedbar 0.13 (or later), and eieio-0.16 (or later, * : * except eieio-0.17beta1). You can obtain all three * : * packages at http://cedet.sourceforge.net* : * * : * This release requires version 1.2.2 (or later) of the * : * JDK.* : * * : * Note: This release does not work with eieio-0.17beta1, but * : * it does work with eieio-0.17beta2. * : * * : * 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://sunsite.dk/jde/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. * : * * : *** : : * The jde-build-ant-command now quotes all path arguments to : accommodate Windows. This change was submitted by : Kevin Jones [EMAIL PROTECTED]. I don't use Ant so I've :not tested this change. : : * Replaced the customization variable jde-db-debugger with : jde-debugger to be consistent with jde-compiler. : :
History list jde-interactive-make-arg-history is unbound
When I enable jde-project - Read Make Args or jde-project - Ant Read Args or jde-project - Ant Read Target, I get errors like the one the subject `History list jde-interactive-make-arg-history is unbound' This is with Xemacs, solaris, jde 2.2.8beta1. Any ideas? Eric
JDEbug on solaris
Is anyone able to use JDEbug on solaris/xemacs? This is with
jde 2.2.6.2
I've followed the instructions for setting up JDEbug and am using
the 1.3.1 beta VM, which is supposed to have fixed the problems with
debugging in hotspot VMs (solaris does not have a "classic" vm).
I coded up a simple class that has a main method that creates a single
instance and invokes a single member method:
String foo(String foo) {
foo += "y"; // breakpoint set here
foo += "z";
return foo;
}
I start up the debugger and do a JDEbug-Processes-Launch Process.
The app starts, but there's no indication that my breakpoint has been
hit (nothing shows up in the Locals buffer, though `foo' is definitely
a local with a value at this point.
JDEbug-Continue runs the app to completion without hitting my breakpoint.
If I set two breakpoints, the same thing happens, so I'm pretty sure
that it's not a problem of the display not being updated to the breakpoint.
The debugger output follows.
Thanks,
Eric
*** Debugger Output for Process FooBar(5) ***
vm started...
All threads suspended...
Launch command line:
java -classpath
/home/eric/classes/xerces.jar:/home/eric/prj/ETJavaFoundation/classes:/home/eric
FooBar
Emacs connected to standard IO port 33819 for process FooBar.
Launched VM Java Debug Interface (Reference Implementation) version 1.3
Java Debug Wire Protocol (Reference Implementation) version 1.0
JVM Debug Interface version 1.0
JVM version 1.3.1-beta (Java HotSpot(TM) Client VM, interpreted mode)
initSIOConnect: starting standard I/O handshake.
initSIOConnect: starting SIO connect thread.
Debugger waiting for Emacs to connect to app SIO port 33819.
Debugger connected to standard I/O socket.
Running FooBar.
FooBar process ended.
vm disconnected...
