Eclipse for Everything – javanese

우리 팀에서 사용 중인 Eclipse IAM에서 가끔 무한하게 빌드를 반복하거나 무한하지는 않더라도 의미없이 빌드를 몇번 반복하는 사례가 있어서 원인을 좀 찾아보았습니다.

• Eclipse IAM은 Maven Incremental Builder를 프로젝트에 추가합니다.
  • Incremental Builder는 내부에서 ResourceBuilderDelegate와 MavenJdtBuilderDelegate 두가지 빌드를 실행합니다.
  • 자바 컴파일은 이클립스 컴파일 결과를 그대로 사용할 줄 알았는데 MavenJdtBuilderDelegate가 따로 있었네요.
  • ResourceBuilderDelegate는 mvn resources:resources와 resources:testResources를 실행해줍니다.

• 문제 원인은 리소스 변경이 있을 때마다 매번 full build가 트리거되는 것이었습니다. 원래는 그러면 안되는 것입니다만..
  • 리소스 변경 후 Refresh를 하면 full build가 트리거
  • full build로 인해 Eclipse Builder clean 작업에서 derived resource를 지움
  • Java Builder, Maven Incremental Builder가 순서대로 실행
  • Maven Incremental Builder의 resources:resources goal 실행
  • resources goal로 인해 리소스 변경 후 다시 내부적으로 refresh 실행
  • 다시 full build 트리거…

Maven 문제는 둘째치고, resource 변경 만으로 Full Build가 실행되면 규모가 큰 프로젝트에서 빌드가 빨라지는 Incremental Build의 장점을 얻을 수 없습니다. 임시 조처는 다음과 같습니다.

1. Main Menu > Preferences
2. Java > Compiler > Building > Output folder > Scrub output folders when cleaning projects 체크 끄기

완전한 해결책은 아니고 workaround이긴 하지만 이것으로 Full Build를 실행하더라도 기존 derived resources를 지우지 않기 때문에 무한반복이 발생하지 않습니다. 다만 clean…으로 full build를 명시적으로 실행하더라도 완전히 깨끗한 빌드는 아니게 되는데요. 완전히 새로 빌드하시려면 Clean… 대신 maven clean을 사용하실 수 있습니다.

refresh만 건드려도 full build가 일어나는 원인을 아시는 분은 알려주세요~ 꼭 IAM 문제라고 할 수는 없고.. 소스 좀 더 까봐야겠네요..

원문기사: http://www.ibm.com/developerworks/kr/library/08/0701_ellingsworth/index.html

Jazz 플랫폼기반의 IBM Rational Team Concert에서 스크럼 프로젝트 관리하는 예를 설명하는 기사입니다. Jazz는 Erich Gamma가 참여한 프로젝트라는 것만으로도 기대하던 프로젝트인데.. 현재 회사에서 사용하고 있는 스크럼 활용에 대한 기사라 바로 훓어보았습니다.

일단.. 툴은 정말 덩치가 커보이네요. 이클립스 + 아웃룩 + 이슈트래커 + Mylyn + 알파 쯤으로 보입니다. 기사 내용만으로는 실제 사용할 때의 느낌이 완전히 와닿지는 않습니다만, 한데 잘 묶어놨을테니 충분한 시너지 효과가 있을 법해보입니다. 이슈트래커로 쩔쩔매며 스프린트 백로그 관리하고 있는 저로서는 눈이 번쩍하네요.

다만.. 아웃룩(+익스체인지 서버)의 역할을 묶어놓는 바람에 모든 사람이 Concert를 메인 커뮤니케이션 도구로 해야 의미가 있을 것 같아요. 상용이라 트라이얼 해보기도 부담스럽고.. 최소한 본부 단위로 적용하지 않는 이상 팀 단위로 유지보수하기는 어려워보입니다. 무료 버전이 있긴 하지만 대시보드와 레포트 기능이 빠져있어서 실제 활용에는 무리가 있습니다.

<Rational Team Concert Dashboard – 출처: IBM developerWorks Korea>

그래도 화려한 대시보드와 레포트는 정말 부럽네요. 꼭 써보고는 싶은데 흑.. 기사 내용과 비교해 볼 때 이슈트래커로 낑낑대고는 있어도 나름 스크럼 답게 프로젝트를 진행하고 있었다는 점이 그나마 위안입니다. Eclipse Process Framework에도 스크럼 지원이 있던데.. 그거나 기대해봐야겠습니다.

