Debugging third party libraries (again)

[t...@quarendon.net]

Is there actually *any* way to do this?

I can attach sources to bundles (from JPM using the "add sources" option for example). When I'm in development I can therefore follow links to classes and see the source code.

I've yet to find *any* method by which I can actually step into the code. I can set breakpoints in my own code, it stops, but try and step back up the stack and I get nothing. Even for libraries I have attached sources to it doesn't work. Interestingly I can SET a breakpoint by clicking on a source line in a third party library and it stops there, but it then just complains it can't find the source code. Well you had it a minute ago!

Unlike with the "development time" source lookup, at debug time you have no idea what the jar is that it's trying to find the source for, or even, as far as I can tell, the full class name including package. And the *only* way I can find of getting it to find source is using the baffling "Edit Source Lookup Path" dialog. And since I've got no idea where the downloaded source jars have been put I have to download them again and connect them up, but it's shooting in the dark because I don't know what my target is.

All in all, as far as I can see debugging into third party libraries is essentially impossible. 

Is this just me?

[t...@quarendon.net]

On Wednesday, 27 July 2016 08:39:13 UTC+1, t...@quarendon.net wrote:

 And the *only* way I can find of getting it to find source is using the baffling "Edit Source Lookup Path" dialog. 

Although, if you DO add external jars using this dialog, you then loose the ability to debug you OWN code.  If looses the "Bnd Dependencies" folder in the "source lookup path".

[BJ Hargrave]

A fix for https://github.com/bndtools/bndtools/issues/1444 which seem like this problem was just merged for the next release.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
BJ

[t...@quarendon.net]

On Wednesday, 27 July 2016 10:27:20 UTC+1, BJ Hargrave wrote:

A fix for https://github.com/bndtools/bndtools/issues/1444 which seem like this problem was just merged for the next release.

On the face of it it looks like that would at least enable you to add sources to the debugger using this "edit source code lookup path" dialog. 

Doesn't cure the root cause issue though of why I even have to go there...

What I'm really wanting is for someone to confirm that what I see is in fact what everyone else sees, that attaching source during "editing" has no effect on the debugger?

I'm not even sure what the debug path that it's setting up represents. Even if I don't play with it it seems messed up. Below the "Bnd Dependencies" folder in that dialog I have three copies of my project, presumably because I have three bundles in my run configuration, and they are all in the same project. But there is no mention of any other bundle in my run configuration. Surely there ought to be an entry in this list for every bundle that has source attached, with then special behaviour for the case where the bundles are actually in your eclipse workspace (i.e only one  entry for each distinct relevant project)?

As I say, what I'm wanting is for someone to verify my understanding to see if it's worthwhile me trying to figure out what's wrong.

Thanks.

[t...@quarendon.net]

It looks like it *does* work if the libraries are in the local repository, just not in Central.

This is at least progress.

An apparent fix is here:

https://github.com/bndtools/bndtools/pull/1451

This just directly constructs an ExternalArchiveSourceContainer pointing to each REPO container, rather than trying to convert the path into a workbench path first.

Let me know if this seems OK.