달력

102019  이전 다음

  •  
  •  
  • 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
  • 31
  •  
  •  
세상에는 두 종류의 사람 얘기하면서 Hello World를 아는 개발자와 모르는 일반인으로 구분하고는 했습니다. 유사한 경우가 소스라고 했을 때 소스 코드가 먼저 떠오르면 개발자고 토마토 소스처럼 요리용 소스가 생각나면 일반인으로 구분할 수도 있을 것 같습니다.


오픈 소스에 관한 글이 하나 떠서 소개합니다.
http://www.ibm.com/developerworks/kr/opensource/newto/index.html

오픈소스를 가져다가 활용하기 때문에 요즘 프로그래밍 기술에 가속도가 붙어있습니다. 예전처럼 코드를 꽁꽁 숨기려는 노력보다는 바벨탑을 쌓아가듯이 코드를 공유하는 문화가 개발자들 사이에서 유행처럼 번지고 있습니다.

좋은 의도에서 소스를 오픈했는데, 아무리 비용이 들지 않는다 하여도 가져다 쓰는 예의와 법이 있습니다. 그것에 대해서 잘 얘기해주고 있는 글입니다.

Posted by 케누 kenu허광남

댓글을 달아 주세요

평소에 들여다 보았으면 좋았을텐데 하는 아쉬움이 남습니다. CVS에서 SVN으로 모든 프로젝트가 이전하는 것은 몇 년 전에 알고 있었는데, 오늘 책을 쓰다가 아파치 소프트웨어 재단(Apache Software Foundation)의 저장소를 보고 놀랬습니다. 백 개가 넘는 모든 프로젝트들이 한 저장소에서 관리되고 있습니다. 각 프로젝트별로 trunk, branches, tags 를 각기 관리하고 있습니다.
리비전 번호에 신경을 쓰지 않아도 될 듯 합니다. 숫자는 다르다는 것만 표시하면 될 뿐, 통합 저장소로 인한 리비전 번호의 증가에 괜히 신경쓰지 않아도 될 것입니다.


톰캣 프로젝트 내에도 여러 서브프로젝트들이 존재합니다. 저장소 구성은 다음과 같습니다.

괜히 은근슬쩍 2002년이 떠오르는군요. 자카르타서울 프로젝트. 지금은 동면상태이죠.
http://www.apache-korea.org

Posted by 케누 kenu허광남

댓글을 달아 주세요

  1. 토비  댓글주소 수정/삭제 댓글쓰기 2008.12.18 14:30

    별로 좋아보이지만은 않습니다. 일단 커뮤니케이션 하기 힘들죠.
    "리비전 넘버 칠십일만팔천오백육십사번을 참조하셈"
    "머.. 칠십...만 오백어쩌고..? 다시 불러주셈"

    좀 지나면 백만 넘어가겠군요. 숨도 같이 넘어가겠습니다. 리비전넘버치다 오타도 많이 나고.. @@

  2. kingori  댓글주소 수정/삭제 댓글쓰기 2008.12.18 15:27

    정말, 번호가 후덜덜하군요!

    그나저나, 저게 정말 좋은 구조인지 아니면 눈물을 머금고 어쩔수없이 선택하다보니 나온 구조인지에 대한 내용을 찾아볼 수 있다면 더 좋겠네요.


앞서 오픈소스인 httpunit을 통해서 프로젝트 소스 구성을 살펴봤습니다. 빌드스크립트인 build.xml를 통해서 프로젝트 소스를 가공하는 방법을 알 수 있습니다. 프로젝트의 작업 지시서와 같은 역할을 하는 것이죠.

이클립스의 아웃라인뷰에 나오는 타겟 목록입니다.
소스를 보면 <project ... default="jar"> 내용을 확인 할 수 있습니다. 기본 프로젝트 타겟은 jar 입니다.

