OK 괜찮아, 동네 개발자형

제 특성 중 하나가 이것 저것 알기는 들은 것은 있는데, 실제로 쓰는 것은 별로 없다는 것이죠. 심한 단점일 수도 있고, 제네럴리스트의 장점일 수도 있죠.
어제 오픈소스 프로젝트 세미나에서 김승권님의 테스트에 대한 내용을 들으면서 나온 테스트 커버리지에 관련된  얘기를 듣고 clover를 이제는 써야겠다 생각이 들었습니다.

해서 연구 시작했습니다.
clover 라는 툴이 있습니다.
http://www.cenqua.com/clover/ 에서 30일 평가판을 다운로드 받을 수 있습니다. 물론 이메일 요구합니다.
 

흔히 하던대로 zip파일 받아서 eclipse의 plugins 디렉토리 아래에 폴더를 놓아둡니다. 그리고 재시동.

다음과 같은 뷰를 볼 수 있습니다.

html, pdf, xml의 리포트도 뽑아줍니다.
JUnit 테스트에 날개를 달아준 것 같다는 생각이 듭니다.

톰캣 시작할 때 디플로이
Deploying on Tomcat startup

host의 "deployOnStartup" 프로퍼티 값이 true이면 host appBase 폴더에 있는 웹 애플리케이션들은 디플로이 됩니다. 디플로이 프로세스는 다음과 같습니다:

• 컨텍스트 XML 선언은 제일 처음 디플로이 됩니다.
  
• 컨텍스트 XML 선언으로 참조되지 않은 펼쳐진 웹 애플리케이션들이 그 다음으로 디플로이 됩니다; 만일 .WAR파일과 연관이 되어있고, 그 .WAR파일이 새 것이라면, 펼쳐진 디렉토리는 제거되고, 웹 애플리케이션은 .WAR 파일 압축이 풀리면서 재 디플로이 될 것입니다.
  
• .WAR 파일들이 디플로이 됩니다.
  

만약 매칭되는 컨텍스트 XML 파일이 없다면, 디플로이되는 웹 애플리케이션마다 해당 컨텍스트 XML이 생성될 것입니다.
 
The webapps which are present in the host appBase will be deployed if the host "deployOnStartup" property is true. The deployment process is the following:

The Context XML declarations will be deployed first

Expanded web applications not referenced by Context XML declarations will then be deployed; if they have an associated .WAR file and it is newer than the expanded web application, the expanded directory will be removed and the webapp will be redeployed from the .WAR

.WAR files will be deployed

For each deployed web application, a matching Context XML descriptor will be created unless one exists already.

from: http://tomcat.apache.org/tomcat-5.0-doc/deployer-howto.html

운영중인 톰캣에 배치
Deploying on a running Tomcat server

만약 host의 "autoDeploy" 프로퍼티가 true이면, 호스트는 필요할 때마다 동적으로 웹 애플리케이션을 배치 또는 업데이트하려고 시도합니다. host는 자동 리로딩 작업에 필요한 백그라운드 처리가 필요할 것인데, 기본적으로 설정되어 있습니다.
If the host "autoDeploy" property is true, the host will attempt to deploy and update web applications dynamically, as needed. The host will need to have background processing enabled for automatic reloading to work, which is the default.

다음을 포함합니다:

• host appBase 폴더에 복사된 WAR파일의 배치
• host appBase 폴더에 복사된 펼쳐진 웹 애플리케이션의 배치
• WAR파일이 갱신되었을 경우 WAR파일로부터 배치된 웹 애플리케이션의 재배치:
  펼쳐있는 웹 애플리케이션이 제거되고, WAR파일이 다시 압축이 풀립니다. 만약 host의 옵션이 WAR파일은 압축해제되지 않도록 설정되었다면 그렇게 되지 않고, 그런 경우에는 웹 애플리케이션은 단순이 재배치 됩니다.
• /WEB-INF/web.xml 파일이 갱신된 경우 웹 애플리케이션의 재배치
• 배치된 웹 애플리케이션의 컨텍스트 XML 파일이 갱신된 경우 웹 애플리케이션의 재배치
• $CATALINA_HOME/conf/[enginename]/[hostname]/ 폴더에 컨텍스트 XML 파일(이전에 배치된 애플리케이션의 컨텍스트 경로와 일치하는 이름을 가진)이 추가된 경우 웹 애플리케이션의 재배치

주의: 웹 애플리케이션 리로딩은 로더에서 설정될 수 있고, 그런 경우 로드된 클래스는 변경에 대해서 추적됩니다.

