[
https://issues.apache.org/jira/browse/DAFFODIL-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515412#comment-17515412
]
Mike Beckerle commented on DAFFODIL-2683:
-----------------------------------------
>From an email thread:
"Regarding your last comment, let's ignore services, this is a higher-level
feature that we do not need to discuss in the context of the Daffodil library.
As you say, Daffodil is just a library (a very useful one, btw) and that's ok,
no need to change anything in this regard. It's also fine to split the code
into several JARs, no problem there.
The only issue I'm trying to address is the split-package that I'm seeing for
package "org.apache.daffodil.api" (and perhaps others as you mention). Classes
of this package reside in more than one JAR and that's a problem with regards
to modularity (see also Java 9 modules where this is not allowed either, for
example
[https://docs.microsoft.com/en-us/java/openjdk/transition-from-java-8-to-java-11#noclassdeffounderror-caused-by-split-packages]).
Think of a package as being _exported_ by one (and only one) JAR and a class
loader can therefore remember this upfront and doesn't need to search the
complete class path to find a class at run-time.
I haven't yet looked at org.apache.daffodil.processors, but if you using
sub-packages for each converter, such as org.apache.daffodil.processors.a,
org.apache.daffodil.processors.b, org.apache.daffodil.processors.c,
org.apache.daffodil.processors.test then "a", "b", "c", "test" can certainly
reside in separate JARs, that again is not a problem. It's only a problem if
the split is on the same package level, e.g. if class
org.apache.daffodil.processors.A.class and
org.apache.daffodil.processors.B.class would not be packaged in the same JAR."
> Don't split packages across jars - OGSI packaging requirements
> --------------------------------------------------------------
>
> Key: DAFFODIL-2683
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2683
> Project: Daffodil
> Issue Type: Bug
> Components: General
> Affects Versions: 3.3.0
> Reporter: Mike Beckerle
> Priority: Major
>
> A user wants to use daffodil inside Apache Karaf, which uses OGSi containers.
> Converting a jar to an OGSi container is feasible; however, there is an
> underlying assumption that a package is not split across such containers.
> As of daffodil 3.3.0, the package structure is not organized this way. The
> packages are orthogonal to the modules.
> For example org.apache.daffodil.processors is split across 6 modules:
> * daffodil-io
> * daffodil-lib
> * daffodil-macro-lib (which shouldn't create a jar, but still it mentions
> the package)
> * daffodil-runtime1
> * daffodil-runtime1-unparser
> * daffodil-tdml-lib (only in test code, which shouldn't impact the jar)
> The requirement is for each package to end up in exactly and only one Jar.
> This ticket possibly interacts with other refactoring tickets that are open
> such as DAFFODIL-2536.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)