bug#11254: 24.0.94; cannot find compilation-error locations for Java

bug#11254: 24.0.94; cannot find compilation-error locations for Java

[Sam Steingold]

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?

bug#11254: 24.0.94; cannot find compilation-error locations for Java

[Lars Ingebrigtsen]

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

bug#11254: 24.0.94; cannot find compilation-error locations for Java

[Sam Steingold]

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>

bug#11254: 24.0.94; cannot find compilation-error locations for Java

[Lars Ingebrigtsen]

Sam Steingold <sds@gnu.org> writes:

> no recollections, sorry.

OK, closing this bug report.  If somebody else is seeing a problem here,
please reopen (or file a new bug report).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no