taverna-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: Release Taverna Language?
Date Wed, 25 Apr 2018 22:34:55 GMT
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

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
- 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 <maanafunedu@gmail.com> 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 <maanafunedu@gmail.com>
> 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 <stain@apache.org>
>> 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

View raw message