If you are using Java with a package/build manager like maven you can always automatically pull all the source jars and then any IDE (Intellij/Eclipse) will allow you to jump through all third party libraries. Are you targeting the non-IDE crowd with this tool?
The main use-case that I see for this is when an exception is thrown in production on some random server inside a third party library. Such exceptions can be excruciatingly hard to run down without the source code.
While useful, I can't see how it could ensure that the right version of the source code is being presented to the user.
In theory, it could analyse all versions of a library, and then choose only those versions that could lead to the given stack trace. Even that would be error prone, and may lead to multiple results.
Setting up an IDE would take extra time, but would be the best way to debug the exception.
Finding the right version of the source code is definitely a challenge. However, it's a solvable one. What you're suggesting is actually what ExceptError does. It indexes all versions of each library, and uses context from the entire stack-trace, including line-numbers, method-names, etc, to find the exact match.
Agree that IDE is the best way, especially when it comes to Java, but it's not always possible. For example you may be debugging distributed systems in production.
The other thing is that even with an IDE, I think folks may find this useful. Not everyone uses Gradle, Maven, etc, and also not every library on Maven comes with the source jars.
I wrote one of these back in 2000. We had a huge WebLogic app with 10s if not more developers rotate in and out of it over many months. So I wrote a tool that did an n-gram search over the codebase and hyper link all of the lines in an exception trace to those files on viewcvs (now viewcv). Paste in a stack trace and immediately start navigating the source repo. I would have like to have made exception capture automatically submit it to the site so we could measure exception popularity.
Edit: the ngram part was so that you could paste in random snippets of code and get hits in the version control store to start navigating. It was strictly needed for the exception hyperlinking.
This reminds me of http://www.grepcode.com/, which I used a lot before I had an environment that auto-downloaded source.
I really like that grepcode lets you see which version and what repository matches what you searched. It can make finding why something doesn't work in a particular released version of a library much easier.
It doesn't integrate with any IDE right now. As @arturnt noted, debugging and jumping to the right source code is generally not a problem when you're inside an IDE.
Even when the error happens on the server and you're not inside an IDE, most of them (I'm sure Netbeans does it) allow you to paste the stacktrace from the production logs and makes classes/lines clickable, so you can enter the source code at the right points.
It's more or less what your tool does on the web.
Your tool may still be useful if some arcane third party app crashes, but how would you track the proper source code without info on dependencies' versions?
"versions" tells you all the software versions which match, based on the context derived from the exception. For example, if you're unsure what version of Hadoop you're running, it'll tell you.
