나는 OSGI를 연구하여 기존 프로젝트를 업데이트 할 수 있는지 확인했다. 프로젝트는 현재 XSL 변환을 포함하는 모듈 (기본적으로 디렉토리 만 포함)로 구성됩니다. 변환에는 다른 모듈의 변환에 대한 종속성이 xsl : import 및 xsl : include 문 형식으로 포함됩니다. OSGI를 고려하는 이유는 모듈 수가 증가하면 의존성을 추적하고 효과적으로 모듈을 테스트하기가 더 어려워지고 있기 때문입니다.OSGI 번들 간의 XSLT 의존성
OSGI 프레임 워크를 사용하여 번들에 포함 된 XML/XSLT 리소스를 선언하고 이러한 리소스를 별도의 번들로 XSL 변환의 import 문에서 참조 할 수 있습니까?
예, 이것은 Lukasz가 지적한대로 작동합니다. Extender 모델을 기반으로 간단한 URIResolver를 작성해야합니다. 흥미로운 접근 방법은 Provide-Capability 및 Require-Capability 헤더를 사용하여 종속성을 모델링하는 것입니다. 이렇게하면 좋은 진단을 통해 종속성을 처리 할 수 있고, 여러 버전을 나란히 실행할 수 있으며, 누락 된 부분을 찾을 수있는 해결 프로그램 인 OBR을 사용할 수 있습니다. http://www.osgi.org/blog/2012/03/requirements-and-capabilities.html
그리고 XSLT가 XML이라는 사실을 처음 보게 될 것입니다 ... 당신은 Require-Capability 헤더를 생성 한 간단한 스타일 시트를 작성할 수 있습니다! :-)
귀하의 질문은 매우 흥미로운 것 같습니다. 개인적으로, 나는 두 개의 번들이있는 시스템에서 작업하고있다. 하나의 번들에는 XSLT 프로세서 구현 (Saxon 사용)이 있고 두 번째 번들에는 복수의 XSLT 파일 (xsl:import 명령어 사용)이 포함되어 있습니다. 그리고 그것은 OSGi 환경에서 실제로 작동하지만 (실제로 퓨즈 ESB) 우리는 javax.xml.transform.URIResolver 인터페이스를 구현하고이를 변환기에 전달해야했습니다.
비슷한 접근 방식을 사용해야한다고 가정합니다. 희망이 도움이됩니다.
루카스, 이것은 좋은 접근 방법처럼 들리 네. 코드 예제 또는이 작업을 수행하는 방법에 대한 링크가 있습니까? –
내가 당신 인 경우 종속성 관리를 위해 Maven을 사용합니다. 종속성을 설정하는 것이 더 간단하고 전이 종속성을 실제로 잘 처리합니다. 실행 시간에서 XSL 모듈을 변경할 수 있어야하는 경우 OSGi를 사용하십시오. 두 경우 모두 다른 대답에서 언급 한 URIResolver을 구현해야합니다.
이미 사용 가능합니까? R5가 올 때 또는 이미 있다면 정보를 찾을 수 없습니까? –
R5 최종본은 화요일 밤 OSGi DevCon BOF (EclipseCon)에 게재 될 예정입니다. 어쨌든, 설명 된 모델은 이미 4.3 프레임 워크에서 작동합니다. –