안드로이드 애플리케이션 소스를 디버깅하는 최선의 방법은 이클립스에서 [Debug As > Android Application]을 실행하는 것입니다. 그러나 어떤 경우에는 이 메뉴를 이용할 수 없거나 또는 이용할 필요가 없는 상황도 생깁니다.  
예를들어 Debug As 메뉴를 실행했더니 바빠 죽겠는데 어디가 꼬였는지(?) 계속 아래와 같은 에러가 발생한다면?

[2010-04-12 11:33:41 - Contacts]Installing Contacts.apk...
[2010-04-12 11:34:19 - Contacts]Installation error: INSTALL_FAILED_UPDATE_INCOMPATIBLE
[2010-04-12 11:34:19 - Contacts]Please check logcat output for more details.
[2010-04-12 11:34:19 - Contacts]Launch canceled!

또는 로컬의 애플리케이션 소스가 타겟에 설치된 버전과 소스가 동일해서 재설치하거나 덮어쓸 필요가 없는데, 소스는 디버깅하고 싶다면?
이럴 때는 Debug As 메뉴를 고집하지 말고 임시로 수동으로 디버깅하면 됩니다. 

수동으로 프로세스에 디버거 붙이기
디버깅하고자 하는 애플리케이션 프로세스에 디버거를 여러분이 직접 수동으로 붙여서(attach) 디버깅할 수 있습니다. 다음 과정을 따릅니다.

  1. 타겟(에뮬레이터)에서 해당 애플리케이션을 시작시킴 
  2. 이클립스 DDMS에서 해당 프로세스를 선택
  3. 미리 만들어둔 리모트 디버그 실행설정을 실행함 
  4. 이제 소스에 중단점 존재시 디버그 퍼스펙티브로 전환됨

* 이클립스에 리모트 디버그 실행 설정 만들기
  • 프로젝트 오른 클릭 > Debug As > Debug Configurations 실행
  • Remote Java Application 타입으로 새로운 launch 설정 생성
  • Port를 8700번으로 수정
  • Apply 클릭 (Debug 클릭하면 바로 실행됨)


프로세스에 디버거 붙이는 작업을 자동화하기

만약 수동으로 디버거를 붙이는 작업을 자꾸 반복해야 한다면, 이것은 당연히 비효율적인 일이 되고 맙니다. 

또한 디버거를 붙이는 작업을 사람이 수동으로 처리하다보니, 애플리케이션 시작부터 리모트 디버거를 붙이기까지 다소 시간이 걸릴 수 있습니다. 이렇게 되면 디버거가 연결되기 전에 액티비티의 onCreate() 같은 메소드에 찍어둔 중단점은 지나쳐 버릴 수가 있습니다 (아 물론, 이 문제는 에뮬레이터의 Dev Tools 애플리케이션의 Development Settins에서 아래처럼 Wait For Debugger 옵션을 체크하여 방지할 수 있습니다).



어쨋든 디버거 붙이는 과정은 가급적 스크립트로 만들어두고 자동으로 실행시키는 것이 좋습니다.


▶ 타겟(에뮬레이터)에서 해당 애플리케이션을 시작

am(Activity Manager) 명령어를 이용합니다. 타겟에서 지정된 액티비티를 디버그 모드로 시작하는 명령형식은 다음과 같습니다.

am start -D -n <package-name>/<package-name>.<class-name> 

자동으로 해당 액티비티 프로세스의 디버깅 포트가 8700 포트로 포워딩되며 만약 8700 포트로 붙는 디버거가 없으면 액티비티는 디버거가 붙을 때까지 대기합니다. 다음은 Contacts 네이티브 애플리케이션의 주소록 목록화면 액티비티 띄우는 예제입니다.

$ adb shell am start -D -n com.android.contacts/.ContactsListActivity


▶ 이클립스 DDMS에서 해당 프로세스를 선택 

이클립스 DDMS를 보지 않고 방금 띄운 프로세스의 디버깅 포트를 알아내는 것이 핵심입니다. 디버깅 포트는 이렇게 알아낼 수 있습니다.

(1) 해당 프로세스가 마지막에 뜬 프로세스인 경우

adb jdwp | tail -1

(2) 프로세스의 이름을 알고 있는 경우

# ps| grep 프로세스명 | awk '{print $2}'
# 다음은 프로세스명이 android.process.acore인 경우 예제
$ adb shell ps | grep android.process.acore | awk '{print $2}'

