블로그 이미지
Max.

calendar

        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

Notice

2007.12.07 17:36 이전글(~2009)

그동안 생각만 하다가 시간을 내어 Maven을 이용한 자동화를 조금씩 진행하기로 한다.

[개요]
Maven을이용하여 라이브러리를 관리하고, 빌드를 자동화 하기 위한 데모프로젝트를 만들어 놓는것에 목적을 둔다.

예제는 다음과 같이 3개의 프로젝트로 나뉜다.
1. core
2. biz
3. web
core는 공통으로 적용될 패키지로 모든 프로젝트의 공통된 패키지를 포함하고 있다.
biz는 각 프로젝트마다 비지니스에 맞는 로직을 구현하는 패키지이다.
web은  target 프로젝트가 웹어플리케이션 일때 사용하는 프로젝트이다.
이들을 다음과 같이 예제 프로젝트로 만들어 본다.
1. max_core
2. max_article,max_member,max_rms .... 등등...
3. max_site
이들 프로젝트의 의존성은  max_core < max_article... < max_site 으로 되어 진다.

[진행순서]
1. Maven Project를 core 프로젝트로 생성, 개발하여 Maven Local Repository에 등록한다.
2. Maven Project를 article 프로젝트로 생성하고, core 프로젝트를  dependency로 추가한다.
   개발완료후 역시 Maven Local Repository에 등록한다. 
3. Maven Project를 site프로젝트로 생성하고, core, article 프로젝트를  dependency로 추가한다.
  

사용자 삽입 이미지

  추가시 아래와 같이 pom.xml에 dependency가 추가 된다.

    <dependency>
      <groupId>com.max.article</groupId>
      <artifactId>article</artifactId>
      <version>1.0.0-SNAPSHOT</version>
    </dependency>
    <dependency>
      <groupId>com.max.core</groupId>
      <artifactId>core</artifactId>
      <version>1.0.0-SNAPSHOT</version>
    </dependency>



4. 최종적으로 site 프로젝트를 install 하고, 웹서버에서 확인한다.
    프로젝트 목록은 다음과 같다.

사용자 삽입 이미지


여기까지 간단히 Maven을 이용해서 라이브러리 관리정도만 테스트 해봤다.
그런데 Spring dependency 등록이 왜이리 복잡한지 모르겠다. ㅡㅡ;;
( 정리좀 되어야 할 필요성이 있다. )
신고

'이전글(~2009)' 카테고리의 다른 글

Openseed - 왜 질문이 없을까?  (2) 2007.12.16
Openseed 소비자 고발....  (4) 2007.12.15
[DDP] Maven을 이용한 Build 자동화 1단계  (2) 2007.12.07
10년 후의 나를 만난다면?  (0) 2007.11.29
꿈은 이루어진다.  (0) 2007.11.23
[서적] 고스트 컴퍼니  (0) 2007.11.16
posted by Max.
TAG 자동화
2007.11.12 10:20 이전글(~2009)
최근 찬욱님의 ROO Architecture review 라는 글을 보고 Demo에 적용해 보기로 했다. 해당글에서 눈에 띄는 것은 두가지가 있었다.

첫째 Repository에서 Finder의 분리이다. 어쩌면 이 당연한 현상을 왜 생각하지 못했는지 나 자신이 얼마나 생각없이 개발하는지 알수 있는 대목이다. 실무 개발시 주도메인은 상당히 많은 finder를 Repository에 만들수 밖에 없다. 그만큼 각양각색의 조건들이 포함된 Select가 많이 있기 때문에 그렇다. 이 개념은 당장 도입해도 좋을 개념이다. 사실 최근 프로젝트에서 엄청나게 많은 finder를 넣은 Repository를 만들었다. Repository라고 부르기에도 민망할정도로....

둘째는 DTO assembler라는 것이다. 이것은 DO를 DTO로 값을 복사해주는 역할을 한다. 이것 자체의 구현 역시 어렵지 않다. 그러나 이것이 주는 의미는 ROO에서 의미하는 바가 크다. 보통 우리가 말하는 Service Layer 에서 DO를 쓴다. 이것은 DTO에서 내부적(?)으로 가져다 쓰는 구조 이다. 즉 모든(3Tier)계층에서 DO를 쓴다. 그러나 ROO에서는 DO를 쓰지 않는다. 엄격히 Domain Layer 아래로 격리시킨다. 따라서 Biz Layer(이것이 다른이름으로 불리던 어쩌던 간에 비지니스로직을 수행하는층을말함)에서는 DTO 를 쓴다. 핵심은 여기서 나온다. 이렇게 DTO를 씀으로써 번거러움이 가중되고, 더 세분화 함(Finder등)으로써 늘어나는 클래스를 어떻게 할것인가?
ROO에서는 이런것들을 Code Generation 으로 해결한다. Finder를 수동(?)으로 구현하거나 DTO를 Dozer를 써서 이것을 수동(?)으로 구현하는것은 기존에 했던 방법보다 손이 많이 가며 그리큰 매력을 느끼기 힘들다.

그러나 이들을 자동화해 버린다면? DTO, Finder,XML 심지여 TestCase까지 자동으로 생성해 준다면? 멋지다. 이것이 ROO의 가장큰 특징이 아닐까 한다. CG(Code Generation)에 대해서는 아직 아는바가 없다. Toby님 글에 '아주 정교하게 구현되어 있다'라는 언급만 나왔을뿐 뭘 어떻게 하는지 알기 힘들다. ROO가 언제 공개될지, 아니면 영원히 오픈 안될수도 있지만, 지속적으로 주시해볼 필요가 있다.

일단 두가지 특징을 수동(?)으로 만들어 Demo에 적용해 보았다. 그냥 그저 그렇다 ㅡㅡ;;
역시 자동화가 Key 인것 같다. Maven과 eclipse에 대한 기능을 잘 익혀두어야 한다. ROO가 나올때를 대비해서 말이다.

(그나 저나 앞으로 ROO에 대한 소식을 들을만한곳이 없다. 어디서 소식을 들어야 할지...Toby님도 잠적하시고...-,.-a )
신고
posted by Max.
2007.10.15 09:01 이전글(~2009)
이번엔 왜 Ant 조차도 쓰지 않았는지 모르겠다.
그거라도 붙여야 겠다. 시간이 너무 많이 소요된다.ㅡㅜ

빌드 자동화 하기 위해서는 여러가지 툴이 있다. 각각 조사하고 어떤것이 나에게 맞는지 알아봐야 겠다.
오래전 Maven를 좀 다듬어 볼려다 그만둔적이 있는데 그쪽도 뒤져봐야 겠다.
그외에도 IDE에서도 지원하거나, 유틸에서도 지원되는게 있다.
가장 좋은것을 취하자.

빌드할 파일이 복잡해 질수록,
테스트할 장비가 많아 질수록 빌드시간이 지속적으로 늘어나는걸 몸소 느꼈다.
이 시간을 줄여보자.

신고
posted by Max.
prev 1 next

티스토리 툴바