Testcontainers-java: Debugging is not possible with downloaded sources

[zbstof]

Steps to reproduce:

1. Create project that uses testcontainers
2. Download testcontainers sources (for example, navigate to GenericContainer.class and clicking 'Download sources' in IntelliJ IDEA)
3. Create breakpoint in some file that uses lombok and shading of dependencies: https://github.com/testcontainers/testcontainers-java/blob/master/core/src/main/java/org/testcontainers/containers/DockerComposeContainer.java#L629
   Result: When breakpoint is hit, instruction pointer point at the different location due to the different between line numbers in bytecode and source.
   Additionally, all the shaded dependencies such as org.zeroturnaround.exec.InvalidExitValueException; are shown in red, as they don't exist on the classpath

Expected result:

1. I can navigate and step into to any shaded dependency and
2. Any breakpoint location works in lombok-enhanced source files.

Solution:
Run

• delombok
• shade plugin
  before packaging source jar

Current workaround:
If I want to read sources, I download them
If I want to debug, I manually remove sources from IntelliJ project setup

[unserializable]

I am trying to use 1.8.3 and find debugging impossible as well, though maybe by this time it is for different reasons. IntelliJ Idea used with download sources, examined testcontainers-1.8.3-sources.jar contains files, e.g. like GenericContainer.java which have headers indicating delombok'ing:

// Generated by delombok at Sun Aug 05 21:14:34 UTC 2018
package org.testcontainers.containers;

None of the breakpoints match at source line numbers.
Release process likely it is happening as follows:

• actual release packages with debugging symbols are created from NON-delombok'ed source code.
• source .jars are created from delombok'ed source code.

Solution in this case would be to either /release/ from delombok'ed source or to release NON-delombok'ed sources with release made from NON-delombok'ed sources.

[dnault]

See https://github.com/johnrengelman/shadow/issues/41 for the repackaged dependency source issue.

[fzakaria]

This is incredibly frustrating. +1 to fixing.

[mmichaelis]

Suggested Workaround: Use tagged sources from repository rather than sources.jar

As workaround I tried to use the tagged sources (here: 1.10.5; git checkout -b release-1.10.5 1.10.5) from repository directly instead of using the sources-JAR. This works much better than the sources.jar — but for some reason IDEs like IntelliJ Idea still complain that the source code does not match the bytecode. But I could not observe problems while stepping through the methods.

In IntelliJ Idea you can add the mapping in File/Project Structure/Libraries. I added sources from core/src/main/java.

[leonard84]

I would suggest not publishing the de-lomboked code as sources, just use the originals. You can publish an additional artifact -sources-delomboked.jar if you want to have the old style available as well.

[nhooey]

So this issue is coming up because Lombok is used to generate getters and setters on the fly?

Maybe the cost of using Lombok is too high while. For now I'm avoiding downloading the source when debugging.

[leonard84]

@nhooey no the issue is that the sources that are published, are not the original sources, but delomboked sources. If you'd use the original sources, debugging works for the non boilerplate code.

[ravenblackdusk]

@rnorth also org.testcontainers:spock sources contain only manifest. Is this a related issue?