(resend making sure M Lichtin is on this thread) It seems that an OGSi module is supposed to provide a "service" which can be activated.
Our daffodil jars are nothing like organized as separate service providers. They're more ad-hoc libraries of code with shared concerns. A sensible "service" from daffodil would involve running code from several of the jars. Can you comment on this - when a sensible OGSI service requires code that is distributed across many jars? > On Thu, Mar 31, 2022 at 10:03 AM Mike Beckerle <[email protected]> > wrote: > >> Created https://issues.apache.org/jira/browse/DAFFODIL-2683 to track >> this issue. >> >> >> >> On Thu, Mar 31, 2022 at 9:55 AM Mike Beckerle <[email protected]> >> wrote: >> >>> So, it seems there is, in general, an assumption in OGSi that a package >>> does not get contributions from multiple jar files? >>> >>> I expect that the org.apache.daffodil.api conflict is only the first of >>> many such conflicts you would hit. Several of our packages are split across >>> the jars. Participation in a package is kind of orthogonal to presence in a >>> jar in Daffodil right now. >>> >>> org.apache.daffodil.processors is split across 5 modules. 6 if you count >>> the test code. >>> >>> This can of course be fixed but this is our first experience with this >>> requirement. >>> >>> I will create a JIRA ticket for this. >>> >>> In the mean time, I'm not sure what to suggest as a workaround. Perhaps >>> you have to unjar everything, put all the files in a common directory tree, >>> and re-jar it all? >>> >>> >>> On Thu, Mar 31, 2022 at 1:42 AM Martin Lichtin <[email protected]> >>> wrote: >>> >>>> Hi >>>> >>>> Trying to run Daffodil inside Apache Karaf (OSGi container) I noticed >>>> that the Daffodil JARs are not built as bundles. That's not a problem, >>>> they can be bundle'ized on the fly. >>>> >>>> However, what's an issue is that two JARs contain the same package. >>>> Both >>>> daffodil-runtime1_2.12 and daffodil-lib_2.12 expose >>>> "org.apache.daffodil.api" and therefore this package is split and >>>> causes >>>> a conflict. >>>> >>>> Could perhaps this package moved into an "api" JAR, or one of the two >>>> JARs renames it such that there's no longer a split-package situation. >>>> >>>> - Martin >>>> >>>> >>>>