요즘 한창 Spring Framework 공부 중 입니다. 그래서 Spring 관련된 플러그인이랑 이래저래 Modeling 관련 플러그인 등 잔뜩 설치하고.. Spring 튜토리얼 보면서 열심히 따라하고 있는데 xml 파일들이 프로젝트 빌드할 때 계속 빠져버려서 일단 ant 빌드 해서 마무리는 했습니다.

뭔가 추가로 설치한 플러그인 중에 XML validation 하다가 에러나서 빌드를 방해하나 하고 플러그인 하나씩 빼보고 이런저런 삽질을 한참 했는데요.. 설치했던 걸 다 지워도 안되더군요 ㅠ_ㅠ 혹시나 해서 워크스페이스를 새로 만들었더니 됐습니다.

결론은 플러그인 문제는 아니고 Preferences > Java > Compile > Building에서 Output folder의 filtered resources 설정에 *.xml, *.html, *.svg 등이 들어가 있지 뭡니까 ㅠ_ㅠ 저는 절대로 설정한 적은 없는데.. 어느 플러그인이 환경설정을 바꿔버리는 것인지는 못찾았습니다. 같이 들어가 있는 filtered resource들이 *.datapool, *.testlog 등인 것으로 보아 TPTP 플러그인을 의심하고는 있습니다만..

비슷한 현상 겪으신 분은 참고하세요. 간만에 삽질다운 삽질 제대로 했네요. 크흑~

원문기사: http://www.ibm.com/developerworks/kr/library/j-ap06108

“사람을 위한 자동화” 시리즈는 항상 관심있게 보게 되네요. 이번 기사인 전자동 문서화는 JavaDoc 생성시 자동으로 UML Diagram 첨부하는 방법과 Ant 빌드 다이어그램, ERD, Doxygen 코드 문서, 사용자문서 등을 자동으로 생성하는 방법을 다루고 있습니다. 사용자 문서 생성은 별다른 마법이 있는 것은 아니고 개발자에게는 워드프로세서보다는 XSL-FO 등을 활용하여 문서를 컴파일하는 것이 문서 유지 보수에도 더 편리하다는 가정 하에 설명하고 있습니다.

UML Diagram을 생성해주는 Doclet은 이희승 님이 만드신 apiviz도 있습니다. 완전한 UML Notation으로 생성하는 것은 아니지만 보기에나 이해하기에는 깔끔하니 사용해보세요 ^^

출처: Netty API Document

원문기사: http://www.ibm.com/developerworks/kr/library/j-benchmark1.html

JVM에서는 핫스팟이나 GC 영향으로 작은 코드 단위의 성능을 측정하기 쉽지 않은데요. 코드 블럭 단위의 마이크로벤치마크의 정확성을 높이기 위한 요령과 고려해야할 요소 등에 대해 설명하고 있습니다.

실제로 유용한건 마이크로벤치마크를 위한 프레임워크를 제공하는 파트2겠습니다만 파트1에서는 기본적인 배경설명과 핫스팟이나 GC를 감안한 성능향상 팁(흔히 생각할 수 없는) 몇가지를 소개하고 있습니다.

    int result = 0;
    for (int i = 0; i < 1000 * 1000; i++) {    // outer loop
        for (int j = 0; j < array.length; j++) {    // inner loop 1
            result += array[j];
        }
        for (int j = 0; j < array.length; j++) {    // inner loop 2
            result ^= array[j];
        }
    }

    int result = 0;
    for (int i = 0; i < 1000 * 1000; i++) {    // sole loop
        result = add(result); // inner loop 1
        result = xor(result); // inner loop 2
    }

위의 두 코드는 같은 일을 하는 코드이구요. main()에 바로 구현된 것이어서 단 한번씩만 실행됩니다. 보기에는 위쪽 코드가 메소드 콜을 적게하기 때문에 더 빠를 것 같은데 핫스팟 적용을 위한 스택 내 치환(OSR)으로 인해 아래쪽 코드가 성능이 최대 두배까지 빨라진다고 합니다. 제 PC에서 테스트 해보니 각각 51.752s, 34.517s로 실제로 상당한 차이가 납니다. 뭐 배치 잡이 아닌 이상 일반적인 어플리케이션에서 딱 한번 호출하는 코드를 짤 경우는 많지 않겠습니다만.. 상식대로만 생각하면 안되겠다는 걸 보여주는 케이스인듯 합니다. ^^ 그외에도 생각지 못했던 재미있는 케이스가 많이 있네요.

요즘 하는 일이 메소드 수준의 성능 최적화가 많이 필요했는데 상당한 도움이 되는 기사였습니다. 좋은 기사와 번역 감사드립니다~