2011-11-21 5 views
0

빌드 트리에서 jar 파일을 빌드하는 사용자 정의 도구를 쓰고 있습니다. 우리는 "루트"클래스 (main()이있는 곳)에서 실제로 참조 된 .class 파일 만 포함하는 "최소"jar 파일을 빌드하는 등 종속성을 재귀 적으로 따르는 방식을 선호합니다.jar 파일에 해결되지 않은 종속성이 있는지 어떻게 테스트 할 수 있습니까?

이전에 우리는 javac을 소스 종속성을 따르도록했지만 실제로는 여러 번 공통 파일을 다시 컴파일해야합니다. (우리는 단일 소스 트리에서 60 개 또는 70 개의 별개의 응용 프로그램 jar를 빌드합니다.) 각 소스 파일을 한 번만 컴파일하는 새로운 빌드 시스템을 작성하고 있지만 이는 .class 파일을 구문 분석하여 종속성을 따라야 함을 의미합니다.

좋은 소식은 내가 원하는대로 작동하는 코드가 있다는 것입니다. 그러나 나는 이어야만합니다. 나는 그것을 망치지 않았습니다. 즉, 내부적으로 일관성있는 jar 파일을 만들고 싶습니다. "일관성있는"은 모든 미해결 참조가 알려진 제 3의 중 하나로 해결 될 수 있다는 것을 의미합니다. - 항아리.

그래서 이상적으로 나는 myapp.jar 내부의 모든 해결되지 않은 참조를 검사하고이 --classpath에 전달 된 타사 항아리 중 하나에 의해 해결 될 수 있는지 확인합니다

MagicTool \ 
    --classpath commons-lang.jar:commons-collections.jar:[...etc...] \ 
    myapp.jar 

처럼 실행할 수있는 MagicTool를 원한다. 그렇지 않다면, barf.

답변

1

정확한 전화 구문이 아니더라도 ProGuard이 마술 도구라고 확신합니다. 그 경로에

2

더 나은 희망 아무것도 또는 방법으로 출력을 제공하지 않을 수도 있습니다 (나는 내 ​​자신의 자바 동굴 탐험 도구를 사용하지 않는 경우) 내가 depfind 사용하는 반사, forName의 종류 등

포함되지 않습니다 그것은 당신에게 도움이됩니다. jdepend은 패키지 수준의 종속성 이외의 용도로 사용한 적이 없지만 또 다른 옵션입니다.

ProGuard와 같은 다른 도구는 동일한 반사적 경고가있는 사용되지 않은 클래스를 제거합니다 (다른 것들 중에서).

도 매우 조심 스럽습니다. 최소한의 jar 파일을 만들기가 어려우므로을 작성하는 것이 좋습니다. 수익 감소/위험 증가의 포인트가 있습니다.

0

몇 년 전 한 단계에서 jar -i으로 JAR 파일의 색인을 생성하면 해결되지 않은 종속성이있는 경우 예외가 발생합니다. 나는 사물의 현재 상태를 빨리 테스트 할 수 없다.