So when I use daffodil by way of sbt, all the managed dependencies of the zip-layer-transformer (really just on apache commons compress) are taken care of for me.
My main schema just declares a managed dependency on a specific version of the zip-layer-transformer, and voila, the transitive dependency on the apache commons compress takes care of itself. When I use the CLI, I have to do this stuff manually. It's amazingly hard to get DAFFODIL_CLASSPATH complete and correct. 'sbt show dependencyClasspath' shows me the dependency on apache commons compress library, of course it also has all the daffodil jars and all their dependencies. How do we make the CLI or any environment for running Daffodil, as easy as sbt? On Tue, Jan 10, 2023 at 3:36 PM Steve Lawrence <slawre...@apache.org> wrote: > I think so. Daffodil can't know what libraries a layer transformer might > need, so we can't depend on them or include them in releases. > > So if a transformer plugin requires one or more libraries that don't > already ship with Daffodil, then they should be marked as a dependency > of the transformer and their jars downloaded and included in the > classpath along with the transformer. > > You could maybe get around his by making your transformer a fat jar, but > it might include all the Daffodil jars as well, which might cause some > problems. > > > On 2023-01-10 03:24 PM, Mike Beckerle wrote: > > So I wrote a layer transformer that unzips zip files in data. > > > > It depends on apache commons compress library. > > > > Daffodil recognizes that a schema requires this, and dynamically loads > it. > > > > But then things fail because apache commons compress library is not > found. > > > > We have to manually add apache commons compress jar to the daffodil > > classpath. > > > > Is this expected behavior? > > > > Mike Beckerle > > Apache Daffodil PMC | daffodil.apache.org > > OGF DFDL Workgroup Co-Chair | > www.ogf.org/ogf/doku.php/standards/dfdl/dfdl > > Owl Cyber Defense | www.owlcyberdefense.com > > > >
