Thanks for having a look, Thilina! Good to know we can always just skip the tests to get it to compile.. but will it still work the same in the rest of Taverna if some tests fail? :)
I had a look and I think the main tests failing now is something to do with handling of folder/ names in RO Bundle that has changed in the underlying zipfs in JDK9.. Basically before there was a bug in JDK where "folder1" was different from "folder1/" (see TestZipFS.directoryOrFile() ) -- and it was possible to create one as a file and another as a directory. But when inspecting a path like "folder1/fred.txt" you might get "folder1" back as it's parent, which was readable as a file in the zip file. Very confusing.. (and somehow permitted by the ZIP format as that always uses "/" in the end for folders) So RO Bundle tried to be opinionated on this and forced the trailing "/" if it was a directory. We then assumed / was there for other parts, e.g. the Manifest.withSlash() method. Now it seems JDK9 has fixed the bug, but taken the opposite stance with always removing trailing "/" (except for the root), but this breaks quite a few other things, like the JSON "bundledAs" we generate from the Path.toString(), or the .toURI() used for resolving relative references. I'm not sure which one to go for? a) If we always remove trailing "/" as far as Path.toString() is concerned, then this simplifies some things, e.g. as JDK9 native, and a directory path looks the same even if it has not been created yet (isDirectory() will say false if it does not exist). However it means we have to selectively re-add the trailing / in .toURL() and Manifest JSON to be compatible with https://researchobject.github.io/specifications/bundle/#manifest-bundledAs - e.g. a new @JsonProperty, or to get JSON-LD parsing to work with base URIs. In JDK9 this breaks a bit backwards-compatability against previous Taverna Language release, but I don't think we have used the folder strings too much outside ...? (famous last words) b) If we always include "/" for folders (keep the current behaviour also in JDK9), we can no longer delegate some methods like .toString() to the underlying Path and have to implement them in BundlePath. Perhaps this is a good thing so we can avoid the tie-in to the zipfs,- as it's shown to be a bit fragile to rely too much upon.. We would then need either to check for directory-existence in the constructor (but it might not have been created yet) or dynamically in .toString() etc. Not sure if this means it would be doing expensive check against the ZIP file on disk or if in zipfs it would effectively already be in memory. I would not prefer such dynamic .toString() as although it is more "correct", it means the paths may no longer be mutable.. the JDK "Path" is like a place-holder, it's perfectly fine to use paths for files that don't exist, just like we can use URIs for web-pages that don't exist. On 24 April 2018 at 18:16, Thilina Manamgoda <[email protected]> wrote: > Hi, > > > I was able to build this repository using java 9 without tests. But with > test build fails at Apache Taverna RO Bundle API module. I have attached > the maven log for both builds. > > On Mon, Apr 23, 2018 at 11:49 PM, Thilina Manamgoda <[email protected]> > wrote: >> >> Hi Stain, >> >> I can work on this. This the repository right? >> https://github.com/apache/incubator-taverna-language. I'll update the result >> as soon as possible. >> >> Thanks. >> >> On Tue, Apr 17, 2018 at 2:47 PM, Stian Soiland-Reyes <[email protected]> >> wrote: >>> >>> Hi, >>> >>> Considering the preparations for GSOC 2018, perhaps now is a good time >>> to release Taverna Language? There have been several pull requests >>> merged since last release which would be good to get out. I can be the >>> Release Manager. >>> >>> (Still waiting for that Taverna Mobile release!) >>> >>> >>> Are there anyone who could have a go at building it with Java 9? It >>> might be sufficient to update the Maven plugins. If many pom-changes >>> are needed for that we can do a new taverna-maven-parent as well, but >>> I think it should be sufficient to bump maven-compiler-plugin. >>> >>> -- >>> Stian Soiland-Reyes >>> http://orcid.org/0000-0001-9842-9718 >> >> > -- Stian Soiland-Reyes http://orcid.org/0000-0001-9842-9718