This includes:
Deployment of WARs which are copied to the host appBase.
Deployment of expanded web applications which are copied to the host appBase.
Redeployment of a web application which has been deployed from a WAR when the WAR is updated: the expanded web application is removed, and the WAR is expanded again. This will not happen if the host is configured so that WARs are not expanded, in which case the webapp will be simply redeployed.
Redeployment of the web application if the /WEB-INF/web.xml file is updated.
Redeployment of the web application if the context XML file from which the web application has been deployed is updated.
Redeployment of the web application if a context XML file (with a name corresponding to the context path of the previously deployed application) is added in the $CATALINA_HOME/conf/[enginename]/[hostname]/ folder.
Note: Web application reloading can also be configured in the loader, in which case loaded classes will be tracked for changes.
from: http://tomcat.apache.org/tomcat-5.0-doc/deployer-howto.html

클라이언트 디플로이어 패키지를 사용해서 디플로이하기
Deploying using the Client Deployer Package
번역 translated by kenu_AT_okjsp.pe.kr

클라이언트 디플로이어는 운영이나 개발 서버에 웹 애플리케이션을 검증, 컴파일, 배치시킬 수 있는 패키지입니다. 이 기능은 자동 배치를 위해서 톰캣 매니저를 사용한다는 것은 알아야 겠죠.
The client deployer is a package which can be used to validate, compile, and deploy a web application to a production or development server. It should be noted that this feature uses the Tomcat manager for automatic deployment.

이 디플로이어는 카탈리나 매니저 앤트 태스크, 배치 전에 JSP 컴파일을 하기 위한 재스퍼 페이지 컴파일러, 그리고 웹 애플리케이션 배치 기술서를 검증하는 태스크를 포함하고 있습니다. 검증 태스크(org.apache.catalina.ant.ValidatorTask 클래스)는 파라미터 하나만 받습니다: 웹 애플리케이션의 기본 경로
The deployer includes the Catalina manager Ant tasks, the Jasper page compiler for JSP compilation before deployment, as well as a task which validates the webapp's deployment descriptor. The validator task (class org.apache.catalina.ant.ValidatorTask) allows only one parameter: the base path of an expanded web application.

디플로이어는 입력으로 펼쳐진 웹 애플리케이션을 이용합니다(아래에 나와 있는 디플로이어의 프로퍼티 목록 참조). 디플로이어가 프로그램으로 배치하게 되는 웹 애플리케이션은 톰캣에 특화된 배치 설정을 포함할 수도 있습니다. /META-INF/context.xml 안에 있는 컨텍스트 설정 XML 파일이죠.
The deployer uses an unpacked web application as input (see the list of the properties used by the deployer below). A web application which is programatically deployed with the deployer may include Tomcat specific deployment configuration, by including a Context configuration XML file in /META-INF/context.xml.

디플로이어 패키지는 다음과 같은 앤트 스크립트 타겟을 사용할 수 있습니다:

• compile (default): 웹 애플리케이션을 컴파일하고 검증합니다. 독립적으로 사용될 수 있고, 실행중인 톰캣 서버가 없어도 됩니다. 컴파일된 애플리케이션은 오직 관련된 톰캣 5.0.x버전의 서버에서만 실행됩니다. 다른 버전에서는 동작한다고 보장할 수 없습니다. 재스퍼에 의해 생성된 코드는 실행 컴포넌트에 의존하기 때문입니다. 또 하나 알아야 할 것은 이 compile 타겟은 웹 애플리케이션의 /WEB-INF/classes 폴더 안에 있는 모든 자바 소스는 자동으로 모두 컴파일 해 버린다는 것입니다.
• deploy: (컴파일 되든 안되든) 웹 애플리케이션을 톰캣 서버로 배치합니다.
• undeploy: 웹 애플리케이션을 제거.
• start: 웹 애플리케이션을 시작.
• reload: 웹 애플리케이션을 릴로드.
• stop: 웹 애플리케이션을 정지.

The deployer package includes a ready to use Ant script, with the following targets:
compile (default): Compile and validate the web application. This can be used standalone, and does not need a running Tomcat server. The compiled application will only run on the associated Tomcat 5.0.x server release, and is not guaranteed to work on another Tomcat release, as the code generated by Jasper depends on its runtime component. It should also be noted that this target will also compile automatically any Java source file located in the /WEB-INF/classes folder of the web application.
deploy: Deploy a web application (compiled or not) to a Tomcat server
undeploy: Undeploy a web application
start: Start web application
reload: Reload web application
stop: Stop web application

