Whiteship's Note

[메이븐 프로파일] 운영시 배포할 설정 파일과 개발시 배포할 설정 파일 샤샥

Build/Maven : 2010.08.19 11:02


운영시에 사용할 설정과 배포할 때 사용할 설정이 다르다. 어떻게 해야할까요? 예전에도 이 고민을 한적이 있었는데 마침 윤석군이랑 봄싹에 구글 캐린더 연동 서비스를 구현했는데 이런 상황이 또 발생했습니다.

개발 할때 사용할 구글 캘린더와 실제 운영시 사용할 구글 캘린더는 달라야 합니다. 혹은 개발 할 때는 캘린더 서비스를 무시할 수도 있어야 하는데 이 경우는 일단 제외하고 우선은 설정을 환경에 따라 구분해야 한다는 것에 초점을 맞췄습니다.

설정 정보가 구체적으로 어떻냐에 따라 방법도 달라질 수 있는데 이전에 봄싹에 적용한 방법은 다음과 같습.. 흠... 아닙니다.. 귀찮군요. 그냥 생략하고 메이븐 프로파일이나 정리하겠습니다. 어쨋든 이전에 사용한 방법은 메이븐을 사용하지 않은 방법이었는데.. 그게 다 장,단점이 있습니다.

이번에 사용할 방법은 메이븐 프로파일을 사용합니다.


일단 폴더를 저런식으로 구분했는데 뭐 저런 구조야 맘대로 정하시면 되겠죠. 중요한건 개발시 사용할 설정파일이 담겨있는 폴더와 운영시 사용할 설정파일이 담겨있는 폴더를 구분했다는 것 정도..

이제 pom.xml에서 <build> 부분에 개발시 사용할 설정이 담겨있는 폴더를 소스 리소스 폴더로 인식하도록 설정해 줍니다.

    <build>
        ...
        <resources>
           ...
            <resource>
                <directory>${project.basedir}/resources/development</directory>
                <excludes>
                    <exclude>**/*.java</exclude>
                </excludes>
            </resource>
        </resources>
        ...
</build>

이렇게 말이죠. 대충 엘리먼트 이름만 봐도 아실테니 설명은 패스.

다음은 운영 환경에서는 저 폴더가 아니라 다른 폴더를 리소스 폴더로 등록해줘야 합니다. 따라서 pom.xml에 프로파일을 추가해 주고 그 안에서 재정의할 설정을 넣어주면 됩니다.

    <profiles>
        <profile>
            <id>production</id>
            <build>
                <resources>
                     ...
                    <resource>
                        <directory>${project.basedir}/resources/production</directory>
                        <excludes>
                            <exclude>**/*.java</exclude>
                        </excludes>
                    </resource>
                </resources>
            </build>
        </profile>
    </profiles>

자 요렇게 해주면 더 프로파일을 가지고 빌드 할때는 운영시 사용할 설정 파일이 담겨있는 폴더를 소스 리소스 폴더로 인식해서 그 안에 있는 .java 파일을 제외한 모든 파일을 배포해줍니다.

마지막으로.. 그럼 저 프로파일을 가지고 빌드 하는 방법은?

mvn clean install -Pproduction -X

요런식으로 mvn을 실행할 때 -P프로파일명 을 주시면 됩니다. 저기서 사용한 -X는 디버깅용 출력에 사용하는 옵션이구요. 나머진 아시겠죠.

좋은점
- 빌드 담당자가 아닌 개발자들은 이전과 동일하게 계속 개발하면 된다.
- 저 설정들을 버전관리에 포함시킬 수 있다.
- 운영 서버에서 빌드 스크립트 설정만 한번 바꿔주면 된다. 그 이후로는 간편하다.

불편한점
- 빌드 담당자(SI에 이런 롤이 있는지 몰겠지만)가 메이븐을 쬐끔 알아야 한다.

사실 위에 적은 좋은점 불편한점은 위에서 생략하고 넘어간 이전 방식과 비교를 했을 때 더 분명한데.. 일단은 그 방법을 적기가 다소 귀찮고 본 글의 주제에도 맞지 않으니 그냥 생략합니다. 대충 세가지 방법을 고민해 뒀는데 나중에 정 한가하고 정 심심해지면 정리해봐야겠습니다.
저작자 표시
신고
top


토비의 스프링 3 북 오픈 기념샷

모하니?/Reading : 2010.08.17 21:31



