ncLineCount column gives error #135
Comments
|
I have not seen this one before. It will take some time to investigate. |
|
Here is the stack if that helps |
|
This stacktrace helps pinpoint the particular details I need to fix it. |
|
How do you add the Clover plugin in your projects? This seems to be a classpath issue more than a class serialization issue. The classes are properly serializable for the particular ones involved here. |
|
I have them extracted to their own gradle include files but that requires calling out the full package names. import com.bmuschko.gradle.clover.CloverPlugin ... apply plugin: com.bmuschko.gradle.clover.CloverPlugin |
|
That is probably why it fails. Are you adding the clover plugin in the top level build.gradle classpath or are you adding it in a separate included I know that classpath additions in included gradle scripts are cause for classpath issues of this kind. |
|
I always make my classpath declarations only in the top build.gradle. I add configuration blocks in separate gradle scripts. FYI, using buildscript classpath dependencies in included gradle modules will be deprecated and removed in a future version of Gradle as far as I know. It is known to be a common cause for classpath issues like the one you are describing here. |
|
I didn't know that. I just hacked the gradle stuff together so open for improvements. I'll try to move the classpath dependency to build.gradle and see if that helps. Thank you ! |
|
I worked out the problem. Moving the classpath dependencies wasn't the solution. Gradle creates a cache directory in your project called .gradle, gradle clean does not clean this. If you change the columns in the report after running once and rebuild without removing the .gradle directory it will fail. I don't know exactly what output gradle has cached that causes this problem. If you generate a clover report and then change the columns do you not see the same problem? I don't think I have anything other than default gradle caching enabled. |
|
That is how Gradle works. The task inputs for the previous successfully executed tasks are cached in the .gradle directory in the root of your project. When Gradle needs to check your task for up to date conditions it will attempt to deserialize the cached inputs. At that point the classpath is important and will need to have the plugin classes to allow the deserialization to succeed. You should not need to remove this directory except when plugins change in incompatible ways. This particular class in the plugin has not changed since many iterations ago. So, I doubt what you are having issues with it any of my problem. All I can see from the stacktrace is that the class was not found which signals me to suspect your nested script classpath configuration. |
|
I agree with you about how gradle works but independent of if you have the classpath dependencies in the main gradle file - as I tried this - re-running after changing a column will not work unless you wipe that .gradle directory. I can't speak to if this is a bug but it seems odd that I'd have to delete the .gradle directory after changing the column configuration in order for the report to work again. Did you give that a try on your end and see if you can run, change the columns, and re-run a build successfully? |
|
I have to try this myself and find out why it fails. The classnotfound error is a classpath error and there is not much I can do about that. I do not control the classpath Gradle uses for finding the plugin classes. As you see from the stacktrace you provided there is no code stack trace from this plugin in the entire stack so even if I wanted to try I would not have any way to change it. So, I cannot promise you that I will be able to figure this out easily. It is not within this plugin execution path. |
|
I can certainly reproduce this easily with a simple project. I suspect this never worked well and had such an issue since I added the feature but as it is an obscure kind of feature not many people use it. If I am correct the problem might be that Gradle cannot handle task inputs with custom task types, it prefers simple primitive types and collections of the same or any Gradle provided types. This might mean that I would have to come up with a metadata representation of the columns when I attach them as task inputs and convert them in the task instead. The behavior implemented right now takes the DSL implementation classes which are correctly serializable and uses them as task inputs in a collection. |
|
Ok thanks for looking at it and all the work on the plugin! I can work around the issue by just deleting the .gradle directory if I change the column format. It just took a lot of testing to figure out that was the issue. Probably just add some documentation for now and put it at the back of the pile - at least there is a work around. |
|
You will probably find that this fails if the code is changed and you rebuild the project incrementally. Any time the task cloverGenerateReport or cloverAggregateReports needs to execute the same kind of failure will happen if the task has executed successfully once before. It is standard incremental build issue with Gradle. I think the solution is actually not hard to implement now that you brought this to my attention. Understanding why this was broken in the first place was the hard part. Now that I can make it happen easily it will not be long before it can be fixed the right way. |
|
Sounds great ! Thank you ! |
This issue was caused by the fact that Gradle task properties must not use classes other than Gradle classes or Java classes. Using plugin implementation classes as task inputs results in ClassNotFound errors when incremental compilation attempts to deserialize the cached task inputs. The fix was accomplished by using JSON strings to represent the more complex data structures used for the custom Clover report columns feature. This ensures the task inputs can be deserialized and works incrementally.
|
Fixed in release 2.2.3 |
report {
//...
columns {
//..
ncLineCount format: 'raw'
//...
https://confluence.atlassian.com/clover/clover-report-71600095.html#clover-report-Columns
The text was updated successfully, but these errors were encountered: