EOL tracking with release date of current dependency version #267 #268
Conversation
| @@ -1212,6 +1216,74 @@ public void projectExceedsMaxLibYearsAndShouldFailTheBuild() throws Exception { | |||
| l.contains("This module exceeds the maximum" + " dependency age of 0.1 libyears"))); | |||
| } | |||
|
|
|||
| @Test | |||
| public void reportFileGenerated(@TempDir Path tempDir) throws Exception { | |||
| Path reportFile = tempDir.resolve("libyear_testreport.txt"); | |||
There was a problem hiding this comment.
Currently the plugin doesn't write any of the libyear findings to a file for outdated dependencies. What's the motivation for adding it here? To me it feels like something that should be everywhere or nowhere, I.e we should implement it everywhere else that we're logging currently. Both for things that are outdated and things that are possibly abandoned?
There was a problem hiding this comment.
We would use the plugin for the asynchronous builds via Jenkins. Analyzing the log files is tedious; We need a file in which we can look up the results at any time and which we could also send to other project participants. And yes, I also think this can be useful for all expenses. Control is possible via a configuration parameter: either all results are written to a file or to the log output.
| * otherwise only dependencies older than the specified number of years will be included. | ||
| */ | ||
| @Parameter(property = "minLibYearsForReport", defaultValue = "0.0") | ||
| private float minLibYearsForReport; |
There was a problem hiding this comment.
Would it be possible to add a test for this setting?
There was a problem hiding this comment.
The test "reportFileGenerated" is also the test for minLibYearsForReport. It is checked that not all outdated dependencies end up in the report. Should I write another separate test? What exactly should the test case be?
| Path path = Paths.get(reportFile); | ||
|
|
||
| try { | ||
| Files.write( |
There was a problem hiding this comment.
If I run this on a multi-module project, with a path that would resolve the same for multiple projects (e.g. /tmp/foo.txt or ../foo.txt, will the last one overwrite all of the previous ones?
Are there any concurrency issues if this was done in parallel?
Example parameters: -DreportFile=/tmp/foo.txt -T2C.
Would it be simpler to replace the text file writing here with log output, and to solve the file problem globally (separately)?
There was a problem hiding this comment.
In my opinion it shouldn't be a problem. The report is written in append mode.
|
Using the following: I can see the following output: But the output of the plugin itself shows this: Am I reading this wrong? It seems to suggest that the version in this project is 9.56 libyears behind but the latest version hasn't been updated in 9.77 years - which doesn't sound right. |
| | Option | Description | Format | | ||
| |----------------------|-------------------------------------------------------------|---------------------------------| | ||
| | `dependencyExcludes` | Ignore certain dependencies | `io.github.mfoo:*,org.apache:*` | | ||
| | `maxLibYears` | Cause the build to fail if dependencies are older than this | `4` | |
There was a problem hiding this comment.
Should this maxLibYears setting interact with the years-without-new-update setting?
E.g, it might make sense to cause failures if either any dependency is more than X years behind the latest or if it hasn't been updated in X years.
There was a problem hiding this comment.
We don't want the build to fail, we just need the information about how old the dependencies are and actually in one file.
|
And regarding your comment: There is a newer version of "maven-plugin-testing-harness" that is 9.56 libyears younger than the one used, but the version used is 9.77 libyears old. That's not a contradiction for me. |
See #267