이제 리모트 디버깅 실행설정에서 설정해둔 8700 포트를 이렇게 알아낸 포트로 포워딩하면 됩니다.

# 먼저 위에서 알아낸 디버깅 포트를 $DEBUG_PORT 변수에 저장합니다
$ adb forward tcp:8700 jdwp:$DEBUG_PORT


▶ 이클립스 리모트 디버그 실행설정을 실행
이클립스에 만들어둔 '리모트 디버그 실행설정'도 스크립트을 통해서 실행하는 방법이 있으면 좋겠네요. 이 부분은 좀더 찾아봐야겠습니다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

  1. 대전글로벌리더십센터 2010.07.07 16:34 신고  댓글주소  수정/삭제  댓글쓰기

    (강의요청)안녕하세요 대전글로벌리더십센터입니다
    혹시 안드로이드 어플리케이션 개발에 대해 강의도 가능하신가요?
    가능하시다면 cute519@naver.com 로 연락 부탁드립니다.
    감사합니다^^

WAS를 start/stop/restart하거나 웹어플리케이션을 deploy/undeploy/redeploy하는 작업을 자동으로 처리하기 위해 쓸 수 있는 방법은 어떤게 있을까?

1. 스크립트 실행
작업을 정의한 스크립트를 실행한다. 아마 이게 제일 속편한 방법일지도 모른다.
Ant에서는 telnet, exec, sshexec 등의 타스크를 이용하여 실행하면 된다.

Ant sshexec 타스크를 통해서 원격지의 Tomcat을 start하는 예제

<target name="remote-tomcat-start">
  <sshexec host="${ssh.hostname}"
  port="${ssh.port}"
  username="${ssh.username}"
  passphrase=""
  trust="true"
  keyfile="${ssh.key.file}"
  command="${tomcat.home}/bin/startup" />
  <sleep seconds="${sleep.time}" />
</target>


2. WAS에서 제공하는 Ant 타스크 또는 Maven 플러그인 이용
대부분의 WAS가 어드민화면을 통하지 않고 여러가지 작업을 수행할 수 있는 수단을 제공한다.

Tomcat에서 제공하는 deploy 타스크를 이용하여 war를 deploy하는 Ant 예제

    <target name="install" description="Install application in Tomcat"
        depends="package-web">
        <deploy url="${tomcat.manager.url}"
            username="${tomcat.username}"
            password="${tomcat.password}"
            path="/${webapp.name}"
            war="file:${webapp.dist}/${webapp.war}"/>
    </target>


3. Cargo 이용
Cargo는 WAS 마다 다른 형태의 API를 래핑하여 표준적인 방법으로 WAS를 핸들링할 수 있게 해준다. 그러나 아직 지원하는 WAS가 많지 않다.

Ant에서 cargo 타스트를 이용하여 Tomcat을 start하는 예제

  <cargo containerId="tomcat5x" home="${tomcat.home}" output="${tomcatlog.dir}/output.log"
      log="${tomcatlog.dir}/cargo.log" action="start">
    <configuration home="${tomcatconfig.dir}">
      <property name="cargo.servlet.port" value="8080"/>
      <property name="cargo.logging" value="high"/>
      <deployable type="war" file="${mywarfile}"/>
    </configuration>
  </cargo>
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

배포용 어플리케이션(deployable application)이 생성된 위치와 설치될 위치가 다를 경우 어플리케이션을 어떤 방식으로 전송할까?

1. 로컬 전송
-생성위치와 설치위치가 같은 서버에 있는 경우
-copy, sync 등

2. 리모트 전송
-생성위치와 설치위치가 다른 서버에 존재하는 경우
-ftp, sftp, scp, rsync 등

3. 업로드 전송
-어플리케이션이 배치되는 WAS가 업로드 방식의 배치를 지원하는 경우
-WAS 어드민화면 또는 WAS 제공 API를 통해 업로드

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

리소스설정치환에 관한 글에서 얘기했듯이 개발소스와 빌드결과물은 여러 서버를 거치면서 생성,이동,배치됩니다.

개발자 로컬PC -> (소스저장소) -> 빌드서버(CI서버) -> 개발서버 -> 테스트서버 -> 스테이징서버 -> 운영서버

1차원적으로 일렬로 나열하니까 간단해보이지만 실상 어플리케이션의 이동경로는 2차원적으로 설계됩니다. 마치 수학자 오일러가 최단코스를 찾기 위해 고민한 것처럼 우리는 각각의 서버를 거점으로 하는 배포 코스를 그려가야 합니다.(배포의 위상수학? 배포 아키텍처? 음.. 배포 아키텍처가 맘에 드는군요.)