그 외에도 수많은 작업그룹이 보입니다. 각각의 내용을 확인해 봐야 정확한 작업 내용을 알 수 있겠지만 여기서는 jar 를 중심으로 살펴보겠습니다.

<!--  ===================================================================  -->
<!--  Creates the jar archive                                              -->
<!--  ===================================================================  -->
<target name="jar" depends="compile" description="create the jar file">
    <mkdir dir="${lib.dir}" />
    <echo file="${build.dir}/info.txt">Manifest-Version: 1.0
Sealed: false
HttpUnit-Version: ${version}
Build-Date: ${TODAY}
Build-Time: ${TSTAMP}
</echo>
    <jar jarfile="${lib.dir}/${name}.jar" manifest="${build.dir}/info.txt">
        <fileset dir="${build.classes}" includes="com/**"/>
        <fileset dir="META-INF" includes="*.dtd"/>
    </jar>
</target>

주석의 모양도 참고 대상입니다.  타겟의 depends속성을 보면 compile 타겟이 먼저 수행되는 것을 알 수 있습니다. <jar> 태스크를 보면 JAR 파일명이 지정되어 있습니다. 컴파일된 클래스 디렉토리를 기준으로 com 패키지 아래 있는 것이 포함되고, META-INF 디렉토리에 있는 *.dtd 파일들도 jar 파일에 들어갑니다.

compile 타겟을 확인하면 소스의 위치는 확실히 알 수 있겠죠.

<!--  ===================================================================  -->
<!--  Compiles the source code                                             -->
<!--  ===================================================================  -->
<target name="compile-for-java2" depends="prepare,check_for_optional_packages" if="dom3.absent">
    <mkdir dir="${build.classes}" />
    <javac srcdir="src-1.4" destdir="${build.classes}"/>
</target>
<target name="compile" depends="prepare,check_for_optional_packages,compile-for-java2">
    <mkdir dir="${build.classes}" />
    <javac srcdir="${src.dir}" destdir="${build.classes}"
           debug="${debug}" deprecation="${deprecation}" optimize="${optimize}">
        <classpath refid="base.classpath" />
        <exclude name="**/JTidyHTMLParser.java" unless="jtidy.present" />
        <exclude name="**/ScriptFilter.java" unless="nekoHTML.present" />
        <exclude name="**/NekoHTMLParser.java" unless="nekoHTML.present" />
        <exclude name="**/NekoDOMParser.java" unless="nekoHTML.present" />
        <exclude name="**/servletunit/*" unless="jsdk.present" />
        <exclude name="**/JUnitServlet.java" unless="junit.present" />
        <exclude name="**/javascript/*" unless="rhino.present" />
    </javac>
</target>
 
클래스의 빌드 디렉토리를 만든 후에 파일들을 컴파일 합니다. 컴파일 시 관련 jar의 유무에 따라 컴파일에서 제외시키기도 합니다. 여러가지 jar파일들을 사용하는 것을 알 수 있습니다. jtidy, nekoHTML, jsdk, junit, rhino. 대부분 자바스크립트 파서나 실행에 관련된 것들이죠.

httpunit 한 프로젝트에서도 건질 것들이 굉장히 많은 듯 합니다.

Posted by 케누 kenu허광남

댓글을 달아 주세요


오픈소스의 좋은 점 중 하나는 제품 개발과정을 볼 수 있다는 것입니다. 소스 프로젝트의 구성을 볼 수 있고, ant나 maven 등의 빌드 구성과 TestCase를 어떻게 만들었는지 확인이 가능합니다.

httpunit이라는 소스포지의 오픈소스를 통해서 그 구성을 살펴보겠습니다.
http://httpunit.sourceforge.net 에 접속합니다.

왼쪽 메뉴 중 Download를 클릭해서 다운로드 받습니다.

파일을 이클립스에서 import 해보겠습니다. httpunit 이라는 이름으로 자바프로젝트를 하나 만듭니다.

