* bug#11254: 24.0.94; cannot find compilation-error locations for Java
@ 2012-04-16 15:22 Sam Steingold
2020-12-07 17:26 ` Lars Ingebrigtsen
0 siblings, 1 reply; 4+ messages in thread
From: Sam Steingold @ 2012-04-16 15:22 UTC (permalink / raw)
To: 11254
When I work on a maven-managed java project, I add this to
java-mode-hook:
(set (make-local-variable 'compile-command)
(concat "cd " (locate-dominating-file buffer-file-name "pom.xml") " && mvn compile test package"))
i.e., M-x compile RET runs maven in a directory far above the location
of the current file.
The errors in the compilation buffer look like this:
java.io.FileNotFoundException: null (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:137)
at java.io.FileInputStream.<init>(FileInputStream.java:96)
at com.clearspring.research.classifier.ml.index.InMemoryDictionaryIndex.buildFeaturesIndex(InMemoryDictionaryIndex.java:151)
at com.clearspring.research.classifier.ml.index.InMemoryDictionaryIndex.<init>(InMemoryDictionaryIndex.java:57)
at com.clearspring.research.classifier.Classifier.<init>(Classifier.java:34)
at com.clearspring.data.filter.bundle.BundleFilterClassify.initialize(BundleFilterClassify.java:49)
at com.clearspring.data.filter.bundle.BundleFilter.initOnceOnly(BundleFilter.java:128)
at com.clearspring.data.filter.bundle.BundleFilter.filter(BundleFilter.java:151)
at com.clearspring.data.filter.bundle.TestBundleFilterClassify.testEmptyParamsConditions(TestBundleFilterClassify.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
at $Proxy0.invoke(Unknown Source)
at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:104)
at org.apache.maven.plugin.surefire.SurefirePlugin.executeAfterPreconditionsChecked(SurefirePlugin.java:617)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:102)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
where every single line in clickable in the most useless way possible:
it asks _me_ for a directory where the file in (file.java:lineno) is located.
Note that most error lines (e.g., org.apache.*) are _not_ in my tree at
all, so making them clickable is a waste and a source of confusion.
Also, note that the method name contains the directory path to the file
(with "/" replaced with "." and some prefix like "main/java" missing).
PROPOSAL:
1. new user variable `compilation-my-methods-regexp', which, when
non-nil, prevents all other methods from being clickable.
2. new user variable `compilation-other-methods-regexp', which, when
non-nil, prevents the specified methods from being clickable.
3. when I click on a line in the stack trace, find(1) is run in the
`default-directory' of the compilation buffer like this:
if I click on
"org.codehaus.classworlds.Launcher.launch(Launcher.java:255)"
`find . -path org/codehaus/classworlds/Launcher.java`
and if that finds a single file, then that file is visited at the
specified line, and if more than one file is found, a find-dired is
run.
PS. I am using JDEE, and it delegates error finding to the stock emacs facilities.
In GNU Emacs 24.0.94.5 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2012-03-29 on t520sds
Windowing system distributor `The X.Org Foundation', version 11.0.11004000
Configured using:
`configure '--with-wide-int''
Major mode: Comint
Minor modes in effect:
semantic-minor-modes-format: ((:eval (if (or semantic-highlight-edits-mode semantic-show-unmatched-syntax-mode jde-bug-minor-mode jde-jdb-minor-mode jde-plugin-minor-mode semantic-idle-scheduler-mode) S)))
diff-auto-refine-mode: t
which-function-mode: t
url-handler-mode: t
show-paren-mode: t
shell-dirtrack-mode: t
compilation-shell-minor-mode: t
tooltip-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
--
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11004000
http://www.childpsy.net/ http://www.memritv.org http://dhimmi.com
http://mideasttruth.com http://truepeace.org http://iris.org.il http://ffii.org
Yeah, yeah, I love cats too... wanna trade recipes?
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#11254: 24.0.94; cannot find compilation-error locations for Java
2012-04-16 15:22 bug#11254: 24.0.94; cannot find compilation-error locations for Java Sam Steingold
@ 2020-12-07 17:26 ` Lars Ingebrigtsen
2020-12-07 18:17 ` Sam Steingold
0 siblings, 1 reply; 4+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-07 17:26 UTC (permalink / raw)
To: Sam Steingold; +Cc: 11254
Sam Steingold <sds@gnu.org> writes:
> When I work on a maven-managed java project, I add this to
> java-mode-hook:
> (set (make-local-variable 'compile-command)
> (concat "cd " (locate-dominating-file buffer-file-name "pom.xml") " && mvn compile test package"))
> i.e., M-x compile RET runs maven in a directory far above the location
> of the current file.
> The errors in the compilation buffer look like this:
>
> java.io.FileNotFoundException: null (No such file or directory)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.<init>(FileInputStream.java:137)
[...]
> where every single line in clickable in the most useless way possible:
> it asks _me_ for a directory where the file in (file.java:lineno) is located.
(This bug report unfortunately got no response at the time.)
I seem to recall there being fixes in this area (Java error parsing)
over the years -- are you still seeing this problem in recent versions
of Emacs?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#11254: 24.0.94; cannot find compilation-error locations for Java
2020-12-07 17:26 ` Lars Ingebrigtsen
@ 2020-12-07 18:17 ` Sam Steingold
2020-12-08 13:52 ` Lars Ingebrigtsen
0 siblings, 1 reply; 4+ messages in thread
From: Sam Steingold @ 2020-12-07 18:17 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 11254
no recollections, sorry.
On Mon, 7 Dec 2020 at 12:26, Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Sam Steingold <sds@gnu.org> writes:
>
> > When I work on a maven-managed java project, I add this to
> > java-mode-hook:
> > (set (make-local-variable 'compile-command)
> > (concat "cd " (locate-dominating-file buffer-file-name "pom.xml") " && mvn compile test package"))
> > i.e., M-x compile RET runs maven in a directory far above the location
> > of the current file.
> > The errors in the compilation buffer look like this:
> >
> > java.io.FileNotFoundException: null (No such file or directory)
> > at java.io.FileInputStream.open(Native Method)
> > at java.io.FileInputStream.<init>(FileInputStream.java:137)
>
> [...]
>
> > where every single line in clickable in the most useless way possible:
> > it asks _me_ for a directory where the file in (file.java:lineno) is located.
>
> (This bug report unfortunately got no response at the time.)
>
> I seem to recall there being fixes in this area (Java error parsing)
> over the years -- are you still seeing this problem in recent versions
> of Emacs?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
> bloggy blog: http://lars.ingebrigtsen.no
--
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net>
<http://steingoldpsychology.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-12-08 13:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-16 15:22 bug#11254: 24.0.94; cannot find compilation-error locations for Java Sam Steingold
2020-12-07 17:26 ` Lars Ingebrigtsen
2020-12-07 18:17 ` Sam Steingold
2020-12-08 13:52 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.