[jira] [Commented] (JENA-1819) Updating from 3.12 to 3.13 breaks
[
https://issues.apache.org/jira/browse/JENA-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018498#comment-17018498
]
xia0c commented on JENA-1819:
-
Hi [~andy], thanks for your help. It could solve my issue. Would it is better
to add a breaking announcement in the release note? Then all other developers
who use Jena can know it.
> Updating from 3.12 to 3.13 breaks
> -
>
> Key: JENA-1819
> URL: https://issues.apache.org/jira/browse/JENA-1819
> Project: Apache Jena
> Issue Type: Bug
>Reporter: xia0c
>Priority: Major
>
> When I try to upgrade jena-arq from 3.12 to 3.13. The following code breaks.
> {code:java}
> public class TestJena {
>
> private static FastDateFormat timestamp =
> FastDateFormat.getInstance("HH:mm:ss.SSS") ;
>
> private void printQuery(Query query, QuerySolution initialBinding) {
> String time = DateTimeUtils.nowAsString(timestamp);
> System.err.print("~~ ");
> System.err.print(time);
> System.err.println(" ~~");
> System.err.println(initialBinding);
> System.err.print(query);
> }
> }
> {code}
> The code should pass, but it throws an error:
> {code:java}
> TestJena.java:[13,36] no suitable method found for
> nowAsString(org.apache.commons.lang3.time.FastDateFormat)
> [ERROR] method
> org.apache.jena.atlas.lib.DateTimeUtils.nowAsString(java.lang.String) is not
> applicable
> [ERROR] (argument mismatch; org.apache.commons.lang3.time.FastDateFormat
> cannot be converted to java.lang.String)
> [ERROR] method
> org.apache.jena.atlas.lib.DateTimeUtils.nowAsString(java.time.format.DateTimeFormatter)
> is not applicable
> [ERROR] (argument mismatch; org.apache.commons.lang3.time.FastDateFormat
> cannot be converted to java.time.format.DateTimeFormatter)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JENA-1819) Updating from 3.12 to 3.13 breaks
[
https://issues.apache.org/jira/browse/JENA-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018399#comment-17018399
]
Andy Seaborne edited comment on JENA-1819 at 1/17/20 11:29 PM:
---
This is due to JENA-1756.
Apache Commons Lang3 moving from v3.4 to v3.9) made a change in the way
{{FastDateFormat}} works. 3.9 does not handle timezones - it always outputs UTC.
We changed to using the JDK {{java.time.format.DateTimeFormatter}}, leaving
"nowAsString(String)" (using {{FastDateFormat}} internally) to aid migration.
Using {{DateTimeFormatter}} does handle timezones as necessary.
Presumably, class {{TestJena}} has not been recompiled with 3.13 - it's a
compile time change.
{{FastDateFormat}} and {DateTimeFormatter}} don't have quite the same syntax
but
{{DateTimeFormatter timestamp = DateTimeFormatter.ofPattern("HH:mm:ss.SSS");}}
should work.
was (Author: andy.seaborne):
This is due to JENA-1756.
Apache Commons Lang3 moving from v3.4 to v3.9) made a change in the way
{{FastDateFormat}} works. 3.9 does not handle timezones - it always outputs UTC.
We changed to using the JDK {{java.time.format.DateTimeFormatter}}, leaving
"nowAsString(String)" (using {{FastDateFormat}} internally) to aid migration.
Using {{DateTimeFormatter}} does handle timezones as necessary.
Presumably, class {{TestJena}} has not been recompiled with 3.13 - it's a
compile time change.
{FastDateFormat}} and {DateTimeFormatter}} don't have quite the same syntax but
{{DateTimeFormatter timestamp = DateTimeFormatter.ofPattern("HH:mm:ss.SSS");}}
should work.
> Updating from 3.12 to 3.13 breaks
> -
>
> Key: JENA-1819
> URL: https://issues.apache.org/jira/browse/JENA-1819
> Project: Apache Jena
> Issue Type: Bug
>Reporter: xia0c
>Priority: Major
>
> When I try to upgrade jena-arq from 3.12 to 3.13. The following code breaks.
> {code:java}
> public class TestJena {
>
> private static FastDateFormat timestamp =
> FastDateFormat.getInstance("HH:mm:ss.SSS") ;
>
> private void printQuery(Query query, QuerySolution initialBinding) {
> String time = DateTimeUtils.nowAsString(timestamp);
> System.err.print("~~ ");
> System.err.print(time);
> System.err.println(" ~~");
> System.err.println(initialBinding);
> System.err.print(query);
> }
> }
> {code}
> The code should pass, but it throws an error:
> {code:java}
> TestJena.java:[13,36] no suitable method found for
> nowAsString(org.apache.commons.lang3.time.FastDateFormat)
> [ERROR] method
> org.apache.jena.atlas.lib.DateTimeUtils.nowAsString(java.lang.String) is not
> applicable
> [ERROR] (argument mismatch; org.apache.commons.lang3.time.FastDateFormat
> cannot be converted to java.lang.String)
> [ERROR] method
> org.apache.jena.atlas.lib.DateTimeUtils.nowAsString(java.time.format.DateTimeFormatter)
> is not applicable
> [ERROR] (argument mismatch; org.apache.commons.lang3.time.FastDateFormat
> cannot be converted to java.time.format.DateTimeFormatter)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JENA-1819) Updating from 3.12 to 3.13 breaks
[
https://issues.apache.org/jira/browse/JENA-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018399#comment-17018399
]
Andy Seaborne edited comment on JENA-1819 at 1/17/20 11:29 PM:
---
This is due to JENA-1756.
Apache Commons Lang3 moving from v3.4 to v3.9) made a change in the way
{{FastDateFormat}} works. 3.9 does not handle timezones - it always outputs UTC.
We changed to using the JDK {{java.time.format.DateTimeFormatter}}, leaving
"nowAsString(String)" (using {{FastDateFormat}} internally) to aid migration.
Using {{DateTimeFormatter}} does handle timezones as necessary.
Presumably, class {{TestJena}} has not been recompiled with 3.13 - it's a
compile time change.
{FastDateFormat}} and {DateTimeFormatter}} don't have quite the same syntax but
{{DateTimeFormatter timestamp = DateTimeFormatter.ofPattern("HH:mm:ss.SSS");}}
should work.
was (Author: andy.seaborne):
This is due to JENA-1756.
Apache Commons Lang3 moving from v3.4 to v3.9) made a change in the way
{{FastDateFormat}} works. 3.9 does not handle timezones - it always outputs UTC.
We changed to using the JDK {{java.time.format.DateTimeFormatter}}, leaving
"nowAsString(String)" (using {{FastDateFormat}} internally) to aid migration.
Using {{DateTimeFormatter}} does handle timezones as necessary.
Presumably, class {{TestJena}} has not been recompiled with 3.13 - it's a
compile time change.
> Updating from 3.12 to 3.13 breaks
> -
>
> Key: JENA-1819
> URL: https://issues.apache.org/jira/browse/JENA-1819
> Project: Apache Jena
> Issue Type: Bug
>Reporter: xia0c
>Priority: Major
>
> When I try to upgrade jena-arq from 3.12 to 3.13. The following code breaks.
> {code:java}
> public class TestJena {
>
> private static FastDateFormat timestamp =
> FastDateFormat.getInstance("HH:mm:ss.SSS") ;
>
> private void printQuery(Query query, QuerySolution initialBinding) {
> String time = DateTimeUtils.nowAsString(timestamp);
> System.err.print("~~ ");
> System.err.print(time);
> System.err.println(" ~~");
> System.err.println(initialBinding);
> System.err.print(query);
> }
> }
> {code}
> The code should pass, but it throws an error:
> {code:java}
> TestJena.java:[13,36] no suitable method found for
> nowAsString(org.apache.commons.lang3.time.FastDateFormat)
> [ERROR] method
> org.apache.jena.atlas.lib.DateTimeUtils.nowAsString(java.lang.String) is not
> applicable
> [ERROR] (argument mismatch; org.apache.commons.lang3.time.FastDateFormat
> cannot be converted to java.lang.String)
> [ERROR] method
> org.apache.jena.atlas.lib.DateTimeUtils.nowAsString(java.time.format.DateTimeFormatter)
> is not applicable
> [ERROR] (argument mismatch; org.apache.commons.lang3.time.FastDateFormat
> cannot be converted to java.time.format.DateTimeFormatter)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JENA-1819) Updating from 3.12 to 3.13 breaks
[
https://issues.apache.org/jira/browse/JENA-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018399#comment-17018399
]
Andy Seaborne commented on JENA-1819:
-
This is due to JENA-1756.
Apache Commons Lang3 moving from v3.4 to v3.9) made a change in the way
{{FastDateFormat}} works. 3.9 does not handle timezones - it always outputs UTC.
We changed to using the JDK {{java.time.format.DateTimeFormatter}}, leaving
"nowAsString(String)" (using {{FastDateFormat}} internally) to aid migration.
Using {{DateTimeFormatter}} does handle timezones as necessary.
Presumably, class {{TestJena}} has not been recompiled with 3.13 - it's a
compile time change.
> Updating from 3.12 to 3.13 breaks
> -
>
> Key: JENA-1819
> URL: https://issues.apache.org/jira/browse/JENA-1819
> Project: Apache Jena
> Issue Type: Bug
>Reporter: xia0c
>Priority: Major
>
> When I try to upgrade jena-arq from 3.12 to 3.13. The following code breaks.
> {code:java}
> public class TestJena {
>
> private static FastDateFormat timestamp =
> FastDateFormat.getInstance("HH:mm:ss.SSS") ;
>
> private void printQuery(Query query, QuerySolution initialBinding) {
> String time = DateTimeUtils.nowAsString(timestamp);
> System.err.print("~~ ");
> System.err.print(time);
> System.err.println(" ~~");
> System.err.println(initialBinding);
> System.err.print(query);
> }
> }
> {code}
> The code should pass, but it throws an error:
> {code:java}
> TestJena.java:[13,36] no suitable method found for
> nowAsString(org.apache.commons.lang3.time.FastDateFormat)
> [ERROR] method
> org.apache.jena.atlas.lib.DateTimeUtils.nowAsString(java.lang.String) is not
> applicable
> [ERROR] (argument mismatch; org.apache.commons.lang3.time.FastDateFormat
> cannot be converted to java.lang.String)
> [ERROR] method
> org.apache.jena.atlas.lib.DateTimeUtils.nowAsString(java.time.format.DateTimeFormatter)
> is not applicable
> [ERROR] (argument mismatch; org.apache.commons.lang3.time.FastDateFormat
> cannot be converted to java.time.format.DateTimeFormatter)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JENA-1819) Updating from 3.12 to 3.13 breaks
xia0c created JENA-1819:
---
Summary: Updating from 3.12 to 3.13 breaks
Key: JENA-1819
URL: https://issues.apache.org/jira/browse/JENA-1819
Project: Apache Jena
Issue Type: Bug
Reporter: xia0c
When I try to upgrade jena-arq from 3.12 to 3.13. The following code breaks.
{code:java}
public class TestJena {
private static FastDateFormat timestamp =
FastDateFormat.getInstance("HH:mm:ss.SSS") ;
private void printQuery(Query query, QuerySolution initialBinding) {
String time = DateTimeUtils.nowAsString(timestamp);
System.err.print("~~ ");
System.err.print(time);
System.err.println(" ~~");
System.err.println(initialBinding);
System.err.print(query);
}
}
{code}
The code should pass, but it throws an error:
{code:java}
TestJena.java:[13,36] no suitable method found for
nowAsString(org.apache.commons.lang3.time.FastDateFormat)
[ERROR] method
org.apache.jena.atlas.lib.DateTimeUtils.nowAsString(java.lang.String) is not
applicable
[ERROR] (argument mismatch; org.apache.commons.lang3.time.FastDateFormat cannot
be converted to java.lang.String)
[ERROR] method
org.apache.jena.atlas.lib.DateTimeUtils.nowAsString(java.time.format.DateTimeFormatter)
is not applicable
[ERROR] (argument mismatch; org.apache.commons.lang3.time.FastDateFormat cannot
be converted to java.time.format.DateTimeFormatter)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: [] Apache Jena 3.14.0 RC 2
Sounds like nothing to worry about (wrt to my NOTICE question). ajs6f > On Jan 17, 2020, at 12:53 PM, Andy Seaborne wrote: > > Thanks for the vote. > > On 17/01/2020 15:58, ajs6f wrote: > >> I did notice: >>> Portions of this software are from Apache Xerces and were originally based >>> on the following: >>> - software copyright (c) 1999, IBM Corporation., http://www.ibm.com. >>> - software copyright (c) 1999, Sun Microsystems., http://www.sun.com. >> I haven't kept track of all of our moves around Xerces and its datatype >> code. Do we still need this, or did we excise all the Xerces-derived stuff? > > Jena has Xerces source code in it. Some of the datatype code was lifted from > Xerces. That's why NOTICE has that text, rather than a binary dependency on > Xerces. > > Nowadays, to avoid a binary dependency, Jena has the source code for all the > datatype machinery under "org.apache.jena.ext.xerces" without the XML parser. > Taken from 2.11.0. > > A binary dependency is a bit problematic using Jena as a library. > xercesImpl.jar has various ServiceLoader files. It will wire itself into the > JVM. > > So the whole application gets Jena's choice of XML parser. Not good. > And there is the recurrent matter of incorrectly repackage/shading jars. > > Extracting the datatype parts (which aren't huge and get called directly from > Jena anyway) and repackaging under "org.apache.jena.ext.xerces" means Jena > uses whatever XML parser the application chooses, including the JDK one > (which is a older fork of Xerces but then modified). No ServiceLoader. Helps > with OSGi as well. JENA-1537 lists a few issues that have come up over the > years. > >Andy > > > > >
Re: [] Apache Jena 3.14.0 RC 2
Thanks for the vote. On 17/01/2020 15:58, ajs6f wrote: I did notice: Portions of this software are from Apache Xerces and were originally based on the following: - software copyright (c) 1999, IBM Corporation., http://www.ibm.com. - software copyright (c) 1999, Sun Microsystems., http://www.sun.com. I haven't kept track of all of our moves around Xerces and its datatype code. Do we still need this, or did we excise all the Xerces-derived stuff? Jena has Xerces source code in it. Some of the datatype code was lifted from Xerces. That's why NOTICE has that text, rather than a binary dependency on Xerces. Nowadays, to avoid a binary dependency, Jena has the source code for all the datatype machinery under "org.apache.jena.ext.xerces" without the XML parser. Taken from 2.11.0. A binary dependency is a bit problematic using Jena as a library. xercesImpl.jar has various ServiceLoader files. It will wire itself into the JVM. So the whole application gets Jena's choice of XML parser. Not good. And there is the recurrent matter of incorrectly repackage/shading jars. Extracting the datatype parts (which aren't huge and get called directly from Jena anyway) and repackaging under "org.apache.jena.ext.xerces" means Jena uses whatever XML parser the application chooses, including the JDK one (which is a older fork of Xerces but then modified). No ServiceLoader. Helps with OSGi as well. JENA-1537 lists a few issues that have come up over the years. Andy
[jira] [Created] (JENA-1818) Bug: CustomCoordinateSequence::setOrdinate missing break statements
Philipp Neuschwander created JENA-1818: -- Summary: Bug: CustomCoordinateSequence::setOrdinate missing break statements Key: JENA-1818 URL: https://issues.apache.org/jira/browse/JENA-1818 Project: Apache Jena Issue Type: Bug Components: Spatial Affects Versions: Jena 3.13.1 Reporter: Philipp Neuschwander https://github.com/apache/jena/blob/master/jena-geosparql/src/main/java/org/apache/jena/geosparql/implementation/jts/CustomCoordinateSequence.java#L441 There should be "break" statements in that switch. Currently there is a fallthrough manipulating other axis' values leading to data corruption. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [VOTE] Apache Jena 3.14.0 RC 2
+1 binding. > + are the GPG signatures fine? > + are the checksums correct? > + is there a source archive? Yes x 3. > + can the source archive really be built? Yes. > + is there a correct LICENSE and NOTICE file in each artifact Looks good. I did notice: > Portions of this software are from Apache Xerces and were originally based on > the following: > - software copyright (c) 1999, IBM Corporation., http://www.ibm.com. > - software copyright (c) 1999, Sun Microsystems., http://www.sun.com. I haven't kept track of all of our moves around Xerces and its datatype code. Do we still need this, or did we excise all the Xerces-derived stuff? > + does the NOTICE file contain all necessary attributions? Seems to. > + have any licenses of dependencies changed due to upgrades? > if so have LICENSE and NOTICE been upgraded appropriately? Looks fine. > + does the tag/commit in the SCM contain reproducible sources? Yes. ajs6f > On Jan 16, 2020, at 12:34 PM, Andy Seaborne wrote: > > Hi, > > Here is a vote on the release of Apache Jena 3.14.0 > This is the second proposed release candidate. > > The deadline is only 72hours in case there are enough +1 votes and I can do > the final stage on Sunday - otherwise, it is likely to be mid next week. > > Changes from RC1: > > Fix for JENA-1817 > https://github.com/apache/jena/commit/08ca0b83 > > Changes for 3.14.0: > > https://s.apache.org/jena-3.14.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-1036 > > 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/d0abcd14 > > Git Commit Hash: > d0abcd14f82c36045a3c047941a6518f3bdb56ce > > Git Commit Tag: > jena-3.14.0 > > Please vote to approve this release: > >[ ] +1 Approve the release >[ ] 0 Don't care >[ ] -1 Don't release, because ... > > This vote will be open until at least > >Sunday, 19th January 2020 at 18: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?
