Я немного запутался о Blueprint и Spring DM:OSGi: Blueprint vs. Spring DM
Из того, что я думаю, что верно:
Нет?
Можно ли ожидать, что эти две структуры станут едиными в будущем (слияние)? Если нет, то какой из них будет самым надежным в будущем?
OSGi 4.2 вводит спецификацию Светокопирование, основанную на проекта Spring Dynamic Modules для которых Spring DM (2.x) является Reference Implementation (RI).
Короче: Blueprint это спецификация, Spring DM является реализация Blueprint API
В дополнение к тому, что в ответ следует отметить, что проект Spring DM несколько мертвый проект, как Дмитро Pishchukhin DM 2 никогда не достигал версии «выпуска».
Вместо этого он был contributed to the Eclipse foundation, где он мутировал в Gemini Blueprint project.
В дополнение к этому =) есть Apache Aries, который является другой реализацией спецификации Blueprint. – earcam
Blueprint был разработан в OSGi Alliance под руководством SpringSource/Interface21.
Однако, если вы ищете способ использования OSGi, используйте Declarative Services (DS) с аннотациями между пакетами (услугами). По моему опыту, вам действительно не нужен проводной XML, когда вы делаете небольшие связные связки. DS намного лучше работает с сервисами, чем Blueprint/Spring DM, так как они стремятся «скрыть» динамику, в то время как DS просто делает ее тривиальной для использования.
для чего нужен DS? –
@ArchimedesTrajano [Declarative Services] (http://wiki.osgi.org/wiki/Declarative_Services) – pauli
Спасибо, я только что проверил ссылку, и я думаю, что я все же склоняюсь к Blueprint. –
Мое понимание таково, что SpringDM is a dead project. Проверьте даты GA и даты выпуска. Поэтому, хотя он в значительной степени способствовал разработке спецификации, в конце концов, у него был плохой подход к загрузчикам классов. Apache-Aries - сильная реализация проекта. Обратите внимание, что использование чертежа не исключает использования пружины. Я бы предложил Karaf как надежную платформу, которая может использовать либо Eclipse Equinox, либо Apache Felix для двигателя OSGI. Мне нравится дизайн по сравнению с DS, если вы разрабатываете на уровне приложений, где ваши службы могут использоваться другими командами или организациями на вашем предприятии или расширены вашими клиентами. Я думаю, что план также лучше подходит для традиционных корпоративных вычислительных сред. Но DS или Ipojo могут быть более подходящими в зависимости от конкретной целевой среды.
Не могли бы вы рассказать о проницательности/указателе о «плохом подходе к загрузчикам» Spring DM? Мне интересно о последствиях. – user1310749
В введении Blueprint документации Gemini они четко объяснить разницу: http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/index.html
Я размножению здесь:
Глава 1.Весенние динамические модули становятся Eclipse Близнецы Blueprint
В конце 2009 года в качестве члена проектного предложения Gemini SpringSource внедрил проект Spring Dynamic Modules (также известный как Spring OSGi) в Eclipse Foundation. База данных Spring DM v2 была перенесена на Eclipse.org вместе со своим трекером и форумом. Проект стал двойной лицензией по лицензии Apache и EPL.
Хотя имя изменилось, код и его функции остались прежними. Существующие приложения Spring DM можно легко перенести в Eclipse Gemini Blueprint, как указано в руководстве по миграции.
И ныне, преемник Gemini Blueprint Spring DM является эталонная реализация ([источник] (http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/blueprint. html)) API Blueprint. –