하지만 너무나 다양하고 특이한 개발환경이 많이 존재하기 때문에 배포코스에 관한 뚜렷한 공식은 없는것 같습니다. 아래에 저의 경험과 동료들의 의견 그리고 온라인상의 자료 등을 종합해서 크게 3가지의 대표적인 코스를 그려보았습니다. 어떤게 베스트 프랙티스다라고 딱부러지게 말씀은 못드리겠군요.
(코스에서 테스트서버는 포함하지 않았습니다. 솔직히 제가 겪었던 모든 프로젝트에서는 개발서버가 테스트서버,스테이징서버의 역할을 모두 겸하고 있었습니다.)

1.빌드서버 중심 코스
-개발서버용, 스테이징서버용, 운영서버용 어플리케이션(빌드산출물)을 모두 빌드서버에서 생성
-어플리케이션은 빌드서버에서 각각의 서버로 전송되어 배포됨


-또는 스테이징 서버에 전송된 어플리케이션을 다시 운영서버로 전송하기도 함



 

2.소스저장소 중심 코스
-개발서버, 스테이징서버, 운영서버가 개별적으로 소스장소로부터 전체 개발소스를 취합하여 각각의 환경에 맞는 어플리케이션을 빌드하여 배포

 

3.혼합된 코스
-개발서버용 어플리케이션은 빌드서버에서 생성하여 개발서버로 전송되어 배포
-스테이징서버용은 스테이징 서버가 소스저장소로부터 전체 개발소스를 취합하여 빌드하고 배포
-스테이징서버에서 빌드된 어플리케이션을 운영서버로 전송

자, 어떤 코스를 타시렵니까?

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

  1. NG 2009.04.14 19:58 신고  댓글주소  수정/삭제  댓글쓰기

    주소만 퍼가겠습니다 ^^

우리가 개발하는 어플리케이션은 최종 사용자에게 서비스되기 전에 여러 장소를 거칩니다.

개발자 로컬PC -> (소스저장소) -> 빌드서버(CI서버) -> 개발서버 -> 테스트서버 -> 스테이징서버 -> 운영서버

불행히도 이렇게 거쳐가는 서버에 따라서 환경/정책이 조금씩 다르기 때문에 우리는 개발소스에 포함된 설정값을 다르게 가져가야 합니다. 예전에는 소스가 서버 사이를 옮겨갈 때마다 수작업으로(vi 에디터로) 설정값을 매번 편집을 해주거나, 설정값을 포함한 파일을 빼고(!) 소스를 옮기기도 했습니다. 여러분은 어떤 방법으로 설정값을 다르게 세팅하셨습나요?

여기, 좀더 우아한 방법이 있습니다.

아, 그보다 먼저 설정값을 포함하는 파일을 보통 뭐라고 부르나요? 설정파일 ? 리소스 파일?  뭐라고 부르든 리소스는 주로 xml, properties 로 작성을 하죠. 레일스에서는 yml인가 이런것도 있더군요. 암튼.

그리고 로컬,개발,운영 등 서버의 환경차이에 따라 리소스 파일을 변환하여 개발소스에 포함된 설정을 달리하는 일을 뭐라고 부르나요? 환경맞춤작업? 리소스변환리소스 설정치환? 이런 거에 대한 공식적인 용어를 들은 바가 없어서 일단은 제목에 리소스 설정치환이라고 임의대로 용어를 지었습니다. 혹시 널리 사용되는 용어를 아시는 분은 알려주세요. 언뜻 profile, portable이란 단어가 떠오르기는 합니다만....

아래는 제가 알고 있는 리소스 설정치환 방법 2가지입니다.(리소스 필터링, 리소스 교체 역시 모두 제가 임의로 만든 용어입니다. 더 나은 용어가 있으면 알려주세요.)

1. 리소스 필터링(filtering)
-빌드시에 설정 파일의 내용을 수정하는 방법
-설정값을 하드코딩하지 않고 정해진 형식의 변수로써 설정. 예를 들어 ${jdbc.password}.
-빌드 실행시 설정 파일 내의 변수는 환경에 적합한 설정값으로 치환됨
-환경별 설정값은 빌드스크립트에 보관됨(메이븐의 경우 프로파일 엘리먼트에)

