Issue with debugging Java Maven Project in beta6

[rowbearto]

If I create a new SlickEdit project and make it a Java Project instead of Maven Project, would I be able to use "mvnDebug" in the debug command and be able to debug my java program?

I'm thinking of moving away from SE Maven Project so I can get the live errors, which should increase productivity.

[patrick]

I don't think that will work.  The problem is the java project template doesn't let you edit the command line, but builds up command lines from the information from java dialogs.  You can't really enter the maven commands in the java dialogs, and if you try to make an end run around the dialogs and edit the vpj file, the code that reads the configuration from the project file seems to get confused. 

I haven't fully checked this out, as I have found a bug with live error's jdk detection for openjdk 1.8 on linux that I need to work through.

[rowbearto]

What if I added a new tool in the Project->Properties->Tools tab? Then I'd be able to run my own command with that, right? So I could do my maven build/exec from a new tool so I could get the live errors and build/exec with one project. Then I'd just be missing the debug.

[patrick]

Creating your own build and execute targets would work.  No debugging without creating your own debug tool, and then attaching.  Getting the bindings for build and execute to call your tools would be a hassle, since the commands that handle those expect to call the well known 'execute' and 'build' targets. 

[rowbearto]

I started to make a Java Project so I can see Live Errors. I think I ran into what you (Patrick) mentioned before:

I have found a bug with live error's jdk detection for openjdk 1.8 on linux that I need to work through.

In "JDK installation directory", I put the "bin" directory of my 1.8 JDK and also tried the parent dir of bin, and I get error: "Path to JDK 1.6 or later must be specified in order to use Live Errors". Is this the same problem you are tracking down?

I'm on RC1, Linux x64, CentOS 7.2

[patrick]

Yes.  That's fixed for RC2.  It's finding the directory and compiler library correctly, but isn't extracting the version number from javac correctly.

[rowbearto]

Excellent! I'm thinking of switching to Java 11 in next few months, did you also test with Java 11 (and also 9 and 10)?

[Marcel]

If you are thinking about modularized applications, I doubt SE is ready for that.  It might work for unnamed module mode, I was able to compile but don't know yet if I can debug/run (too busy getting rid of old sun crypto apis).
My work place is using Gradle instead of Maven, but the problems are the same.  In the past I have made suggestions for SE to index the Gradle cache but have changed my mind about that. My cache has over 1000 jars with frequent updates, so indexing that is clearly not workable. I want SE to remain usable as an editor, not keep itself busy indexing 3rd-party libraries which I may never need to dive in. Maybe there is a smarter way to do late/as needed fine-grained indexing, for example when pulling up a 3rd-part class file.

For the heavy Java lifting, I am using Intellij.  It is friendly enough to download the matching sources jars for everything it needs from the Gradle cache.  The price to pay for this is a few minutes of loading time when opening a project. It doesn't do full indexing of the Gradle cache, I think all they do is build a package/class index.  it is enough to debug 3rd-party libraries at the source level and resolve imports.  If you need to clean up import lists, locate unused code, or need refactoring, IntelliJ is your friend.

SE can do certain things very well, but I don't expect it do be a replacement for a full-fledged specialized IDE. It cannot possibly replace VisualStudio or IntelliJ, they have two orders of magnitude more staff to support their products.

[patrick]

It works with openjdk 11, and 10, I didn't check 9. 

@Marcel - agree that some incremental way of dealing with the huge number of jars would be needed.  Or a way for SlickEdit to ask on a tag not found if we should try to find the corresponding source jar on a background thread. 

The ability to pull down source jars was only recently added for our Gradle support, so right now it's only used to pull down the Kotlin and Scala standard library source.  That may expand a little for the point release.

[rowbearto]

For indexing the dependencies, for Maven the pom.xml says exactly which dependencies my application is using, so limiting indexing to just those jars would do the trick?

In my case I'm writing simple tools in Java, not some big application.

In the case of debugging a maven project when using it as a Java project in SE, I think I know a workaround where I would not need to perform an attach and could debug directly. In the Build->Java Options->JRE it allows to specify "JRE app name". Instead of "java", I could put my script there "myjava", and then "myjava" would repackage the command line options and run mvnDebug instead. Would that work?

[patrick]

Yes. Support for extracting that and locating/locating the source jar files will have to go in the v23 point release.

A script works.  The only gotcha I see is that the parameters passed to the script get a "." where the qualified main class name would normally be.

[rowbearto]

But even with locating the source dependencies in a Maven project, I'd still not be able to get the "Live Errors", which sounds like much work and could not be put into a point release? Live Errors in Maven probably needs to go into a future release?

So I'll probably end up using Java Project in the short term (until Live Errors in Maven is ever supported), manually setting up tag files for my Maven dependencies, and using my script hack to do debugging if I wanted to debug in SE (I'm using eclipse now for debugging, but would be nice to stay in SE). But in the real short term when I don't have time to hack up the Java Project I'll stick with the Maven project, not index the dependencies, not have Live Errors and use eclipse for debugging until I have time to work the other things out.