Ok, I'l proceed and if I run into trouble, I'll reawaken this thread. We seemed to be getting "this is a bug" exceptions thrown from deserialization logic because the extendedCharsets was compiled with daffodil 3.8.0.
Trying to create the DAFFODIL_CLASSPATH in an assembly project was showing the daffodil-udf 3.8.0 library in the DAFFODIL_CLASSPATH, and trying to run CLI 'daffodil parse --parser ...savedBinParser dataFile' was giving the "this is a bug" uncaught exception in deserialization. At this point we've rebuilt all of these locally end-to-end with daffodil 3.9.0 and are unable to reproduce the issue now, but are no longer blocked in our work. On Fri, Oct 25, 2024 at 3:10 PM Steve Lawrence <slawre...@apache.org> wrote: > You actually shouldn't really have to do anything. The Daffodil CLI orders > the > classpath so it its own jars go before anything provided in > DAFFODIL_CLASSPATH, > and thus have precedence. > > So, for example, if you add daffodil-lib-3.8.0.jar to DAFFODIL_CLASSPATH > but you > are running with Daffodil CLI 3.9.0, that 3.8.0 jar will just be ignored > and the > daffodil-lib-3.9.0.jar will be used. > > > On 2024-10-25 03:03 PM, Mike Beckerle wrote: > > Thanks for this. However, right now plugins seem to drag in dependencies > on > > the version of daffodil they were compiled with. > > > > This is fixed in the next (as yet unreleased) sbt-daffidil, but how do I > > cope with this in the short term? > > > > If I do 'sbt "export fullClassPath"' I will get a mixture of different > > daffodil jars, or entirely wrong ones it seems. > > > > Do I just edit this classpath by hand so I can set DAFFODIL_CLASSPATH > > properly, or is there a better workaround? > > > > > > On Fri, Oct 25, 2024 at 2:55 PM Steve Lawrence <slawre...@apache.org> > wrote: > > > >> I just responded to the other thread related to this, but more > succinctly: > >> > >> For modern versions of Daffodil you shouldn't need different plugin > >> versions for > >> different Daffodil versions. > >> > >> A charset plugin will work with all version of Daffodil 3.4.0 or newer > >> > >> A layer plugin will work with all versions of Daffodil 3.8.0 or newer > >> > >> A UDF plugin will work with all versions of Daffodil 3.0.0 or newer > >> > >> I suggest only including a daffodil version in the name or version of a > >> plugin > >> if you are maintaining a plugin for use with an older version of > Daffodil > >> than > >> listed above. It should not be needed for newer versions of Daffodil as > >> long as > >> we continue to maintain backwards compatibility. And I think our APIs > are > >> stable > >> enough that this shouldn't be a problem. > >> > >> So if you want a charset plugin to work with 3.8 and 3.9, you can built > it > >> with > >> an modern version of Daffodil and the jar should work with all of them. > >> Note > >> that if this isn't the case, it means we probably have a bug somewhere, > or > >> maybe > >> I have the version numbers off. > >> > >> On 2024-10-25 02:41 PM, Mike Beckerle wrote: > >>> I want to have a daffodil 3.8.0 and a daffodil 3.9.0 version of an > >>> extendedCharsets plugin. > >>> > >>> This is true of all our plugins, layers, UDFs, etc. > >>> > >>> But the jar file created when compiling them is not named differently > for > >>> different versions of daffodil. > >>> > >>> That suggests that I need to have different versions for different > >> versions > >>> of daffodil, e.g., > >>> > >>> version 1.1.380 for daffodil 3.8.0, and version 1.1.390 for daffodil > >> 3.9.0 > >>> > >>> Or am I missing something about how to do this? > >>> > >>> 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 > >>> > >> > >> > > > >
