OSGi - это разработка программного обеспечения. О проверке того, что ваши зависимости времени компиляции соответствуют совместимым зависимостям времени выполнения. Когда вы следуете (простым) правилам, вы получаете гораздо более надежную систему, чем без OSGi, потому что ничего не «предполагается», как во многих проектах, не связанных с OSGi.
К сожалению, это означает, что вам нужно правильно понимать метаданные. Хотя сейчас огромное количество кода содержит метаданные OSGi, у людей есть естественная тенденция делать короткие пути. В этот момент у вас есть худшее из обоих миров. Вы не получаете много преимуществ, но вы все равно платите. OSGi, по сути, является технологией «полностью», выбор некоторых компонентов дает мало преимуществ.
Если бы я столкнулся с вашей проблемой, я бы проанализировал, что нужно моему коду от Spark, и посмотрел, смогу ли я превратить это в ряд чистых, связных и несвязанных сервисных API. Я бы написал свой код против этих API. Во время выполнения OSGi я бы использовал свои собственные зависимости. Мои реализации сервиса Spark, которые я регистрировал бы вне каркаса, чтобы пространство классов Spark и пространства классов OSGi были отдельными. Тем не менее, это не тривиально, так как многие API имеют тенденцию к утечке деталей реализации и зависимостей реализации.
Попытка портировать проект с открытым исходным кодом, который не был разработан для OSGi с зависимостями 200 Мб, является моей основной задачей. Это очень похоже на попытку повысить безопасность программы, которая не была разработана с нуля, чтобы принять во внимание безопасность.