On 25/11/2020 00:03, Andy Seaborne wrote:
On 24/11/2020 20:13, Bruno P. Kinoshita wrote:
I had a look at one of the failures:
Error Message
NTFS ADS separator (':') in file name is forbidden.
Stacktrace
java.lang.IllegalArgumentException: NTFS ADS separator (':') in file
name is forbidden.
at
org.apache.jena.riot.TestRDFParser.source_streamManager(TestRDFParser.java:169)
That looks like a legit error. `:` is not allowed in Windows
file/folder names.
It's this:
https://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_(ADS)
which is a trailing use of ":"
and that clashes with file:data.ttl because extension handling in
Commons IO check that the extension comes from the file name.
It copes by getting the extension in:
"data.ttl:something"
but throws IllegalArgumentException on because the extension is in the
ADS name:
"data:something.ttl"
PR:
https://github.com/apache/jena/pull/871
which is done to be lowest risk (code copying and restoring the
behaviour for URI paths).
Andy
Not sure if that's coming from a newer JVM version... I thought even
older JVMs would fail for that.
For the test of the error above, I think we could just rename `file:`
to `file-` or some other prefix -
https://github.com/apache/jena/blob/967d2609cf3f23ea5252d8e94d7ffb76bd6c382a/jena-arq/src/test/java/org/apache/jena/riot/TestRDFParser.java#L169
Thanks for looking and confirming this. It been quite slow going round
the loop to a Windows build. Still don't see why the stacktrace is what
it is but when I put in printStackTrace I got a long trace. (JUnit
abbreviated printing?)
It's the update of Commons IO to v 2.8.0. (The change is in 2.7.x).
FilenameUtils.indexOfExtension added the check.
Jena works in URIs ... including "file:" but the same code can be hit
for other URI schemes. It was relying on that for handling URI paths
with URI scheme and that's not a Windows filename.
(Java11 that is much more picky about file system details as well but
not the actual problem here)
The calling Jena code is IO.filenameNoCompression from
RDFLanguages.guessContentType->IO.filenameToLang
To be robust against uses elsewhere, we can adopt the Commons IO code
removing the check, at least for now (what commons-io 2.6 was doing)
Probably still better (more robust to corner cases) than the original
Jena code from a while back.
Some filenames are appearing in the Jenkins build on Windows as
"/F:/foobar" , not just "F:/", so there may be other cases lurking nearby.
Andy
Bruno
On Tuesday, 24 November 2020, 5:32:24 pm UTC, Andy Seaborne
<[email protected]> wrote:
There are test failures on Windows.
I don't have a windows development machine available so this may take
some time and build noise.
It is code that has not changed for a while and none of the commits of
the first time it happen seem to have any relation to this part of the
code but IIRC there have java JDK changes tightening up filename
handling. The build runs "jdk latest".
The stacktrace does not make sense through - it's cutoff in the middle
Jena code, not near some JVM runtime.
Andy
https://ci-builds.apache.org/job/Jena/job/Jena_Development_Windows/53/
On 24/11/2020 10:56, Andy Seaborne wrote:
Hi,
Here is a vote on the release of Apache Jena 3.17.0
This is the first proposed release candidate.
The deadline is Friday, 27 November at 12:00 UTC.
Please vote to approve this release:
[ ] +1 Approve the release
[ ] 0 Don't care
[ ] -1 Don't release, because ...
==== Major items in this release
JENA-1949: Dockerfile
and build instructions
https://jena.apache.org/documentation/fuseki2/fuseki-docker.html
JENA-1937: SHACL Compact Syntax writer
JENA-1982: SPARQL \U escapes in String and IRIs.
This is a change to ARQ extended SPARQL syntax.
JENA-1950: Use GraalVM for javascript if available.
The license means we do not ship GraalVM itself (and it is quite big).
JENA-1968:
Support Turtle output with relative URIs but no BASE declaration.
JENA-1974: G library
A library for working with Graphs
More :
https://lists.apache.org/thread.html/r973fd076583327b75e15bda798dce66d47f4f7cd8dbaa14c280f1fe3%40%3Cdev.jena.apache.org%3E
==== Dependency changes:
## Updates:
JENA-1959, JENA-1967: JSON-LD 0.12.5 -> 0.13.2 (umbreak)
JENA-1972: Jetty 9.4.26 -> 9.4.31
JENA-1973: Micrometer: 1.2.1 -> 1.5.5
JENA-1992: Update Log4j2 to 2.14.0
JENA-1993: Update Eclipse Jetty to 9.4.34
HttpClient to 4.5.13
commons-lang3 from 3.10 to 3.11
guava 29-jre to 30-jre
spatial4j from 0.6 to 0.7
airline.version from 2.1.1 to 2.8.0 (#839)
jts-core from 1.16.1 to 1.17.1 (#844)
ver.shiro from 1.5.1 to 1.7.0 (#840)
jackson-core from 2.10.1 to 2.11.3 (#847)
commons-codec 1.14 to 1.15
commons-io from 2.6 to 2.8.0
micrometer from 1.5.5 to 1.6.1
lucene 7.7.2 to 7.7,3
ElasticSearch from 6.8.6 to 6.8.9
==== Changes for 3.17.0:
https://s.apache.org/jena-3.17.0-jira
==== Release Vote
Everyone, not just committers, is invited to test and vote.
Please download and test the proposed release.
Staging repository:
https://repository.apache.org/content/repositories/orgapachejena-1040
Proposed dist/ area:
https://dist.apache.org/repos/dist/dev/jena/
Keys:
https://svn.apache.org/repos/asf/jena/dist/KEYS
Git commit (browser URL):
https://github.com/apache/jena/commit/482d2f0009
Git Commit Hash:
482d2f0009e2ab05be82faf371a7a6233bbaafd0
Git Commit Tag:
jena-3.17.0
This vote will be open until at least
Friday, 27 November at 12:00 UTC
If you expect to check the release but the time limit does not work
for you, please email within the schedule above with an expected time
and we can extend the vote period.
Thanks,
Andy
Checking needed:
+ are the GPG signatures fine?
+ are the checksums correct?
+ is there a source archive?
+ can the source archive really be built?
(NB This requires a "mvn install" first time)
+ is there a correct LICENSE and NOTICE file in each artifact
(both source and binary artifacts)?
+ does the NOTICE file contain all necessary attributions?
+ have any licenses of dependencies changed due to upgrades?
if so have LICENSE and NOTICE been upgraded appropriately?
+ does the tag/commit in the SCM contain reproducible sources?