2. 리소스 교체(replacing)
-빌드시에 기준(로컬) 설정 파일을 다른 파일로 교체하는 방법
-설정 파일을 환경별로 분리하여 관리
  (1)환경별로 별도 디렉토리를 만들어 기준 파일과 동일한 파일명으로 관리.
      예를 들어 /web/WEB-INF/web.xml 이 로컬PC용 설정파일이면,
      개발서버용 web.xml은 /conf/dev/web.xml에 두고 관리.
  (2)기준 설정파일과 동일한 경로에, 다른 파일명으로 관리.
      예를 들어 개발서버용 web.xml을 /web/WEB-INF/web.xml.dev 라는 이름으로 관리.
-빌드실행시 환경에 맞는 파일을 골라서 (1)빌드디렉토리로 이동하거나 (2)파일명을 변경하여 기준 설정 파일을 덮어씀

1번 리소스 필터링의 경우 메이븐에서는 Profile 기능과 Resource Filtering 기능을 이용하면 되고, 2번 리소스 교체의 경우 메이븐에서는 Profile 기능과 Ant의 copy 타스크 조합으로 처리할 수 있습니다. 아래는 메이븐에서 2번을 처리한 예제입니다.

... ...
<plugin>
 <artifactId>maven-antrun-plugin</artifactId>
 <executions>
  <execution>
   <id>resource-changing</id>
   <phase>process-resources</phase>
   <goals><goal>run</goal></goals>
   <configuration> <tasks>
          <copy todir="${project.build.outputDirectory}"
                    overwrite="true" preservelastmodified="true" verbose="true">
               <fileset dir="${project.build.outputDirectory}"
                          includes="**/${conf.replace.pattern}" />
                   <mapper type="glob" from="${conf.replace.pattern}" to="*" />
          </copy>
    </tasks></configuration>
  </execution>
...... .......
..... ........
 <profiles>
  <profile>
   <id>env-dev</id>
   <activation>
    <property><name>env</name><value>dev</value></property>
   </activation>
   <properties>
    <conf.replace.pattern>*.dev</conf.replace.pattern>
   </properties>
  </profile>
  <profile>
   <id>env-prod</id>
   <activation>
    <property><name>env</name><value>prod</value></property>
   </activation>
   <properties>
    <conf.replace.pattern>*.prod</conf.replace.pattern>
   </properties>
  </profile>
 </profiles>
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

통합빌드를 수행하기 위해 전체 소스를 SCM(소스저장소)에서 취합하는 방식은 2가지로 나뉜다.

1. 체크아웃 방식
-매번 새로 전체 소스를 SCM으로부터 체크아웃 받음
-소스의 양이 많을 경우 내려받는 시간이 오래걸림
-항상 깨끗한 상태의 소스를 이용하므로 스테이징/운영 서버에 배포하기 위한 용도에 적합

2. 업데이트 방식
-처음 한번만 전체 소스를 체크아웃 받고 그 이후로는 변경된 소스만 SCM으로부터 업데이트 받음
-변경된 소스만 받아오므로 상대적으로 시간이 덜 걸림
-순전히 빌드오류를 잡아내어 피드백을 주기 위한 빌드에 적합(?)


* 위 2가지는 다시 무조건 최신 소스를 가져오느냐 아니면 특정 버전(태그)의 소스만 가져오느냐로 나뉠 수 있다.
* Hudson에서는 빌드Job 선택 > Configure > Source Code Management > Advanced… > ‘Use Update’ 옵션 체크시 2번의 업데이트 방식이 적용된다.

* 조대협님 블로그 참조함

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

우리는 빌드,테스트,배포를 자동화하기 위해 Ant나 Maven 같은 걸로 작업을 정의한 스크립트를 만듭니다.
스크립트가 완성되면 이제 스크립트를 실행할 일만 남았습니다. 그럼 이 스크립트를 언제, 어떻게 실행할까요?
자동화 프로세스를 런치시키는 3가지 유형이 있습니다

1. 예약 자동화(scheduled)
-일정 주기마다 자동으로 작업 실행
-개발자들의 스케줄관리에 유리하며 대규모 빌드에 적당
-오랜 시간 소스에 변경이 없을 경우 불필요한 빌드 발생

2. 유발 자동화(triggered)
-이벤트 발생시 자동으로 실행
-이벤트 감지를 위한 폴링 간격이 짧고 커밋이 자주 발생하는 경우 빌드적체 유발 가능성 있음

3. 지시 자동화(commanded)
-커맨드라인에서 빌드스크립트를 직접 실행하거나 빌드서버에서 빌드버튼을 클릭하는 등의 방법으로 사용자가 수동으로 작업을 실행
-비정기적인 빌드/배포를 수행해야 할 경우 사용


