반응형

요즘 이슈 관리툴로 mantis를 사용해서 작업을 하고 있다.

trac을 사용하려고 했지만

trac이 잘 안되가지고 ㅋㅋㅋ

맨티도 무지 괜찮은 툴이더라구요

그런데

박재성님이 쓰신

자바 프로젝트 필수 유틸리티

책에 보니깐

trac과 eclipse의 MyLyn을 연동하는 부분이 나옵니다.

그래서 mantis와 eclipse는 연동이 안될까 하는 생각을 했습니다.

네 박사와 구글신에 문의를 해본 결과 위에 링크에 그 답이 있었습니다.

그런데

클라이언트는 제대로 설치를 했는데

제가 한 작업 중에 말썽이 있었습니다. ^^;;

mantis의 Web Service 서버버젼을 압축을 풀명 webservice/mc 이렇게 시작 합니다.

ㅋㅋㅋ 그래서 그대로 두었습니다.

그런데 T.T 저게 문제였습니다.

mc는 무조건 mantis가 설치된 디렉토리 아래에 설치 하십시오

이름은 어떻게 바꿔도 되지만 ^^;;

서버에 web service 설치 하실때 꼭 mantis의 하부 디렉토리에 설치 하셔야 됩니다. ^^;;

저같이 삽질 하는 사람이 없기를 바라면서 적습니다.^^;;

저도 다음에 삽질을 안하려구요.

PS.참 그리고, 이슈 관리툴로 mantis를 선택하게 된 이유는

mantis가 PHP로 되어 있다는 겁니다. ^^;;


[2026년 추기] 17년이 지났는데, 둘 다 아직 있습니다

본문에서 "위에 링크에 그 답이 있었습니다"라고 한 그 링크는 스프링노트를 가리키고
있었습니다. 그 서비스는 종료됐고, 링크도 함께 사라져 지웠습니다.

정작 사라진 건 링크뿐이었습니다. 확인해 봤습니다.

① 맨티스는 아직 있습니다

MantisBT 2.28.4가 2026년 7월 1일에 나왔고, 2.29.0이 개발 중입니다.
2000년에 시작한 프로젝트가 26년째 굴러가고 있습니다.

이 글을 쓰던 2009년에 이미 "요즘 이슈 관리툴로 mantis를 사용해서"라고 적었으니,
저도 이 도구를 17년째 알고 지낸 셈입니다.

② SOAP도 아직 있습니다. 다만 정공법은 REST로 바뀌었습니다

본문에서 헤맸던 그 webservice/mcMantisConnect, SOAP 기반 웹서비스입니다.
없어졌을 줄 알았는데 아닙니다. 개발자 가이드에 독립 챕터가 그대로 있고,
2.29.0 계획에는 SOAP API 문서를 배포판에 포함시키겠다는 항목까지 있습니다.

바뀐 건 무게중심입니다. 공식 문서는 REST를 이렇게 표현합니다.

The primary means of integrating with MantisBT with web services is with the bundled REST API.

지금 새로 연동을 만드신다면 REST를 보십시오. 이미 SOAP으로 돌아가는 게 있다면
급히 걷어낼 이유는 없습니다.

③ Mylyn도 아직 있습니다

Eclipse Mylyn은 4.6.0이 2025년 3월에 나왔고 Eclipse IDE에 계속 들어갑니다.

다만 이슈와 코드를 잇는 자리는 옮겨갔습니다. 2009년에는 그 일을 IDE 플러그인이
했지만, 지금은 커밋 메시지의 이슈 번호와 CI가 그 몫을 나눠 가졌습니다.
IDE를 거치지 않아도 이슈와 코드가 붙습니다.

붙이는 자리가 바뀐 것이지, 잇는다는 생각 자체는 그대로입니다.

④ 그때 제가 한 선택은 지금도 같은 이유로 유효합니다

맨 아래 추신에 이렇게 적어뒀습니다.

이슈 관리툴로 mantis를 선택하게 된 이유는 mantis가 PHP로 되어 있다는 겁니다

가볍게 쓴 한 줄인데, 도구를 고르는 기준으로는 지금도 제일 중요한 축입니다.
기능 비교표는 오래 못 갑니다. 정작 오래 가는 건 이겁니다.

  • 막혔을 때 우리 팀이 열어볼 수 있는가
  • 고쳐야 할 때 고칠 수 있는 언어인가
  • 운영할 사람이 이미 아는 스택인가

그때 제가 PHP를 다룰 줄 알았기 때문에 맨티스를 골랐고, 실제로 이 글에 적은
webservice/mc 문제도 직접 열어보고 풀었습니다. Trac이 안 되던 것을 붙들고 있었다면
거기서 멈췄을 겁니다.

그리고 17년이 지나 확인해 보니 그 도구가 아직 살아 있습니다.
그때는 알 수 없었던 일이지만, 결과적으로 오래 가는 쪽을 골랐습니다.

지금 고객사에 도구를 제안할 때도 같은 순서로 봅니다.
기능은 그다음입니다.

⑤ 그리고 이 삽질 자체가 흔한 유형입니다

mc를 mantis 아래에 두어야 했던 이유는, 그 코드가 자기 위치를 전제하고 있었기
때문입니다. 상대 경로로 설정과 인증을 끌어 쓰니 위치가 바뀌면 아무것도 못 찾습니다.

이런 건 지금도 그대로 있습니다. 컨텍스트 패스를 바꾸면 죽는 애플리케이션,
특정 디렉토리에서 실행해야만 도는 배치, 심볼릭 링크를 걸면 설정을 못 읽는 서버.
"어디에 두느냐"가 동작을 바꾸는 소프트웨어는 지금도 많습니다.

에러 메시지는 대개 그 사실을 알려주지 않습니다. 그래서 이런 걸 만나면
기능부터 의심하지 말고 경로부터 확인하는 습관이 시간을 아껴줍니다.


함께 보기

최신 버전 · SOAP 관련 항목

open https://mantisbt.org/bugs/changelog_page.php

반응형

+ Recent posts