[
https://issues.apache.org/jira/browse/DAFFODIL-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18009602#comment-18009602
]
Steve Lawrence commented on DAFFODIL-2994:
------------------------------------------
> Layer would be super hard to pull out into its own jar, so I suggest we
> should merge UDF into runtime1 so runtime1 jar (or renamed to core jar) has
> everything in it.
We don't necessarily need to pull all of Layer logic into a separate jar. We
would just pull the layer API into a separate jar. Things building a custom
layer would depend on that jar. As would daffodil-core. But maybe there are
some references to layer runtime stuff in the layer API that would make that
difficult?
The main benefit of a separate layer or udf jar is projects can depend on just
that jar, so things are a bit more simple and it's a bit more clear what part
of daffodil a project is using. But i'm not sure that's worth the effort unless
it's trivial. And maybe it is nice that regardless if you are builbind a custom
layer or charset or udf, you still depend on the same jar. So it's a bit more
simple in that regard.
> Should we also pull the schematron library into core like the other built-in
> validators?
I would suggest we keep schematron separate unless there is a compelling reason
to combine it into core. My main thinking is that daffodil-schematron has s
dependency to Saxon-HE, which we don't really need to require unless people are
using the schematron capabilities. If we combine it into core, then anyone
using Daffodil will now pull in Saxon-HE regardless if they need it or not. We
don't have the same dependency issue with UDF/layers.
Note that similarly, it might be nice to split out our different infoset
inputters/outputters in the separate jars. For example, the
JDOMInfosetInputter/Outputter is part of daffodil-core and requires JDOM. If
you aren't using those infosets then it's comlpetely unnecessary to pull in
JDOM dependencies for an infoset you aren't using. But splitting those out
requires a lot more thought and consideration than schematron, especially since
we not longer have runtime1 distinction, and we probably need that before we
have infoset distictions, which are specific to runtime1.
> Merge daffodil-udf into core
> ----------------------------
>
> Key: DAFFODIL-2994
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2994
> Project: Daffodil
> Issue Type: Improvement
> Components: Back End
> Affects Versions: 3.10.0
> Reporter: Olabusayo Kilo
> Priority: Major
>
> There might be value in creating a daffodil-charset and daffodil-layer
> directory/jar that contains the interfaces for building custom layers and
> charsets, similar to what we have with daffodil-udf? Or maybe we have a
> daffodil-plugins that contains all the udf, layer, and charset interfaces? Or
> do we want to- merging daffodil-udf into daffodil-core so no matter what
> you're doing, you just depend on daffodil-core? it seems a inconsistent to
> have udf be it's own jar and other plugins be part of daffodil-core.
> Note the charset api is not super java friendly at the moment DAFFODIL-2894
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