프로젝트를 선택하고 컨텍스트 메뉴에서 Import... 를 선택합니다.

ar 이라고 필터란에 입력하면 Archive File 메뉴가 보입니다.

앞서 다운로드 받은 httpunit-1.7.zip 파일을 선택합니다.

폴더 통째로 import를 해왔습니다.

디렉토리의 구성을 잘 살펴볼 필요가 있습니다.
doc : 아마도 html 이나 프로젝트 관련 문서들 원본 등이 있을 것입니다.
examples : httpunit을 이용하는 예제들 디렉토리
jars : 프로젝트 관련 jar 파일 디렉토리
lib : httpunit.jar 산출물 생성 디렉토리
META-INF : jar 압축시 기본 생성 디렉토리
src : java 소스 디렉토리
test : 테스트케이스 디렉토리
build.xml : 프로젝트 빌드를 위한 ant 빌드 스크립트


이러한 구성을 참고로 자신이 진행하는 프로젝트의 소스 및 파일들을 관리하는 것도 좋을 것입니다.

Posted by 케누 kenu허광남

댓글을 달아 주세요

  1. 권남  댓글주소 수정/삭제 댓글쓰기 2008.10.26 00:07

    저 같은 경우에는 요즘 Maven을 사용하면서 Maven이 제공하는 기본 디렉토리 구조를 그대로 사용하는 버릇이 생겨버렸네요.
    디렉토리 깊이가 지나치게 깊다는 단점이 있지만, IDE를 사용하면 그 단점이 크게 다가오지는 않기 때문에 뭐 그닥 나쁘지는 않은 것 같습니다.

  2. 나그네  댓글주소 수정/삭제 댓글쓰기 2008.10.27 12:39

    이 포스트가 좋아서 담아갑니다.

버그 찾아드립니다.

java 2008.09.30 22:26

http://findbugs.sourceforge.net 메릴랜드(Maryland) 대학에서 공개한 도구입니다. 자바의 버그패턴에 맞춰서 자바 소스코드를 컴파일된 바이트코드로 정적 분석한 후에 어느 부분이 문제가 되는지 자동 리포팅해줍니다.
누군가 내 코드를 검사한다는 것이 개발자에게는 탐탁치 않지만 임신진단시약처럼 자가테스트를 한다면 다른 얘기가 되겠죠. 남에게 보이기 전에 자신의 코드를 깔끔하게 만들 수 있으니까요.