* 조대협님 블로그와 실용주의 자동화 책 참고

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

메이븐다운(?) 방법으로 웹어플리케이션을 원격서버로 전송하기 위해서 이것저것 찾아보다가 알게 된 거 정리해본다.

1. deploy:deploy
packaging한 artifacts를 리모트의 메이븐저장소로 전송한다. 원격 저장소는  <distributionManagement>엘리먼트의 <repository>에 설정한다. 임의의 파일을 전송하는 건 불가능하다. package 가 war 이고 저장소 경로가 ftp://repository.mycompany.com/repository 라면, 실제로 war 파일은 저장소 layout에 맞춰서 ~/repository/groupId/artifactId/version 디렉토리에 전송된다.

2. site:deploy
 site phase에서 생성된 사이트를 리모트 (웹)서버로 전송한다. 리모트 서버정보는<distributionManagement>엘리먼트의 <site>에 설정한다. inputDirectory 옵션을 통해 target/site 디렉토리가 아닌 다른 디렉토리의 파일들을 전송할 수 있다. 그러나 <site>는 하나만 설정가능하기 때문에 2군데 이상의 서버로 파일들을 전송하는 건 불가능하다.

3. cargo 플러그인
일부 컨테이너에 대해 remote container에 expanded war(war 파일의 압축을 풀어놓은 것. exploded war)를 배포할 수 있다고 cargo 웹사이트에 나온다. 하지만 과연 이게 가능할지는 의구심이 든다. 실제로 작동여부를 테스트해봐야 할 듯하지만, 아마도 war 파일만 원격배포가 가능하지 않을까 싶다. 아직 최신 버전의 상용 WAS에 대한 지원이 미비하다.

4. myfaces의 wagon-maven 플러그인 
임의의 디렉토리 내의 파일들을 원격 서버로 전송한다. 임의의 디렉토리를 2군데 이상의 원격서버에 전송할 수 있다. 실제 프로젝트에서 개발서버 배포를 이 플러그인으로 처리했다. target/webapp 디렉토리의 파일들은 WAS서버로 전송하고, target/htdocs 디렉토리의 파일들은 WEB서버로 전송하도록 말이다. 
아쉽다면, 지정된 디렉토리 내의 모든 파일들을 전송하며 그 디렉토리의 몇몇 파일들만 골라서 전송할 수는 없다는 것이다. 즉 fileset 개념이 없다(사실 이건 이 플러그인의 문제라기 보다 이 플러그인이 이용하는 메이븐 wagon의 문제이다. 몇몇파일만 골라내는 건 ant copy를 써서 target/htdocs처럼 별도의 디렉토리에 전송할 대상만 따로 모아놓으면 해결할 수 있다).
이 플러그인의 장점이라면 디렉토리를 압축하여 전송후 리모트에서 압축을 해제하는 방식의 wagon 기능을 이용하기 때문에 전송할 파일이 많은 경우에 ant의 ftp/scp 타스크를 이용하는 것보다 전송시간이 현저히 줄어든다는 거.
아래는 실제 pom.xml의 일부인데 별거 아닌게 내용이 긴거 같아 맘이 편하지만은 않다.

   <plugin>
    <groupId>org.apache.myfaces.buildtools</groupId>
    <artifactId>myfaces-wagon-plugin</artifactId>
    <version>1.0.0</version>
    <executions>
     <!-- config 배포 작업 -->
     <execution>
      <id>deploy-conf</id>
      <phase>pre-integration-test</phase>
      <goals>
       <goal>deploy</goal>
      </goals>
      <configuration>
       <id>deploy-config</id>
       <url>
        scp://${wasserver.username}:${wasserver.password}@${wasserver.ip}:${wasserver.config.dir}
       </url>
       <inputDirectory>${config.home.dir}</inputDirectory>
      </configuration>
     </execution>
     <!-- 웹어플리케이션 배포 작업 -->
     <execution>
      <id>deploy-web</id>
      <phase>pre-integration-test</phase>
      <goals>
       <goal>deploy</goal>
      </goals>
      <configuration>
       <id>deploy-web</id>
       <url>
        scp://${wasserver.username}:${wasserver.password}@${wasserver.ip}:${wasserver.web.dir}
       </url>
       <inputDirectory>${web.output.exploded.dir}</inputDirectory>
      </configuration>
     </execution>
     <!-- 웹파일 배포 작업 -->
     <execution>
      <id>deploy-html</id>
      <phase>pre-integration-test</phase>
      <goals>
       <goal>deploy</goal>
      </goals>
      <configuration>
       <id>deploy-html</id>
       <url>
        scp://${webserver.username}:${webserver.password}@${webserver.ip}:${webserver.htdocs.dir}
       </url>
       <inputDirectory>${web.output.html.dir}</inputDirectory>
      </configuration>
     </execution>
    </executions>
   </plugin>


