Re: ant build problem
Suraj Acharya wrote: Hi Mark, Have you tried running the ant command from your shell to see if it completes sucessfully? Use the same arguments that emacs is passing to ant: ant -Dant.home=/usr/share/ant -buildfile '/home/mhansen/chap5/oneway/build.xml' -emacs init Suraj On Wed, 8 Sep 2004 21:01:29 -0400, Mark D. Hansen [EMAIL PROTECTED] wrote: One more thing on this ... I've read all the posts related to jde-ant-build and can't find this problem. My problem is NOT related to the \' delimiter around the buildfile. Thanks for any possible help / ideas. -- Mark -Original Message- From: Mark D. Hansen [mailto:[EMAIL PROTECTED] Sent: Monday, September 06, 2004 12:08 AM To: JDE (E-mail) Subject: ant build problem When I try to build (any target / any build file) C-c C-v C-b, I get the following error message: error in process sentinel: byte-code: No more errors error in process sentinel: No more errors ... and the following in the compilation window (abnormal exit): cd ~/chap5/oneway/ ant -Dant.home=/usr/share/ant -buildfile '/home/mhansen/chap5/oneway/build.xml' -emacs init Buildfile: /home/mhansen/chap5/oneway/build.xml Compilation exited abnormally with code 129 at Mon Sep 6 00:04:30 i've got the same problem...in addition, i've observed that whenever i invoke an ant build target that in turn invokes something different than the normal java tools (javac, etc) --- for example, when i'm using antenna (to build MIDP packages) --- the process running in JDE will just die, the same process running in the shell just completes fine... -- Dr Dirk Husemann, Mobile Computing, IBM Research, Zurich Research Lab [EMAIL PROTECTED] --- http://www.zurich.ibm.com/~hud/ PGP key: http://www.zurich.ibm.com/~hud/contact/PGP PGP Fingerprint: 983C 48E7 0A78 A313 401C C4AD 3C0A 278E 6431 A149 Email only authentic if signed with PGP key. Appended to this email is an electronic signature attachment. You can ignore it if your email program does not know how to verify such a signature. If you'd like to learn more about this topic, www.gnupg.org is a good starting point. signature.asc Description: OpenPGP digital signature
RE: ant build problem
I replaced JDE's default ant script (/usr/bin/ant) with the simple wrapper script called ant-jde shown below: #!/bin/bash ant $@ 21 This wrapper simply redirects stderr to stdout. That seems to solve the problem, which is apparently caused by the *compilation* buffer not being able to handle an undefined stderr. You replace the default ant script by setting the jde-ant-program option (go to menu / JDE / Project / Options / Ant) and enter the path of your wrapper script in the spot labeled JDE Ant Program. Good luck, Mark -Original Message- From: Dirk Husemann [mailto:[EMAIL PROTECTED] Sent: Thursday, September 09, 2004 4:00 AM To: Suraj Acharya Cc: Mark D. Hansen; JDE (E-mail) Subject: Re: ant build problem Suraj Acharya wrote: Hi Mark, Have you tried running the ant command from your shell to see if it completes sucessfully? Use the same arguments that emacs is passing to ant: ant -Dant.home=/usr/share/ant -buildfile '/home/mhansen/chap5/oneway/build.xml' -emacs init Suraj On Wed, 8 Sep 2004 21:01:29 -0400, Mark D. Hansen [EMAIL PROTECTED] wrote: One more thing on this ... I've read all the posts related to jde-ant-build and can't find this problem. My problem is NOT related to the \' delimiter around the buildfile. Thanks for any possible help / ideas. -- Mark -Original Message- From: Mark D. Hansen [mailto:[EMAIL PROTECTED] Sent: Monday, September 06, 2004 12:08 AM To: JDE (E-mail) Subject: ant build problem When I try to build (any target / any build file) C-c C-v C-b, I get the following error message: error in process sentinel: byte-code: No more errors error in process sentinel: No more errors ... and the following in the compilation window (abnormal exit): cd ~/chap5/oneway/ ant -Dant.home=/usr/share/ant -buildfile '/home/mhansen/chap5/oneway/build.xml' -emacs init Buildfile: /home/mhansen/chap5/oneway/build.xml Compilation exited abnormally with code 129 at Mon Sep 6 00:04:30 i've got the same problem...in addition, i've observed that whenever i invoke an ant build target that in turn invokes something different than the normal java tools (javac, etc) --- for example, when i'm using antenna (to build MIDP packages) --- the process running in JDE will just die, the same process running in the shell just completes fine... -- Dr Dirk Husemann, Mobile Computing, IBM Research, Zurich Research Lab [EMAIL PROTECTED] --- http://www.zurich.ibm.com/~hud/ PGP key: http://www.zurich.ibm.com/~hud/contact/PGP PGP Fingerprint: 983C 48E7 0A78 A313 401C C4AD 3C0A 278E 6431 A149 Email only authentic if signed with PGP key. Appended to this email is an electronic signature attachment. You can ignore it if your email program does not know how to verify such a signature. If you'd like to learn more about this topic, www.gnupg.org is a good starting point.
Fwd: Default directory for project files
Paul, You are right that things like jde-gloabl-classpath works already. So whatever I did wouldn't have any effect on them. I was wrong when I applied them to the change I made. However, the change I made is still valid. The original intention of the changes are targeted to the statements outside of the jde-set-variable block. (I should have sticked to that instead of broaden that to those inside). Currently if we define anything outside of that block, it will be loaded under the deepest originating project's directory. For example, jde-ant-buildfile. If you define a relative dir to this variable in /somewhere/src, and try to run the build under /somewhere/src/cp1, that relative path would be wrong because it will be relative to cp1. I don't know if it is the intention of the design to allow people define things outside the the jde-set-variable block. I want to do it because I can have a lot of project specific things defined here. One example is there are different code convention for the indentation in different projects. I can set it differently in different prj.el files. In terms of the term relative, I mean ./classes == prj-dir/classes. Thanks. Ping On Tue, 31 Aug 2004 10:44:13 -0400, Paul Kinnucan [EMAIL PROTECTED] wrote: Ping Liang writes: I made some modification to the function jde-load-project-file in jde.el so that when each project file is loaded, the default directory is set the directory where this project file is in. See change below. Hi Ping, I don't understand how your change works. I haven't looked at the project file code in a long time but as far as I remember, it does not use or depend on the default directory in any way. Relative paths in jde-global-classpath and jde-sourcepath are resolved at compile- or run-time, not when the project file is loaded, i.e., loading a project does not resolve the relative path: ./classes. Further, it is not clear to me in which sense you are using relative path. Are you using it in the sense of the JDEE's project-relative path feature where the JDEE resolves the period in a path (e.g., ./classes == prj-dir/classes) or in the traditional sense where Emacs or the host operating system resolves the period in a relative path (e.g., ./classes == curr_dir/classes)? I need to know in which sense you are using the term in order to understand what problem you are trying to solve. Paul This change is very important because this makes relative path possible under the following scenario. Assuming you have the dir structure like this, /somewhere/lib /somewhere/src /somewhere/src/cp1 /somewhere/src/cp2 I usually put prj.el files in src, cp1 and cp2. This means the settings I put in src is common to cp1 and cp2, so I don't have to define them again in prj.el in the subdirs. This has been OK as long as I don't use relative path in settings like jde-global-classpath. If I do, the relative path in src/prj.el becomes relative to the bottom-most prj.el's directory (such as /src/cp1) and all the settings in src/prj.el having relative path would point to the wrong directory. This also affects the variables I defined outside of the jde-set-variable block. As a work-around, I have been redefining these variable in each prj.el file. This does not look good; it defeats the purpose of having a common prj.el file. I have to use relative path and strongly suggest others do the same. This way, I can check out the source code from revision control system to any directory I want and start using JDE right away, without having to change the absolute path. Besides, none of the other IDEs are able to use relative path (let me know if you found one) and Emacs (JDEE) is the one that stands out. Here is the changed code segment in jde.el, (if prj-files (progn (jde-set-variables-init-value) (setq default-directory-backup default-directory) ;; ping (loop for file in prj-files do (setq jde-loading-project file) (jde-log-msg jde-load-project-file: Loading %s file) ;; reset project file version (setq jde-loaded-project-file-version nil) (setq default-directory (file-name-directory file)) ;; ping (load-file file) (setq jde-loading-project nil)) (setq default-directory default-directory-backup) ;; ping (run-hooks 'jde-project-hooks))... Regards, Ping
problems with jde-java-font-lock-constant-face
JDEE beta 5 doesn't consistently fontify constants such as FOO_BAR.
Sometimes it does, sometimes it doesn't. When it doesn't, if I edit the
buffer, it will suddenly fontify properly, but if I reload the file the
proper fontification will go away. For example, if I start up emacs
without my init file (emacs -q), and only do:
(load-file /usr/share/emacs/site-lisp/cedet-1.0beta3b/common/cedet.elc)
(semantic-load-enable-code-belpers)
(require 'jde)
If I load the following file into a buffer:
public class test {
public final static boolean FONT_LOCK_TEST = false;
public void foo() {
System.out.println(FONT_LOCK_TEST);
}
}
FONT_LOCK_TEST will not be fontified. However, if I edit in any way
lines 2 or 4 (that contain FONT_LOCK_TEST), it will be fontified
according to jde-java-font-lock-constant-face correctly. If I then kill
the buffer and revisit the same file, the fontification will go away.
In larger source files, some constants will be fontified, and some
won't. I can't tell what will determine it; code structures such as:
if (foo == FIRST_CONSTANT || foo == SECOND_CONSTANT) { ... }
may fontify the first or second or both. The same constant will appear
fontified in some lines but not others in the same source file. Very
weird. Help?
Raul