다음 프로퍼티는 시스템 프로퍼티나 또는 디플로이어 패키지의 루트 폴더에 있는 deployer.properties 파일을 통해서 지정할 수 있습니다:

• build: 기본적으로 사용되는 빌드 폴더는 ${build}/webapp${path} 입니다. compile 타겟의 실행이 마친 후, 웹 애플리케이션 WAR 파일은 ${build}/webapp${path}.war 에 만들어집니다.
• webapp: 컴파일되고 검증되고, 압축이 풀린 웹 애플리케이션이 담길 폴더. 기본 폴더명은 myapp 입니다.
• path: 웹 애플리케이션의 배치될 컨텍스트 경로. 기본값은 /myapp.
• url: 실행중인 톰캣 서버의 매니저 웹애플리케이션에 접근할 수 있는 절대 URL. 여기를 통해서 웹 애플리케이션을 배치(설치) 또는 제거할 수 있습니다. 정해지지 않으면 디플로이어는 로컬호스트에서 돌아가는 톰캣인스턴스의 주소 http://localhost:8080/manager로 접근하려 할 것 입니다.
• username: 톰캣 매니저 연결용 username.
• password: 톰캣 매니저 연결용 password.

The following properties can be specified, either as system properties, or by using a deployer.properties file located in the root folder of the deployer package:
build: The build folder used will be, by default, ${build}/webapp${path}. After the end of the execution of the compile target, the web application WAR will be located at ${build}/webapp${path}.war.
webapp: Folder containing the expanded web application which will be compiled and validated. By default, the folder is myapp.
path: Deployed context path of the web application, by default /myapp.
url: Absolute URL to the manager web application of a running Tomcat server, which will be used to deploy and undeploy the web application. By default, the deployer will attempt to access a Tomcat instance running on localhost, at http://localhost:8080/manager.
username: Username to be used to connect to the Tomcat manager.
password: Password to be used to connect to the Tomcat manager.

from: http://tomcat.apache.org/tomcat-5.0-doc/deployer-howto.html

지난 포스트에 이미지만 작뜩 붙여놓고 설명을 하지 못했습니다.
하지만 김풍주님의 도움으로 더 좋은 방법을 알게 되었습니다. 그리고 근원적인 이유도 함께 말이죠.

http://www.eclipse.org/webtools/faq/TomcatServerFAQ.php#info_10
주소에 나와있는 것인데, 톰캣에 왜 META-INF 디렉토리가 있었나 생각했었는데, 컨텍스트 관련한 설치 정보를 넣을 수 있더군요.

곧 좋은 기사를 하나 내놓을 수 있을 듯 합니다. 급방긋 ^_^

오픈소스.
보기에 좋아보입니다.
회사에서 쓰려니 망설여집니다.
우선 매력적인 것이
1. 비용이 들지 않아서 손해날 것도 없다는 생각
2. 소스를 마음대로 들여다 볼 수 있어서 답답하지 않을 것이다
3. 기회만 되면 직접 커스터마이징도 가능할 것입니다.

하지만 걱정되는 것은
1. 프로젝트 납기일이 짧습니다.
2. 한글문제나 성능문제가 나타나면 많이 난감합니다.
3. 패치가 너무 자주 됩니다.
4. 윗선에서 별로 탐탁해하지 않습니다. 신뢰감이 없어 보인다는 것이죠.

그래도 오픈소스를 써야할까요?

말도 안되는 것이지만, 타당한 이유가 있습니다.

편집기 이상의 기능을 하는 이클립스의 Navigate 메뉴를 중심으로 편리하게 소스를 읽을 수 있도록 도와주는 기능들을 살펴봅니다.
이름하여 eclipse code navigation
부제는 코드 빨리 찾기

코드를 쉽게 읽을 수 있도록 도와주는 기능. 참조하는 소스코드들을 쉽게 찾아내는 기능입니다.
legend
ctrl :  ^
alt :  @
shift : ~

찾기/바꾸기
^ + F

파일 찾기
^ + ~ + R, @ + n u

문자열 포함된 소스 찾기
contextMenu + find
^ + H

코드 패턴 찾기
^ + j
^ + k, ^~ + k

파일과 파일 사이 이동
^ + f6

상속 관계 찾기
^ + t

메소드 찾기
^ + o

선언부 찾기
^ + leftClick
f3

