[
https://issues.apache.org/jira/browse/JENA-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne resolved JENA-1917.
---------------------------------
Resolution: Done
> Prepare FileManager for removal from public API.
> ------------------------------------------------
>
> Key: JENA-1917
> URL: https://issues.apache.org/jira/browse/JENA-1917
> Project: Apache Jena
> Issue Type: Improvement
> Components: Core
> Affects Versions: Jena 3.15.0
> Reporter: Andy Seaborne
> Assignee: Andy Seaborne
> Priority: Major
> Fix For: Jena 3.16.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> This is preparation work for a clearup of FileManager.
> Applications should not be using (jena-core) FileManager directly - there is
> equivalent functionality for remapping in RIOT and the read caching is
> separated out in RIOT.
> Long term, FileManager can be removed from general use. It is used by the
> OntDocumentManager so making solely for that purpose, maybe moving it to the
> "ont" sub-system.
> The first step is to mark access via \{{FileManager.get()}} as deprecated to
> signal future change. Also, mark the operations "readModel", "loadModel" that
> are better done with {{RDFDataMgr}} anyway.
> Within Jena, clean up and switch to an access function that has the name
> "Internal" in it : \{{FileManager.getInternal()}}
> There are assemblers for FileManager and (jena-core) LocationMapper. We don't
> have an easy way to signal deprecation. They are used for OntDocumentManager.
> In the documentation:
> * documentation/notes/file-manager.html
> * assembler: only mention in the documentation for OntDocumentManager
> assembly.
> and a few mentions in usage examples elsewhere.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
