[
https://issues.apache.org/jira/browse/DAFFODIL-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Lawrence resolved DAFFODIL-2919.
--------------------------------------
Fix Version/s: 3.9.0
Resolution: Fixed
Fixed in commit dd5d908aa7dbd7fd08a7c89ceb2f42b414bcd7e7
> Need compile API that allows better control over diagnostic path
> ----------------------------------------------------------------
>
> Key: DAFFODIL-2919
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2919
> Project: Daffodil
> Issue Type: Bug
> Components: API, Diagnostics
> Affects Versions: 3.8.0
> Reporter: Steve Lawrence
> Priority: Major
> Fix For: 3.9.0
>
>
> The SBT Daffodil Plugin uses the compileSource function to create a saved
> parser, and passes in an absolute URI to the main schema. When this URI is to
> a file, Daffodil can't make a good guess at which directories are important
> for diagnostics, so we use the full URI as the diagnostic path, which leads
> non-depersonalized diagnostics. We could come up with heurstics to guess at
> which directories can be removed, but that is fragile and potentially
> complicated.
> What might be useful is a new API function called "compileResource", which
> takes a resource path instead of a URI or File like compileSource/compileFile
> do. This function will search for the resource path on the classpath and use
> the resource path as the diagnostic for the URI, which should be
> depersonalized. For example, maybe something like this:
> {code:scala}
> def compileResource(
> resource: String,
> optRootName: Option[String] = None,
> optRootNamespace: Option[String] = None
> ): ProcessorFactory = {
> val uri = Misc.getRequireResource(resource)
> val source = URISchemaSource(new File(resource), uri)
> val pf = sCompiler.compileSource(source, optRootName, optRootNamespace)
> new ProcessorFactory(pf.asInstanceOf[SProcessorFactory])
> }
> {code}
> Note that one alternative is to set "exportJars := true" in a schema projects
> build.sbt file. When this is set, the schema will be found in a jar instead
> of a directory, and our depersonalization logic works well with jar URIs--it
> is file URIs where we cannot do much.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
