2017-12-20 13:29 GMT+01:00 Gábor Boskovits : > 2017-12-20 11:34 GMT+01:00 Gábor Boskovits : > >> 2017-12-19 23:11 GMT+01:00 Ricardo Wurmus : >> >>> >>> Gábor Boskovits writes: >>> >>> > Now I have another blocking issue: >>> > https://github.com/Boskovits/guix/issues/24 >>> >>> > Error message: >>> > >>> > BUILD FAILED >>> > /tmp/guix-build-java-bsh-2.0b6.drv-0/beanshell-2.0b6/build.xml:654: >>> > Problem: failed to create task or type junit >>> > Cause: the class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask >>> was >>> > not found. >>> >>> Is it not just enough to add junit to the inputs of java-bsh? >>> >>> No, unfortunately it seems to affect all packages using junit. >> I guess it is because I use ant/java8, and maybe that is more fussy about >> this... >> >> It seems, that we should add the lib flag to the nat commend line, if we > have > junit as input. However junit has quite a big dependency graph with the new > hamcrest-core fix, but that is needed for junit. I think we should discuss > our options here, > I don't feel comfortable to make such a decision without prior discussion. > > Regarding this issue, in my opinion we cloud do the following: Add two parameters to ant build system: junit? junit If junit? then force use of junit, if not, then force not to use it, if unspecified check if we have junit in build.inputs, and use it if it is. junit should default to java-junit, like we have for icedtea, and ant. Can something like this be done? It would be nice if the ant-build-system needed junit only if it is in build-inputs, or explicitly requested, so that we can still use it while we don't have junit. WDYT? > In the meanwhile I will create an integration branch, and start to create > a list of patches that > can be merged to core-updates. > > Where should I send those? > > >> >> >>> -- >>> Ricardo >>> >>> GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC >>> https://elephly.net >>> >>> >>> >> >