참조 소스 목록
ctrl + shift + g
contextMenu > References > Project

같은 변수 찾기
형광펜

method 집중해서 보기
형광펜 옆

라인번호로 이동
^ + L

중괄호({} brace) 처음과 끝
ctrl + shift + p
@ + ~ + 좌우화살표

코드 비교하기
compare with...
replace with...

...

편집

코드를 쉽게 짤 수 있는 기능들입니다.

copy & paste
^ + insert / ~ + insert
^ + c / ^ + v
^ + @ + 상하 화살표

method copy/remove
outline view에서 copy/remove

refactoring
집중 분석 필요

오늘 다운받았습니다.(http://www.eclipse.org/downloads/)
유로파 (europa) 라는 배포 시스템을 통해서 확장 플러그인에 대한 손쉬운 접근법을 선택했습니다. eclipse java IDE의 경우 PDE를 제거하고 Java IDE, CVS client, XML Editor, Mylyn 만 포함시켰습니다. New 메뉴에서 생성가능한 것들입니다.

plugin 개발이나 C/C++ 개발인 경우는 그에 따른 배포판을 다운로드 받거나 유로파를 통해서 업데이트할 수 있습니다. http://www.eclipse.org/downloads/ 예전처럼 JDT(Java Development Tool)와 PDE(Plugin Development Enviroment)가 있는 classic버전도 있습니다.

Mylyn이라는 새로운 기능이 들어갔는데, 커다란 workspace에서 업무단위로 소규모 그룹화 시켜서 작업할 수 있도록 도와주는 기능입니다. 아직 쉽게 와닿지는 않지만 연구해볼 만 합니다.

다시 한 번 변화의 바람이 불 것 같습니다.

jdk1.5에 tomcat5.5 그리고 eclipseWTP1.5 버전에 해당됩니다.

cvs의 버전관리 기능을 이용해서 특정한 시간에 대한 소스 디렉토리와 파일들을 복원해 낼 수 있습니다. 타임머신과도 같은 기능이죠.
현재의 소스와 과거의 소스를 이클립스를 통해서 비교도 할 수 있습니다.
보시죠.

CVS Repositories에서 프로젝트를 선택해서 Check Out As...를 선택합니다. Check Out 할 경우는 cvs에 등록된 대로 바로 프로젝트가 생기게 되는 것은 다 아실 겁니다. 로컬의 디렉토리로 가져올 때 프로젝트 커스터마이징을 하기 위해서 Check Out As... 메뉴를 선택합니다

프로젝트 이름을 적당하게 바꿔줍니다. 이미 okjsp2007이라는 이름으로 프로젝트가 있는 상태이기 때문에 okjsp2007_timemachine이라는 프로젝트 이름을 지었습니다. ㅎㅎ 꽤 잘 지은 것 같습니다. Next 버튼을 클릭합니다. Finish 클릭하면 말짱 황입니다. 조심조심.

Tag를 설정하는 화면입니다. Dates를 선택하고 Add Date... 버튼을 클릭합니다. 중간 맨 오른쪽에 있죠.

캡쳐한 시점이 6월23일인데 한 달 전 시간 5월23일 저녁 6시 기준으로 소스를 가져오도록 하겠습니다. 시간 세팅은 어렵지 않겠죠.

시간 태그가 보일 겁니다. 그 태그를 선택하고 Finish 버튼을 클릭합니다.

퍼스펙티브를 바꿔서 프로젝트 두 개가 나란히 서있는 것을 볼 수 있습니다. ^^; 찌그러져 앉아있는지도 모르죠. 헙. 일단 두 개의 프로젝트를 선택합니다. 비교해 봐야죠.

컨텍스트 메뉴의 Compare With > Each Other 를 선택합니다. 말이 되네요. 비교해봐 > 서로

화면에 Compare tab이 나타날 겁니다. 탭을 더블클릭해서 전체 화면으로 만들고 비료하면 됩니다. 일단 파일을 선택하면 파일의 어느 부분이 바뀌었는지 우측에 구조 비교화면이 나오고 해당 메소드를 선택하면 하단에 소스가 비교되어 나옵니다. 왼쪽과 오른쪽 소스 상단에 프로젝트 이름이 보이니 어떤 것인지 혼동하지 않아도 됩니다.


이클립스에서 프로젝트 구조의 비교도 가능하다니 훌륭하지 않습니까? 이클립스가 조금 더 좋아지지 않나요? ^^ 이상 마치겠습니다.