Invoking ANT build fails in W2K/GNU Emacs environment
Fellow JDEE-Users, Invoking the command jde-build with setup for ANT ends with a message in the *compilation* buffer: Buildfile: 'h:\repositories\development\build.xml' does not exist! The build file is there. The problem are the single quotes. That diff shows the change in jde-ant.el the makes it work again: 253c253,255 < (not (featurep 'xemacs --- > (not (or > (featurep 'xemacs) > (eq system-type 'windows-nt) I'm not exactly sure whether that's a bug (and the suggested workaround candidate for a permanent fix for it) or the real problem would be somewhere else. Just thought I should share what I've experienced. Regards Stefan P.S.: Environment details: Windows 2000 SP3 GNU Emacs 21.3.1 (i386-msvc-nt5.0.2195) of 2003-03-28 on buffy Ant 1.5.2 JDEE 2.3.3beta5
JDE-CVS-Commit
[EMAIL PROTECTED] writes: > Update of /pack/anoncvs/jde/lisp > In directory sunsite.dk:/tmp/cvs-serv11659 > > Modified Files: > jde-xref.el > Log Message: > Made jde-xref-store-prefixes non-optional. I think if we didn't do > this, most people would leave it blank, therefore significantly > impacting both size of the database and the time and memory it takes > to make it. > Hi Andy, How about making nil default to the package of the class in the current source buffer? Also, I'd like to suggest renaming jde-xref-store-prefixes to jde-xref-packages as that more clearly indicates the variables purpose. - 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
aspectj & jde
[EMAIL PROTECTED] writes: > 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? > One approach might be to use the new "plugin" capability that JDEE 2.3.3 supports. This would allow people who are familiar with niche extensions to Java to develop and distribute independently JDEE extensions that support the Java extensions. - Paul > Apologies for the disconnected thoughts -- I'm not really sure what the > "right" thing to do is in this case. > > Eric
Re: JDE-CVS-Commit
Paul Kinnucan <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] writes: > > Update of /pack/anoncvs/jde/lisp > > In directory sunsite.dk:/tmp/cvs-serv11659 > > > > Modified Files: > >jde-xref.el > > Log Message: > > Made jde-xref-store-prefixes non-optional. I think if we didn't do > > this, most people would leave it blank, therefore significantly > > impacting both size of the database and the time and memory it takes > > to make it. > > > > Hi Andy, > > How about making nil default to the package of the class in the > current source buffer? I'm not sure I want to make any assumptions. Typically, people would want their database to encompass more than one package. Plus, I anticipate that this will not always be invoked from a Java buffer. For instance, you could rebuild the database every night, and in that case you wouldn't be in a buffer. > > Also, I'd like to suggest renaming jde-xref-store-prefixes to > jde-xref-packages as that more clearly indicates the variables > purpose. > Let me think about this one. The thing is, the variable doesn't contain package names, it contains package prefixes. But the name is a bit confusing, I agree. > - Paul
Re: JDE-CVS-Commit
Andrew Hyatt writes: > Paul Kinnucan <[EMAIL PROTECTED]> writes: > > > [EMAIL PROTECTED] writes: > > > Update of /pack/anoncvs/jde/lisp > > > In directory sunsite.dk:/tmp/cvs-serv11659 > > > > > > Modified Files: > > > jde-xref.el > > > Log Message: > > > Made jde-xref-store-prefixes non-optional. I think if we didn't do > > > this, most people would leave it blank, therefore significantly > > > impacting both size of the database and the time and memory it takes > > > to make it. > > > > > > > Hi Andy, > > > > How about making nil default to the package of the class in the > > current source buffer? > I think it's nice to have all the jde-xref variables to have defaults that allow a new user to try it out quickly without having to do any preliminary setup, which is now required with your latest change. Previously, the default for this variable was to cross-ref the universe by default. I'm suggesting that we change it to cross-ref the current package. Is this what the user is likely to want ultimately? No, but it's a good starting point. The new user should quickly notice that the xrefing is limited and this should lead them to the doc to find out why. > I'm not sure I want to make any assumptions. Typically, people would > want their database to encompass more than one package. Plus, I > anticipate that this will not always be invoked from a Java buffer. > For instance, you could rebuild the database every night, and in that > case you wouldn't be in a buffer. > > > > > Also, I'd like to suggest renaming jde-xref-store-prefixes to > > jde-xref-packages as that more clearly indicates the variables > > purpose. > > > > Let me think about this one. The thing is, the variable doesn't > contain package names, it contains package prefixes. What's the difference? > But the name is a bit confusing, I agree. I think this variable, whatever its name, should allow the user to specify the packages that the user wants to xref, including specifying that all subpackages of a package be xrefed, e.g., if I have a package structure like this: pkgA pkgAa pkgAb I should be able to specify pkgA and have everything in pkgA, including pkgAa and pkgAb, xrefed. On the other hand, if I specified pkgA.pkgAb, I'd expect only pkgAb to be xrefed. - Paul
Re: JDE-CVS-Commit
Paul Kinnucan <[EMAIL PROTECTED]> writes: > > I think it's nice to have all the jde-xref variables to have defaults > that allow a new user to try it out quickly without having to do any > preliminary setup, which is now required with your latest > change. Previously, the default for this variable was to cross-ref the > universe by default. I'm suggesting that we change it to cross-ref the > current package. Is this what the user is likely to want ultimately? > No, but it's a good starting point. The new user should quickly > notice that the xrefing is limited and this should lead them to the > doc to find out why. Xref already requires the user to set up the jde-xref-db-base-directory as well as the jde-built-class-path. There may be a way to automatically guess these things, but I couldn't see how with the jde variables already there. The base directory should usually correspond to something in the sourcepath, but we don't know which entry. And the jde-built-class-path cannot be figured out from the classpath, it's actually a subset of the classpath, but again we don't know what subset. So we need the user to fill out two things, with my latest change, it's now three things. I would rather force the user to fill out a reasonable value. I think not doing so will confuse users, and they may assume it doesn't work right.We could try to "guess" this one, but I think it would be an error prone process.I would like to minimize confusion and potential bugs, that's why I like the user to fill this one out. > > > > Let me think about this one. The thing is, the variable doesn't > > contain package names, it contains package prefixes. > > What's the difference? Well, it's that package (in the sense that something like "com" or "org" is a package), and all children of that package. To be specific, it's just whatever packages match that any of the prefixes in this variable, so the prefix "co" would match "com.foo.bar". > > > But the name is a bit confusing, I agree. > > I think this variable, whatever its name, should allow the > user to specify the packages that the user wants to xref, including > specifying that all subpackages of a package be xrefed, e.g., if > I have a package structure like this: > > pkgA > pkgAa > pkgAb > > I should be able to specify pkgA and have everything in pkgA, including > pkgAa and pkgAb, xrefed. On the other hand, if I specified pkgA.pkgAb, > I'd expect only pkgAb to be xrefed. This is the way it works now. > > - Paul
Re: JDE-CVS-Commit
Andrew Hyatt writes: > Paul Kinnucan <[EMAIL PROTECTED]> writes: > > > > > I think it's nice to have all the jde-xref variables to have defaults > > that allow a new user to try it out quickly without having to do any > > preliminary setup, which is now required with your latest > > change. Previously, the default for this variable was to cross-ref the > > universe by default. I'm suggesting that we change it to cross-ref the > > current package. Is this what the user is likely to want ultimately? > > No, but it's a good starting point. The new user should quickly > > notice that the xrefing is limited and this should lead them to the > > doc to find out why. > > Xref already requires the user to set up the > jde-xref-db-base-directory as well as the jde-built-class-path. There > may be a way to automatically guess these things, but I couldn't see > how with the jde variables already there. The base directory should > usually correspond to something in the sourcepath, but we don't know > which entry. And the jde-built-class-path cannot be figured out from > the classpath, it's actually a subset of the classpath, but again we > don't know what subset. So we need the user to fill out two things, > with my latest change, it's now three things. > > I would rather force the user to fill out a reasonable value. I think > not doing so will confuse users, and they may assume it doesn't work > right.We could try to "guess" this one, but I think it would be an > error prone process.I would like to minimize confusion and > potential bugs, that's why I like the user to fill this one out. > In my ideal world, no setup would be required. If you did nothing, the JDEE would xref the code in the current package (or perhaps prompt you to enter a list of packages with the default being the current package) and store the result in the root of the project directory (i.e., where the prj.el file is stored). Further, you would not need to specify a classpath in addition to jde-global-classpath. The JDEE would be smart enough to process only those portions of jde-global-classpath where the packages that you specify live. Further, you would not even need to build the xref db. If there is no xref db in the db directory, the JDEE would build it the first time you executed jde-xref-first-caller. This would work great for the project I am currently working on here at the Mathworks. There are a lot of classes but they all live in the same root package. If the JDEE were set up the way I described, I'd just have to call jde-xref-first-caller to get started. No tedious setup. - Paul > > > > > > Let me think about this one. The thing is, the variable doesn't > > > contain package names, it contains package prefixes. > > > > What's the difference? > > Well, it's that package (in the sense that something like "com" or > "org" is a package), and all children of that package. To be > specific, it's just whatever packages match that any of the prefixes > in this variable, so the prefix "co" would match "com.foo.bar". > > > > > > > But the name is a bit confusing, I agree. > > > > I think this variable, whatever its name, should allow the > > user to specify the packages that the user wants to xref, including > > specifying that all subpackages of a package be xrefed, e.g., if > > I have a package structure like this: > > > > pkgA > > pkgAa > > pkgAb > > > > I should be able to specify pkgA and have everything in pkgA, including > > pkgAa and pkgAb, xrefed. On the other hand, if I specified pkgA.pkgAb, > > I'd expect only pkgAb to be xrefed. > > This is the way it works now. > > > > > - Paul
Re: JDE-CVS-Commit
Paul Kinnucan <[EMAIL PROTECTED]> writes: > In my ideal world, no setup would be required. If you did nothing, the > JDEE would xref the code in the current package (or perhaps prompt you > to enter a list of packages with the default being the current > package) and store the result in the root of the project directory > (i.e., where the prj.el file is stored). Further, you would not need > to specify a classpath in addition to jde-global-classpath. The JDEE > would be smart enough to process only those portions of > jde-global-classpath where the packages that you specify live. > > Further, you would not even need to build the xref db. If there > is no xref db in the db directory, the JDEE would build it the > first time you executed jde-xref-first-caller. > > This would work great for the project I am currently working on > here at the Mathworks. There are a lot of classes but they > all live in the same root package. If the JDEE were set up > the way I described, I'd just have to call jde-xref-first-caller > to get started. No tedious setup. > > - Paul Your suggestions are interesting, and they are doable, I think. And I agree that having a no-setup solution is desirable. My problem would be that they do require some guesswork, and that guesswork may go awry, causing problems. Let me see if I can code something up that does what you suggest.
Using JDEbug to debug a J2EE app
Hi,
I have been trying to use the debugger from the latest beta(5) of JDEE to debug an
enterprise application running within weblogic, but it keeps
printing the following messages (I think for every method call or something):
-8<---8<
Debug message: 3:58:20 PM: EventHandler: sending event
jde.debugger.EventSetEvent[eventSet=event set, policy:2, count:1 = {ClassPrepareEvent
in thread
ExecuteThread: '12' for queue: 'default'},suspended=false,threadRef=instance of
weblogic.kernel.ExecuteThread(name='ExecuteThread: '12' for queue:
'default'', id=2)]
Debug message: 3:58:20 PM: EventHandler: sending resume event to [EMAIL PROTECTED]
Debug message: 3:58:22 PM: EventHandler: VM resumed
Debug message: 3:58:22 PM: EventHandler: sending resume event to [EMAIL PROTECTED]
Debug message: 3:58:22 PM: EventHandler: VM resumed
Debug message: 3:58:22 PM: JDEbug got cmd
Debug message: 3:58:22 PM: JDEbug firing command event
Debug message: 3:58:22 PM: proc: 1 got command:
jde.debugger.CommandEvent[m_procId=1,m_cmdId=3,m_cmdName=finish,m_args=[]]
Debug message: 3:58:22 PM: JDEbug command is jde.debugger.command.Finish
Debug message: 3:58:22 PM: JDEbug waiting for cmd
-8<---8<
As a result, it's too darn slow and it makes the debugger virtually useless.
Am I doing something wrong in terms of set up?
Any help would be greatly appreciated.
Thanks,
- Neeraj
Refactoring the templates
Hi, I've spent a little time looking at the JDE templates and there are a number of places where they could be refactored. I'm willing to spend some time doing it, but I'm unsure as to how to submit the refactored code. Also, there is a page on the Emacs Wiki (www.emacswiki.org) for the JDE (http://www.emacswiki.org/cgi-bin/wiki.pl/JavaDevelopmentEnvironment). Would people be willing to post some of their more useful templates or JDE customizations there? Given the ease of updating the wiki, it could also become an extended FAQ of sorts for JDE users. Thoughts? -Nick
