Bug#846116: libhamcrest-java: FTBFS randomly (error: cannot access Description)

[tony mancill]

On Thu, Dec 29, 2016 at 03:13:40PM +0100, Markus Koschany wrote:
> It seems #738789 is back or it was never completely fixed. Apparently
> the 002-fix-random-compilation-failure.patch was the intended solution.
> 
> I have pushed my preliminary work to SVN. I first tried to cure the
> problem with a switch to dh sequencer which solved similar weird
> behavior in the past for me. With cdbs I could reproduce the issue all
> the time and with dh it seems to be gone now...if you don't try to build
> twice in a row.
> 
> There are two outstanding issues now. First of all the build system does
> not clean all files from the first run and secondly there is still this
> race condition
> 
>  [javac]
> /<<PKGBUILDDIR>>/hamcrest-library/src/main/java/org/hamcrest/beans/HasProperty.java:5:
> error: cannot access Description
>     [javac] import org.hamcrest.Description;
>     [javac]                    ^
>     [javac]   bad class file:
> /<<PKGBUILDDIR>>/build/hamcrest-core-1.3.jar(org/hamcrest/Description.class)
>     [javac]     unable to access file: corrupted zip file
>     [javac]     Please remove or make sure it appears in the correct
> subdirectory of the classpath.
> 
> We could try to remove the jarjar step when the build system merges
> class files from one jar file into another or we could build-depend on
> libhamcrest-java, put that on the classpath and use the already existing
> jars in the archive instead of relying on the ones which are part of the
> build process. This option is obviously not perfect but since we can
> build libhamcrest-java from source at least once, it is not a real problem.
> 
> As Emmanuel pointed out in #738789 the randomness appears to be related
> either to Ant or the JDK or both. I don't know why it happens but we can
> only work around it.

Hi Markus,

This is some really good progress and investigation.

Just my 0.02 worth, but for the remaining race condition, I tend to
favor depending upon libhamcrest-java (as I assume this is more aligned
with how upstream does it).  Although this is technically a circular
dependency, we don't have an issues with porting since we already have
an arch:all binary package.

Cheers,
tony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20170105/089beb85/attachment.sig>