음하핫.. 드디어 받았군요. 제가 마지막에 쿨하지 못해서 넣게된 추천사까지 볼 수 있고 알파리딩 때는 보지 못했던 토비님의 감사의 인사도 볼 수 있어서 감회가 새로웠습니다.  길게 쓰고 싶지만 운동갈 시간이라.. 짧게 남겨도 이해해 주세요.

책에는 이클립스 기준으로 소스코드 실행하는 방법이 있지만 전 인텔리J로 돌리렵니다. 메이븐 프로젝트도 아니니까 이클립스로 돌려도 무난하겠지만... 메이븐 프로젝트는 인텔리J가 백배 좋습니다.
저작자 표시
신고
top


구글 Buzz API와 OAuth 관련 링크

Good Tools : 2010.08.14 22:42


구글 버즈
http://code.google.com/intl/ko-KR/apis/buzz/
http://code.google.com/intl/ko-KR/apis/buzz/docs/libraries.html
http://code.google.com/intl/ko-KR/apis/buzz/v1/using_rest.html#create-activity

OAuth
http://code.google.com/intl/ko-KR/apis/accounts/docs/OAuth_ref.html#GetAuth
http://code.google.com/intl/ko-KR/apis/accounts/docs/OAuth.html
http://googlecodesamples.com/oauth_playground/index.php

OAuth 토큰이 여러개인게 아니라 토큰 종류가 여러 가지인거 였구만... 어려워 어려워 @_@;;
저작자 표시
신고
top

TAG OAuth

이웃나라 (부동산) 이야기

모하니?/Thinking : 2010.08.13 17:27






이제 한국 차례.. 
저작자 표시
신고
top


템플릿-콜백 패턴으로 Try-Catch-Finally 블럭을 무찌르자.

모하니?/Coding : 2010.08.11 18:40


어제부터 계속 정리하고 싶었는데 어젠 이상하게 시간을 쏟아 버리는 바람에.. 이제 정리한다. 자세한 내용은 토비의 스프링 3에 나오는데 이번에 구글 캘린더 API 코딩하다가 써먹을 기회가 와서.. 적용해 봤다. 문제는 내 강의를 들었던 학생은 그걸 하지 못했다는게 아쉽다. 어디 한술에 배부르랴.. 그래도 내가 코딩한 걸 보고 그게 그건지 알아차렸으니.. 그걸로 만족한다.


구글 캘린더 API를 사용하려면 위에 있는 문서만 보면 된다. 친절하게 안내해주고 있어서 쓰기 편하다. 그런데 문제는 예외처리다. 


    public List<CalendarEntry> getMyCalendarList(){
        URL feedUrl = makeUrl(OWN_CALENDAR_URL);
        try {
            CalendarFeed resultFeed = calendarService.getFeed(feedUrl, CalendarFeed.class);
            return resultFeed.getEntries();
        } catch (IOException e) {
            throw new RuntimeException(e);
        } catch (ServiceException e) {
            throw new RuntimeException(e);
        }
    }


저기서 호출하고 있는 calendarService는 구글에서 제공해주는 API로 IOException과 ServiceException을 던지는 메서드들을 왕창 가지고 있다. 또 그녀석들을 자주 쓰게 된다.

따라서 어떤 호출을 하더라도 위와같은 예외 처리 코드가 생기기 마련이다. 이걸 어떻게 하면 좋을까? 스프링 개발자라면 이런 코드를 스프링과 잘 어울리는 형태로 처리할 수 있어야 한다.

어떻게 할것인가? 어떻게 하면 저 지져분한 Try-Catch(-Filnally) 문에서 벗어날 것인가? 한번 도전 해보자...

결과는..

public List<CalendarEntry> getMyCalendarList(){
        return calendarServiceTemplate(new CalendarServiceCallBack<List<CalendarEntry>> () {
            public List<CalendarEntry> queryForObject() throws IOException, ServiceException {
                return calendarService.getFeed(makeUrl(OWN_CALENDAR_URL), CalendarFeed.class).getEntries();
            }
        });
    }

이것과 비슷한 형태가 될 것이다. 물론 중요한건 결과가 아니라 저렇게 바꾸는 프로세스.. 그걸 이해하고 자신의 스킬로 만드는 것이 중요하겠다. 토비의 스프링 3에서 아주 잘 배울 수 있으니 꼭.. 3장 템플릿을 정독하도록 하자. 연습하고. 또 연습하고. 또 연습하고. try-catch 문이 반복해서 나올 떄 마다 적용해 보도록 하자.

저작자 표시
신고
top




: 1 : 2 : 3 : 4 : 5 : ··· : 528 :





티스토리 툴바