Bye bye commons-io#14
Conversation
| if (writerFile != null) { | ||
| try { | ||
| FileUtils.moveFile(writerFile, readerFile); | ||
| Files.move(writerFile.toPath(), readerFile.toPath()); |
There was a problem hiding this comment.
Just a caveat, the docs for nio.files state The move fails if the target file exists, unless the REPLACE_EXISTING option is specified. Might need to check that is expected behaviour .
There was a problem hiding this comment.
Yep, I checked that before I made the change. That specific behaviour is identical to that of FileUtils.moveFile():
- https://docs.oracle.com/javase/8/docs/api/java/nio/file/Files.html#move-java.nio.file.Path-java.nio.file.Path-java.nio.file.CopyOption...-
- https://commons.apache.org/proper/commons-io/javadocs/api-2.5/org/apache/commons/io/FileUtils.html#moveFile(java.io.File,%20java.io.File)
There are likely other behavioral differences but I don't think they're particularly relevant.
|
Excluding, other repositories e.g. omero-renderer will require some TLC. |
| } | ||
|
|
||
| configurations.all { | ||
| exclude group: 'commons-io' |
There was a problem hiding this comment.
Running gradle dependencies shows quite a lot of inclusions of commons-io. Would excluding it entirely not trigger an error when a dependency attempts to use any commons-io APIs?
There was a problem hiding this comment.
that's what is currently happening omero-renderer for example uses commons-io cf. build link in the previous comment
There was a problem hiding this comment.
Yes it would, however that's highly situational. Let's take one commons-io example from the dependency tree of this library:
...
| +--- org.hibernate:hibernate-core:3.6.10.Final
| | +--- antlr:antlr:2.7.6
| | +--- commons-collections:commons-collections:3.1
| | +--- dom4j:dom4j:1.6.1
| | +--- org.hibernate:hibernate-commons-annotations:3.2.0.Final
| | | \--- org.slf4j:slf4j-api:1.5.8 -> 1.7.22
| | +--- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.1.Final
| | +--- javax.transaction:jta:1.1
| | \--- org.slf4j:slf4j-api:1.6.1 -> 1.7.22
...
This is brought in because omero-romio depends on omero-common which by extension depends on omero-model. Hibernate annotations are used there so nearly all the Hibernate JARs are brought in. However, omero-romio doesn't actually use any of these classes itself.
It's hard to build things in such a way where dependencies do not unexpectedly leak. Serious software engineering care and attention has to be paid to interface, concrete class, and dependency construction to avoid it and we have not historically spent a lot of time doing so.
Are you talking about omero-server, @jburel? There are no omero-renderer build failure references that I can see in the aforementioned build 72 failure. Rather the issues seem to be in omero-server, no?
|
@jburel : I propose to remove your |
|
removed |
|
Looking a bit more carefully at the usage of |
|
removing exclude to test it again Some changes required in omero-blitz |
4 participants
Remove use of commons-io. Most critical code paths were able to be replaced with Java 8 nio
PathsorFilesusage. Where that was not possible equivalent Guava functions were used.@mtbc @rgozim @jburel @sbesson @joshmoore