[
https://issues.apache.org/jira/browse/ANY23-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272893#comment-13272893
]
Peter Ansell commented on ANY23-83:
-----------------------------------
My personal preference ( as you may have noticed at ANY23-19 ) is to stay with
the OpenRDF API, even if you don't use the Sesame implementation of it. All of
the elements of the OpenRDF API are specified as interfaces and there are no
hidden static singletons in the background that you can't reimplement another
way when you need to. In addition, you can pull in the API using Maven without
having to use the implementations which I view as a large point in its favour.
I made quite a few changes yesterday to basically suit my use cases. These
including fixing the cause for this issue by switching to RDFFormat as the
central point of reference for the utils classes. I pushed the changes to
GitHub at https://github.com/ansell/any23 . I am not sure how many of the
changes you will want to pick up but you may find something interesting. The
most visible change is that I split the core module up into a large number of
smaller modules. You probably won't want to do that just yet, but I found that
I could work with it and visualise it more easily if everything wasn't in a
single core module. It may seem a little convoluted, particularly having the
test resources in their own module, separate from the core unit tests, but it
makes it simpler to use the test resources in maven to unit test the other
modules, without having to either split up the test resource bundle or
replicate some resources in other modules.
The other very visible change is that I deleted the Any23 NQuads library in
favour of importing the MIT licensed Sesametools NQuads library (
https://github.com/joshsh/sesametools ). It contains both a NQuadsParserFactory
and an NQuadsWriterFactory that make it work with the static Rio methods that
are all based on Service Provider Interface (ie, META-INF/services), including
Rio.createParser() and Rio.createWriter(). This meant that the use of RDFFormat
was no longer a breaking point, as it was when I first tried to switch and I
was wondering why Rio.getParserFormatForFileName() was not working for NQuads.
It turned out to be due to the missing ParserFactory in the Any23 NQuads
implementation. In either case it doesn't really matter for long as there are
plans inside Aduna to pick parts from one or both of the Any23 or Sesametools
NQuads libraries (or the other two open source OpenRDF NQuads implementations)
and implement them internally in a new sesame-rio-nquads package.
> Remove hardcoded formats throughout Any23 to make it useful as a library
> ------------------------------------------------------------------------
>
> Key: ANY23-83
> URL: https://issues.apache.org/jira/browse/ANY23-83
> Project: Apache Any23
> Issue Type: Improvement
> Components: core
> Affects Versions: 0.7.0
> Reporter: Peter Ansell
>
> Many classes inside of Any23 seem to hardcode restrictions on the supported
> formats, making it difficult to utilise Any23 as an extensible library.
> One example of this are RDFSchemaUtils that artificially restricts itself to
> three formats using an enum mapping, where it could easily accept any
> RDFHandler, even if it were not an RDFWriter.
> Another example is RDFUtils where the list of RDFParser's is hardcoded in,
> and enforced using an enum.
> What was the reasoning for creating artificial format classes and manually
> mapping them to writers/parsers instead of using either allowing any
> RDFHandler in the first case, or allowing any accessible RDFParser in the
> second case, using Rio.getParser() to avoid hardcoding anything.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
