You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@daffodil.apache.org by "Steve Lawrence (Jira)" <ji...@apache.org> on 2024/08/28 11:40:00 UTC

[jira] [Resolved] (DAFFODIL-2919) Need compile API that allows better control over diagnostic path

     [ 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)