Maven, DS, SCR을 사용하여 Felix의 OSGI 번들의 경우 최소는 무엇입니까?

Question

OSGI에서 구성 요소를 배선하는 과정은 시간이 지남에 따라 진화 한 것으로 보입니다.

진행은 다음과 같습니다.

• 직접 API 액세스
• Servicetracker 패턴
• 화이트 보드 패턴
• 선언 서비스
• Bnd
• 이포 조?? 봄?? 이 시점에서 그것은 매우 퍼지입니다.

다양한 라이브러리와 접근 방식이있어 옵션을 합리적인 접근 방식으로이기는 방법이 필요합니다. 기술이 언제 같은 문제에 대한 중복 접근법인지 또는 서로를 구축하는시기를 알 수 없습니다.

다음을 사용할 것임을 알고 있습니다.

• 아파치 펠릭스
• 아파치 슬링
• Maven

그 외에도, 나는 중복없이 번들 생성을위한 간단한 기술을 원합니다.

다음은 Maven과 다음 플러그인을 사용하여 만든 번들의 스크린 샷입니다 : Maven-Bundle-Plugin, Maven-Scr-Plugin.

나는 많은 중복성을 발견하고 필요한 것이 무엇인지 확실하지 않습니다.

1. pom.xmlPOM.XML이 항아리에 포함되는 이유는 무엇입니까? OSGI는 OSGI 번들 저장소 (OBR)에서 의존성을 가져 오기 위해 이것이 필요합니까?

2. 매니페스트 .mf또한 종속성을 나열하고 servicecomponents.xml을 나타냅니다Service-Component: OSGI-INF/serviceComponents.xml

3. servicecomponents.xmlSCR 주석의 XML 표현식으로 매니페스트의 확장처럼 보입니다. 이 시점에서 Java 클래스의 SCR 주석은 관련이 없거나 Osgi 가이 XML을 사용하여 주석이있는 클래스를 찾을 것입니까? 이 XML을 iPojo XML로 대체 할 것 같아요?

4. scrinfo.xml이것은 servicecomponents.xml의 복제품입니다. private="false" 각 노드에.

5. Metatype.xml이것은 다른 생성 된 XML처럼 보이지만 SCR 네임 스페이스를 사용하지는 않습니다.

6. 리브스나는 이것들이 시스템의 나머지 부분에 노출되지 않은 내 번들의 개인 의존성이라고 생각합니다.

나는 이것이 구불 구불 한 질문이라는 사실을 좋아하지 않지만, OSGI의 Apache-Felix 구현이 무엇을 찾고 있는지, 그리고 하나의 기술이 끝나고 다른 기술이 시작되는지에 대한 신뢰할만한 그림을 찾을 수는 없습니다. 오버 랩을 보여주는 좋은 다이어그램이 있거나 도움이 될 것입니다. 또는 누군가가 특정 권장 스택으로 좁힐 수 있으므로 기술 세부 사항을 정렬하는 동안 일부 블라인더를 넣을 수 있습니다.

Answer 1

몇 가지 추가 바이트에 대해 걱정해야 할 유효한 이유가 없다면 Maven 플러그인이 번들 항아리에 넣은 것에 대해 너무 걱정하지 않을 것입니다.

귀하의 목록에서 Afaics에서 모든 파일은 LIB의 항아리를 제외하고는 그곳에있을 좋은 이유가 있습니다. 번들이 다른 번들에서 해당 패키지를 가져 오는 것이 일반적으로 묶음으로 사용하는 대신 공유 할 수 있도록하는 것이 좋습니다.

Apache Sling으로 작업하는 경우 아래 /번들 아래에있는 묶음을 거의 가져갈 수 있습니다. 슬링 코드베이스 예를 들어, 잘 확립 된 모범 사례에 따라 구축됩니다. Sling Codebase는 Servicetrackers, Whiteboard 패턴 및 많은 선언 서비스를 사용하며 BND는 Maven 플러그인에 의해 실행 된 빌드 시간에 후드 아래에서 BND를 사용합니다.

나는 Ipojo를 직접 사용하지 않았다. 나는 그것이 슬링과 잘 어울릴 것이라고 생각하지만 우리는 슬링 자체에서 그 필요성을 보지 못했다.

나는 OSGI 애플리케이션에서 Spring을 사용하는 팬이 아닙니다. 일부 사람들이 성공적으로 그렇게하는 것처럼 보이지만 IMO는 일반 선언 서비스에 비해 많은 가치를 가져 오지 않는 추가 계층입니다.