현재까지 패턴을 적용하여 임의의 파일/디렉토리를 내 맘대로 전송할 수 있는 방법은 메이븐에서는 antrun을 이용하는 방법밖에 없는 듯싶다. maven의 wagon api와 file management api 이용하여 직접 플러그인을 만드는 것도 재밌을거 같다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

Hudson을 이용한다면 scm 저장소로부터 (메이븐 타입의) 프로젝트를 체크아웃/업데이트 받아서 특정 goal/phase를 실행하는 일은 Hudson의 몫이다. 그러니까 보통은 메이븐타입 프로젝트의 pom.xml로는 프로젝트 자체를 scm에서 체크아웃/업데이트 받는 일은 안한다.

하지만 허드슨을 이용하지 않고 허드슨의 일을 대신해서 프로젝트 소스를 scm으로부터 받아와서 빌드/배포 goal을 실행해야 하는 상황이라면 어떻게 해야할까?

scm에서 체크아웃/업데이트하고 프로젝트 안의 pom.xml에 대해 goal을 실행하는 쉘스크립트를 짜는 것도 한가지 방법일 수 있지만 이러한 작업을 하는 또다른 pom.xml을 만드는 것도 가능하다. maven-scm-plugin 플러그인을 이용하면 된다.

 <scm>
  <connection>scm:svn:https://127.0.0.1:8443/svn/XXX</connection>
 </scm>
 ... ...
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-scm-plugin</artifactId>
    <version>1.1</version>
    <configuration>
     <connectionType>connection</connectionType>
     <scmVersionType>tag</scmVersionType>
     <scmVersion>${scm.version}</scmVersion>
     <checkoutDirectory>workspace</checkoutDirectory>
     <workingDirectory>workspace</workingDirectory>
     <skipCheckoutIfExists>true</skipCheckoutIfExists>
     <username>user</username>
     <password>user</password>
     <goals>clean test war:inplace</goals>
     <profiles>env-staging</profiles>
    </configuration>
 </plugin>

위처럼 pom.xml을 만들어 놓고 scm:bootstrap 을 실행하면 메이븐은 checkoutDirectory로 지정된 workspace에 프로젝트 소스를 체크아웃 받는다. 체크아웃 받은 뒤에 프로젝트 root의 pom.xml에 대해서 <goals/>에 나열된 goal을 실행해준다.

mvn -Dscm.version=RB123 scm:bootstrap
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요

단위 테스트케이스 소스가 없는 프로젝트를 메이븐으로 빌드할 때 test phase(단계)는 불필요한 것이 명백하다.

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
      <skip>true</skip>
    </configuration>
  </plugin>

또는 maven.test.skip 프로퍼티 값을 true로 설정하면 test phase에 바인딩된 surefire:test 골의 실행을 skip할 수 있다.

메이븐에서 deploy는 개발 결과 아티팩트(jar,war,....)를 리모트의 메이븐 저장소에 등록하는 것을 의미한다.
공통라이브러리나 오픈소스 라이브러리를 개발한다면 이게 deploy의 의미에 합당할지도 모르겠다.
그러나 아마도 대부분의 JEE 기반 웹시스템 개발 프로젝트에서 deploy는 웹어플리케이션을 WAS에 배치하는 것을 의미한다. test 단계를 skip한 것처럼 deploy 단계에 기본으로 바인딩된 deploy:deploy 골도 skip할 수 있다.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-deploy-plugin</artifactId>
    <configuration>
     <skip>true</skip>
    </configuration>
</plugin>

이렇게 deploy:deploy를 skip해놓고 anttrun 등으로 WAS에 배포본을 올리는 작업을 deploy phase에 바인딩하면 deploy가 진정 내가 원하는 deploy로 바뀌게 된다.

한가지 또 아쉬운게 있다면 deploy 단계 이전에 실행되는 install 단계도 skip할 수 있으면 좋겠는데 안타깝게도 install:install 모조에는 skip 옵션이 없다. 젠장.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 에코지오

댓글을 달아 주세요



티스토리 툴바