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 <mbecke...@apache.org> 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 <mbecke...@apache.org> > 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 <lich...@yahoo.com> 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 >>> >>> >>>
