[jira] [Updated] (IO-506) Deprecate methods FileSystemUtils.freeSpaceKb()
[ https://issues.apache.org/jira/browse/IO-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated IO-506: --- Summary: Deprecate methods FileSystemUtils.freeSpaceKb() (was: Deprecate methods FileSystemUtils.freeSpaceKb(). ) > Deprecate methods FileSystemUtils.freeSpaceKb() > --- > > Key: IO-506 > URL: https://issues.apache.org/jira/browse/IO-506 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Christian Schulte >Priority: Trivial > Fix For: 2.6 > > Attachments: IO-506.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IO-506) Deprecate methods FileSystemUtils.freeSpaceKb()
[ https://issues.apache.org/jira/browse/IO-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated IO-506: --- Assignee: Gary Gregory Description: Deprecated in favour of [java.nio.file.Filestore.getUsableSpace()|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html#getUsableSpace()] and [getUnallocatedSpace|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html#getUnallocatedSpace()] in Java 7 and later. As all the methods of FileSystemUtils are now deprecated, I think we should not deprecate the whole class as well? > Deprecate methods FileSystemUtils.freeSpaceKb() > --- > > Key: IO-506 > URL: https://issues.apache.org/jira/browse/IO-506 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Christian Schulte >Assignee: Gary Gregory >Priority: Trivial > Fix For: 2.6 > > Attachments: IO-506.patch > > > Deprecated in favour of > [java.nio.file.Filestore.getUsableSpace()|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html#getUsableSpace()] > and > [getUnallocatedSpace|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html#getUnallocatedSpace()] > in Java 7 and later. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IO-506) Deprecate methods FileSystemUtils.freeSpaceKb()
[ https://issues.apache.org/jira/browse/IO-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16183344#comment-16183344 ] Stian Soiland-Reyes edited comment on IO-506 at 9/27/17 10:11 PM: -- As all the methods of FileSystemUtils are now deprecated, should we not deprecate the whole class as well? was (Author: stain): As all the methods of FileSystemUtils are now deprecated, I think we should not deprecate the whole class as well? > Deprecate methods FileSystemUtils.freeSpaceKb() > --- > > Key: IO-506 > URL: https://issues.apache.org/jira/browse/IO-506 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Christian Schulte >Assignee: Gary Gregory >Priority: Trivial > Fix For: 2.6 > > Attachments: IO-506.patch > > > Deprecated in favour of > [java.nio.file.Filestore.getUsableSpace()|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html#getUsableSpace()] > and > [getUnallocatedSpace|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html#getUnallocatedSpace()] > in Java 7 and later. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IO-506) Deprecate methods FileSystemUtils.freeSpaceKb()
[
https://issues.apache.org/jira/browse/IO-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16183404#comment-16183404
]
Stian Soiland-Reyes commented on IO-506:
Suggested javadoc:
{code}
* @deprecated As of 2.6 deprecated without replacement. Use equivalent
* methods in {@link java.nio.file.FileStore} instead, e.g.
*
Files.getFileStore(Paths.get("/home")).getUsableSpace()
* or iterate over
FileSystems.getDefault().getFileStores()
{code}
> Deprecate methods FileSystemUtils.freeSpaceKb()
> ---
>
> Key: IO-506
> URL: https://issues.apache.org/jira/browse/IO-506
> Project: Commons IO
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Christian Schulte
>Assignee: Gary Gregory
>Priority: Trivial
> Fix For: 2.6
>
> Attachments: IO-506.patch
>
>
> Deprecated in favour of
> [java.nio.file.Filestore.getUsableSpace()|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html#getUsableSpace()]
> and
> [getUnallocatedSpace|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html#getUnallocatedSpace()]
> in Java 7 and later.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (COMMONSRDF-62) japicmp-maven-plugin breaking build because there is at least one incompatibility
[
https://issues.apache.org/jira/browse/COMMONSRDF-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated COMMONSRDF-62:
--
Assignee: Peter Ansell
> japicmp-maven-plugin breaking build because there is at least one
> incompatibility
> -
>
> Key: COMMONSRDF-62
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-62
> Project: Apache Commons RDF
> Issue Type: Bug
> Components: api, build
>Affects Versions: 0.3.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Lewis John McGibbney
>Assignee: Peter Ansell
>Priority: Blocker
> Fix For: 1.0.0
>
>
> When I attempt to build using above environment, I get the following
> {code}
> [INFO] Commons RDF SUCCESS [ 2.897
> s]
> [INFO] Commons RDF API FAILURE [ 8.461
> s]
> [INFO] Commons RDF impl: Simple ... SKIPPED
> [INFO] Commons RDF impl: RDF4j SKIPPED
> [INFO] Commons RDF impl: Jena . SKIPPED
> [INFO] Commons RDF impl: JSON-LD Java . SKIPPED
> [INFO] Commons RDF Integration tests .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 11.626 s
> [INFO] Finished at: 2017-07-24T19:40:13-07:00
> [INFO] Final Memory: 51M/584M
> [INFO]
>
> [ERROR] Failed to execute goal
> com.github.siom79.japicmp:japicmp-maven-plugin:0.10.0:cmp (default) on
> project commons-rdf-api: Breaking the build because there is at least one
> incompatibility:
> org.apache.commons.rdf.api.RDFSyntax.byName(java.lang.String):METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.equals(java.lang.Object):METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.fileExtension():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.fileExtensions():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.hashCode():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.iri():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.mediaType():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.mediaTypes():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.name():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.supportsDataset():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.title():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.valueOf(java.lang.String):METHOD_REMOVED,org.apache.commons.rdf.api.RDFSyntax.values():METHOD_REMOVED,org.apache.commons.rdf.api.RDFSyntax.w3cSyntaxes():METHOD_ADDED_TO_INTERFACE,java.lang.Comparable[java.lang.Comparable]:INTERFACE_REMOVED,java.io.Serializable[java.io.Serializable]:INTERFACE_REMOVED,org.apache.commons.rdf.api.RDFSyntax:SUPERCLASS_REMOVED,org.apache.commons.rdf.api.RDFSyntax.RDFA_XHTML:FIELD_REMOVED,org.apache.commons.rdf.api.RDFSyntax.RDFA_HTML:FIELD_REMOVED,org.apache.commons.rdf.api.RDFSyntax.mediaType:FIELD_REMOVED,org.apache.commons.rdf.api.RDFSyntax.supportsDataset:FIELD_REMOVED,org.apache.commons.rdf.api.RDFSyntax.fileExtension:FIELD_REMOVED,org.apache.commons.rdf.api.RDFSyntax:CLASS_NOW_ABSTRACT,org.apache.commons.rdf.api.RDFSyntax:CLASS_TYPE_CHANGED
> -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :commons-rdf-api
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (COMMONSRDF-62) japicmp-maven-plugin breaking build because there is at least one incompatibility
[
https://issues.apache.org/jira/browse/COMMONSRDF-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved COMMONSRDF-62.
---
Resolution: Fixed
> japicmp-maven-plugin breaking build because there is at least one
> incompatibility
> -
>
> Key: COMMONSRDF-62
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-62
> Project: Apache Commons RDF
> Issue Type: Bug
> Components: api, build
>Affects Versions: 0.3.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Lewis John McGibbney
>Assignee: Peter Ansell
>Priority: Blocker
> Fix For: 1.0.0
>
>
> When I attempt to build using above environment, I get the following
> {code}
> [INFO] Commons RDF SUCCESS [ 2.897
> s]
> [INFO] Commons RDF API FAILURE [ 8.461
> s]
> [INFO] Commons RDF impl: Simple ... SKIPPED
> [INFO] Commons RDF impl: RDF4j SKIPPED
> [INFO] Commons RDF impl: Jena . SKIPPED
> [INFO] Commons RDF impl: JSON-LD Java . SKIPPED
> [INFO] Commons RDF Integration tests .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 11.626 s
> [INFO] Finished at: 2017-07-24T19:40:13-07:00
> [INFO] Final Memory: 51M/584M
> [INFO]
>
> [ERROR] Failed to execute goal
> com.github.siom79.japicmp:japicmp-maven-plugin:0.10.0:cmp (default) on
> project commons-rdf-api: Breaking the build because there is at least one
> incompatibility:
> org.apache.commons.rdf.api.RDFSyntax.byName(java.lang.String):METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.equals(java.lang.Object):METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.fileExtension():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.fileExtensions():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.hashCode():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.iri():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.mediaType():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.mediaTypes():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.name():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.supportsDataset():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.title():METHOD_ADDED_TO_INTERFACE,org.apache.commons.rdf.api.RDFSyntax.valueOf(java.lang.String):METHOD_REMOVED,org.apache.commons.rdf.api.RDFSyntax.values():METHOD_REMOVED,org.apache.commons.rdf.api.RDFSyntax.w3cSyntaxes():METHOD_ADDED_TO_INTERFACE,java.lang.Comparable[java.lang.Comparable]:INTERFACE_REMOVED,java.io.Serializable[java.io.Serializable]:INTERFACE_REMOVED,org.apache.commons.rdf.api.RDFSyntax:SUPERCLASS_REMOVED,org.apache.commons.rdf.api.RDFSyntax.RDFA_XHTML:FIELD_REMOVED,org.apache.commons.rdf.api.RDFSyntax.RDFA_HTML:FIELD_REMOVED,org.apache.commons.rdf.api.RDFSyntax.mediaType:FIELD_REMOVED,org.apache.commons.rdf.api.RDFSyntax.supportsDataset:FIELD_REMOVED,org.apache.commons.rdf.api.RDFSyntax.fileExtension:FIELD_REMOVED,org.apache.commons.rdf.api.RDFSyntax:CLASS_NOW_ABSTRACT,org.apache.commons.rdf.api.RDFSyntax:CLASS_TYPE_CHANGED
> -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :commons-rdf-api
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMMONSRDF-64) Add Automatic-Module-Name to bundle manifest
[
https://issues.apache.org/jira/browse/COMMONSRDF-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16184940#comment-16184940
]
Stian Soiland-Reyes commented on COMMONSRDF-64:
---
Thanks! Now merged. How do we document which module names we have?
> Add Automatic-Module-Name to bundle manifest
>
>
> Key: COMMONSRDF-64
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-64
> Project: Apache Commons RDF
> Issue Type: Improvement
> Components: api, jena, jsonld-java, rdf4j, simple
>Affects Versions: 0.3.0
>Reporter: Aaron Coburn
>Assignee: Stian Soiland-Reyes
> Fix For: 1.0.0
>
>
> The JDK 9 module system will honor an Automatic-Module-Name manifest header
> when importing modules. It would be nice if the Commons RDF modules provided
> this.
> In the absence of this header, the modules can still be imported, but the
> {{requires}} statement will look different. Adding the header proactively
> will make the transition to Java9 easier for code that uses the Commons RDF
> library.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (COMMONSRDF-64) Add Automatic-Module-Name to bundle manifest
[
https://issues.apache.org/jira/browse/COMMONSRDF-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved COMMONSRDF-64.
---
Resolution: Fixed
> Add Automatic-Module-Name to bundle manifest
>
>
> Key: COMMONSRDF-64
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-64
> Project: Apache Commons RDF
> Issue Type: Improvement
> Components: api, jena, jsonld-java, rdf4j, simple
>Affects Versions: 0.3.0
>Reporter: Aaron Coburn
>Assignee: Stian Soiland-Reyes
> Fix For: 1.0.0
>
>
> The JDK 9 module system will honor an Automatic-Module-Name manifest header
> when importing modules. It would be nice if the Commons RDF modules provided
> this.
> In the absence of this header, the modules can still be imported, but the
> {{requires}} statement will look different. Adding the header proactively
> will make the transition to Java9 easier for code that uses the Commons RDF
> library.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (COMMONSRDF-64) Add Automatic-Module-Name to bundle manifest
[
https://issues.apache.org/jira/browse/COMMONSRDF-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated COMMONSRDF-64:
--
Assignee: Stian Soiland-Reyes
> Add Automatic-Module-Name to bundle manifest
>
>
> Key: COMMONSRDF-64
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-64
> Project: Apache Commons RDF
> Issue Type: Improvement
> Components: api, jena, jsonld-java, rdf4j, simple
>Affects Versions: 0.3.0
>Reporter: Aaron Coburn
>Assignee: Stian Soiland-Reyes
> Fix For: 1.0.0
>
>
> The JDK 9 module system will honor an Automatic-Module-Name manifest header
> when importing modules. It would be nice if the Commons RDF modules provided
> this.
> In the absence of this header, the modules can still be imported, but the
> {{requires}} statement will look different. Adding the header proactively
> will make the transition to Java9 easier for code that uses the Commons RDF
> library.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (COMMONSRDF-65) Upgrade Jena version to 3.4.0
[ https://issues.apache.org/jira/browse/COMMONSRDF-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated COMMONSRDF-65: -- Affects Version/s: 0.3.0 > Upgrade Jena version to 3.4.0 > - > > Key: COMMONSRDF-65 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-65 > Project: Apache Commons RDF > Issue Type: Improvement > Components: jena >Affects Versions: 0.3.0 >Reporter: A. Soroka >Priority: Minor > Fix For: 1.0.0 > > > Upgrade Jena dependency to 3.4.0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (COMMONSRDF-65) Upgrade Jena version to 3.4.0
[ https://issues.apache.org/jira/browse/COMMONSRDF-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated COMMONSRDF-65: -- Fix Version/s: 1.0.0 > Upgrade Jena version to 3.4.0 > - > > Key: COMMONSRDF-65 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-65 > Project: Apache Commons RDF > Issue Type: Improvement > Components: jena >Affects Versions: 0.3.0 >Reporter: A. Soroka >Priority: Minor > Fix For: 1.0.0 > > > Upgrade Jena dependency to 3.4.0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (COMMONSRDF-65) Upgrade Jena version to 3.4.0
[ https://issues.apache.org/jira/browse/COMMONSRDF-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated COMMONSRDF-65: -- Assignee: Stian Soiland-Reyes > Upgrade Jena version to 3.4.0 > - > > Key: COMMONSRDF-65 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-65 > Project: Apache Commons RDF > Issue Type: Improvement > Components: jena >Affects Versions: 0.3.0 >Reporter: A. Soroka >Assignee: Stian Soiland-Reyes >Priority: Minor > Fix For: 1.0.0 > > > Upgrade Jena dependency to 3.4.0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (COMMONSRDF-63) AbstractRDFParserTest.parseFile and parseFileContentType broken under Mac OS X
[
https://issues.apache.org/jira/browse/COMMONSRDF-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated COMMONSRDF-63:
--
Assignee: Stian Soiland-Reyes
> AbstractRDFParserTest.parseFile and parseFileContentType broken under Mac OS X
> --
>
> Key: COMMONSRDF-63
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-63
> Project: Apache Commons RDF
> Issue Type: Bug
> Components: simple
>Affects Versions: 0.3.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Lewis John McGibbney
>Assignee: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.0.0
>
>
> {code}
> mvn clean install
> -Dcommons.japicmp.breakBuildOnBinaryIncompatibleModifications=false
> -Djava.io.tmpdir=/path/to/some/directory
> {code}
> results in the following
> {code}
> Results :
> Failed tests:
> AbstractRDFParserTest.parseFile:121
> expected:< but
> was:<
> AbstractRDFParserTest.parseFileContentType:165
> expected:< but
> was:<
> Tests run: 87, Failures: 2, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Commons RDF SUCCESS [ 3.086
> s]
> [INFO] Commons RDF API SUCCESS [ 8.001
> s]
> [INFO] Commons RDF impl: Simple ... FAILURE [ 3.706
> s]
> [INFO] Commons RDF impl: RDF4j SKIPPED
> [INFO] Commons RDF impl: Jena . SKIPPED
> [INFO] Commons RDF impl: JSON-LD Java . SKIPPED
> [INFO] Commons RDF Integration tests .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 15.042 s
> [INFO] Finished at: 2017-09-12T16:20:45-07:00
> [INFO] Final Memory: 47M/721M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project commons-rdf-simple: There are test failures.
> [ERROR]
> [ERROR] Please refer to /usr/local/commons-rdf/simple/target/surefire-reports
> for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :commons-rdf-simple
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (COMMONSRDF-63) AbstractRDFParserTest.parseFile and parseFileContentType broken under Mac OS X
[
https://issues.apache.org/jira/browse/COMMONSRDF-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved COMMONSRDF-63.
---
Resolution: Fixed
> AbstractRDFParserTest.parseFile and parseFileContentType broken under Mac OS X
> --
>
> Key: COMMONSRDF-63
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-63
> Project: Apache Commons RDF
> Issue Type: Bug
> Components: simple
>Affects Versions: 1.0.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Lewis John McGibbney
>Assignee: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.0.0
>
>
> {code}
> mvn clean install
> -Dcommons.japicmp.breakBuildOnBinaryIncompatibleModifications=false
> -Djava.io.tmpdir=/path/to/some/directory
> {code}
> results in the following
> {code}
> Results :
> Failed tests:
> AbstractRDFParserTest.parseFile:121
> expected:< but
> was:<
> AbstractRDFParserTest.parseFileContentType:165
> expected:< but
> was:<
> Tests run: 87, Failures: 2, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Commons RDF SUCCESS [ 3.086
> s]
> [INFO] Commons RDF API SUCCESS [ 8.001
> s]
> [INFO] Commons RDF impl: Simple ... FAILURE [ 3.706
> s]
> [INFO] Commons RDF impl: RDF4j SKIPPED
> [INFO] Commons RDF impl: Jena . SKIPPED
> [INFO] Commons RDF impl: JSON-LD Java . SKIPPED
> [INFO] Commons RDF Integration tests .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 15.042 s
> [INFO] Finished at: 2017-09-12T16:20:45-07:00
> [INFO] Final Memory: 47M/721M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project commons-rdf-simple: There are test failures.
> [ERROR]
> [ERROR] Please refer to /usr/local/commons-rdf/simple/target/surefire-reports
> for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :commons-rdf-simple
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (COMMONSRDF-63) AbstractRDFParserTest.parseFile and parseFileContentType broken under Mac OS X
[
https://issues.apache.org/jira/browse/COMMONSRDF-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated COMMONSRDF-63:
--
Affects Version/s: (was: 0.3.0)
1.0.0
> AbstractRDFParserTest.parseFile and parseFileContentType broken under Mac OS X
> --
>
> Key: COMMONSRDF-63
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-63
> Project: Apache Commons RDF
> Issue Type: Bug
> Components: simple
>Affects Versions: 1.0.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Lewis John McGibbney
>Assignee: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.0.0
>
>
> {code}
> mvn clean install
> -Dcommons.japicmp.breakBuildOnBinaryIncompatibleModifications=false
> -Djava.io.tmpdir=/path/to/some/directory
> {code}
> results in the following
> {code}
> Results :
> Failed tests:
> AbstractRDFParserTest.parseFile:121
> expected:< but
> was:<
> AbstractRDFParserTest.parseFileContentType:165
> expected:< but
> was:<
> Tests run: 87, Failures: 2, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Commons RDF SUCCESS [ 3.086
> s]
> [INFO] Commons RDF API SUCCESS [ 8.001
> s]
> [INFO] Commons RDF impl: Simple ... FAILURE [ 3.706
> s]
> [INFO] Commons RDF impl: RDF4j SKIPPED
> [INFO] Commons RDF impl: Jena . SKIPPED
> [INFO] Commons RDF impl: JSON-LD Java . SKIPPED
> [INFO] Commons RDF Integration tests .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 15.042 s
> [INFO] Finished at: 2017-09-12T16:20:45-07:00
> [INFO] Final Memory: 47M/721M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project commons-rdf-simple: There are test failures.
> [ERROR]
> [ERROR] Please refer to /usr/local/commons-rdf/simple/target/surefire-reports
> for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :commons-rdf-simple
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMMONSRDF-63) AbstractRDFParserTest.parseFile and parseFileContentType broken under Mac OS X
[
https://issues.apache.org/jira/browse/COMMONSRDF-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16185084#comment-16185084
]
Stian Soiland-Reyes commented on COMMONSRDF-63:
---
Fixed by using .toRealPath() when testing the dummy parser's "base". Also added
explicit test that base URI is resolved from the real path of following
symbolic links.
> AbstractRDFParserTest.parseFile and parseFileContentType broken under Mac OS X
> --
>
> Key: COMMONSRDF-63
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-63
> Project: Apache Commons RDF
> Issue Type: Bug
> Components: simple
>Affects Versions: 1.0.0
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Lewis John McGibbney
>Assignee: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.0.0
>
>
> {code}
> mvn clean install
> -Dcommons.japicmp.breakBuildOnBinaryIncompatibleModifications=false
> -Djava.io.tmpdir=/path/to/some/directory
> {code}
> results in the following
> {code}
> Results :
> Failed tests:
> AbstractRDFParserTest.parseFile:121
> expected:< but
> was:<
> AbstractRDFParserTest.parseFileContentType:165
> expected:< but
> was:<
> Tests run: 87, Failures: 2, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Commons RDF SUCCESS [ 3.086
> s]
> [INFO] Commons RDF API SUCCESS [ 8.001
> s]
> [INFO] Commons RDF impl: Simple ... FAILURE [ 3.706
> s]
> [INFO] Commons RDF impl: RDF4j SKIPPED
> [INFO] Commons RDF impl: Jena . SKIPPED
> [INFO] Commons RDF impl: JSON-LD Java . SKIPPED
> [INFO] Commons RDF Integration tests .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 15.042 s
> [INFO] Finished at: 2017-09-12T16:20:45-07:00
> [INFO] Final Memory: 47M/721M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project commons-rdf-simple: There are test failures.
> [ERROR]
> [ERROR] Please refer to /usr/local/commons-rdf/simple/target/surefire-reports
> for the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :commons-rdf-simple
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (COMMONSRDF-65) Upgrade to Jena 3.4.0, RDF4J 2.2.2
[ https://issues.apache.org/jira/browse/COMMONSRDF-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated COMMONSRDF-65: -- Summary: Upgrade to Jena 3.4.0, RDF4J 2.2.2 (was: Upgrade Jena version to 3.4.0) > Upgrade to Jena 3.4.0, RDF4J 2.2.2 > -- > > Key: COMMONSRDF-65 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-65 > Project: Apache Commons RDF > Issue Type: Improvement > Components: jena >Affects Versions: 0.3.0 >Reporter: A. Soroka >Assignee: Stian Soiland-Reyes >Priority: Minor > Fix For: 1.0.0 > > > Upgrade Jena dependency to 3.4.0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMMONSRDF-65) Upgrade to Jena 3.4.0, RDF4J 2.2.2
[ https://issues.apache.org/jira/browse/COMMONSRDF-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16185097#comment-16185097 ] Stian Soiland-Reyes commented on COMMONSRDF-65: --- Thanks, [~ajs6f]! I also bumped RDF4J to 2.2.2 which does not seem to add any incompatibility issues. > Upgrade to Jena 3.4.0, RDF4J 2.2.2 > -- > > Key: COMMONSRDF-65 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-65 > Project: Apache Commons RDF > Issue Type: Improvement > Components: jena >Affects Versions: 0.3.0 >Reporter: A. Soroka >Assignee: Stian Soiland-Reyes >Priority: Minor > Fix For: 1.0.0 > > > Upgrade Jena dependency to 3.4.0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (COMMONSRDF-65) Upgrade to Jena 3.4.0, RDF4J 2.2.2
[ https://issues.apache.org/jira/browse/COMMONSRDF-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes resolved COMMONSRDF-65. --- Resolution: Fixed > Upgrade to Jena 3.4.0, RDF4J 2.2.2 > -- > > Key: COMMONSRDF-65 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-65 > Project: Apache Commons RDF > Issue Type: Improvement > Components: jena >Affects Versions: 0.3.0 >Reporter: A. Soroka >Assignee: Stian Soiland-Reyes >Priority: Minor > Fix For: 1.0.0 > > > Upgrade Jena dependency to 3.4.0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IO-506) Deprecate FileSystemUtils
[ https://issues.apache.org/jira/browse/IO-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated IO-506: --- Summary: Deprecate FileSystemUtils (was: Deprecate methods FileSystemUtils.freeSpaceKb()) > Deprecate FileSystemUtils > - > > Key: IO-506 > URL: https://issues.apache.org/jira/browse/IO-506 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 2.5 >Reporter: Christian Schulte >Assignee: Gary Gregory >Priority: Trivial > Fix For: 2.6 > > Attachments: IO-506.patch > > > Deprecated in favour of > [java.nio.file.Filestore.getUsableSpace()|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html#getUsableSpace()] > and > [getUnallocatedSpace|https://docs.oracle.com/javase/7/docs/api/java/nio/file/FileStore.html#getUnallocatedSpace()] > in Java 7 and later. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IO-522) Symbolic links get followed in deleteQuietly
[ https://issues.apache.org/jira/browse/IO-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated IO-522: --- Assignee: Stian Soiland-Reyes > Symbolic links get followed in deleteQuietly > > > Key: IO-522 > URL: https://issues.apache.org/jira/browse/IO-522 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.5 >Reporter: Daniel Temme >Assignee: Stian Soiland-Reyes >Priority: Critical > > IO-168 describes the problem. > `deleteQuietly` will behave correctly for nested symlinks but the initial > call erroneously calls `cleanDirectory`. Calling `deleteDirectory` and > returning would probably be the better behaviour (analogous to `forceDelete`) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (COMMONSRDF-69) Update NOTICE year
[
https://issues.apache.org/jira/browse/COMMONSRDF-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated COMMONSRDF-69:
--
Assignee: Stian Soiland-Reyes
> Update NOTICE year
> --
>
> Key: COMMONSRDF-69
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-69
> Project: Apache Commons RDF
> Issue Type: Improvement
> Components: build
>Affects Versions: 0.5.0
>Reporter: Sergio Fernández
>Assignee: Stian Soiland-Reyes
>Priority: Trivial
>
> As [~brunodepau...@yahoo.com.br] commented during the release of {{0.5.0}}
> (https://lists.apache.org/thread.html/7ce02e505da04bf03094b70efd7f2353375d8841b1d454724ab4041e@%3Cdev.commons.apache.org%3E),
> we are using a wrong year in out {{NOTICE}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (COMMONSRDF-69) Update NOTICE year
[
https://issues.apache.org/jira/browse/COMMONSRDF-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved COMMONSRDF-69.
---
Resolution: Resolved
Updated.
Also added META-INF/LICENSE and META-INF/NOTICE to the remaining commons-rdf-*
modules and tests so they appear in all the JARs for the Maven repo.
> Update NOTICE year
> --
>
> Key: COMMONSRDF-69
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-69
> Project: Apache Commons RDF
> Issue Type: Improvement
> Components: build
>Affects Versions: 0.5.0
>Reporter: Sergio Fernández
>Assignee: Stian Soiland-Reyes
>Priority: Trivial
>
> As [~brunodepau...@yahoo.com.br] commented during the release of {{0.5.0}}
> (https://lists.apache.org/thread.html/7ce02e505da04bf03094b70efd7f2353375d8841b1d454724ab4041e@%3Cdev.commons.apache.org%3E),
> we are using a wrong year in out {{NOTICE}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMMONSRDF-73) Jena module has Simple dependency, SPI will never work
[
https://issues.apache.org/jira/browse/COMMONSRDF-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280172#comment-16280172
]
Stian Soiland-Reyes commented on COMMONSRDF-73:
---
Agree with Marco here that we could try to move some dependencies from
commons-rdf-simple to the commons-rdf-api module (or a new internal module) to
avoid this issue.
In commons-rdf-jena and -rdf4j the only dependency for -simple is due to:
{code}
import org.apache.commons.rdf.simple.experimental.AbstractRDFParser;
{code}
In commons-rdf-jsonld-java there are also:
{code}
import org.apache.commons.rdf.simple.Types;
import org.apache.commons.rdf.simple.experimental.AbstractRDFParser;
{code}
So when we 'graduate' RDFParser out of `experimental` then we can also graduate
the Abstract implementation to commons-rdf-api.
> Jena module has Simple dependency, SPI will never work
> --
>
> Key: COMMONSRDF-73
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-73
> Project: Apache Commons RDF
> Issue Type: Bug
> Components: jena
>Affects Versions: 0.3.0
>Reporter: Marco Brandizi
>
> I'm trying to setup the RDF object one should use with Commons-RDF in a
> transparent way, using the SPI mechanism, ServiceLoader and
> META-INF/org.apache.commons.rdf.api.RDF.
> This is the code I'm using:
> {code:java}
> private synchronized static RDF getDefaultRdf ()
> {
> if ( defaultRdf != null ) return defaultRdf;
>
> ServiceLoader loader = ServiceLoader.load ( RDF.class );
> Iterator itr = loader.iterator();
>
> if ( !itr.hasNext () ) throw new RdfException (
> "No implementation found for Commons RDF, please, review your
> dependencies/classpath"
> );
> defaultRdf = itr.next();
> if ( itr.hasNext () ) log.warn (
> "More than one RDF instance available for Commons RDF, taking
> the first one ({})",
> itr.next ().getClass ().getName ()
> );
>
> return defaultRdf;
> }
> {code}
> I've done a first test with the Jena module (commons-rdf-jena). SPI is broken
> by the fact this module also declares commons-rdf-simple as one of its
> dependencies. At least in Maven, the META-INF in commons-rdf-simple is the
> first that is met in the classpath and the simple implementation is the one
> that is picked by the code above, as reported by the warning. I expect the
> Jena implementation to be pulled up when I link the jena module as the only
> dependency.
> Such dependency should be removed, and not just because of this problem
> (different commons implementations should be independent of each other). I've
> given a look at the source files and it seem the rdf-simple module is only
> used for testing purposes (but physically is in the main code folders).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (COMMONSRDF-73) Jena module has Simple dependency, SPI will never work
[
https://issues.apache.org/jira/browse/COMMONSRDF-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated COMMONSRDF-73:
--
Assignee: Stian Soiland-Reyes
> Jena module has Simple dependency, SPI will never work
> --
>
> Key: COMMONSRDF-73
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-73
> Project: Apache Commons RDF
> Issue Type: Bug
> Components: jena
>Affects Versions: 0.3.0
>Reporter: Marco Brandizi
>Assignee: Stian Soiland-Reyes
>
> I'm trying to setup the RDF object one should use with Commons-RDF in a
> transparent way, using the SPI mechanism, ServiceLoader and
> META-INF/org.apache.commons.rdf.api.RDF.
> This is the code I'm using:
> {code:java}
> private synchronized static RDF getDefaultRdf ()
> {
> if ( defaultRdf != null ) return defaultRdf;
>
> ServiceLoader loader = ServiceLoader.load ( RDF.class );
> Iterator itr = loader.iterator();
>
> if ( !itr.hasNext () ) throw new RdfException (
> "No implementation found for Commons RDF, please, review your
> dependencies/classpath"
> );
> defaultRdf = itr.next();
> if ( itr.hasNext () ) log.warn (
> "More than one RDF instance available for Commons RDF, taking
> the first one ({})",
> itr.next ().getClass ().getName ()
> );
>
> return defaultRdf;
> }
> {code}
> I've done a first test with the Jena module (commons-rdf-jena). SPI is broken
> by the fact this module also declares commons-rdf-simple as one of its
> dependencies. At least in Maven, the META-INF in commons-rdf-simple is the
> first that is met in the classpath and the simple implementation is the one
> that is picked by the code above, as reported by the warning. I expect the
> Jena implementation to be pulled up when I link the jena module as the only
> dependency.
> Such dependency should be removed, and not just because of this problem
> (different commons implementations should be independent of each other). I've
> given a look at the source files and it seem the rdf-simple module is only
> used for testing purposes (but physically is in the main code folders).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMMONSRDF-72) Pointers to containers (Graph/RDF)
[
https://issues.apache.org/jira/browse/COMMONSRDF-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280180#comment-16280180
]
Stian Soiland-Reyes commented on COMMONSRDF-72:
---
I think this is quite difficult to expect from Commons RDF as there is no
requirement of containment.
For {{RDFTerm.getGraph}}:
* The term (perhaps except for {{BlankNode}}) can be used in any graph/dataset
in any implementation - how is it to be informed of this?
* An RDFTerm can be used in many triples/quads (which can be in many graphs and
datasets.)
* An RDFTerm can be used independent of any graph or dataset
* Keeping backlinks adds to unnecessary memory usage per RDFTerm object
* Two RDFTerms created in different ways (and even in different
implementations) with say the same IRI are {{.equals()}}. Would they return the
same list of graphs/dataset no matter how they were constructed? (How?)
{{Triple.getGraph()}} / {{Quad.getDataset()}}:
* (Same as above, e.g.)
* A Triple or Quad can be used outside a Graph/Dataset
* A Triple/Quad can be used in many Graph/Datasets across implementations
* ..
*
{{Graph.getRDF()}} / {{Dataset.getRDF()}}:
* I can see this one is useful - it could just give the preferred RDF factory
to use for efficiency reasons (which may or may not be the {{RDF}} used to make
the Graph instance).
Could you make a new ticket to suggest Graph.getRDF and Dataset.getRDF?
> Pointers to containers (Graph/RDF)
> --
>
> Key: COMMONSRDF-72
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-72
> Project: Apache Commons RDF
> Issue Type: New Feature
> Components: api
>Reporter: Marco Brandizi
>
> I'm writing a few utilities to ease the use of commons RDF, starting from a
> library I already have for Jena
> ([here|https://github.com/marco-brandizi/rdfutils/blob/master/rdfutils-core/src/main/java/info/marcobrandizi/rdfutils/GraphUtils.java]
> the interface).
> It would be quite useful to have container links in interfaces like Graph
> (Graph.getRDF()) or RDFTerm (RDFTerm.getGraph()). Methods that need to go
> back to their container to do something (e.g., add some property/value
> statement to a given IRI object, using the graph it comes from) wouldn't need
> to receive too many parameters (new triples would be added to
> subject.getGraph() and new IRI properties would be generated using
> subject.getGraph().getRDF() ).
> Jena uses this approach (e.g., RDFNode has getModel() ).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (COMMONSRDF-72) Pointers to containers (Graph/RDF)
[ https://issues.apache.org/jira/browse/COMMONSRDF-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated COMMONSRDF-72: -- Assignee: Stian Soiland-Reyes > Pointers to containers (Graph/RDF) > -- > > Key: COMMONSRDF-72 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-72 > Project: Apache Commons RDF > Issue Type: New Feature > Components: api >Reporter: Marco Brandizi >Assignee: Stian Soiland-Reyes > > I'm writing a few utilities to ease the use of commons RDF, starting from a > library I already have for Jena > ([here|https://github.com/marco-brandizi/rdfutils/blob/master/rdfutils-core/src/main/java/info/marcobrandizi/rdfutils/GraphUtils.java] > the interface). > It would be quite useful to have container links in interfaces like Graph > (Graph.getRDF()) or RDFTerm (RDFTerm.getGraph()). Methods that need to go > back to their container to do something (e.g., add some property/value > statement to a given IRI object, using the graph it comes from) wouldn't need > to receive too many parameters (new triples would be added to > subject.getGraph() and new IRI properties would be generated using > subject.getGraph().getRDF() ). > Jena uses this approach (e.g., RDFNode has getModel() ). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CSV-215) CSVRecord mutability
[ https://issues.apache.org/jira/browse/CSV-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358644#comment-16358644 ] Stian Soiland-Reyes commented on CSV-215: - https://github.com/apache/commons-csv/pull/25 proposes some mutator functions. > CSVRecord mutability > > > Key: CSV-215 > URL: https://issues.apache.org/jira/browse/CSV-215 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Nitin Mahendru >Priority: Minor > Labels: features > Original Estimate: 16h > Remaining Estimate: 16h > > I recently pushed a change(pull request 20) to get the line ending from the > parser. > Now I want to push another change which I feel will also be useful for the > community. I want to add a CSVRecordMutable class which had a constructor > which accepts a CSVRecord object. So when we have a CSVRecordMutable object > from it then we can edit individual columns using it. > I would be using this to write back my edited CSV file. My use case is to > read a csv, mangle some columns, write back a new csv. > I could have directly raised a pull request but I just wanted to float the > idea before and see the reaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-216) Allow for mutable CSV records
[ https://issues.apache.org/jira/browse/CSV-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358651#comment-16358651 ] Stian Soiland-Reyes commented on CSV-216: - See also https://github.com/apache/commons-csv/pull/25 > Allow for mutable CSV records > - > > Key: CSV-216 > URL: https://issues.apache.org/jira/browse/CSV-216 > Project: Commons CSV > Issue Type: New Feature > Components: Parser >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > > All for mutable CSV records. > See the dev ML and https://github.com/apache/commons-csv/pull/21 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (COMMONSRDF-74) Add Dataset and DatasetGraph conversions to JenaRDF
[ https://issues.apache.org/jira/browse/COMMONSRDF-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated COMMONSRDF-74: -- Assignee: Stian Soiland-Reyes > Add Dataset and DatasetGraph conversions to JenaRDF > --- > > Key: COMMONSRDF-74 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-74 > Project: Apache Commons RDF > Issue Type: Improvement > Components: jena >Affects Versions: 0.3.0 >Reporter: A. Soroka >Assignee: Stian Soiland-Reyes >Priority: Trivial > Fix For: 0.5.0 > > > Users will find it helpful to have conversions for Jena's Dataset and > DatasetGraph types where they can already find conversions for Graphs, > Models, Triples, etc., in JenaRDF. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (COMMONSRDF-74) Add Dataset and DatasetGraph conversions to JenaRDF
[ https://issues.apache.org/jira/browse/COMMONSRDF-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes resolved COMMONSRDF-74. --- Resolution: Fixed Fix Version/s: (was: 0.5.0) 0.6.0 Thanks, [~ajs6f] > Add Dataset and DatasetGraph conversions to JenaRDF > --- > > Key: COMMONSRDF-74 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-74 > Project: Apache Commons RDF > Issue Type: Improvement > Components: jena >Affects Versions: 0.3.0 >Reporter: A. Soroka >Assignee: Stian Soiland-Reyes >Priority: Trivial > Fix For: 0.6.0 > > > Users will find it helpful to have conversions for Jena's Dataset and > DatasetGraph types where they can already find conversions for Graphs, > Models, Triples, etc., in JenaRDF. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (COMMONSRDF-72) Pointers to containers (Graph/RDF)
[ https://issues.apache.org/jira/browse/COMMONSRDF-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes closed COMMONSRDF-72. - Resolution: Won't Fix Closing as Won't Fix as the RDFTerm/Triple/Quad objects can live independent of potentially multiple graph/dataset backends. Adding Graph.getRDF() and Dataset.getRDF() could be useful, but I think that should be a new issue. > Pointers to containers (Graph/RDF) > -- > > Key: COMMONSRDF-72 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-72 > Project: Apache Commons RDF > Issue Type: New Feature > Components: api >Reporter: Marco Brandizi >Assignee: Stian Soiland-Reyes >Priority: Major > > I'm writing a few utilities to ease the use of commons RDF, starting from a > library I already have for Jena > ([here|https://github.com/marco-brandizi/rdfutils/blob/master/rdfutils-core/src/main/java/info/marcobrandizi/rdfutils/GraphUtils.java] > the interface). > It would be quite useful to have container links in interfaces like Graph > (Graph.getRDF()) or RDFTerm (RDFTerm.getGraph()). Methods that need to go > back to their container to do something (e.g., add some property/value > statement to a given IRI object, using the graph it comes from) wouldn't need > to receive too many parameters (new triples would be added to > subject.getGraph() and new IRI properties would be generated using > subject.getGraph().getRDF() ). > Jena uses this approach (e.g., RDFNode has getModel() ). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COMMONSSITE-103) GSOC: Apache Commons bug bounty
Stian Soiland-Reyes created COMMONSSITE-103:
---
Summary: GSOC: Apache Commons bug bounty
Key: COMMONSSITE-103
URL: https://issues.apache.org/jira/browse/COMMONSSITE-103
Project: Commons All
Issue Type: New Feature
Reporter: Stian Soiland-Reyes
[Apache Commons|https://commons.apache.org/] is a project that manage a series
of independent Java libraries called
[components|https://commons.apache.org/components.html].
Some of the perhaps most well known components include
[commons-io|https://commons.apache.org/proper/commons-io/],
[commons-lang|https://commons.apache.org/proper/commons-lang/],
[commons-collections|https://commons.apache.org/proper/commons-collections/]
and [commons-cli|https://commons.apache.org/proper/commons-cli/]
But did you know that Commons is also managing some more specialized components
like [commons-crypto|https://commons.apache.org/proper/commons-crypto/],
[commons-numbers|https://commons.apache.org/proper/commons-numbers/],
[commons-rng|https://commons.apache.org/proper/commons-rng/] and
[commons-rdf|https://commons.apache.org/proper/commons-rdf/] ?
The potential GSOC student will propose an idea to work with one or more chosen
Apache Commons components to churn through any outstanding Jira issues, update
for Java 8/9, improve web site, documentation or testing.
As the appropriate GSOC mentor will depend slightly on which Commons component
the student is interested in, prospective students are encouraged to engage
early by subscribing and posting to
[dev@commons|https://lists.apache.org/list.html?d...@commons.apache.org] using
the subject tag [GSOC] and the commons component(s) they are intested in, e.g.
{quote}
To: d...@commons.apache.org
Subject: [GSOC] [Crypto] Potential GSOC idea
Hi, I am Alice, student at Foo university, and I am interested in GSOC for
Apache Commons, in particular Commons Crypto as I have been quite involved in
cryptography protocols over the years together with my friend Bob.
What could be a good chunk of work to get started with? Perhaps adding support
for rot13?
{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (COMMONSSITE-103) GSOC: Apache Commons bug bounty
[
https://issues.apache.org/jira/browse/COMMONSSITE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated COMMONSSITE-103:
Labels: commons gsoc2018 library (was: gsoc2018)
> GSOC: Apache Commons bug bounty
> ---
>
> Key: COMMONSSITE-103
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-103
> Project: Commons All
> Issue Type: New Feature
>Reporter: Stian Soiland-Reyes
>Priority: Major
> Labels: commons, gsoc2018, library
>
> [Apache Commons|https://commons.apache.org/] is a project that manage a
> series of independent Java libraries called
> [components|https://commons.apache.org/components.html].
> Some of the perhaps most well known components include
> [commons-io|https://commons.apache.org/proper/commons-io/],
> [commons-lang|https://commons.apache.org/proper/commons-lang/],
> [commons-collections|https://commons.apache.org/proper/commons-collections/]
> and [commons-cli|https://commons.apache.org/proper/commons-cli/]
> But did you know that Commons is also managing some more specialized
> components like
> [commons-crypto|https://commons.apache.org/proper/commons-crypto/],
> [commons-numbers|https://commons.apache.org/proper/commons-numbers/],
> [commons-rng|https://commons.apache.org/proper/commons-rng/] and
> [commons-rdf|https://commons.apache.org/proper/commons-rdf/] ?
> The potential GSOC student will propose an idea to work with one or more
> chosen Apache Commons components to churn through any outstanding Jira
> issues, update for Java 8/9, improve web site, documentation or testing.
> As the appropriate GSOC mentor will depend slightly on which Commons
> component the student is interested in, prospective students are encouraged
> to engage early by subscribing and posting to
> [dev@commons|https://lists.apache.org/list.html?d...@commons.apache.org]
> using the subject tag [GSOC] and the commons component(s) they are intested
> in, e.g.
> {quote}
> To: d...@commons.apache.org
> Subject: [GSOC] [Crypto] Potential GSOC idea
> Hi, I am Alice, student at Foo university, and I am interested in GSOC for
> Apache Commons, in particular Commons Crypto as I have been quite involved in
> cryptography protocols over the years together with my friend Bob.
> What could be a good chunk of work to get started with? Perhaps adding
> support for rot13?
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (COMMONSSITE-103) GSOC: Apache Commons bug bounty
[
https://issues.apache.org/jira/browse/COMMONSSITE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated COMMONSSITE-103:
Labels: gsoc2018 (was: )
> GSOC: Apache Commons bug bounty
> ---
>
> Key: COMMONSSITE-103
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-103
> Project: Commons All
> Issue Type: New Feature
>Reporter: Stian Soiland-Reyes
>Priority: Major
> Labels: commons, gsoc2018, library
>
> [Apache Commons|https://commons.apache.org/] is a project that manage a
> series of independent Java libraries called
> [components|https://commons.apache.org/components.html].
> Some of the perhaps most well known components include
> [commons-io|https://commons.apache.org/proper/commons-io/],
> [commons-lang|https://commons.apache.org/proper/commons-lang/],
> [commons-collections|https://commons.apache.org/proper/commons-collections/]
> and [commons-cli|https://commons.apache.org/proper/commons-cli/]
> But did you know that Commons is also managing some more specialized
> components like
> [commons-crypto|https://commons.apache.org/proper/commons-crypto/],
> [commons-numbers|https://commons.apache.org/proper/commons-numbers/],
> [commons-rng|https://commons.apache.org/proper/commons-rng/] and
> [commons-rdf|https://commons.apache.org/proper/commons-rdf/] ?
> The potential GSOC student will propose an idea to work with one or more
> chosen Apache Commons components to churn through any outstanding Jira
> issues, update for Java 8/9, improve web site, documentation or testing.
> As the appropriate GSOC mentor will depend slightly on which Commons
> component the student is interested in, prospective students are encouraged
> to engage early by subscribing and posting to
> [dev@commons|https://lists.apache.org/list.html?d...@commons.apache.org]
> using the subject tag [GSOC] and the commons component(s) they are intested
> in, e.g.
> {quote}
> To: d...@commons.apache.org
> Subject: [GSOC] [Crypto] Potential GSOC idea
> Hi, I am Alice, student at Foo university, and I am interested in GSOC for
> Apache Commons, in particular Commons Crypto as I have been quite involved in
> cryptography protocols over the years together with my friend Bob.
> What could be a good chunk of work to get started with? Perhaps adding
> support for rot13?
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMMONSSITE-103) GSOC: Apache Commons bug bounty
[
https://issues.apache.org/jira/browse/COMMONSSITE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16383466#comment-16383466
]
Stian Soiland-Reyes commented on COMMONSSITE-103:
-
Hi, [~kamila.molina97] - that sounds like a great idea since Commons RDF it has
multiple impementations of the same API, and they are currently separated as
Maven modules. Another potential candidate for that could be Commons-VFS
although that is a single Maven module currently.
https://commons.apache.org/proper/commons-rdf/userguide.html#Creating_Commons_RDF_instances
shows how it now uses ServiceLoader SPI to find implementations, which could
be good to revise/test for Java 9 modules.
I suggest you make a new brief JIRA issue under the "Commons RDF" Jira project
(I'm afraid there's one project per Commons component) and point to that from
here -- perhaps [~ajs6f] could be interested in being the GSOC mentor..? ;-)
> GSOC: Apache Commons bug bounty
> ---
>
> Key: COMMONSSITE-103
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-103
> Project: Commons All
> Issue Type: New Feature
>Reporter: Stian Soiland-Reyes
>Priority: Major
> Labels: commons, gsoc2018, library
>
> [Apache Commons|https://commons.apache.org/] is a project that manage a
> series of independent Java libraries called
> [components|https://commons.apache.org/components.html].
> Some of the perhaps most well known components include
> [commons-io|https://commons.apache.org/proper/commons-io/],
> [commons-lang|https://commons.apache.org/proper/commons-lang/],
> [commons-collections|https://commons.apache.org/proper/commons-collections/]
> and [commons-cli|https://commons.apache.org/proper/commons-cli/]
> But did you know that Commons is also managing some more specialized
> components like
> [commons-crypto|https://commons.apache.org/proper/commons-crypto/],
> [commons-numbers|https://commons.apache.org/proper/commons-numbers/],
> [commons-rng|https://commons.apache.org/proper/commons-rng/] and
> [commons-rdf|https://commons.apache.org/proper/commons-rdf/] ?
> The potential GSOC student will propose an idea to work with one or more
> chosen Apache Commons components to churn through any outstanding Jira
> issues, update for Java 8/9, improve web site, documentation or testing.
> As the appropriate GSOC mentor will depend slightly on which Commons
> component the student is interested in, prospective students are encouraged
> to engage early by subscribing and posting to
> [dev@commons|https://lists.apache.org/list.html?d...@commons.apache.org]
> using the subject tag [GSOC] and the commons component(s) they are intested
> in, e.g.
> {quote}
> To: d...@commons.apache.org
> Subject: [GSOC] [Crypto] Potential GSOC idea
> Hi, I am Alice, student at Foo university, and I am interested in GSOC for
> Apache Commons, in particular Commons Crypto as I have been quite involved in
> cryptography protocols over the years together with my friend Bob.
> What could be a good chunk of work to get started with? Perhaps adding
> support for rot13?
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMMONSSITE-82) Glitch when project base url is not commons.apache.org
[
https://issues.apache.org/jira/browse/COMMONSSITE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14508117#comment-14508117
]
Stian Soiland-Reyes commented on COMMONSSITE-82:
Changing it to
{code}
background-image: none;
{code}
seems to work, as it then does not reset the other background-properties within
the nav-list.
> Glitch when project base url is not commons.apache.org
> --
>
> Key: COMMONSSITE-82
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-82
> Project: Commons All
> Issue Type: Bug
> Components: Commons Skin
>Reporter: Benedikt Ritter
> Attachments: commons-skin-glitch.png
>
>
> When using the commons skin for projects not located at commons.apache.org
> (but for example in the incubator) the commons skin will produce a broken
> side nav.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COMMONSSITE-82) Glitch when project base url is not commons.apache.org
[
https://issues.apache.org/jira/browse/COMMONSSITE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14508116#comment-14508116
]
Stian Soiland-Reyes commented on COMMONSSITE-82:
Changing it to
{code}
background-image: none;
{code}
seems to work, as it then does not reset the other background-properties within
the nav-list.
> Glitch when project base url is not commons.apache.org
> --
>
> Key: COMMONSSITE-82
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-82
> Project: Commons All
> Issue Type: Bug
> Components: Commons Skin
>Reporter: Benedikt Ritter
> Attachments: commons-skin-glitch.png
>
>
> When using the commons skin for projects not located at commons.apache.org
> (but for example in the incubator) the commons skin will produce a broken
> side nav.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (COMMONSSITE-82) Glitch when project base url is not commons.apache.org
[
https://issues.apache.org/jira/browse/COMMONSSITE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated COMMONSSITE-82:
---
Comment: was deleted
(was: Changing it to
{code}
background-image: none;
{code}
seems to work, as it then does not reset the other background-properties within
the nav-list.
)
> Glitch when project base url is not commons.apache.org
> --
>
> Key: COMMONSSITE-82
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-82
> Project: Commons All
> Issue Type: Bug
> Components: Commons Skin
>Reporter: Benedikt Ritter
> Attachments: commons-skin-glitch.png
>
>
> When using the commons skin for projects not located at commons.apache.org
> (but for example in the incubator) the commons skin will produce a broken
> side nav.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COMMONSSITE-82) Glitch when project base url is not commons.apache.org
[
https://issues.apache.org/jira/browse/COMMONSSITE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14511199#comment-14511199
]
Stian Soiland-Reyes commented on COMMONSSITE-82:
If you replace site.css you have to include all the existing content. It's
better to include additional CSS.
This worked in site.xml:
{code}
{code}
(I didn't add a and additional CSS file, as then there could be relative
path problems)
> Glitch when project base url is not commons.apache.org
> --
>
> Key: COMMONSSITE-82
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-82
> Project: Commons All
> Issue Type: Bug
> Components: Commons Skin
>Reporter: Benedikt Ritter
> Attachments: commons-skin-glitch.png
>
>
> When using the commons skin for projects not located at commons.apache.org
> (but for example in the incubator) the commons skin will produce a broken
> side nav.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COMMONSSITE-82) Glitch when project base url is not commons.apache.org
[ https://issues.apache.org/jira/browse/COMMONSSITE-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14517185#comment-14517185 ] Stian Soiland-Reyes commented on COMMONSSITE-82: Fixed in SVN. > Glitch when project base url is not commons.apache.org > -- > > Key: COMMONSSITE-82 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-82 > Project: Commons All > Issue Type: Bug > Components: Commons Skin >Reporter: Benedikt Ritter > Attachments: commons-skin-glitch.png > > > When using the commons skin for projects not located at commons.apache.org > (but for example in the incubator) the commons skin will produce a broken > side nav. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (VFS-604) PermissionsTests fail if built on noexec mounted file system (e.g. tmpfs)
Stian Soiland-Reyes created VFS-604:
---
Summary: PermissionsTests fail if built on noexec mounted file
system (e.g. tmpfs)
Key: VFS-604
URL: https://issues.apache.org/jira/browse/VFS-604
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.1
Environment: Ubuntu 14.04, with noexec mounted tmpfs
{code}
stain@biggie:/tmp/vfs$ cat /etc/fstab| grep tmp
tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=4G 0 0
{code}
and OpenJDK 8
{code}
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_72-internal, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "3.16.0-67-generic", arch: "amd64", family: "unix"
{code}
Reporter: Stian Soiland-Reyes
Priority: Trivial
If Commons VFS is compiled on a file system mounted with the noexec flag, e.g.
on /tmp with tmpfs, then the PermissionsTests.testExecutable fails:
{code}
Tests run: 90, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.259
sec <<< FAILURE! - in
org.apache.commons.vfs2.provider.local.test.LocalProviderTestCase
testExecutable(org.apache.commons.vfs2.test.PermissionsTests) Time
elapsed: 0.011 sec <<< FAILURE!
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.commons.vfs2.test.PermissionsTests.testExecutable(PermissionsTests.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:218)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:252)
at junit.framework.TestSuite.run(TestSuite.java:247)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
at
org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:149)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at
org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:154)
{code}
See
http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAMBJEmVkgqCbnz4BUJ7KpBn_cyTgxgJJiy%3D16dJQxNcyTT_c4w%40mail.gmail.com%3E
I must admit this is a bit weird - because you ARE allowed to set exec
permissions - they just don't work when trying to run.
{code}
stain@biggie:/var/tmp$ echo '#!/bin/cat' > hello
stain@biggie:/var/tmp$ chmod 755 hello
stain@biggie:/var/tmp$ ./hello
#!/bin/cat
stain@biggie:/var/tmp$ cd /tmp
stain@biggie:/tmp$ echo '#!/bin/cat' > hello
stain@biggie:/tmp$ chmod 755 hello
stain@biggie:/tmp$ ./hello
-bash: ./hello: Permission denied
stain@biggie:/tmp$ ls -al hello
-rwxr-xr-x 1 stain stain 11 May 5 10:16 hello
{code}
So I don't think Commons VFS is doing something wrong - file.isExecutable() is
still false even though setExecutable() (presumably) succeeds - but the test
could be improved to check the return values. Unless the signature for
isExecutable should read what the file permission is SET as (e.g. replicate ls
-al), rather than what the EFFECTIVE permission is (can I execute it?).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (VFS-605) [HTTP] EC AlgorithmParameters not available
Stian Soiland-Reyes created VFS-605:
---
Summary: [HTTP] EC AlgorithmParameters not available
Key: VFS-605
URL: https://issues.apache.org/jira/browse/VFS-605
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.1
Environment: IBM JDK6 or IcedTea/Open JDK 7.
Reporter: Stian Soiland-Reyes
When building Commons VFS RC1 with IBM JDK 6 and IcedTea/OpenJDK 7, Jörg
Schaible [reported an
issue|http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3Cngdtmr%24vr5%241%40ger.gmane.org%3E]
with:
{code}
java.lang.RuntimeException:
java.security.NoSuchAlgorithmException: EC AlgorithmParameters not
available".
at
org.apache.commons.vfs2.provider.http.HttpFileContentInfoFactory.create(HttpFileContentInfoFactory.java:51)
at
org.apache.commons.vfs2.provider.DefaultFileContent.getContentInfo(DefaultFileContent.java:806)
at
org.apache.commons.vfs2.provider.https.test.GetContentInfoFunctionalTest.testGoogle(GetContentInfoFunctionalTest.java:76)
..
{code}
The test tries to fetch https://www.google.com/images/logos/ps_logo2.png
This seems like a [bug in OpenJDK
distributions|https://bugzilla.redhat.com/show_bug.cgi?id=1167153] and whatever
SSL methods https://www.google.com/ requests that day.
However I don't think building should rely on www.google.com - if anything we
should rely on https://www.apache.org/ - e.g.
https://www.apache.org/licenses/LICENSE-2.0.txt which presumably won't go away
soon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (VFS-605) [HTTP] EC AlgorithmParameters not available
[
https://issues.apache.org/jira/browse/VFS-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved VFS-605.
-
Resolution: Fixed
Changed tests to use http://www.apache.org/licenses/LICENSE-2.0.txt /
https://www.apache.org/licenses/LICENSE-2.0.txt
This issue could re-surface if https://www.apache.org/ start requiring Elastic
Curve in its SSL configuration - but we can hope Java 6 is no longer relevant
by then..
> [HTTP] EC AlgorithmParameters not available
> ---
>
> Key: VFS-605
> URL: https://issues.apache.org/jira/browse/VFS-605
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: IBM JDK6 or IcedTea/Open JDK 7.
>Reporter: Stian Soiland-Reyes
>
> When building Commons VFS RC1 with IBM JDK 6 and IcedTea/OpenJDK 7, Jörg
> Schaible [reported an
> issue|http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3Cngdtmr%24vr5%241%40ger.gmane.org%3E]
> with:
> {code}
> java.lang.RuntimeException:
> java.security.NoSuchAlgorithmException: EC AlgorithmParameters not
> available".
> at
> org.apache.commons.vfs2.provider.http.HttpFileContentInfoFactory.create(HttpFileContentInfoFactory.java:51)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getContentInfo(DefaultFileContent.java:806)
> at
> org.apache.commons.vfs2.provider.https.test.GetContentInfoFunctionalTest.testGoogle(GetContentInfoFunctionalTest.java:76)
> ..
> {code}
> The test tries to fetch https://www.google.com/images/logos/ps_logo2.png
> This seems like a [bug in OpenJDK
> distributions|https://bugzilla.redhat.com/show_bug.cgi?id=1167153] and
> whatever SSL methods https://www.google.com/ requests that day.
> However I don't think building should rely on www.google.com - if anything we
> should rely on https://www.apache.org/ - e.g.
> https://www.apache.org/licenses/LICENSE-2.0.txt which presumably won't go
> away soon.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (VFS-606) Hadoop tests fail on JDK9 - tools.jar not found
Stian Soiland-Reyes created VFS-606:
---
Summary: Hadoop tests fail on JDK9 - tools.jar not found
Key: VFS-606
URL: https://issues.apache.org/jira/browse/VFS-606
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.1
Environment: JDK 9
Reporter: Stian Soiland-Reyes
As [reported by Jörg
Schaible|http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3Cngdtmr%24vr5%241%40ger.gmane.org%3E]
{quote}
{code}
> [ERROR] Failed to execute goal on project commons-vfs2: Could not resolve
> dependencies for project org.apache.commons:commons-vfs2:jar:2.1: Could not
> find artifact jdk.tools:jdk.tools:jar:1.6 at specified path /opt/oracle-jdk-
> bin-1.9.0.0_beta116/../lib/tools.jar -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :commons-vfs2
{code}
>
> The reason is an invalid (transitive) system dependency on tools.jar of
> Hadoop which is no longer present in Java 9.
{quote}
hadoop-common:test-jar pulls in:
http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.6.0/hadoop-annotations-2.6.0.pom
With two different profiles, the os.linux profile activates for me as
well, as the activation here is "Not a mac".
The newer Hadoop 2.7.1 seems to have fixed to these activations.
http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.7.1/hadoop-annotations-2.7.1.pom
(Hadoop 2.7 presumably no longer works on JDK6)
We don't need the tools.jar for our test, so while upgrading to 2.7.1 would fix
this - it would also mean we could no longer support JDK6. So I suggest adding
an on tools.jar on our hadoop test dependency.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (VFS-606) Hadoop tests fail on JDK9 - tools.jar not found
[
https://issues.apache.org/jira/browse/VFS-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved VFS-606.
-
Resolution: Fixed
Committed of tools.jar
> Hadoop tests fail on JDK9 - tools.jar not found
> ---
>
> Key: VFS-606
> URL: https://issues.apache.org/jira/browse/VFS-606
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: JDK 9
>Reporter: Stian Soiland-Reyes
>
> As [reported by Jörg
> Schaible|http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3Cngdtmr%24vr5%241%40ger.gmane.org%3E]
> {quote}
> {code}
> > [ERROR] Failed to execute goal on project commons-vfs2: Could not resolve
> > dependencies for project org.apache.commons:commons-vfs2:jar:2.1: Could not
> > find artifact jdk.tools:jdk.tools:jar:1.6 at specified path /opt/oracle-jdk-
> > bin-1.9.0.0_beta116/../lib/tools.jar -> [Help 1]
> > [ERROR]
> > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> > switch.
> > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> > [ERROR]
> > [ERROR] For more information about the errors and possible solutions, please
> > read the following articles:
> > [ERROR] [Help 1]
> > http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> > [ERROR]
> > [ERROR] After correcting the problems, you can resume the build with the
> > command
> > [ERROR] mvn -rf :commons-vfs2
> {code}
> >
> > The reason is an invalid (transitive) system dependency on tools.jar of
> > Hadoop which is no longer present in Java 9.
> {quote}
> hadoop-common:test-jar pulls in:
> http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.6.0/hadoop-annotations-2.6.0.pom
> With two different profiles, the os.linux profile activates for me as
> well, as the activation here is "Not a mac".
> The newer Hadoop 2.7.1 seems to have fixed to these activations.
> http://central.maven.org/maven2/org/apache/hadoop/hadoop-annotations/2.7.1/hadoop-annotations-2.7.1.pom
> (Hadoop 2.7 presumably no longer works on JDK6)
> We don't need the tools.jar for our test, so while upgrading to 2.7.1 would
> fix this - it would also mean we could no longer support JDK6. So I suggest
> adding an on tools.jar on our hadoop test dependency.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (VFS-611) Clarify NOTICE is not required for JcrUtils from JackRabbit
Stian Soiland-Reyes created VFS-611: --- Summary: Clarify NOTICE is not required for JcrUtils from JackRabbit Key: VFS-611 URL: https://issues.apache.org/jira/browse/VFS-611 Project: Commons VFS Issue Type: Task Affects Versions: 2.1 Reporter: Stian Soiland-Reyes Fix For: 2.1 In reviewing an RC for Apache Commons VFS 2.1 https://lists.apache.org/thread.html/Zjouqd6cpmohrj3 we wondered about a file https://github.com/apache/commons-vfs/blob/trunk/core/src/test/java/org/apache/commons/vfs2/provider/webdav/test/JcrUtils.java which we have adapted from Jackrabbit 2.4.0. Jackrabbit has a NOTICE which includes > Based on source code originally developed by > Day Software (http://www.day.com/). Looking at the git history https://github.com/apache/jackrabbit/commits/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/JcrUtils.java I think this file was earliest added in JackRabbit in 2009 by Jukka Zitting: https://github.com/apache/jackrabbit/commit/0882a5cc1ed4ce1cf9d3c6b3a592f97c5772ce25 (first released in 1.6.0 and 2.0-alpha1 ) We believe that as this file was added 3 years after graduating from the Incubator it is not covered by the "Day Software" NOTICE requirement and is just made by Apache Software Foundation - in which case no special self-attribution is needed in VFS's NOTICE file. I've asked on dev@jackrabbit just to verify: https://lists.apache.org/thread.html/Zk01ufa8icmfvo8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-611) Clarify NOTICE is not required for JcrUtils from JackRabbit
[ https://issues.apache.org/jira/browse/VFS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290674#comment-15290674 ] Stian Soiland-Reyes commented on VFS-611: - I added link to VFS-611 (this issue) to: core/src/test/java/org/apache/commons/vfs2/provider/webdav/test/JackrabbitMain.java core/src/test/java/org/apache/commons/vfs2/provider/webdav/test/JcrUtils.java > Clarify NOTICE is not required for JcrUtils from JackRabbit > --- > > Key: VFS-611 > URL: https://issues.apache.org/jira/browse/VFS-611 > Project: Commons VFS > Issue Type: Task >Affects Versions: 2.1 >Reporter: Stian Soiland-Reyes >Assignee: Stian Soiland-Reyes >Priority: Blocker > > In reviewing an RC for Apache Commons VFS 2.1 > https://lists.apache.org/thread.html/Zjouqd6cpmohrj3 > we wondered about a file > https://github.com/apache/commons-vfs/blob/trunk/core/src/test/java/org/apache/commons/vfs2/provider/webdav/test/JcrUtils.java > which we have adapted from Jackrabbit 2.4.0. > Jackrabbit has a NOTICE which includes > > Based on source code originally developed by > > Day Software (http://www.day.com/). > Looking at the git history > https://github.com/apache/jackrabbit/commits/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/JcrUtils.java > I think this file was earliest added in JackRabbit in 2009 by Jukka Zitting: > https://github.com/apache/jackrabbit/commit/0882a5cc1ed4ce1cf9d3c6b3a592f97c5772ce25 > (first released in 1.6.0 and 2.0-alpha1 ) > We believe that as this file was added 3 years after graduating from the > Incubator it is not covered by the "Day Software" NOTICE requirement and is > just made by Apache Software Foundation - in which case no special > self-attribution is needed in VFS's NOTICE file. > I've asked on dev@jackrabbit just to verify: > https://lists.apache.org/thread.html/Zk01ufa8icmfvo8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (VFS-611) Clarify NOTICE is not required for JcrUtils from JackRabbit
[ https://issues.apache.org/jira/browse/VFS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated VFS-611: Fix Version/s: 2.2 > Clarify NOTICE is not required for JcrUtils from JackRabbit > --- > > Key: VFS-611 > URL: https://issues.apache.org/jira/browse/VFS-611 > Project: Commons VFS > Issue Type: Task >Affects Versions: 2.1 >Reporter: Stian Soiland-Reyes >Assignee: Stian Soiland-Reyes >Priority: Blocker > Fix For: 2.2 > > > In reviewing an RC for Apache Commons VFS 2.1 > https://lists.apache.org/thread.html/Zjouqd6cpmohrj3 > we wondered about a file > https://github.com/apache/commons-vfs/blob/trunk/core/src/test/java/org/apache/commons/vfs2/provider/webdav/test/JcrUtils.java > which we have adapted from Jackrabbit 2.4.0. > Jackrabbit has a NOTICE which includes > > Based on source code originally developed by > > Day Software (http://www.day.com/). > Looking at the git history > https://github.com/apache/jackrabbit/commits/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/JcrUtils.java > I think this file was earliest added in JackRabbit in 2009 by Jukka Zitting: > https://github.com/apache/jackrabbit/commit/0882a5cc1ed4ce1cf9d3c6b3a592f97c5772ce25 > (first released in 1.6.0 and 2.0-alpha1 ) > We believe that as this file was added 3 years after graduating from the > Incubator it is not covered by the "Day Software" NOTICE requirement and is > just made by Apache Software Foundation - in which case no special > self-attribution is needed in VFS's NOTICE file. > I've asked on dev@jackrabbit just to verify: > https://lists.apache.org/thread.html/Zk01ufa8icmfvo8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-611) Clarify NOTICE is not required for JcrUtils from JackRabbit
[
https://issues.apache.org/jira/browse/VFS-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15292989#comment-15292989
]
Stian Soiland-Reyes commented on VFS-611:
-
We got verification from the original author on
[dev@jackrabbit|https://lists.apache.org/thread.html/Zsvdz0jsv2cv0q1]:
{quote}
Your assumption is correct.
The NOTICE entry refers to code from the original Day Software grant that
accompanied Jackrabbit's entry to the Incubator (
http://wiki.apache.org/incubator/JcrProposal).
The JcrUtils class was contributed under normal CLA and thus doesn't need
extra NOTICE entries.
Best,
Jukka Zitting
{quote}
As technically the code comment about this was added after 2.1 I've set the Fix
Version for 2.2.
> Clarify NOTICE is not required for JcrUtils from JackRabbit
> ---
>
> Key: VFS-611
> URL: https://issues.apache.org/jira/browse/VFS-611
> Project: Commons VFS
> Issue Type: Task
>Affects Versions: 2.1
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Blocker
> Fix For: 2.2
>
>
> In reviewing an RC for Apache Commons VFS 2.1
> https://lists.apache.org/thread.html/Zjouqd6cpmohrj3
> we wondered about a file
> https://github.com/apache/commons-vfs/blob/trunk/core/src/test/java/org/apache/commons/vfs2/provider/webdav/test/JcrUtils.java
> which we have adapted from Jackrabbit 2.4.0.
> Jackrabbit has a NOTICE which includes
> > Based on source code originally developed by
> > Day Software (http://www.day.com/).
> Looking at the git history
> https://github.com/apache/jackrabbit/commits/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/JcrUtils.java
> I think this file was earliest added in JackRabbit in 2009 by Jukka Zitting:
> https://github.com/apache/jackrabbit/commit/0882a5cc1ed4ce1cf9d3c6b3a592f97c5772ce25
> (first released in 1.6.0 and 2.0-alpha1 )
> We believe that as this file was added 3 years after graduating from the
> Incubator it is not covered by the "Day Software" NOTICE requirement and is
> just made by Apache Software Foundation - in which case no special
> self-attribution is needed in VFS's NOTICE file.
> I've asked on dev@jackrabbit just to verify:
> https://lists.apache.org/thread.html/Zk01ufa8icmfvo8
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (BEANUTILS-492) PropertyDescriptor ClassCastException with JDK8
Stian Soiland-Reyes created BEANUTILS-492:
-
Summary: PropertyDescriptor ClassCastException with JDK8
Key: BEANUTILS-492
URL: https://issues.apache.org/jira/browse/BEANUTILS-492
Project: Commons BeanUtils
Issue Type: Bug
Affects Versions: 1.9.3
Environment: maven:3.3-jdk8
Reporter: Stian Soiland-Reyes
Priority: Critical
Fix For: 1.9.3
With MAven 3.3 and JDK 8, Common Beanutils fails:
https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
{code}
Failed tests:
IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
IndexedPropertyDescriptor expected:
but was:
IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
java.beans.IndexedPropertyDescriptor
IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
java.beans.IndexedPropertyDescriptor
IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
IndexedPropertyDescriptor expected:
but was:
IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
java.beans.IndexedPropertyDescriptor
IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
java.beans.IndexedPropertyDescriptor
IndexedPropertyTestCase.testListReadMethod:256 Threw exception
java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
java.beans.IndexedPropertyDescriptor
IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
java.beans.IndexedPropertyDescriptor
Jira422TestCase.testRootBean:36 expected: but
was:
Jira422TestCase.testSecondChildBean:42 expected: but
was:
{code}
It seems some assumptions about java.beans.PropertyDescriptor implementation
are no longer true in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-492) PropertyDescriptor ClassCastException with JDK8
[
https://issues.apache.org/jira/browse/BEANUTILS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318215#comment-15318215
]
Stian Soiland-Reyes commented on BEANUTILS-492:
---
This is a bug with not getting back IndexedPropertyDescriptor - so the
BEANUTILS-422 Jira422TestCase for instance checks if it can retrieve an indexed
property with {{file[0]}} from {{getFile(int i)}}, but instead it simply gets
the containing {{java.util.List}} from {{getFile()}}.
The IndexedPropertyTestCase fails for the same reaason, but fails earlier
because it tests the typing.
Is this a deliberate change in Java 8, or a bug upstream? Are further property
annotations needed in Java 8 for this?
> PropertyDescriptor ClassCastException with JDK8
> ---
>
> Key: BEANUTILS-492
> URL: https://issues.apache.org/jira/browse/BEANUTILS-492
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.9.3
> Environment: maven:3.3-jdk8
>Reporter: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.9.3
>
>
> With MAven 3.3 and JDK 8, Common Beanutils fails:
> https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
> {code}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> {code}
> It seems some assumptions about java.beans.PropertyDescriptor implementation
> are no longer true in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-492) PropertyDescriptor ClassCastException with JDK8
[
https://issues.apache.org/jira/browse/BEANUTILS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329814#comment-15329814
]
Stian Soiland-Reyes commented on BEANUTILS-492:
---
The behaviour seems to ahve changed in Java 8:
[Is JRE 1.8 still JavaBean specs compliant about
IndexedPropertyDescriptor?|http://stackoverflow.com/questions/34726164/is-jre-1-8-still-javabean-specs-compliant-about-indexedpropertydescriptor]
[Java JDK 8 IndexedPropertyDescriptor has changed since JDK 7 with List
object|http://stackoverflow.com/questions/30663238/java-jdk-8-indexedpropertydescriptor-has-changed-since-jdk-7-with-list-object]
Basically I think a List bean is no longer supported with an
IndexedPropertyDescriptor - only for [] arrays.
So should we change our javadoc on supposedly supporting List and remove those
tests? Or is anyone able to write a generic BeanInfo we can use to get the
indexed properties?
> PropertyDescriptor ClassCastException with JDK8
> ---
>
> Key: BEANUTILS-492
> URL: https://issues.apache.org/jira/browse/BEANUTILS-492
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.9.3
> Environment: maven:3.3-jdk8
>Reporter: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.9.3
>
>
> With MAven 3.3 and JDK 8, Common Beanutils fails:
> https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
> {code}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> {code}
> It seems some assumptions about java.beans.PropertyDescriptor implementation
> are no longer true in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BEANUTILS-492) IndexedPropertyDescriptor not supported for List in Java 8
[
https://issues.apache.org/jira/browse/BEANUTILS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated BEANUTILS-492:
--
Summary: IndexedPropertyDescriptor not supported for List in Java 8 (was:
PropertyDescriptor ClassCastException with JDK8)
> IndexedPropertyDescriptor not supported for List in Java 8
> --
>
> Key: BEANUTILS-492
> URL: https://issues.apache.org/jira/browse/BEANUTILS-492
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.9.3
> Environment: maven:3.3-jdk8
>Reporter: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.9.3
>
>
> With MAven 3.3 and JDK 8, Common Beanutils fails:
> https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
> {code}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> {code}
> It seems some assumptions about java.beans.PropertyDescriptor implementation
> are no longer true in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-492) IndexedPropertyDescriptor not supported for List in Java 8
[
https://issues.apache.org/jira/browse/BEANUTILS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15344077#comment-15344077
]
Stian Soiland-Reyes commented on BEANUTILS-492:
---
OK; so I'll update the javadocs that indexed List's don't work in JDK8 and
later (they accidentally worked before), and perhaps add this to the changelog
as a "gotcha".
> IndexedPropertyDescriptor not supported for List in Java 8
> --
>
> Key: BEANUTILS-492
> URL: https://issues.apache.org/jira/browse/BEANUTILS-492
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.9.3
> Environment: maven:3.3-jdk8
>Reporter: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.9.3
>
>
> With MAven 3.3 and JDK 8, Common Beanutils fails:
> https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
> {code}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> {code}
> It seems some assumptions about java.beans.PropertyDescriptor implementation
> are no longer true in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-492) IndexedPropertyDescriptor not supported for List in Java 8
[
https://issues.apache.org/jira/browse/BEANUTILS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484006#comment-15484006
]
Stian Soiland-Reyes commented on BEANUTILS-492:
---
Sorry, I missed this in the holidays :(
Personally I think we should remove the failing index property tests overall,
as they test behaviour that is just incidentally supported by older JDKs, but
not required by the JavaBeans spec.
Perhaps better than another java version parsing is to add an Assume that tests
index properties directly (outside Beanutils) first? Then we can keep testing
that we don't break it for older Javas.
> IndexedPropertyDescriptor not supported for List in Java 8
> --
>
> Key: BEANUTILS-492
> URL: https://issues.apache.org/jira/browse/BEANUTILS-492
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.9.3
> Environment: maven:3.3-jdk8
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.9.3
>
>
> With MAven 3.3 and JDK 8, Common Beanutils fails:
> https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
> {code}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> {code}
> It seems some assumptions about java.beans.PropertyDescriptor implementation
> are no longer true in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-492) IndexedPropertyDescriptor not supported for List in Java 8
[
https://issues.apache.org/jira/browse/BEANUTILS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484219#comment-15484219
]
Stian Soiland-Reyes commented on BEANUTILS-492:
---
I've added documentation to getPropertyDescriptor()
What about getPropertyType()? It will return List in Java 8 rather than the
leaf-type String in Java 6 (which presumably did a heuristic guess by the first
element).
> IndexedPropertyDescriptor not supported for List in Java 8
> --
>
> Key: BEANUTILS-492
> URL: https://issues.apache.org/jira/browse/BEANUTILS-492
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.9.3
> Environment: maven:3.3-jdk8
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.9.3
>
>
> With MAven 3.3 and JDK 8, Common Beanutils fails:
> https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
> {code}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> {code}
> It seems some assumptions about java.beans.PropertyDescriptor implementation
> are no longer true in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (BEANUTILS-492) IndexedPropertyDescriptor not supported for List in Java 8
[
https://issues.apache.org/jira/browse/BEANUTILS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484229#comment-15484229
]
Stian Soiland-Reyes edited comment on BEANUTILS-492 at 9/12/16 2:12 PM:
Two tests I can't seem to fix:
{code}
public void testListIndexedWriteMethod() throws Exception {
final PropertyDescriptor descriptor =
propertyUtilsBean.getPropertyDescriptor(bean, "stringList");
assertNotNull("stringList descriptor not found", descriptor);
Assume.assumeTrue(BEANUTILS_492, descriptor instanceof
IndexedPropertyDescriptor);
assertNotNull("No List Indexed Write Method",
((IndexedPropertyDescriptor)descriptor).getIndexedWriteMethod());
}
public void testListIndexedReadMethod() throws Exception {
final PropertyDescriptor descriptor =
propertyUtilsBean.getPropertyDescriptor(bean, "stringList");
assertNotNull("stringList descriptor not found", descriptor);
Assume.assumeTrue(BEANUTILS_492, descriptor instanceof
IndexedPropertyDescriptor);
assertNotNull("No List Indexed Read Method",
((IndexedPropertyDescriptor)descriptor).getIndexedReadMethod());
}
{code}
but strangely I get:
{code}
Tests in error:
IndexedPropertyTestCase.testListIndexedReadMethod:288 » AssumptionViolated
BEA...
IndexedPropertyTestCase.testListIndexedWriteMethod:298 » AssumptionViolated
BE...
{code}
How do I get the assumption fail to just ignore the test?
(These tests also seem to do weird things like try...catch Exception ex {
fail(ex) instead of just letting junit catch the exception.)
was (Author: stain):
Two tests I can't seem to
{code}
public void testListIndexedWriteMethod() throws Exception {
final PropertyDescriptor descriptor =
propertyUtilsBean.getPropertyDescriptor(bean, "stringList");
assertNotNull("stringList descriptor not found", descriptor);
Assume.assumeTrue(BEANUTILS_492, descriptor instanceof
IndexedPropertyDescriptor);
assertNotNull("No List Indexed Write Method",
((IndexedPropertyDescriptor)descriptor).getIndexedWriteMethod());
}
{code}
but strangely I get:
{code}
Tests in error:
IndexedPropertyTestCase.testListIndexedReadMethod:288 » AssumptionViolated
BEA...
IndexedPropertyTestCase.testListIndexedWriteMethod:298 » AssumptionViolated
BE...
{code}
How do I get the assumption fail to just ignore the test?
(These tests also seem to do weird things like try...catch Exception ex {
fail(ex) instead of just letting junit catch the exception.)
> IndexedPropertyDescriptor not supported for List in Java 8
> --
>
> Key: BEANUTILS-492
> URL: https://issues.apache.org/jira/browse/BEANUTILS-492
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.9.3
> Environment: maven:3.3-jdk8
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.9.3
>
>
> With MAven 3.3 and JDK 8, Common Beanutils fails:
> https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
> {code}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase
[jira] [Commented] (BEANUTILS-492) IndexedPropertyDescriptor not supported for List in Java 8
[
https://issues.apache.org/jira/browse/BEANUTILS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484229#comment-15484229
]
Stian Soiland-Reyes commented on BEANUTILS-492:
---
Two tests I can't seem to
{code}
public void testListIndexedWriteMethod() throws Exception {
final PropertyDescriptor descriptor =
propertyUtilsBean.getPropertyDescriptor(bean, "stringList");
assertNotNull("stringList descriptor not found", descriptor);
Assume.assumeTrue(BEANUTILS_492, descriptor instanceof
IndexedPropertyDescriptor);
assertNotNull("No List Indexed Write Method",
((IndexedPropertyDescriptor)descriptor).getIndexedWriteMethod());
}
{code}
but strangely I get:
{code}
Tests in error:
IndexedPropertyTestCase.testListIndexedReadMethod:288 » AssumptionViolated
BEA...
IndexedPropertyTestCase.testListIndexedWriteMethod:298 » AssumptionViolated
BE...
{code}
How do I get the assumption fail to just ignore the test?
(These tests also seem to do weird things like try...catch Exception ex {
fail(ex) instead of just letting junit catch the exception.)
> IndexedPropertyDescriptor not supported for List in Java 8
> --
>
> Key: BEANUTILS-492
> URL: https://issues.apache.org/jira/browse/BEANUTILS-492
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.9.3
> Environment: maven:3.3-jdk8
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.9.3
>
>
> With MAven 3.3 and JDK 8, Common Beanutils fails:
> https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
> {code}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> {code}
> It seems some assumptions about java.beans.PropertyDescriptor implementation
> are no longer true in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-492) IndexedPropertyDescriptor not supported for List in Java 8
[
https://issues.apache.org/jira/browse/BEANUTILS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484272#comment-15484272
]
Stian Soiland-Reyes commented on BEANUTILS-492:
---
For reference -
http://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/
section 7.2 only describes indexed properties of arrays. So it 'accidentally'
working on List before is no longer always the case (the
IndexedPropertyDescriptor constructor checks for type mismatches between the
positional methods and the overall getter - which now must return a proper
array)
> IndexedPropertyDescriptor not supported for List in Java 8
> --
>
> Key: BEANUTILS-492
> URL: https://issues.apache.org/jira/browse/BEANUTILS-492
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.9.3
> Environment: maven:3.3-jdk8
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.9.3
>
>
> With MAven 3.3 and JDK 8, Common Beanutils fails:
> https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
> {code}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> {code}
> It seems some assumptions about java.beans.PropertyDescriptor implementation
> are no longer true in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (BEANUTILS-492) IndexedPropertyDescriptor not supported for List in Java 8
[
https://issues.apache.org/jira/browse/BEANUTILS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved BEANUTILS-492.
---
Resolution: Fixed
I've updated the tests to test for Java 7 vs Java 8 behaviour.
I've also updated JAvadoc on getPropertyType() and getPropertyDescriptor() to
also include the legacy behaviour on collections.
> IndexedPropertyDescriptor not supported for List in Java 8
> --
>
> Key: BEANUTILS-492
> URL: https://issues.apache.org/jira/browse/BEANUTILS-492
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.9.3
> Environment: maven:3.3-jdk8
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.9.3
>
>
> With MAven 3.3 and JDK 8, Common Beanutils fails:
> https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
> {code}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> {code}
> It seems some assumptions about java.beans.PropertyDescriptor implementation
> are no longer true in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-492) IndexedPropertyDescriptor not supported for List in Java 8
[
https://issues.apache.org/jira/browse/BEANUTILS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484530#comment-15484530
]
Stian Soiland-Reyes commented on BEANUTILS-492:
---
BTW: OpenJDK 9 fails
{code}
Failed tests:
PropertyUtilsTestCase.testGetDescriptorInvalidBoolean:442 invalidBoolean
getter method is isInvalidBoolean
SqlTimestampConverterTestCase.testLocale:73->DateConverterTestBase.validConversion:403
Converting 'java.lang.String' value '3/21/06 3:06 pm' threw
org.apache.commons.beanutils.ConversionException: Error converting 'String' to
'java.sql.Timestamp' using pattern 'M/d/yy, h:mm a'
{code}
.. but those are not related to this bug.
> IndexedPropertyDescriptor not supported for List in Java 8
> --
>
> Key: BEANUTILS-492
> URL: https://issues.apache.org/jira/browse/BEANUTILS-492
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.9.3
> Environment: maven:3.3-jdk8
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.9.3
>
>
> With MAven 3.3 and JDK 8, Common Beanutils fails:
> https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
> {code}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> {code}
> It seems some assumptions about java.beans.PropertyDescriptor implementation
> are no longer true in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-492) IndexedPropertyDescriptor not supported for List in Java 8
[
https://issues.apache.org/jira/browse/BEANUTILS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484527#comment-15484527
]
Stian Soiland-Reyes commented on BEANUTILS-492:
---
Tested with Docker:
{code}
docker run -v /home/stain/src/beanutils:/usr/src/app -w /usr/src/app -it
maven:3-jdk-8 mvn clean install
docker run -v /home/stain/src/beanutils:/usr/src/app -w /usr/src/app -it
maven:3-jdk-7 mvn clean install
docker run -v /home/stain/src/beanutils:/usr/src/app -w /usr/src/app -it
maven:3-jdk-6 mvn clean install # slw
{code}
and with openjdk-8 and openjdk-9 in Ubuntu 16.04.
Could anyone have a chance to have a go with an Oracle JDK 6/7/8?
> IndexedPropertyDescriptor not supported for List in Java 8
> --
>
> Key: BEANUTILS-492
> URL: https://issues.apache.org/jira/browse/BEANUTILS-492
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: 1.9.3
> Environment: maven:3.3-jdk8
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.9.3
>
>
> With MAven 3.3 and JDK 8, Common Beanutils fails:
> https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
> {code}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> {code}
> It seems some assumptions about java.beans.PropertyDescriptor implementation
> are no longer true in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (BEANUTILS-496) testGetDescriptorInvalidBoolean fails on Java 9
Stian Soiland-Reyes created BEANUTILS-496:
-
Summary: testGetDescriptorInvalidBoolean fails on Java 9
Key: BEANUTILS-496
URL: https://issues.apache.org/jira/browse/BEANUTILS-496
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.9.3
Environment: OpenJDK 9, Ubuntu 16.04
Reporter: Stian Soiland-Reyes
Assignee: Stian Soiland-Reyes
Priority: Minor
{code}
PropertyUtilsTestCase.testGetDescriptorInvalidBoolean:442 invalidBoolean getter
method is isInvalidBoolean
{code}
Seems only to fail on JAva 9?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (BEANUTILS-495) DateConverterTestBase fails on M/d/yy in Java 9
Stian Soiland-Reyes created BEANUTILS-495:
-
Summary: DateConverterTestBase fails on M/d/yy in Java 9
Key: BEANUTILS-495
URL: https://issues.apache.org/jira/browse/BEANUTILS-495
Project: Commons BeanUtils
Issue Type: Bug
Components: ConvertUtils & Converters
Affects Versions: 1.9.3
Environment: OpenJDK 9, Ubuntu 16.04
Reporter: Stian Soiland-Reyes
Assignee: Stian Soiland-Reyes
Priority: Minor
{code}
SqlTimestampConverterTestCase.testLocale:73->DateConverterTestBase.validConversion:403
Converting 'java.lang.String' value '3/21/06 3:06 pm' threw
org.apache.commons.beanutils.ConversionException: Error converting 'String' to
'java.sql.Timestamp' using pattern 'M/d/yy, h:mm a'
{code}
Only seems to happen with Open JDK 9?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BEANUTILS-492) IndexedPropertyDescriptor not supported for List in Java 8
[
https://issues.apache.org/jira/browse/BEANUTILS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated BEANUTILS-492:
--
Component/s: Bean / Property Utils
> IndexedPropertyDescriptor not supported for List in Java 8
> --
>
> Key: BEANUTILS-492
> URL: https://issues.apache.org/jira/browse/BEANUTILS-492
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.9.3
> Environment: maven:3.3-jdk8
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Critical
> Fix For: 1.9.3
>
>
> With MAven 3.3 and JDK 8, Common Beanutils fails:
> https://builds.apache.org/view/Apache%20Commons/job/Commons%20Beanutils%20docker/4/console
> {code}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> {code}
> It seems some assumptions about java.beans.PropertyDescriptor implementation
> are no longer true in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-496) testGetDescriptorInvalidBoolean fails on Java 9
[
https://issues.apache.org/jira/browse/BEANUTILS-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484562#comment-15484562
]
Stian Soiland-Reyes commented on BEANUTILS-496:
---
It's testing:
{code}
/**
* Negative tests on an invalid property with two different boolean
* getters (which is fine, according to the JavaBeans spec) but a
* String setter instead of a boolean setter.
*
* Although one could logically argue that this combination of method
* signatures should not identify a property at all, there is a sentence
* in Section 8.3.1 making it clear that the behavior tested for here
* is correct: "If we find only one of these methods, then we regard
* it as defining either a read-only or write-only property called
* .
*/
public void testGetDescriptorInvalidBoolean() throws Exception {
final PropertyDescriptor pd =
PropertyUtils.getPropertyDescriptor(bean, "invalidBoolean");
assertNotNull("invalidBoolean is a property", pd);
assertNotNull("invalidBoolean has a getter method",
pd.getReadMethod());
assertNull("invalidBoolean has no write method",
pd.getWriteMethod());
assertTrue("invalidBoolean getter method is isInvalidBoolean",
"isInvalidBoolean".equals(pd.getReadMethod().getName()));
}
{code}
with TestBean having
{code}
/**
* An invalid property that has two boolean getters (getInvalidBoolean
* and isInvalidBoolean) plus a String setter (setInvalidBoolean). By the
* rules described in the JavaBeans Specification, this will be considered
* a read-only boolean property, using isInvalidBoolean() as the getter.
*/
private boolean invalidBoolean = false;
public boolean getInvalidBoolean() {
return (this.invalidBoolean);
}
public boolean isInvalidBoolean() {
return (this.invalidBoolean);
}
public void setInvalidBoolean(final String invalidBoolean) {
if ("true".equalsIgnoreCase(invalidBoolean) ||
"yes".equalsIgnoreCase(invalidBoolean) ||
"1".equalsIgnoreCase(invalidBoolean)) {
this.invalidBoolean = true;
} else {
this.invalidBoolean = false;
}
}
{code}
This assumption seems to no longer be true in Java 9 - I don't think we can
assume that {{isInvalidBoolean}} will be preferred method, so I'll change it to:
{code}
assertTrue("invalidBoolean getter method is isInvalidBoolean or
getInvalidBoolean",
Arrays.asList("isInvalidBoolean", "getInvalidBoolean")
.contains(pd.getReadMethod().getName()));
{code}
> testGetDescriptorInvalidBoolean fails on Java 9
> ---
>
> Key: BEANUTILS-496
> URL: https://issues.apache.org/jira/browse/BEANUTILS-496
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.9.3
> Environment: OpenJDK 9, Ubuntu 16.04
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Minor
>
> {code}
> PropertyUtilsTestCase.testGetDescriptorInvalidBoolean:442 invalidBoolean
> getter method is isInvalidBoolean
> {code}
> Seems only to fail on JAva 9?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (BEANUTILS-496) testGetDescriptorInvalidBoolean fails on Java 9
[
https://issues.apache.org/jira/browse/BEANUTILS-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved BEANUTILS-496.
---
Resolution: Fixed
> testGetDescriptorInvalidBoolean fails on Java 9
> ---
>
> Key: BEANUTILS-496
> URL: https://issues.apache.org/jira/browse/BEANUTILS-496
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.9.3
> Environment: OpenJDK 9, Ubuntu 16.04
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Minor
> Fix For: 1.9.3
>
>
> {code}
> PropertyUtilsTestCase.testGetDescriptorInvalidBoolean:442 invalidBoolean
> getter method is isInvalidBoolean
> {code}
> Seems only to fail on JAva 9?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BEANUTILS-496) testGetDescriptorInvalidBoolean fails on Java 9
[
https://issues.apache.org/jira/browse/BEANUTILS-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated BEANUTILS-496:
--
Fix Version/s: 1.9.3
> testGetDescriptorInvalidBoolean fails on Java 9
> ---
>
> Key: BEANUTILS-496
> URL: https://issues.apache.org/jira/browse/BEANUTILS-496
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
>Affects Versions: 1.9.3
> Environment: OpenJDK 9, Ubuntu 16.04
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Minor
> Fix For: 1.9.3
>
>
> {code}
> PropertyUtilsTestCase.testGetDescriptorInvalidBoolean:442 invalidBoolean
> getter method is isInvalidBoolean
> {code}
> Seems only to fail on JAva 9?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-495) DateConverterTestBase fails on M/d/yy in Java 9
[
https://issues.apache.org/jira/browse/BEANUTILS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484635#comment-15484635
]
Stian Soiland-Reyes commented on BEANUTILS-495:
---
{code}
final String testString = "3/21/06 3:06 pm";
{code}
is no longer recognized by Locale.US, instead it expects a comma - e.g.
{{9/12/16, 5:57 PM}}
> DateConverterTestBase fails on M/d/yy in Java 9
> ---
>
> Key: BEANUTILS-495
> URL: https://issues.apache.org/jira/browse/BEANUTILS-495
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: ConvertUtils & Converters
>Affects Versions: 1.9.3
> Environment: OpenJDK 9, Ubuntu 16.04
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Minor
>
> {code}
>
> SqlTimestampConverterTestCase.testLocale:73->DateConverterTestBase.validConversion:403
> Converting 'java.lang.String' value '3/21/06 3:06 pm' threw
> org.apache.commons.beanutils.ConversionException: Error converting 'String'
> to 'java.sql.Timestamp' using pattern 'M/d/yy, h:mm a'
> {code}
> Only seems to happen with Open JDK 9?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BEANUTILS-495) DateConverterTestBase fails on M/d/yy in Java 9
[
https://issues.apache.org/jira/browse/BEANUTILS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated BEANUTILS-495:
--
Fix Version/s: 1.9.3
> DateConverterTestBase fails on M/d/yy in Java 9
> ---
>
> Key: BEANUTILS-495
> URL: https://issues.apache.org/jira/browse/BEANUTILS-495
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: ConvertUtils & Converters
>Affects Versions: 1.9.3
> Environment: OpenJDK 9, Ubuntu 16.04
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Minor
> Fix For: 1.9.3
>
>
> {code}
>
> SqlTimestampConverterTestCase.testLocale:73->DateConverterTestBase.validConversion:403
> Converting 'java.lang.String' value '3/21/06 3:06 pm' threw
> org.apache.commons.beanutils.ConversionException: Error converting 'String'
> to 'java.sql.Timestamp' using pattern 'M/d/yy, h:mm a'
> {code}
> Only seems to happen with Open JDK 9?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-495) DateConverterTestBase fails on M/d/yy in Java 9
[
https://issues.apache.org/jira/browse/BEANUTILS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15484703#comment-15484703
]
Stian Soiland-Reyes commented on BEANUTILS-495:
---
Reproducible with:
{code}
DateFormat f = DateFormat.getDateTimeInstance(DateFormat.SHORT,
DateFormat.SHORT, Locale.US);
f.setLenient(true);
f.parse("3/21/06 3:06 PM");
{code}
which works in Java 8, but in Java 9 fails with
{code}
java.text.ParseException: Unparseable date: "3/21/06 3:06 PM"
at java.text.DateFormat.parse(java.base@9-internal/DateFormat.java:366)
at
org.apache.commons.beanutils.converters.SqlTimestampConverterTestCase.testLocale(SqlTimestampConverterTestCase.java:79)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-internal/Native Method)
{code}
Detecting workaround in SqlTimestampConverterTestCase - but Locale.US-based
date parsing would still be sensitive to this. Perhaps this should be raised
upstream with Open JDK 9 (it might just be a bug in Ubuntu's JDK 9?) - I don't
think it should fail when 'format.setLenient(true)' is on DateFormat.
> DateConverterTestBase fails on M/d/yy in Java 9
> ---
>
> Key: BEANUTILS-495
> URL: https://issues.apache.org/jira/browse/BEANUTILS-495
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: ConvertUtils & Converters
>Affects Versions: 1.9.3
> Environment: OpenJDK 9, Ubuntu 16.04
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Minor
> Fix For: 1.9.3
>
>
> {code}
>
> SqlTimestampConverterTestCase.testLocale:73->DateConverterTestBase.validConversion:403
> Converting 'java.lang.String' value '3/21/06 3:06 pm' threw
> org.apache.commons.beanutils.ConversionException: Error converting 'String'
> to 'java.sql.Timestamp' using pattern 'M/d/yy, h:mm a'
> {code}
> Only seems to happen with Open JDK 9?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (BEANUTILS-495) DateConverterTestBase fails on M/d/yy in Java 9
[
https://issues.apache.org/jira/browse/BEANUTILS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved BEANUTILS-495.
---
Resolution: Fixed
> DateConverterTestBase fails on M/d/yy in Java 9
> ---
>
> Key: BEANUTILS-495
> URL: https://issues.apache.org/jira/browse/BEANUTILS-495
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: ConvertUtils & Converters
>Affects Versions: 1.9.3
> Environment: OpenJDK 9, Ubuntu 16.04
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Minor
> Fix For: 1.9.3
>
>
> {code}
>
> SqlTimestampConverterTestCase.testLocale:73->DateConverterTestBase.validConversion:403
> Converting 'java.lang.String' value '3/21/06 3:06 pm' threw
> org.apache.commons.beanutils.ConversionException: Error converting 'String'
> to 'java.sql.Timestamp' using pattern 'M/d/yy, h:mm a'
> {code}
> Only seems to happen with Open JDK 9?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BEANUTILS-493) Exception when setting indexed properties: "Default conversion to ArrayList failed"
[
https://issues.apache.org/jira/browse/BEANUTILS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated BEANUTILS-493:
--
Fix Version/s: 1.9.3
> Exception when setting indexed properties: "Default conversion to ArrayList
> failed"
> ---
>
> Key: BEANUTILS-493
> URL: https://issues.apache.org/jira/browse/BEANUTILS-493
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils, DynaBean
>Affects Versions: 1.9.2, 1.9.3
> Environment: commons-beanutils-1.9.3-20160606.150953-11
> jdk1.8.0_92
>Reporter: Bernhard Seebass
>Priority: Blocker
> Labels: regression
> Fix For: 1.9.3
>
> Attachments: BeanUtilsBean.java.patch, BeanUtilsBeanTest.java
>
>
> An exception is thrown when adding indexed properties to a DynaBean. This
> worked perfectly with Version 1.8.3
> org.apache.commons.beanutils.ConversionException: Default conversion to
> ArrayList failed.
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleMissing(AbstractConverter.java:314)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleError(AbstractConverter.java:269)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.convert(AbstractConverter.java:177)
> at
> org.apache.commons.beanutils.converters.ConverterFacade.convert(ConverterFacade.java:61)
> at
> org.apache.commons.beanutils.ConvertUtilsBean.convert(ConvertUtilsBean.java:491)
> at
> org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1004)
> at BeanUtilsBeanTestApp.main(BeanUtilsBeanTestApp.java:11)
> Caused by: org.apache.commons.beanutils.ConversionException: Can't convert
> value '' to type class java.util.ArrayList
> at
> org.apache.commons.beanutils.converters.AbstractConverter.conversionException(AbstractConverter.java:474)
> at
> org.apache.commons.beanutils.converters.StringConverter.convertToType(StringConverter.java:96)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleMissing(AbstractConverter.java:312)
> ... 6 more
> Test Class:
> import org.apache.commons.beanutils.BeanUtilsBean;
> import org.apache.commons.beanutils.LazyDynaBean;
> public class BeanUtilsBeanTestApp {
>
> public static void main(String[] args) {
> try {
> LazyDynaBean lazyDynaBean = new LazyDynaBean();
> BeanUtilsBean beanUtilsBean =
> BeanUtilsBean.getInstance();
> beanUtilsBean.setProperty(lazyDynaBean, "x[0]", "x1");
> beanUtilsBean.setProperty(lazyDynaBean, "x[1]", "x2");
> System.out.println(lazyDynaBean.get("x")); // output
> using commons-beanutils 1.8.3: [x1, x2]
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-493) Exception when setting indexed properties: "Default conversion to ArrayList failed"
[
https://issues.apache.org/jira/browse/BEANUTILS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490250#comment-15490250
]
Stian Soiland-Reyes commented on BEANUTILS-493:
---
Thanks!
I've included it in the upcoming 1.9.3 RC2.
> Exception when setting indexed properties: "Default conversion to ArrayList
> failed"
> ---
>
> Key: BEANUTILS-493
> URL: https://issues.apache.org/jira/browse/BEANUTILS-493
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils, DynaBean
>Affects Versions: 1.9.2, 1.9.3
> Environment: commons-beanutils-1.9.3-20160606.150953-11
> jdk1.8.0_92
>Reporter: Bernhard Seebass
>Priority: Blocker
> Labels: regression
> Fix For: 1.9.3
>
> Attachments: BeanUtilsBean.java.patch, BeanUtilsBeanTest.java
>
>
> An exception is thrown when adding indexed properties to a DynaBean. This
> worked perfectly with Version 1.8.3
> org.apache.commons.beanutils.ConversionException: Default conversion to
> ArrayList failed.
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleMissing(AbstractConverter.java:314)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleError(AbstractConverter.java:269)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.convert(AbstractConverter.java:177)
> at
> org.apache.commons.beanutils.converters.ConverterFacade.convert(ConverterFacade.java:61)
> at
> org.apache.commons.beanutils.ConvertUtilsBean.convert(ConvertUtilsBean.java:491)
> at
> org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1004)
> at BeanUtilsBeanTestApp.main(BeanUtilsBeanTestApp.java:11)
> Caused by: org.apache.commons.beanutils.ConversionException: Can't convert
> value '' to type class java.util.ArrayList
> at
> org.apache.commons.beanutils.converters.AbstractConverter.conversionException(AbstractConverter.java:474)
> at
> org.apache.commons.beanutils.converters.StringConverter.convertToType(StringConverter.java:96)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleMissing(AbstractConverter.java:312)
> ... 6 more
> Test Class:
> import org.apache.commons.beanutils.BeanUtilsBean;
> import org.apache.commons.beanutils.LazyDynaBean;
> public class BeanUtilsBeanTestApp {
>
> public static void main(String[] args) {
> try {
> LazyDynaBean lazyDynaBean = new LazyDynaBean();
> BeanUtilsBean beanUtilsBean =
> BeanUtilsBean.getInstance();
> beanUtilsBean.setProperty(lazyDynaBean, "x[0]", "x1");
> beanUtilsBean.setProperty(lazyDynaBean, "x[1]", "x2");
> System.out.println(lazyDynaBean.get("x")); // output
> using commons-beanutils 1.8.3: [x1, x2]
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (BEANUTILS-493) Exception when setting indexed properties: "Default conversion to ArrayList failed"
[
https://issues.apache.org/jira/browse/BEANUTILS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved BEANUTILS-493.
---
Resolution: Fixed
> Exception when setting indexed properties: "Default conversion to ArrayList
> failed"
> ---
>
> Key: BEANUTILS-493
> URL: https://issues.apache.org/jira/browse/BEANUTILS-493
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils, DynaBean
>Affects Versions: 1.9.2, 1.9.3
> Environment: commons-beanutils-1.9.3-20160606.150953-11
> jdk1.8.0_92
>Reporter: Bernhard Seebass
>Priority: Blocker
> Labels: regression
> Fix For: 1.9.3
>
> Attachments: BeanUtilsBean.java.patch, BeanUtilsBeanTest.java
>
>
> An exception is thrown when adding indexed properties to a DynaBean. This
> worked perfectly with Version 1.8.3
> org.apache.commons.beanutils.ConversionException: Default conversion to
> ArrayList failed.
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleMissing(AbstractConverter.java:314)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleError(AbstractConverter.java:269)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.convert(AbstractConverter.java:177)
> at
> org.apache.commons.beanutils.converters.ConverterFacade.convert(ConverterFacade.java:61)
> at
> org.apache.commons.beanutils.ConvertUtilsBean.convert(ConvertUtilsBean.java:491)
> at
> org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1004)
> at BeanUtilsBeanTestApp.main(BeanUtilsBeanTestApp.java:11)
> Caused by: org.apache.commons.beanutils.ConversionException: Can't convert
> value '' to type class java.util.ArrayList
> at
> org.apache.commons.beanutils.converters.AbstractConverter.conversionException(AbstractConverter.java:474)
> at
> org.apache.commons.beanutils.converters.StringConverter.convertToType(StringConverter.java:96)
> at
> org.apache.commons.beanutils.converters.AbstractConverter.handleMissing(AbstractConverter.java:312)
> ... 6 more
> Test Class:
> import org.apache.commons.beanutils.BeanUtilsBean;
> import org.apache.commons.beanutils.LazyDynaBean;
> public class BeanUtilsBeanTestApp {
>
> public static void main(String[] args) {
> try {
> LazyDynaBean lazyDynaBean = new LazyDynaBean();
> BeanUtilsBean beanUtilsBean =
> BeanUtilsBean.getInstance();
> beanUtilsBean.setProperty(lazyDynaBean, "x[0]", "x1");
> beanUtilsBean.setProperty(lazyDynaBean, "x[1]", "x2");
> System.out.println(lazyDynaBean.get("x")); // output
> using commons-beanutils 1.8.3: [x1, x2]
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (BEANUTILS-491) Tests fail on Oracle and IBM Java 8
[
https://issues.apache.org/jira/browse/BEANUTILS-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes resolved BEANUTILS-491.
---
Resolution: Fixed
Assignee: Stian Soiland-Reyes
> Tests fail on Oracle and IBM Java 8
> ---
>
> Key: BEANUTILS-491
> URL: https://issues.apache.org/jira/browse/BEANUTILS-491
> Project: Commons BeanUtils
> Issue Type: Bug
>Affects Versions: Nightly Builds, 1.9.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_91\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: C:\eclipse\IBM\ibm_sdk80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Gary Gregory
>Assignee: Stian Soiland-Reyes
>
> On Oracle Java 8:
> {noformat}
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_91\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> {noformat}
> I get:
> {noformat}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedPropertyDescriptor:156 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testListIndexedReadMethod:288 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListIndexedWriteMethod:302 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListReadMethod:256 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testListWriteMethod:274 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor cannot be cast to
> java.beans.IndexedPropertyDescriptor
> Jira422TestCase.testRootBean:36 expected: but
> was:
> Jira422TestCase.testSecondChildBean:42 expected: but
> was:
> Tests run: 1281, Failures: 10, Errors: 0, Skipped: 0
> {noformat}
> All is well on Oracle Java 7:
> {noformat}
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
> {noformat}
> With IBM Java 8:
> {noformat}
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0, vendor: IBM Corporation
> Java home: C:\eclipse\IBM\ibm_sdk80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> {noformat}
> I also get failures:
> {noformat}
> Failed tests:
> IndexedPropertyTestCase.testArrayListIndexedPropertyDescriptor:175 Not
> IndexedPropertyDescriptor expected: java.beans.IndexedPropertyDescriptor> but was: java.beans.PropertyDescriptor>
> IndexedPropertyTestCase.testArrayListReadMethod:316 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor incompatible with
> java.beans.IndexedPropertyDescriptor
> IndexedPropertyTestCase.testArrayListWriteMethod:330 Threw exception
> java.lang.ClassCastException: java.beans.PropertyDescriptor incompatible with
> java.b
[jira] [Updated] (BEANUTILS-480) Improved threading performance ContextClassLoaderLocal
[ https://issues.apache.org/jira/browse/BEANUTILS-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated BEANUTILS-480: -- Fix Version/s: (was: 1.9.3) > Improved threading performance ContextClassLoaderLocal > -- > > Key: BEANUTILS-480 > URL: https://issues.apache.org/jira/browse/BEANUTILS-480 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 1.9.2 >Reporter: Saponenko Denis > Labels: patch, performance > Attachments: ContextClassLoaderLocal.java(2).patch > > > Improved > src/main/java/org/apache/commons/beanutils/ContextClassLoaderLocal.java with > concurrent collections to improve performance in a narrow places synchronized > blocks. Path attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BEANUTILS-480) Improved threading performance ContextClassLoaderLocal
[ https://issues.apache.org/jira/browse/BEANUTILS-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490273#comment-15490273 ] Stian Soiland-Reyes commented on BEANUTILS-480: --- Hi, Saponenko - have you got a chance to try again to make your patch for ContextClassLoaderLocal.java? It might be easier to do it as a GitHub pull request. > Improved threading performance ContextClassLoaderLocal > -- > > Key: BEANUTILS-480 > URL: https://issues.apache.org/jira/browse/BEANUTILS-480 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 1.9.2 >Reporter: Saponenko Denis > Labels: patch, performance > Attachments: ContextClassLoaderLocal.java(2).patch > > > Improved > src/main/java/org/apache/commons/beanutils/ContextClassLoaderLocal.java with > concurrent collections to improve performance in a narrow places synchronized > blocks. Path attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-513) Add convenience methods for reading class path resources
[
https://issues.apache.org/jira/browse/IO-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490886#comment-15490886
]
Stian Soiland-Reyes commented on IO-513:
I agree with Gary that there should be variants with the ClassLoader as an
additional parameter, (or even required parameter), use of these functions
will, unlike getResourceAsStream(), lead to errors in environments with
multiple classloaders (e.g. OSGi, or perhaps even within Tomcat), as:
IOUtils.class.getResource(name) will use the classloader of IOUtils, which
might not have access to the classloader that holds the resource you want. It's
all fine if you run on a single classpath (e.g. java -classpath
loads:of:tsuff).
And so a library using IOUtils.resourceTo* methods without providing the
ClassLoader might break by anyone trying to use it in such "enterprise"
environments.
Perhaps using the (a bit slow) Reflection.getCallerClass() is a better default
if no ClassLoader is provided and the resource can't be found? Or what do folks
think - is that too much magic?
Better javadoc might help (if devs read it) - but for sure the variant
providing the ClassLoader.
> Add convenience methods for reading class path resources
>
>
> Key: IO-513
> URL: https://issues.apache.org/jira/browse/IO-513
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
>Reporter: Behrang Saeedzadeh
>Priority: Minor
> Labels: beginner, features, github-import, newbie
>
> Add convenience methods to {{IOUtils}} for reading class path resources and
> returning them as {{String}}, {{byte[]}}, and {{URL}} respectively.
> Github PR: https://github.com/apache/commons-io/pull/17
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IO-513) Add convenience methods for reading class path resources
[
https://issues.apache.org/jira/browse/IO-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490886#comment-15490886
]
Stian Soiland-Reyes edited comment on IO-513 at 9/14/16 4:38 PM:
-
I agree with Gary that there should be variants with the ClassLoader as an
additional parameter, (or even required parameter), use of these functions
will, unlike getResourceAsStream(), lead to errors in environments with
multiple classloaders (e.g. OSGi, or perhaps even within Tomcat), as:
IOUtils.class.getResource(name) will use the classloader of IOUtils, which
might not have access to the classloader that holds the resource you want. It's
all fine if you run on a single classpath (e.g. java -classpath loads:of:stuff)
- but not in anything more complex.
And so a library using IOUtils.resourceTo* methods without providing the
ClassLoader might break by anyone trying to use it in such "enterprise"
environments.
Perhaps using the (a bit slow) Reflection.getCallerClass() is a better default
if no ClassLoader is provided and the resource can't be found? Or what do folks
think - is that too much magic?
Better javadoc might help (if devs read it) - but for sure the variant
providing the ClassLoader.
was (Author: stain):
I agree with Gary that there should be variants with the ClassLoader as an
additional parameter, (or even required parameter), use of these functions
will, unlike getResourceAsStream(), lead to errors in environments with
multiple classloaders (e.g. OSGi, or perhaps even within Tomcat), as:
IOUtils.class.getResource(name) will use the classloader of IOUtils, which
might not have access to the classloader that holds the resource you want. It's
all fine if you run on a single classpath (e.g. java -classpath
loads:of:tsuff).
And so a library using IOUtils.resourceTo* methods without providing the
ClassLoader might break by anyone trying to use it in such "enterprise"
environments.
Perhaps using the (a bit slow) Reflection.getCallerClass() is a better default
if no ClassLoader is provided and the resource can't be found? Or what do folks
think - is that too much magic?
Better javadoc might help (if devs read it) - but for sure the variant
providing the ClassLoader.
> Add convenience methods for reading class path resources
>
>
> Key: IO-513
> URL: https://issues.apache.org/jira/browse/IO-513
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
>Reporter: Behrang Saeedzadeh
>Priority: Minor
> Labels: beginner, features, github-import, newbie
>
> Add convenience methods to {{IOUtils}} for reading class path resources and
> returning them as {{String}}, {{byte[]}}, and {{URL}} respectively.
> Github PR: https://github.com/apache/commons-io/pull/17
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CODEC-208) Make some DigestUtils APIs public
[ https://issues.apache.org/jira/browse/CODEC-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated CODEC-208: -- Fix Version/s: 1.11 > Make some DigestUtils APIs public > - > > Key: CODEC-208 > URL: https://issues.apache.org/jira/browse/CODEC-208 > Project: Commons Codec > Issue Type: New Feature > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) > Maven home: E:\Java\apache-maven-3.3.9\bin\.. > Java version: 1.7.0_79, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.7.0_79\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 1.11 > > > Make some DigestUtils private APIs public > - digest(MessageDigest, ByteBuffer) > - digest(MessageDigest, InputStream) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CODEC-225) InputStream not closed
[ https://issues.apache.org/jira/browse/CODEC-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated CODEC-225: -- Fix Version/s: 1.11 > InputStream not closed > -- > > Key: CODEC-225 > URL: https://issues.apache.org/jira/browse/CODEC-225 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.10, 1.11 >Reporter: Svetlin Zarev >Assignee: Jochen Wiedmann > Fix For: 1.11 > > > After running static code analysis on common codecs we discovered that it > leaks file descriptors. The relevant locations are: > * DaitchMokotoffSoundex -> the static initializer on line 229 > * Rule -> the static initializer on line 212 and the parseRules() method on > line 438. > patch provided via github pull request. > This issue is relevant for web app deployments on OSes (like windows) that > lock the files if ther eare open streams to them, and will prevent > application undeployment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CODEC-213) Support JEP 287: SHA-3 Hash Algorithms
[ https://issues.apache.org/jira/browse/CODEC-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated CODEC-213: -- Fix Version/s: 1.11 > Support JEP 287: SHA-3 Hash Algorithms > -- > > Key: CODEC-213 > URL: https://issues.apache.org/jira/browse/CODEC-213 > Project: Commons Codec > Issue Type: New Feature > Environment: java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+115) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+115, mixed mode) >Reporter: Gary Gregory > Fix For: 1.11 > > Attachments: CODEC-SHA3.diff > > > Support JEP 287: SHA-3 Hash Algorithms: SHA3-224, SHA3-256, SHA3-384, > SHA3-512. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (BEANUTILS-497) Fix javadoc doclint errors
Stian Soiland-Reyes created BEANUTILS-497:
-
Summary: Fix javadoc doclint errors
Key: BEANUTILS-497
URL: https://issues.apache.org/jira/browse/BEANUTILS-497
Project: Commons BeanUtils
Issue Type: Task
Affects Versions: 1.9.3
Reporter: Stian Soiland-Reyes
Priority: Minor
Javadoc in Oracle JDK 8 uses -Xdoclint by default (but not in javadoc) - which
breaks {{mvn site}} there.
Try with:
{code}
mvn javadoc:javadoc -DadditionalJOption=-Xdoclint
{code}
(or if you are brave - {{-Xdoclint:all}} )
and get various errors and warnings like:
{code}
[ERROR] Exit code: 1 -
/home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:860:
error: bad use of '>'
[ERROR] * register your own String --> Object conversions for any given Java
class.
[ERROR] ^
[ERROR]
/home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:899:
warning: empty tag
[ERROR] *
[ERROR] ^
{code}
Most of these relate to wrong use of HTML, which we should fix (it affects the
html we put on our site).
I notice that beanutils has a large use of
{code}
DynaClass
{code}
where perhaps I would have expected
{code}
{@link DynaClass}
{code}
-- but if you fix those - make sure that you also get the full classname for
classes in a different package that are not {{import}}ed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (BEANUTILS-497) Fix javadoc doclint errors
[
https://issues.apache.org/jira/browse/BEANUTILS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15516462#comment-15516462
]
Stian Soiland-Reyes commented on BEANUTILS-497:
---
If we can't fix them all, we should at least make {{mvn site}} work on Oracle
JDK 8.
(Emmanuel Bourg points out that Doclint has been turned off in Linux distro's
OpenJDK - but it's active on say Windows or OS X with Oracle JDK)
MJAVADOC-387 shows that the javadoc maven plugin has not yet got its own
configuration for doclint.
So a workaround is to add to pom.xml the option -Xdoclint:none - sadly this
option causes an error in older Javas, so it would have to be activated only
for JAva 8 or more.
> Fix javadoc doclint errors
> --
>
> Key: BEANUTILS-497
> URL: https://issues.apache.org/jira/browse/BEANUTILS-497
> Project: Commons BeanUtils
> Issue Type: Task
>Affects Versions: 1.9.3
>Reporter: Stian Soiland-Reyes
>Priority: Minor
>
> Javadoc in Oracle JDK 8 uses -Xdoclint by default (but not in javadoc) -
> which breaks {{mvn site}} there.
> Try with:
> {code}
> mvn javadoc:javadoc -DadditionalJOption=-Xdoclint
> {code}
> (or if you are brave - {{-Xdoclint:all}} )
> and get various errors and warnings like:
> {code}
> [ERROR] Exit code: 1 -
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:860:
> error: bad use of '>'
> [ERROR] * register your own String --> Object conversions for any given Java
> class.
> [ERROR] ^
> [ERROR]
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:899:
> warning: empty tag
> [ERROR] *
> [ERROR] ^
> {code}
> Most of these relate to wrong use of HTML, which we should fix (it affects
> the html we put on our site).
> I notice that beanutils has a large use of
> {code}
> DynaClass
> {code}
> where perhaps I would have expected
> {code}
> {@link DynaClass}
> {code}
> -- but if you fix those - make sure that you also get the full classname for
> classes in a different package that are not {{import}}ed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BEANUTILS-497) Fix javadoc doclint errors
[
https://issues.apache.org/jira/browse/BEANUTILS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated BEANUTILS-497:
--
Fix Version/s: 1.9.3
> Fix javadoc doclint errors
> --
>
> Key: BEANUTILS-497
> URL: https://issues.apache.org/jira/browse/BEANUTILS-497
> Project: Commons BeanUtils
> Issue Type: Task
>Affects Versions: 1.9.3
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Minor
>
> Javadoc in Oracle JDK 8 uses -Xdoclint by default (but not in javadoc) -
> which breaks {{mvn site}} there.
> Try with:
> {code}
> mvn javadoc:javadoc -DadditionalJOption=-Xdoclint
> {code}
> (or if you are brave - {{-Xdoclint:all}} )
> and get various errors and warnings like:
> {code}
> [ERROR] Exit code: 1 -
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:860:
> error: bad use of '>'
> [ERROR] * register your own String --> Object conversions for any given Java
> class.
> [ERROR] ^
> [ERROR]
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:899:
> warning: empty tag
> [ERROR] *
> [ERROR] ^
> {code}
> Most of these relate to wrong use of HTML, which we should fix (it affects
> the html we put on our site).
> I notice that beanutils has a large use of
> {code}
> DynaClass
> {code}
> where perhaps I would have expected
> {code}
> {@link DynaClass}
> {code}
> -- but if you fix those - make sure that you also get the full classname for
> classes in a different package that are not {{import}}ed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (BEANUTILS-497) Fix javadoc doclint errors
[
https://issues.apache.org/jira/browse/BEANUTILS-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stian Soiland-Reyes updated BEANUTILS-497:
--
Fix Version/s: (was: 1.9.3)
> Fix javadoc doclint errors
> --
>
> Key: BEANUTILS-497
> URL: https://issues.apache.org/jira/browse/BEANUTILS-497
> Project: Commons BeanUtils
> Issue Type: Task
>Affects Versions: 1.9.3
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Minor
>
> Javadoc in Oracle JDK 8 uses -Xdoclint by default (but not in javadoc) -
> which breaks {{mvn site}} there.
> Try with:
> {code}
> mvn javadoc:javadoc -DadditionalJOption=-Xdoclint
> {code}
> (or if you are brave - {{-Xdoclint:all}} )
> and get various errors and warnings like:
> {code}
> [ERROR] Exit code: 1 -
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:860:
> error: bad use of '>'
> [ERROR] * register your own String --> Object conversions for any given Java
> class.
> [ERROR] ^
> [ERROR]
> /home/stain/src/beanutils/src/main/java/org/apache/commons/beanutils/package-info.java:899:
> warning: empty tag
> [ERROR] *
> [ERROR] ^
> {code}
> Most of these relate to wrong use of HTML, which we should fix (it affects
> the html we put on our site).
> I notice that beanutils has a large use of
> {code}
> DynaClass
> {code}
> where perhaps I would have expected
> {code}
> {@link DynaClass}
> {code}
> -- but if you fix those - make sure that you also get the full classname for
> classes in a different package that are not {{import}}ed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1265) Build failures when building with Java 9 EA
[
https://issues.apache.org/jira/browse/LANG-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15523262#comment-15523262
]
Stian Soiland-Reyes commented on LANG-1265:
---
I had similar issues in BEANUTILS-495
> Build failures when building with Java 9 EA
> ---
>
> Key: LANG-1265
> URL: https://issues.apache.org/jira/browse/LANG-1265
> Project: Commons Lang
> Issue Type: Bug
>Reporter: Benedikt Ritter
> Fix For: 3.5
>
>
> When building with Java 9 EA I get:
> {code}
> Failed tests:
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_AD:304->FastDateParserTest.testLocales:342
> Locale no failed with /////ss// era AD
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/mandag
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_BC:309->FastDateParserTest.testLocales:342
> Locale no failed with /////ss// era BC
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/lørdag
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_AD:284->FastDateParserTest.testLocales:342
> Locale no failed with //////ss// era AD
> java.text.ParseException: Unparseable date:
> AD/2003/februar/0010/0012//00/AM/mandag
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_BC:289->FastDateParserTest.testLocales:342
> Locale qu_EC failed with //////ss// era BC
> java.text.ParseException: Unparseable date: "/2003/Hatun
> puquy/0010/0012//00/a.m./Sábado"
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_AD:314->FastDateParserTest.testLocales:342
> Locale no failed with y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/ma
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_BC:319->FastDateParserTest.testLocales:342
> Locale no failed with y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/lø
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_AD:294->FastDateParserTest.testLocales:342
> Locale no failed with G/y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: e.Kr./2003/2/10/12/AM/0/0/ma
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_BC:299->FastDateParserTest.testLocales:342
> Locale qu_EC failed with G/y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: "/2003/2/10/12/a.m./0/0/Sab"
> FastDateParserTest.testLocales_LongNoEra_AD:304->testLocales:342 Locale no
> failed with /////ss// era AD
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/mandag
> FastDateParserTest.testLocales_LongNoEra_BC:309->testLocales:342 Locale no
> failed with /////ss// era BC
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/lørdag
> FastDateParserTest.testLocales_Long_AD:284->testLocales:342 Locale no
> failed with //////ss// era AD
> java.text.ParseException: Unparseable date:
> AD/2003/februar/0010/0012//00/AM/mandag
> FastDateParserTest.testLocales_Long_BC:289->testLocales:342 Locale qu_EC
> failed with //////ss// era BC
> java.text.ParseException: Unparseable date: "/2003/Hatun
> puquy/0010/0012//00/a.m./Sábado"
> FastDateParserTest.testLocales_ShortNoEra_AD:314->testLocales:342 Locale no
> failed with y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/ma
> FastDateParserTest.testLocales_ShortNoEra_BC:319->testLocales:342 Locale no
> failed with y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/lø
> FastDateParserTest.testLocales_Short_AD:294->testLocales:342 Locale no
> failed with G/y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: e.Kr./2003/2/10/12/AM/0/0/ma
> FastDateParserTest.testLocales_Short_BC:299->testLocales:342 Locale qu_EC
> failed with G/y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: "/2003/2/10/12/a.m./0/0/Sab"
> Tests in error:
> LocaleUtilsTest.testParseAllLocales:578 » IllegalArgument Invalid locale
> forma...
>
> FastDateFormat_ParserTest>FastDateParserTest.testParses:252->FastDateParserTest.validateSdfFormatFdpParseEquality:228
> » Parse
> FastDateFormat_ParserTest>FastDateParserTest.testTzParses:275 » Parse
> Unparsea...
> FastDateParserTest.testParses:252->validateSdfFormatFdpParseEquality:228 »
> Parse
> FastDateParserTest.testTzParses:275 » Parse Unparseable date: 2000/02/10
> 北美东部标...
> Tests run: 3882, Failures: 16, E
[jira] [Commented] (BEANUTILS-495) DateConverterTestBase fails on M/d/yy in Java 9
[
https://issues.apache.org/jira/browse/BEANUTILS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15523268#comment-15523268
]
Stian Soiland-Reyes commented on BEANUTILS-495:
---
Not a very clever workaround in the test.. but a workaround nevertheless:
https://github.com/apache/commons-beanutils/commit/c3d13908a2e8ca7b9832fa693ca72bc228a4e92d
> DateConverterTestBase fails on M/d/yy in Java 9
> ---
>
> Key: BEANUTILS-495
> URL: https://issues.apache.org/jira/browse/BEANUTILS-495
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: ConvertUtils & Converters
>Affects Versions: 1.9.3
> Environment: OpenJDK 9, Ubuntu 16.04
>Reporter: Stian Soiland-Reyes
>Assignee: Stian Soiland-Reyes
>Priority: Minor
> Fix For: 1.9.3
>
>
> {code}
>
> SqlTimestampConverterTestCase.testLocale:73->DateConverterTestBase.validConversion:403
> Converting 'java.lang.String' value '3/21/06 3:06 pm' threw
> org.apache.commons.beanutils.ConversionException: Error converting 'String'
> to 'java.sql.Timestamp' using pattern 'M/d/yy, h:mm a'
> {code}
> Only seems to happen with Open JDK 9?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1265) Build failures when building with Java 9 EA
[
https://issues.apache.org/jira/browse/LANG-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15532752#comment-15532752
]
Stian Soiland-Reyes commented on LANG-1265:
---
So I guess the unit tests could use System.setProperty to make them pass.. but
would this not just hide the problems that actual users of FastDateParser will
struggle with because they have not set that provider?
> Build failures when building with Java 9 EA
> ---
>
> Key: LANG-1265
> URL: https://issues.apache.org/jira/browse/LANG-1265
> Project: Commons Lang
> Issue Type: Bug
>Reporter: Benedikt Ritter
> Fix For: 3.5
>
>
> When building with Java 9 EA I get:
> {code}
> Failed tests:
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_AD:304->FastDateParserTest.testLocales:342
> Locale no failed with /////ss// era AD
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/mandag
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_BC:309->FastDateParserTest.testLocales:342
> Locale no failed with /////ss// era BC
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/lørdag
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_AD:284->FastDateParserTest.testLocales:342
> Locale no failed with //////ss// era AD
> java.text.ParseException: Unparseable date:
> AD/2003/februar/0010/0012//00/AM/mandag
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_BC:289->FastDateParserTest.testLocales:342
> Locale qu_EC failed with //////ss// era BC
> java.text.ParseException: Unparseable date: "/2003/Hatun
> puquy/0010/0012//00/a.m./Sábado"
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_AD:314->FastDateParserTest.testLocales:342
> Locale no failed with y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/ma
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_BC:319->FastDateParserTest.testLocales:342
> Locale no failed with y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/lø
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_AD:294->FastDateParserTest.testLocales:342
> Locale no failed with G/y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: e.Kr./2003/2/10/12/AM/0/0/ma
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_BC:299->FastDateParserTest.testLocales:342
> Locale qu_EC failed with G/y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: "/2003/2/10/12/a.m./0/0/Sab"
> FastDateParserTest.testLocales_LongNoEra_AD:304->testLocales:342 Locale no
> failed with /////ss// era AD
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/mandag
> FastDateParserTest.testLocales_LongNoEra_BC:309->testLocales:342 Locale no
> failed with /////ss// era BC
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/lørdag
> FastDateParserTest.testLocales_Long_AD:284->testLocales:342 Locale no
> failed with //////ss// era AD
> java.text.ParseException: Unparseable date:
> AD/2003/februar/0010/0012//00/AM/mandag
> FastDateParserTest.testLocales_Long_BC:289->testLocales:342 Locale qu_EC
> failed with //////ss// era BC
> java.text.ParseException: Unparseable date: "/2003/Hatun
> puquy/0010/0012//00/a.m./Sábado"
> FastDateParserTest.testLocales_ShortNoEra_AD:314->testLocales:342 Locale no
> failed with y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/ma
> FastDateParserTest.testLocales_ShortNoEra_BC:319->testLocales:342 Locale no
> failed with y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/lø
> FastDateParserTest.testLocales_Short_AD:294->testLocales:342 Locale no
> failed with G/y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: e.Kr./2003/2/10/12/AM/0/0/ma
> FastDateParserTest.testLocales_Short_BC:299->testLocales:342 Locale qu_EC
> failed with G/y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: "/2003/2/10/12/a.m./0/0/Sab"
> Tests in error:
> LocaleUtilsTest.testParseAllLocales:578 » IllegalArgument Invalid locale
> forma...
>
> FastDateFormat_ParserTest>FastDateParserTest.testParses:252->FastDateParserTest.validateSdfFormatFdpParseEquality:228
> » Parse
> FastDateFormat_ParserTest>FastDateParserTest.testTzParses:275 » Parse
> Unparsea...
> FastDateParserTest.testParses:
[jira] [Comment Edited] (LANG-1265) Build failures when building with Java 9 EA
[
https://issues.apache.org/jira/browse/LANG-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15530334#comment-15530334
]
Stian Soiland-Reyes edited comment on LANG-1265 at 9/29/16 1:20 PM:
Based upon [Dalibor's
email|https://lists.apache.org/thread.html/e034bf56aafeef278682b7c9cab2d47be39c61a3e9218b3375bcb3e8@%3Cdev.commons.apache.org%3E]
to the ML, the following does work running the tests in java 9:
{code}
mvn -Djava.locale.providers=JRE clean test
{code}
was (Author: chtompki):
Based upon Dalibor's email to the ML, the following does work running the tests
in java 9:
{code}
mvn -Djava.locale.providers=JRE clean test
{code}
> Build failures when building with Java 9 EA
> ---
>
> Key: LANG-1265
> URL: https://issues.apache.org/jira/browse/LANG-1265
> Project: Commons Lang
> Issue Type: Bug
>Reporter: Benedikt Ritter
> Fix For: 3.5
>
>
> When building with Java 9 EA I get:
> {code}
> Failed tests:
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_AD:304->FastDateParserTest.testLocales:342
> Locale no failed with /////ss// era AD
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/mandag
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_LongNoEra_BC:309->FastDateParserTest.testLocales:342
> Locale no failed with /////ss// era BC
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/lørdag
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_AD:284->FastDateParserTest.testLocales:342
> Locale no failed with //////ss// era AD
> java.text.ParseException: Unparseable date:
> AD/2003/februar/0010/0012//00/AM/mandag
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Long_BC:289->FastDateParserTest.testLocales:342
> Locale qu_EC failed with //////ss// era BC
> java.text.ParseException: Unparseable date: "/2003/Hatun
> puquy/0010/0012//00/a.m./Sábado"
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_AD:314->FastDateParserTest.testLocales:342
> Locale no failed with y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/ma
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_ShortNoEra_BC:319->FastDateParserTest.testLocales:342
> Locale no failed with y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/lø
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_AD:294->FastDateParserTest.testLocales:342
> Locale no failed with G/y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: e.Kr./2003/2/10/12/AM/0/0/ma
>
> FastDateFormat_ParserTest>FastDateParserTest.testLocales_Short_BC:299->FastDateParserTest.testLocales:342
> Locale qu_EC failed with G/y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: "/2003/2/10/12/a.m./0/0/Sab"
> FastDateParserTest.testLocales_LongNoEra_AD:304->testLocales:342 Locale no
> failed with /////ss// era AD
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/mandag
> FastDateParserTest.testLocales_LongNoEra_BC:309->testLocales:342 Locale no
> failed with /////ss// era BC
> java.text.ParseException: Unparseable date:
> 2003/februar/0010/0012//00/AM/lørdag
> FastDateParserTest.testLocales_Long_AD:284->testLocales:342 Locale no
> failed with //////ss// era AD
> java.text.ParseException: Unparseable date:
> AD/2003/februar/0010/0012//00/AM/mandag
> FastDateParserTest.testLocales_Long_BC:289->testLocales:342 Locale qu_EC
> failed with //////ss// era BC
> java.text.ParseException: Unparseable date: "/2003/Hatun
> puquy/0010/0012//00/a.m./Sábado"
> FastDateParserTest.testLocales_ShortNoEra_AD:314->testLocales:342 Locale no
> failed with y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/ma
> FastDateParserTest.testLocales_ShortNoEra_BC:319->testLocales:342 Locale no
> failed with y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: 2003/2/10/12/AM/0/0/lø
> FastDateParserTest.testLocales_Short_AD:294->testLocales:342 Locale no
> failed with G/y/M/d/h/a/m/s/E era AD
> java.text.ParseException: Unparseable date: e.Kr./2003/2/10/12/AM/0/0/ma
> FastDateParserTest.testLocales_Short_BC:299->testLocales:342 Locale qu_EC
> failed with G/y/M/d/h/a/m/s/E era BC
> java.text.ParseException: Unparseable date: "/2003/2/10/12/a.m./0/0/Sab"
> Tests in error:
> LocaleUtilsTest.testParseAllLocales:578 » IllegalArgument In
[jira] [Resolved] (COMMONSRDF-52) Duplicate Bundle-SymbolicName values across all components
[ https://issues.apache.org/jira/browse/COMMONSRDF-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes resolved COMMONSRDF-52. --- Resolution: Fixed Assignee: Stian Soiland-Reyes Merged https://github.com/apache/commons-rdf/pull/28 from Aaron Coburn. > Duplicate Bundle-SymbolicName values across all components > -- > > Key: COMMONSRDF-52 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-52 > Project: Apache Commons RDF > Issue Type: Bug > Components: api, jena, jsonld-java, rdf4j, simple >Affects Versions: 0.3.0 > Environment: OSGi provisioning >Reporter: Aaron Coburn >Assignee: Stian Soiland-Reyes > Fix For: 1.0.0 > > > In the 0.3.0-incubating release, all of the commons-rdf bundles have the same > Symbolic-BundleName, namely: org.apache.commons.rdf. This makes it impossible > to install multiple bundles in an OSGi container (e.g. Karaf), as every > bundle must have a distinct Symbolic-BundleName/Version combination. > The commons-parent pom configuration provides a mechanism for setting the > value of Symbolic-BundleName in the bundle manifest by overriding the > property value for commons.osgi.symbolicName. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case
[ https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stian Soiland-Reyes updated COMMONSRDF-51: -- Description: The [RDF-1.1 specification states that the [value space of Literal language tags is lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which does not conflict with the case-insensitive specification in BCP47. The Literal.equals and Literal.hashCode API contracts should specify that language tags must be compared using lowercase, even if they are otherwise stored and returned as upper-case by getLanguageTag. The API currently has incorrect language by saying "character-by-character" for language tag comparisons, as that implies case-sensitive comparisons are used. The lowercasing must also be done using a locale that is consistent (known example where lowercase and uppercase do not roundtrip as expected for US-ASCII characters is Turkish [1]), so I would recommend actually stating that .toLowerCase(Locale.ENGLISH) is used. was: The RDF-1.1 specification states that the value space of Literal language tags is lowercase, which does not conflict with the case-insensitive specification in BCP47. The Literal.equals and Literal.hashCode API contracts should specify that language tags must be compared using lowercase, even if they are otherwise stored and returned as upper-case by getLanguageTag. The API currently has incorrect language by saying "character-by-character" for language tag comparisons, as that implies case-sensitive comparisons are used. The lowercasing must also be done using a locale that is consistent (known example where lowercase and uppercase do not roundtrip as expected for US-ASCII characters is Turkish [1]), so I would recommend actually stating that .toLowerCase(Locale.ENGLISH) is used. > RDF-1.1 specifies that language tags need to be compared using lower-case > - > > Key: COMMONSRDF-51 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-51 > Project: Apache Commons RDF > Issue Type: Bug > Components: api >Affects Versions: 0.3.0 >Reporter: Peter Ansell > > The [RDF-1.1 specification states that the [value space of Literal language > tags is > lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which > does not conflict with the case-insensitive specification in BCP47. The > Literal.equals and Literal.hashCode API contracts should specify that > language tags must be compared using lowercase, even if they are otherwise > stored and returned as upper-case by getLanguageTag. The API currently has > incorrect language by saying "character-by-character" for language tag > comparisons, as that implies case-sensitive comparisons are used. > The lowercasing must also be done using a locale that is consistent (known > example where lowercase and uppercase do not roundtrip as expected for > US-ASCII characters is Turkish [1]), so I would recommend actually stating > that .toLowerCase(Locale.ENGLISH) is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case
[
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15818566#comment-15818566
]
Stian Soiland-Reyes commented on COMMONSRDF-51:
---
I think this needs to be clarified on public-rdf-comme...@w3.org as our
"character by character" is a [quote from the
spec|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal]:
{quote}
Literal term equality: Two literals are term-equal (the same RDF literal) if
and only if the two lexical forms, the two datatype IRIs, and the two language
tags (if any) compare equal, character by character. Thus, two literals can
have the same value without being the same RDF term. For example:
"1"^^xs:integer
"01"^^xs:integer
denote the same value, but are not the same literal RDF terms and are not
term-equal because their lexical form differs.
{quote}
It also says above the value space is always in lower case, but then says
equality is done "character by character" and not by value space. (As that
example shows, the lexical value of data types like integers are also compared
by character instead of by value space)
I have nevertheless started a branch
[COMMONSRDF-51-langtag-lcase|https://github.com/apache/commons-rdf/compare/COMMONSRDF-51-langtag-lcase]
to try this out.. this revealed bugs in the bindings for simple (just the
Turkish case), jsonld-java (which does no validation of language tags), rdf4j
(fails Turkish test) and jena (fails Turkish test).
As both RDF4J and Jena are vulnerable to the Turkish case, that should be
reported upstream after rdf-comments clarifications.
Would it make sense for Commons RDF to strengthen getLanguageTag() to ALWAYS
return the language tag in lower case for any RDF implementations (e.g.
normalize if implementation does not do it correctly internally) - as a kind of
interoperability/RDF 1.1 measure - or should we strive to keep their current
case representation as-is?
> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
> Issue Type: Bug
> Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language
> tags is
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which
> does not conflict with the case-insensitive specification in BCP47. The
> Literal.equals and Literal.hashCode API contracts should specify that
> language tags must be compared using lowercase, even if they are otherwise
> stored and returned as upper-case by getLanguageTag. The API currently has
> incorrect language by saying "character-by-character" for language tag
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known
> example where lowercase and uppercase do not roundtrip as expected for
> US-ASCII characters is Turkish [1]), so I would recommend actually stating
> that .toLowerCase(Locale.ENGLISH) is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case
[ https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15818570#comment-15818570 ] Stian Soiland-Reyes commented on COMMONSRDF-51: --- TODO: Stian to report to public-rdf-comments@w3 > RDF-1.1 specifies that language tags need to be compared using lower-case > - > > Key: COMMONSRDF-51 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-51 > Project: Apache Commons RDF > Issue Type: Bug > Components: api >Affects Versions: 0.3.0 >Reporter: Peter Ansell >Assignee: Stian Soiland-Reyes > > The [RDF-1.1 specification states that the [value space of Literal language > tags is > lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which > does not conflict with the case-insensitive specification in BCP47. The > Literal.equals and Literal.hashCode API contracts should specify that > language tags must be compared using lowercase, even if they are otherwise > stored and returned as upper-case by getLanguageTag. The API currently has > incorrect language by saying "character-by-character" for language tag > comparisons, as that implies case-sensitive comparisons are used. > The lowercasing must also be done using a locale that is consistent (known > example where lowercase and uppercase do not roundtrip as expected for > US-ASCII characters is Turkish [1]), so I would recommend actually stating > that .toLowerCase(Locale.ENGLISH) is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case
[
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15818566#comment-15818566
]
Stian Soiland-Reyes edited comment on COMMONSRDF-51 at 1/11/17 4:24 PM:
I think this needs to be clarified on public-rdf-comme...@w3.org as our
"character by character" is a [quote from the
spec|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal]:
{quote}
Literal term equality: Two literals are term-equal (the same RDF literal) if
and only if the two lexical forms, the two datatype IRIs, and the two language
tags (if any) compare equal, character by character. Thus, two literals can
have the same value without being the same RDF term. For example:
"1"^^xs:integer
"01"^^xs:integer
denote the same value, but are not the same literal RDF terms and are not
term-equal because their lexical form differs.
{quote}
It also says above the value space is always in lower case, but then says
equality is done "character by character" -- not by value space. (As that
example shows, the lexical value of data types like integers are also compared
by character instead of by value space)
I have nevertheless started a branch
[COMMONSRDF-51-langtag-lcase|https://github.com/apache/commons-rdf/compare/COMMONSRDF-51-langtag-lcase]
to try this out.. this revealed bugs in the bindings for simple (just the
Turkish case), jsonld-java (which does no validation of language tags), rdf4j
(fails Turkish test) and jena (fails Turkish test).
As both RDF4J and Jena are vulnerable to the Turkish case, that should be
reported upstream after rdf-comments clarifications.
Would it make sense for Commons RDF to strengthen getLanguageTag() to ALWAYS
return the language tag in lower case for any RDF implementations (e.g.
normalize if implementation does not do it correctly internally) - as a kind of
interoperability/RDF 1.1 measure - or should we strive to keep their current
case representation as-is?
was (Author: stain):
I think this needs to be clarified on public-rdf-comme...@w3.org as our
"character by character" is a [quote from the
spec|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal]:
{quote}
Literal term equality: Two literals are term-equal (the same RDF literal) if
and only if the two lexical forms, the two datatype IRIs, and the two language
tags (if any) compare equal, character by character. Thus, two literals can
have the same value without being the same RDF term. For example:
"1"^^xs:integer
"01"^^xs:integer
denote the same value, but are not the same literal RDF terms and are not
term-equal because their lexical form differs.
{quote}
It also says above the value space is always in lower case, but then says
equality is done "character by character" and not by value space. (As that
example shows, the lexical value of data types like integers are also compared
by character instead of by value space)
I have nevertheless started a branch
[COMMONSRDF-51-langtag-lcase|https://github.com/apache/commons-rdf/compare/COMMONSRDF-51-langtag-lcase]
to try this out.. this revealed bugs in the bindings for simple (just the
Turkish case), jsonld-java (which does no validation of language tags), rdf4j
(fails Turkish test) and jena (fails Turkish test).
As both RDF4J and Jena are vulnerable to the Turkish case, that should be
reported upstream after rdf-comments clarifications.
Would it make sense for Commons RDF to strengthen getLanguageTag() to ALWAYS
return the language tag in lower case for any RDF implementations (e.g.
normalize if implementation does not do it correctly internally) - as a kind of
interoperability/RDF 1.1 measure - or should we strive to keep their current
case representation as-is?
> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
> Issue Type: Bug
> Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language
> tags is
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which
> does not conflict with the case-insensitive specification in BCP47. The
> Literal.equals and Literal.hashCode API contracts should specify that
> language tags must be compared using lowercase, even if they are otherwise
> stored and returned as upper-case by getLanguageTag. The API currently has
> incorrect language by saying "character-by-character" for language tag
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must
[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case
[ https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15820811#comment-15820811 ] Stian Soiland-Reyes commented on COMMONSRDF-51: --- Yes, so both a-z and A-Z are permitted and valid in Turtle etc. However the spec also says (and here is the ambiguity against "character by character"): > Lexical representations of language tags may be converted to lower case. and : > The value space of language tags is always in lower case. then doing a case-sensitive comparison sounds fragile, e.g. impl1 may do lowercase (e.g. Jena) and impl2 leave them as-is (e.g. JSON-LD) - and then that would break calls like graph.contains(). So even if my [public-rdf-comments question|http://lists.w3.org/Archives/Public/public-rdf-comments/2017Jan/thread.html] concludes with case sensitivity, we would probably want to make Commons RDF do its best for lowercase comparisons anyway for consistent interoperability. In that case perhaps we should add tests also to the graph and datasets to ensure any "call-through" don't break literal equivalence. > RDF-1.1 specifies that language tags need to be compared using lower-case > - > > Key: COMMONSRDF-51 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-51 > Project: Apache Commons RDF > Issue Type: Bug > Components: api >Affects Versions: 0.3.0 >Reporter: Peter Ansell >Assignee: Stian Soiland-Reyes > > The [RDF-1.1 specification states that the [value space of Literal language > tags is > lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which > does not conflict with the case-insensitive specification in BCP47. The > Literal.equals and Literal.hashCode API contracts should specify that > language tags must be compared using lowercase, even if they are otherwise > stored and returned as upper-case by getLanguageTag. The API currently has > incorrect language by saying "character-by-character" for language tag > comparisons, as that implies case-sensitive comparisons are used. > The lowercasing must also be done using a locale that is consistent (known > example where lowercase and uppercase do not roundtrip as expected for > US-ASCII characters is Turkish [1]), so I would recommend actually stating > that .toLowerCase(Locale.ENGLISH) is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case
[
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15820814#comment-15820814
]
Stian Soiland-Reyes commented on COMMONSRDF-51:
---
Got one reply already on
[public-rdf-comments|http://lists.w3.org/Archives/Public/public-rdf-comments/2017Jan/thread.html],
from [Richard
Cyganiak|http://lists.w3.org/Archives/Public/public-rdf-comments/2017Jan/0005.html]:
{quote}
RDF 2004 forced the language tag to be lower-cased in the abstract syntax.
Implementations of RDF 2004 often did not do that, but retained the case when
storing or transforming RDF, while still treating @en and @EN as equal. My
recollection is that we wanted to change the language of the spec to make this
behaviour legal. Unfortunately it seems the language came out less clear than
it should be. I do not think that there was any intention to make @en and @EN
not equal.
{quote}
> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
> Issue Type: Bug
> Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language
> tags is
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which
> does not conflict with the case-insensitive specification in BCP47. The
> Literal.equals and Literal.hashCode API contracts should specify that
> language tags must be compared using lowercase, even if they are otherwise
> stored and returned as upper-case by getLanguageTag. The API currently has
> incorrect language by saying "character-by-character" for language tag
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known
> example where lowercase and uppercase do not roundtrip as expected for
> US-ASCII characters is Turkish [1]), so I would recommend actually stating
> that .toLowerCase(Locale.ENGLISH) is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case
[
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15820820#comment-15820820
]
Stian Soiland-Reyes commented on COMMONSRDF-51:
---
[BCP47 section 2.1.1|https://tools.ietf.org/html/bcp47#section-2.1.1] also
clearly states case has no meaning, just convention. Therefore we should
probably try to preserve the casing, but not use it for comparison:
{quote}
At all times, language tags and their subtags, including private use
and extensions, are to be treated as case insensitive: there exist
conventions for the capitalization of some of the subtags, but these
MUST NOT be taken to carry meaning.
Thus, the tag "mn-Cyrl-MN" is not distinct from "MN-cYRL-mn" or "mN-
cYrL-Mn" (or any other combination), and each of these variations
conveys the same meaning: Mongolian written in the Cyrillic script as
used in Mongolia.
The ABNF syntax also does not distinguish between upper- and
lowercase: the uppercase US-ASCII letters in the range 'A' through
'Z' are always considered equivalent and mapped directly to their US-
ASCII lowercase equivalents in the range 'a' through 'z'. So the tag
"I-AMI" is considered equivalent to that value "i-ami" in the
'irregular' production.
{quote}
I'll push the branch as a pull request and make bugs for the Turkish issue
upstream.
> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
> Issue Type: Bug
> Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language
> tags is
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which
> does not conflict with the case-insensitive specification in BCP47. The
> Literal.equals and Literal.hashCode API contracts should specify that
> language tags must be compared using lowercase, even if they are otherwise
> stored and returned as upper-case by getLanguageTag. The API currently has
> incorrect language by saying "character-by-character" for language tag
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known
> example where lowercase and uppercase do not roundtrip as expected for
> US-ASCII characters is Turkish [1]), so I would recommend actually stating
> that .toLowerCase(Locale.ENGLISH) is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
