[
https://issues.apache.org/jira/browse/DAFFODIL-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Thompson closed DAFFODIL-2919.
-----------------------------------
Verified the specified commit (commit dd5d908aa7dbd7fd08a7c89ceb2f42b414bcd7e7)
is included in the latest pull from the daffodil repository.
Verified, via review, changes identified in the commit comment were
implemented.
Verified the affected daffodil subproject sbt test suites executed
successfully, including the new tests.
> 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)