그러나 바쁜 현대인을 위해서 지속적인 통합툴에서 대신해 주기도 합니다. (참고: http://www.ibm.com/developerworks/kr/library/tutorial/j-cq11207/section11.html )

이클립스 플러그인도 있습니다. findbugs의 수많은 옵션을 알지 못해도 간단하게 마우스 버튼으로 조작해서 사용할 수 있습니다. (참고: http://findbugs.sourceforge.net/manual/eclipse.html )

QA역할을 하는 동료가 짐을 덜었다고 좋아하던데, 자기가 짠 코드의 결함 검사는 스스로하는 것이 바람직할 듯 합니다. 경기 후 어지러진 관중석을 보는 듯한 코드는 으윽 이니까요.
Posted by 케누 kenu허광남

댓글을 달아 주세요

  1. Outsider  댓글주소 수정/삭제 댓글쓰기 2008.10.01 09:14

    좋은 정보 감사합니다. 집에가서 좀 만져봐야겠네요.. ㅎㅎㅎㅎ

  2. 수아기  댓글주소 수정/삭제 댓글쓰기 2008.10.01 09:17

    자동화된 도구가 많은것을 도와줄수는 있지만 결국은 또 사람의 손길이 다아야겠죠. 그래도 저런걸 만들어내는 분들 참 대단해요.^^

  3. 조병장  댓글주소 수정/삭제 댓글쓰기 2008.10.01 09:35 신고

    좋은 정보 감사합니다. 잘쓰겠습니다.^-^

요즘 개발할 때 소스코드 보험은 필수입니다. CVS나 Subversion 같은 것 말이죠.
xcode에도 이 기능을 지원하네요.
메뉴에 SCM을 선택합니다. Source Code Management 의 약자일까요?
사용자 삽입 이미지

Xcode Preferences 창이 뜨면서 SCM 메뉴가 선택되어있습니다. 좌측 하단의 +를 클릭합니다.
사용자 삽입 이미지

okjsp 사이트 소스는 공개되어있습니다. anoncvs 계정과 anoncvs 패스워드로 접속가능합니다.
사용자 삽입 이미지

등록을 마치고 메뉴에서 Repositories 를 선택하면 접속이 됩니다.
사용자 삽입 이미지


좋군요.
Posted by 케누 kenu허광남

댓글을 달아 주세요

  1. Eminency  댓글주소 수정/삭제 댓글쓰기 2008.09.04 18:44

    SCM은 Software configuration management의 약자입니다(흔히 형상관리라고 하더군요).
    CVS, Subversion 같은 것들이 하는 버전 관리를 거창하게 부르는거죠 -_-;;

  2. 달룟  댓글주소 수정/삭제 댓글쓰기 2008.09.04 19:49

    저는 그냥 Snapshot 기능으로 만족하고 있는데요. SCM을 쓰는 것이 좋을까요?

  3. groovy  댓글주소 수정/삭제 댓글쓰기 2008.09.05 12:54 신고

    Source Control Management로 알고있었는데 Eminecy님덕분에 배웠습니다. :0

    여전히 부지런하십니다. kenu 엉아.

  4. Kenny  댓글주소 수정/삭제 댓글쓰기 2008.09.08 15:12

    뭐.. 고만고만한 약어 입니다..

    http://en.wikipedia.org/wiki/Scm

    http://en.wikipedia.org/wiki/Software_configuration_management

    http://en.wikipedia.org/wiki/Source_Code_Management

좀 좋게 미친듯하다. 좋은 소리 듣기는 힘들겠지만, 그래도 시도는 한 것이 나쁘지만은 않다. 다음에 올라온 이데일리 뉴스를 보고 16일 오픈한다는데, 도메인(http://www.anyframejava.org/ )이 있기에 들어가 보니 "와~" 소리 나오게 잘 만들어 놓았다.

Struts와 Spring 프레임워크를 국내 SI에 맞게 만들어 놓은 듯한 인상을 지울 수는 없지만 사이트 체계는 잘 만들어 놓았다.
소스와 바이너리 버전, JIRA를 이용한 이슈 관리, Subversion로 버전관리, 그리고 포럼을 통한 의견교환, 그리고 제법 갖춰진 매뉴얼과 문서들.

LAF/J 보다 나은 점은 사내망을 벗어나서 외부와 소통하겠다는 의지인데, 관건은 얼마나 오래 유지될 것이냐는 것이다.

유령의 집 같은 폐가로 만들지 않으면 좋겠다.

http://www.anyframejava.org/
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
Posted by 케누 kenu허광남

댓글을 달아 주세요

  1. 이동국  댓글주소 수정/삭제 댓글쓰기 2008.06.15 17:14 신고

    성능측정툴로 InfraRED를 제공한다는데요.
    설치가 좀 어렵고 UI가 좀 구린데, 어떻게 멋있게 고쳐서 제공할지 기대되요..

  2. 해피씨커  댓글주소 수정/삭제 댓글쓰기 2008.06.15 18:26

    제가 회사 다닐때, 사내에서 아테나라는 프레임웍을 개발했다고 해서
    잠시 검토를 해보았는데, Struts에 약간 커스터마이징을 한 수준이였죠.
    Struts에 비해 메리트도 없고, 설정은 더 복잡하고,
    그러면서 문.서.도 없고
    (SI 프로젝트 들어갈때는 사내기술로 개발한 프레임웍 이라고 당당히 문구에 적어놓고..<- 회사 입장에서는 이 목적이 더 컸던든...)
    AnyFrame은 그 때보다는 더 당당히 공개 했지만,
    어떻게 키.워.나.갈.지. 지켜보아야겠죠.
    그때처럼 만들어놓고 광고용으로만 쓰고.. 나 몰라라 하는 건 아닌지...

  3. 쌩이  댓글주소 수정/삭제 댓글쓰기 2008.06.16 17:03

    문서는 정말잘되어있네요

    멀티캠퍼스에 강좌도 개설해놨더라구요..

    얼마나 밀지는 두고봐야 할듯합니다

    해피씨커님말처럼 영업용으로만 쓰이는게아니라면 좋겠습니다만..

  4. 아스키  댓글주소 수정/삭제 댓글쓰기 2008.06.16 23:08

    삼숑 프레임워크 공식 = 아테나+시스템미어(Struts)
    차기 신버전 = 애니프레임 (Struts or struts2+spring)
    기반은 거의 STRUTS이더군요.. - -;

  5. benelog  댓글주소 수정/삭제 댓글쓰기 2008.06.17 14:46

    안녕하세요. 저도 전에 이전 버전을 써봤었습니다.

    전버전의 프레임웍 명칭이 Systemier였고, 웹단이 Athena(Struts기반), 그 뒷의 서버단이 Titan(Avalon 기반)으로 이름 붙여져 있었습니다. 웹단은 거의 그냥 Struts로 보입니다. 웹단 설정방법은 완전히 똑같습니다. (Struts + Tiles plug-in으로 주로 썼었습니다.)

    이번 버전은 웹단은 Struts1과 Spring MVC 2개의 샘플을 제공하고 그 뒷단은 Spring 기반인데 설정부분에서 약간의 Avalon에 대한 의존성이 있는 것 같습니다.

    개인적으로는 그냥 Spring+Spring MVC 또는 Struts2로 갔으면 하는데 Struts1에 대한 애착이 무척이나 큰 가 봅니다.

  6. 참◈서빈  댓글주소 수정/삭제 댓글쓰기 2008.06.19 00:21

    믿지 마세요.. 거기 얻은거 솔루션으로 들어가요 ㅎㅎㅎ
    그것도 초보들이 배껴서 ㅋㅋ

관련글 : http://okjsp.tistory.com/tag/openapi

WoC(Winter of Code)에서 함께 할 파트너가 정해졌습니다. 돌아오는 토요일에 처음 만나게 됩니다. 함께 진행하지 못하는 네분의 신청자분들에게 고마움과 미안함을 전합니다. 이 프로젝트가 어떻게 진행되는지는 프로젝트 홈페이지(http://code.google.com/p/shopgallery)를 통해서 확인할 수 있습니다.

사용자 삽입 이미지

구걸 코드에서 제공하는 오픈소스 프로젝트 호스팅 서비스를 이용해서 다음과 같은 일들을 진행할 수 있습니다.

  • 프로젝트 홈페이지
  • 다운로드 서비스
  • 위키
  • 이슈트래커
  • 소스버전관리 - subversion
  • 프로젝트 멤버 관리
비슷한 류의 원조격인 서비스는 sourceforge.net 입니다. 한국어로 된 서비스로 kldp.net도 있습니다. 자바닷넷도 오픈소스 프로젝트 인큐베이터를 자처하고 있습니다.

현재 프로젝트에는 옥션의 openAPI 샘플만 들어가 있습니다. 소스 탭에 나온 설명대로 다음의 소스 주소를 통해서 확인할 수 있습니다.

svn checkout http://shopgallery.googlecode.com/svn/trunk/ shopgallery-read-only

내년 2월까지 진행되는 이 프로젝트를 통해서 오픈소스에 대한 감각을 좀 더 익히고 싶습니다.
Posted by 케누 kenu허광남

댓글을 달아 주세요