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 2021/07/02 13:38:00 UTC

[jira] [Commented] (DAFFODIL-2540) Try Maven Shade renaming of ICU library

    [ https://issues.apache.org/jira/browse/DAFFODIL-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17373542#comment-17373542 ] 

Steve Lawrence commented on DAFFODIL-2540:
------------------------------------------

If I understand correctly, this would do something like take all classes in the com.ibm.icu namespace and  copy them into the daffodil-lib jar into a namespace like org.apache.daffodil.com.ibm.icu, and update import/references accordingly? So we essentially remove icu as a depdendency and embed it as something almost like a fat jar. Seems kindof a waste of duplication just to deal with this ICU conflict. Might have potential licensing implications too–probably fine, but we need to make sure the ICU license allows this.

I'm reminded of Apache Nifi, which has a concept of nar files to solve a similar problem. A nar file is essentially a fat jar containing all dependencies of a set of processors. And NiFi has a custom classloader so that when looking for classes for a Processor, it only looks in at the dependencies embedded in the associated nar. I guess it's kindof like shading in that it's embedding dependencies, just a different approach.

Which makes me wonder if we could take a more specific approach to our solution. I wonder if we could just create a special class loader so that when IBM DFDL is loading classes the class loader would only look at the right icu jar, and something similar for Daffodil. I'm not faimilar enough with class loaders to know if this is even possible, or how to the class loader can differentiate btween when IBM DFDL is loading vs when Daffodil is loading.

Also note that this isn't isn't really specific to ICU. I think we also have a pretty strict dependency to a specific Xerces version (I know an upgrade broke a bunch of stuff once). IBM doesn't use Xerces so no issue with the cross tester, but this doesn't solve the more general. Seems a bit heavy for a relatively small use case that few people really need (aside from us devs)

> Try Maven Shade renaming of ICU library
> ---------------------------------------
>
>                 Key: DAFFODIL-2540
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2540
>             Project: Daffodil
>          Issue Type: Improvement
>          Components: Libraries
>    Affects Versions: 3.1.0
>            Reporter: Mike Beckerle
>            Priority: Minor
>
> We depend on a recent ICU library.
> Some well known programs such as the ibm-cross-tester at OpenDFDL github site, depend on an older ICU library version.
> Hence, we cannot link both daffodil and IBM DFDL together into one application for cross testing purposes.
> The Maven Shade plugin can be used to rename a library (change all its packages), and we could do this for daffodil's use of the ICU library.
> That would allow Daffodil to link with other 3rd-party libraries that conflict with our dependent libraries.
> Then the ibm-cross-tester could be rewritten to be an "ordinary" application, and not an an alternative TDML processor that must be used instead of the daffodil TDML processor.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)