arunkumar9t2/scabbard

Build fails while updating the generated graph image

bazyle opened this issue · 4 comments

From what I understand from the stacktrace, it's the path that's looking for doesn't exist because of the naming/path naming conventions or something.
It's complaining about:

<path/to/project>/build/tmp/kapt3/classes/devDebug/ie/my/package/di/activities/ListActivityBindingModule_BindListFragment/ListFragmentSubcomponent/ie.my.package.di.activities.ListActivityBindingModule_BindListFragment.ListFragmentSubcomponent.png

But the actual directory structure on the disk is slightly different:
<path/to/project>/build/tmp/kapt3/classes/devDebug/ie/my/package/di/activities/ListActivityBindingModule_BindListFragment.ListFragmentSubcomponent/ie.my.package.di.activities.ListActivityBindingModule_BindListFragment.ListFragmentSubcomponent.png

I have the following setup:

scabbard {
    enabled true
    failOnError true
    fullBindingGraphValidation true
}

I'm using the kapt plugin in a java+kotlin project. Applying the scabbard plugin directly to a single module only.

Below's the entire stacktrace:

e: [kapt] An exception occurred: java.lang.RuntimeException: Scabbard processor failed
at dev.arunkumar.scabbard.plugin.processor.graphviz.GraphVizBindingGraphProcessor.process(GraphVizBindingGraphProcessor.kt:342)
at dev.arunkumar.scabbard.plugin.ScabbardBindingGraphPlugin.visitGraph(ScabbardBindingGraphPlugin.kt:46)
at dagger.internal.codegen.validation.BindingGraphValidator.runPlugins(BindingGraphValidator.java:100)
at dagger.internal.codegen.validation.BindingGraphValidator.visitPlugins(BindingGraphValidator.java:90)
at dagger.internal.codegen.validation.BindingGraphValidator.isValid(BindingGraphValidator.java:64)
at dagger.internal.codegen.validation.ModuleValidator.validateModuleBindings(ModuleValidator.java:642)
at dagger.internal.codegen.validation.ModuleValidator.validateUncached(ModuleValidator.java:248)
at dagger.internal.codegen.validation.ModuleValidator.lambda$validate$0(ModuleValidator.java:176)
at dagger.internal.codegen.base.Util.reentrantComputeIfAbsent(Util.java:33)
at dagger.internal.codegen.validation.ModuleValidator.validate(ModuleValidator.java:176)
at dagger.internal.codegen.validation.ModuleValidator.validate(ModuleValidator.java:170)
at dagger.internal.codegen.ModuleProcessingStep.process(ModuleProcessingStep.java:109)
at dagger.internal.codegen.ModuleProcessingStep.process(ModuleProcessingStep.java:58)
at dagger.internal.codegen.validation.TypeCheckingProcessingStep.lambda$process$0(TypeCheckingProcessingStep.java:51)
at com.google.common.collect.RegularImmutableMap.forEach(RegularImmutableMap.java:185)
at dagger.internal.codegen.validation.TypeCheckingProcessingStep.process(TypeCheckingProcessingStep.java:48)
at dagger.internal.codegen.ModuleProcessingStep.process(ModuleProcessingStep.java:100)
at dagger.internal.codegen.ModuleProcessingStep.process(ModuleProcessingStep.java:58)
at dagger.internal.codegen.statistics.DaggerStatisticsCollectingProcessingStep.process(DaggerStatisticsCollectingProcessingStep.java:52)
at dagger.shaded.auto.common.BasicAnnotationProcessor.process(BasicAnnotationProcessor.java:330)
at dagger.shaded.auto.common.BasicAnnotationProcessor.process(BasicAnnotationProcessor.java:181)
at org.jetbrains.kotlin.kapt3.base.incremental.IncrementalProcessor.process(incrementalProcessors.kt)
at org.jetbrains.kotlin.kapt3.base.ProcessorWrapper.process(annotationProcessing.kt:132)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:794)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:705)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1035)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1176)
at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1068)
at org.jetbrains.kotlin.kapt3.base.AnnotationProcessingKt.doAnnotationProcessing(annotationProcessing.kt:80)
at org.jetbrains.kotlin.kapt3.base.AnnotationProcessingKt.doAnnotationProcessing$default(annotationProcessing.kt:36)
at org.jetbrains.kotlin.kapt3.AbstractKapt3Extension.runAnnotationProcessing(Kapt3Extension.kt:223)
at org.jetbrains.kotlin.kapt3.AbstractKapt3Extension.analysisCompleted(Kapt3Extension.kt:187)
at org.jetbrains.kotlin.kapt3.ClasspathBasedKapt3Extension.analysisCompleted(Kapt3Extension.kt:98)
at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM$analyzeFilesWithJavaIntegration$2.invoke(TopDownAnalyzerFacadeForJVM.kt:95)
at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration(TopDownAnalyzerFacadeForJVM.kt:105)
at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration$default(TopDownAnalyzerFacadeForJVM.kt:80)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler$analyze$1.invoke(KotlinToJVMBytecodeCompiler.kt:395)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler$analyze$1.invoke(KotlinToJVMBytecodeCompiler.kt:65)
at org.jetbrains.kotlin.cli.common.messages.AnalyzerWithCompilerReport.analyzeAndReport(AnalyzerWithCompilerReport.kt:107)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.analyze(KotlinToJVMBytecodeCompiler.kt:386)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli(KotlinToJVMBytecodeCompiler.kt:118)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:166)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:56)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:84)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:42)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:104)
at org.jetbrains.kotlin.daemon.CompileServiceImpl$compile$1$1$2.invoke(CompileServiceImpl.kt:442)
at org.jetbrains.kotlin.daemon.CompileServiceImpl$compile$1$1$2.invoke(CompileServiceImpl.kt:102)
at org.jetbrains.kotlin.daemon.CompileServiceImpl$doCompile$$inlined$ifAlive$lambda$2.invoke(CompileServiceImpl.kt:1005)
at org.jetbrains.kotlin.daemon.CompileServiceImpl$doCompile$$inlined$ifAlive$lambda$2.invoke(CompileServiceImpl.kt:102)
at org.jetbrains.kotlin.daemon.common.DummyProfiler.withMeasure(PerfUtils.kt:138)
at org.jetbrains.kotlin.daemon.CompileServiceImpl.checkedCompile(CompileServiceImpl.kt:1047)
at org.jetbrains.kotlin.daemon.CompileServiceImpl.doCompile(CompileServiceImpl.kt:1004)
at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:441)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at sun.rmi.transport.Transport$1.run(Transport.java:200)
at sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: Scabbard processor failed
at dev.arunkumar.scabbard.plugin.processor.graphviz.GraphVizBindingGraphProcessor.process(GraphVizBindingGraphProcessor.kt:320)
... 72 more
Caused by: javax.annotation.processing.FilerException: Attempt to reopen a file for path <path/to/project>/build/tmp/kapt3/classes/devDebug/ie/my/package/di/activities/ListActivityBindingModule_BindListFragment/ListFragmentSubcomponent/ie.my.package.di.activities.ListActivityBindingModule_BindListFragment.ListFragmentSubcomponent.png
at com.sun.tools.javac.processing.JavacFiler.checkFileReopening(JavacFiler.java:535)
at com.sun.tools.javac.processing.JavacFiler.createResource(JavacFiler.java:431)
at dev.arunkumar.scabbard.plugin.output.DefaultOutputManager.createOutputFiles(DefaultOutputManager.kt:24)
at dev.arunkumar.scabbard.plugin.processor.graphviz.GraphVizBindingGraphProcessor.process(GraphVizBindingGraphProcessor.kt:74)
... 72 more

Could you please try flipping failOnError to false and check if the png is generated after build and has the correct path? fullBindingGraphValidation has tendency to process graph for a component multiple times and that leads to FilerException but in the current implementation it is explicitly ignored and does not affect graph generation behavior. Please let me know if flipping to false works, I will address how FilerExceptions are handled for next release.

I've set the fullBindingGraphValidation and failOnError to false and the build runs fine and generates graphs, but not for all the modules. Probably it silently skips the generation for some of the modules/subcomponents.
Anyways, setting fullBindingGraphValidation to false solved the problem for my instance.
Also, as a side note(or maybe a request?): would it be possible to have gutter icons in AS for modules used with ContributesAndroidInjector? I'm using ContributesAndroidInjector extensively and would benefit a LOT from this instead of digging through the generated subcomponents code be able to navigate to that sub-component's generated graph.

Oh thanks for letting me know, I will continue to investigate how FilerExceptions are currently handled.

I was already thinking to add icons for @ContibutesAndroidInjector, I agree this will be helpful. I have created #27 to track that.

I have fixed the exceptions and also added Gutters for @ContributesAndroidInjector in #33. Both should be available in 0.2.0.