Whiteship's Note

'maven'에 해당되는 글 47건

  1. 2009.04.13 OpenSprout Nexus 이용하여 스프링 3.0 라이브러리 추가하기 (2)
  2. 2008.11.03 아키타입(메이븐 프로젝트 베이스) 만들기
  3. 2008.10.23 Maven 프로젝트 의존성 파일들 패키징하기 (2)
  4. 2008.10.21 Maven 같지 않은 Maven 프로젝트 만들기 (2)
  5. 2008.10.20 Maven 멀티 모듈 프로젝트 구성하기 (2)
  6. 2008.10.16 스프링 DM 프로젝트 빌드하기
  7. 2008.09.29 메이븐 settings.xml 살펴보기
  8. 2008.09.08 Maven을 활용한 배포
  9. 2008.08.18 pom.xml에서 bnd 설정 파일 분리하기
  10. 2008.08.18 Nexus - Maven Repository Manager 설치하기 (8)
  11. 2008.08.07 JavaMail - pom.xml에 dependency 추가하기
  12. 2008.07.28 로컬에서는 무사히 빌드가 되는데, 왜 서버로 올라가서 CI가 돌리면 컴파일 에러가 날까
  13. 2008.07.28 메이븐 플러그인 탐험기1 - UMLGraph
  14. 2008.07.16 exclusion을 하까마까
  15. 2008.07.09 Spring Dynamic Modules Maven Archetype
  16. 2008.07.03 메이븐을 대체할 것인가~ Buildr
  17. 2008.07.01 Ivy로 메이븐 저장소를 사용하기
  18. 2008.05.19 Maven을 사용하세요. 코딩이 편해집니다. (11)
  19. 2008.05.13 Maven의 archetype:create DEPRECATED 되다.
  20. 2008.05.13 Maven으로 Spring DM Project 만들기(Eclipse에서 import 가능)
  21. 2008.04.19 Q4E 플러그인 사용기 1 (2)
  22. 2008.04.18 pom.xml에 종속성 추가하기 (8)
  23. 2008.04.18 이클립스용 Maven 플러그인 Q4E (10)
  24. 2008.04.17 기본적인 managed dependency 사용법 (2)
  25. 2008.04.17 Managed Depedency 네 녀석의 정체를 드디어 알았다.
  26. 2008.04.16 Maven으로 이클립스 프로젝트 만들기 - Screen Cast (4)
  27. 2008.04.14 Managed dependency는 무슨 뜻인가요?
  28. 2008.03.18 Artifactory 설치하기
  29. 2008.03.18 Maven + Clover (1)
  30. 2008.03.03 Maven을 쓴다고 해서 종속성을 안중에서 Out 시킬 수 있느냐? (2)

OpenSprout Nexus 이용하여 스프링 3.0 라이브러리 추가하기

OSAF : 2009.04.13 10:11


참조:
Spring 3.0 (4) - Maven에서 Spring 3.0 최신버전 사용하기
Spring3.0 (5) - 스프링 모듈의 의존관계
Maven의 version range를 사용할 때 주의할 점

일단 사부님이 관리 중인 OpenSprout Nexus를 메이븐 settings.xml나 프로젝트의 pom.xml에 등록해 주세요.

<repository> 
    <id>spring-latest</id> 
    <name>Spring Latest by OpenSprout</name> 
    <url>http://www.opensprout.org/nexus/content/repositories/spring-latest</url> 
</repository> 

다음으로 스프링 번들 리파지토리도 등록해주세요.

<repository> 
    <id>com.springsource.repository.bundles.external</id>  
    <name>SpringSource Enterprise Bundle Repository - External Bundle Releases</name> 
    <url>http://repository.springsource.com/maven/bundles/external</url> 
</repository>

이제 준비는 끝났습니다. 본격적으로 스프링 3.0 라이브러리를 추가하면 됩니다. 추가하는 방법은 두 가지가 있을 수 있습니다. 모든 라이브러리를 직관적으로 명시해주는 방법과 추이적 종속성을 이용하여 반드시 명시해야 할 것만 명시하는 방법이 있습니다.

사용자 삽입 이미지
원본 이미지: http://toby.epril.com/?p=598

사부님이 그린 그림을 보면 빨간색 박스로 표시한 라이브러리만 추가하면 파란색으로 칠한 모든 라이브러리를 추이적으로 가져올 거라는 것을 알 수 있습니다. 따라서.. pom.xml에 다음과 같이 설정하면 스프링 라이브러리 중에 필요한 것은 대부분 가져옵니다.

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>org.springframework.web.servlet</artifactId>
            <version>[3.0.0.BUILD-00000000000000,9.9.9.BUILD]</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>org.springframework.aspects</artifactId>
            <version>[3.0.0.BUILD-00000000000000,9.9.9.BUILD]</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>org.springframework.orm</artifactId>
            <version>[3.0.0.BUILD-00000000000000,9.9.9.BUILD]</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>org.springframework.test</artifactId>
            <version>[3.0.0.BUILD-00000000000000,9.9.9.BUILD]</version>
        </dependency>

버전 범위 표시를 저렇게 한 이유는 세 번째 참조 글에서 확인할 수 있습니다.

이렇게 해서 가져온 라이브러리들을 M2Eclipse 플러긴의 Dependency Graph 또는 Dependency Hierarchy로 확인할 수 있습니다.

사용자 삽입 이미지
사용자 삽입 이미지

스프링 3.0이 어떤 제 3 라이브러리(어떤 버전을) 사용하는지 궁금하다면

http://spreadsheets.google.com/pub?key=ppDRa3Yit-05zS2cqWYFlNA

사부님이 작성하신 위 문서를 참조하시면 됩니다.

나이스!! 이제는 드디어 스프링 3.0 개발을 시작합니다~
신고
top


아키타입(메이븐 프로젝트 베이스) 만들기

Build/Maven : 2008.11.03 16:43


메이븐에는 아주 괜찮아 보이는 기능이 하나 있습니다. 프로젝트 기본 구조를 생성해주는 아키타입이라는 기능입니다. 매번 프로젝트 시작할 때마다 pom.xml에 필요한 라이브러리 정의한 것조차 매우 귀찮습니다. 웹 프로젝트일 경우에는 자주 사용하는 설정 파일들까지도 매번 다른 프로젝트에서 복사해서 붙여 넣던지 이클립스에 등록한 템플릿 코드를 사용해서 찍어내다시피 합니다. 이런 것들을 전부 처음부터 프로젝트 시작할 때 가지고 있는 상태에서 시작한다면...정말 좋겠죠? ㅎㅎ 하지만 공짜는 없었습니다.

OSAF 웹 애플리케이션 샘플을 아키타입으로 만들어서 OSAF를 사용한 웹 개발을 편리하게 할 수 있는 기능을 제공하려고 마음 먹고 아키타입 개발을 시작했습니다. (원래 오전에 할려고 했는데 블로깅하다보니. 밥먹을 시간이고 밥먹고 좀 놀다보니;;; 어느새 2시..ㄷㄷㄷㄷ)

http://maven.apache.org/plugins/maven-archetype-plugin-1.0-alpha-7/examples/archetype.html

위 링크에 나와있는 맨땅에서 아키타입을 만드는 방법은 완전 완전 완전 완전 완전 노가다입니다. pom.xml 만 살짝 수정하는 아키타입을 만들꺼라면 상관없는데.. 제가 만들고자 하는 아키타입을 기본으로 제공할 파일들이 엄청나게 많습니다. 그럴 때 저런 방법으로 아키타입을 만드는건.. 그냥... 너 좀 고생해봐라.. 라는 것 밖에 안 됩니다.

제가 선택한 방법은

http://maven.apache.org/plugins/maven-archetype-plugin/advanced-usage.html


링크에서부터 느껴지는 포스. 어드밴스드.. 하지만 이 녀석으로 아키타입 만드는 방법도 노가다가 필요합니다. 그다지 행복하진 않았습니다.

만드는 방법을 보죠. 아주 간단합니다.



0. 프로젝트 정리

기존 프로젝트에서 아키타입에 포함시키지 않을 폴더와 파일을 제거합니다. 버전 관리를 하고 있는게 안전하겠죠.

특 히 제거해야 할 폴더는 이클립스 빌드 패스에 output 폴더로 지정되어 있는 폴더 그걸 삭제해 줍니다. 그럼 폴더만 다시 생기고 그 안에 있는 파일과 폴더들은 삭제됩니다. 기본적으로 그 폴더는 Package Explorer에선 안 보이고 Navigator에서 봐야 보일 겁니다.

1. mvn archetype:create-from-project


아키타입으로 만들 프로젝트로 이동해서 위 명령을 입력해 줍니다. 아.. 아닙니다. 주의할 것이 있는 프로젝트 기본 인코딩이 UTF-8이면 그냥 저렇게 실행해도 되지만, 저처럼 euc-kr이면 -DdefaultEncoding=euc-kr 옵션을 추가합니다.

2. 생성된 파일들 확인(노가다)

위 명령을 실행하면 target/generated~~/archytype/ 밑에 아키타입에 추가할 파일들이 쫙 보입니다. 그 파일들을 전부 열어서 원하는 대로 생성될지 확인합니다. 특히 인코딩과 ${packageInPathFormat} 같은걸 제대로 확인합니다.

3. 로컬 저장소에 설치합니다.

target/generated~~/archytype/ 폴더로 이동해서 mvn install을 실행합니다. 그럼 로컬 저장소에 아키타입이 설치됩니다.

4. 로컬 저장소의 아키타입을 이용해서 프로젝트를 생성합니다.

mvn archetype:generate -DarchetypeCatalog=local

이 명령어를 사용하면 아키타입 목록을 메이븐 중앙 저장소가 아니라 로컬 저장소에서 읽어옵니다. 이 목록에 위에서 설치한 아키타입이 보일 겁니다. 그 번호를 선택해줍니다.

그리고 필요한 정보를 줘서 프로젝트를 생성하면 됩니다.

5. 원격 저장소에 배포

최종적으로 프로젝트를 확인하고 원하는대로 생성이되면 원격 저장소에 배포해서 다른 개발자도 이용할 수 있게하면 되겠습니다.

배포하는 방법은 mvn install하던 장소로 이동해서 mvn deploy를 하면 되겠죠. 간단 간단.

ps: 한글 문제는 해결했지만, 패키지가 동적으로 안 바뀌는 문제가 남아있습니다. -_-;; 흠... 이상하네. package명을 주면 만들 때 알아서 바껴야지 왜 패키지는 고정적으로 만들고 import 문에 있는 package만 바뀌는거얌.. 어쩌라구 ㅠ.ㅠ


신고
top


Maven 프로젝트 의존성 파일들 패키징하기

Build/Maven : 2008.10.23 10:03


보통, mvn package를 하면, 해당 프로젝트의 의존성 라이브러리들은 그대로 둔채 패키징을 합니다. 그런데, 배포 할 때는 maven을 사용하지 않는 분들을 위해서 이 프로젝트가 의존하고 있는 다른 라이브러리들도 같이 배포해주는 것이 좋을 겁니다. 그럴 때 유요한 플러그인은 바로 maven-dependency-plugin 입니다.

maven-assembly-plugin이 이런 일을 해주는게 아닌지 싶어서 이것 저것 해봤는데, 이 플러그인은 컴파일된 class 파일들을 만들어서 의존하고 있는 클래스들까지 통째로 가지고 있는 jar 파일을 만들 때 사용하는 거더군요. 뭐 의존성 관리 안하고 한 방 파일로 마치 cglib-nodep 같은 걸 만들 때 사용하면 모를까. 의존성 라이브러리를 계속 버전업 하며 교체할 수 있는 형태로 제공하려면 이 플러그인 보단 maven-dependency-plugin을 사용해서 의존성 라이브러리를 별도의 폴더(보통 lib에 두죠)에 같이 배포해주는 것이 좋겠습니다.

방법은 간단합니다.

<build>
...
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <executions>
                    <execution>
                        <id>copy-dependencies</id>
                        <phase>package</phase>
                        <goals>
                            <goal>copy-dependencies</goal>
                        </goals>
                        <configuration>
                            <outputDirectory>
                                ${project.build.directory}/lib
                            </outputDirectory>
                            <overWriteReleases>false</overWriteReleases>
                            <overWriteSnapshots>
                                false
                            </overWriteSnapshots>
                            <overWriteIfNewer>true</overWriteIfNewer>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
...
</build>

이런식으로 pom.xml의 <build> 안에 <plugins> 안에 넣어주면, target 폴더 아래 lib 폴더를 만들고 그 안에 의존성 라이브러리들을 쫘르륵~ 복사해 줍니다.
신고
top


Maven 같지 않은 Maven 프로젝트 만들기

Build/Maven : 2008.10.21 15:28


사용자 삽입 이미지

위 프로젝트는 일반적인 이클립스의 웹 프로젝트와 다름 없이 src와 test 소스 폴더를 가지고 있고, 웹 폴더도 루트바로 밑에 webapp를 사용하고 있습니다. 하지만, 이 녀석은 메이븐 프로젝트 입니다. 맨 아래에 pom.xml 보이시죠?

사부님이 전에 작성하셨던 메이븐 기본 디렉터리 설정 방법과 Arawn님의 메이븐 웹 폴더 설정 플러긴 사용방법을 조합하면 위와 같은 프로젝트를 만들 수 있습니다.

둘 다 pom.xml의 build 엘리먼트 내부에 적절하게 넣어주면 됩니다.

<build>
...
        <sourceDirectory>${project.basedir}/src</sourceDirectory>
        <scriptSourceDirectory>
            ${project.basedir}/scripts
        </scriptSourceDirectory>
        <testSourceDirectory>
            ${project.basedir}/test
        </testSourceDirectory>
        <resources>
            <resource>
                <directory>${project.basedir}/src</directory>
                <excludes>
                    <exclude>**/*.java</exclude>
                </excludes>
            </resource>
        </resources>
...
        <plugins>
...
            <plugin>
                <artifactId>maven-war-plugin</artifactId>
                <version>2.1-alpha-2</version>
                <configuration>
                    <warSourceDirectory>webapp</warSourceDirectory>
                </configuration>
            </plugin>
...
        </plugins>
<build>

설정 내용은 엘리먼트 이름을 보면 대충 알 수 있으면 자세한 설명은 사부님과 Arawn님의 블로그에 가셔서 보시면 되겠습니다. ㅋㅋ
신고
top


Maven 멀티 모듈 프로젝트 구성하기

Build/Maven : 2008.10.20 18:02


간단하네요~ 상위 프로젝트(부모-자신 관계가 아닌, 다단 구조에서 상위)의 pom.xml에서 해당 프로젝트의 packaging을 pom으로 하고, <modules> 엘리먼트를 사용해서 하위 프로젝트의 이름을 명시해주면 됩니다. 그럼 상위 프로젝트에서 빌드를 하면, 자신은 물론 자신이 <modules>에 명시한 모든 프로젝트를 동일하게 빌드해줍니다.

상위 pom.xml
...
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.opensprout</groupId>
    <artifactId>osaf</artifactId>
    <packaging>pom</packaging>
    <version>1.0.0-m1</version>
    <name>OpenSprout Application Framework</name>
    <url>http://www.opensprout.org</url>
...
    <modules>
        <module>osaf-core</module>
    </modules>
...

프로젝트 구조
사용자 삽입 이미지

바로 하위 폴더를 만들고 그 안에 파일들을 복사해두면 됩니다.


신고
top


스프링 DM 프로젝트 빌드하기

Spring DM/exercise : 2008.10.16 14:59


메이븐 기반 프로젝트기 때문에, 간단하게 mvn package로 빌드 할 수 있을 거라고 생각했는데;;; 땡.. 틀렸습니다. mvn packae로 빌드하면 다음과 같은 에러를 볼 수 있습니다.

[ERROR]

Mojo:

    org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile

FAILED for project:

    org.springframework.osgi:spring-osgi-mock:bundle:1.2.0-m1

Reason:

C:\java\spring-osgi-1.2.0-m1\src\mock\src\main\java\org\springframework\osgi\mock\MockServiceReference.java:[23,25] package org.osgi.framework does not exist

OSGi 플랫폼이 없어서 발생하는 에러로, 스프링 DM 프로젝트를 빌드 할 때 프로파일을 선택해줘야 한다는 군요. 그래서 스프링 DM 프로젝트에 있는 프로파일을 살펴봤습니다.

사용자 삽입 이미지

여러가지가 있었습니다. 맨 위에 세 개는 OSGi 플랫폼이고, jdk 버전을 1.5 이상용도로 빌드해서 애노테이션 지원 기능을 사용할 수 있게 빌드 할 수 있나보네요. it은 통합 테스트(이 옵션을 안 주면 단위테스트만 합니다.)

mvn -Pequinox

통합 테스트까지 하면서 빌드 하려면

mvn -Pequinox,it

굳이 빌드를 안 해도 dist 폴더에 들어있긴 하지만... 오픈 소스쓰는 기본 자세라는 사부님 말씀. 캬~ 덕분에 오늘도 한 수 배웠습니다.

메이븐 프로파일은 안 써봤는데, 저걸 사용해서 빌드 하면 여러 환경에 따른 빌드 커스터마이징이 가능하군요. 특히 저 통합테스트가 눈에 띄는데 빌드 시간을 엄청 오래 잡아먹는 통합 테스트들은 주기 적으로만 실행하고 한 번의 커밋당 실행하는 빌드는 단위테스트만 실행하게 할 수도 있겠습니다.. 흠.. 프로파일 좋구나.


신고
top


메이븐 settings.xml 살펴보기

Build/Maven : 2008.09.29 11:44


참조 : http://maven.apache.org/ref/2.0.8/maven-settings/settings.html
사용자 삽입 이미지

현재 제가 사용하고 있는 settings.xml 파일에서 1단계 엘리먼트만 보여주고 있습니다.

1. settings

최상위 엘리먼트로, 하위 엘리먼트들로 메이븐 설정함.

2. pluginGroups

  <pluginGroups>
  <pluginGroup>com.atlassian.maven.plugins</pluginGroup>
  </pluginGroups>

열어보면 이렇게 설정되어 있습니다. Maven-Clover2-Plugin 설치할 때 settings.xml에 추가한 기억이 납니다. 뭔 내용인지 몰랐는데, 지금 살펴봅니다.
List of groupIds to search for a plugin when that plugin groupId is not explicitly provided.
groupid 리스트로 플러그인의 groupId가 명시적으로 설정되어 있지 않을 때 플러그인을 찾을 곳이로군요.

            <plugin>
                <groupId>com.atlassian.maven.plugins</groupId>
                <artifactId>maven-clover2-plugin</artifactId>
                <version>2.3.2</version>
                <configuration>
                    <generateXml>true</generateXml>
                    <generateHtml>true</generateHtml>
                    <licenseLocation>/app/webapp/opensprout/clover/clover.license</licenseLocation>
                    <includesTestSourceRoots>
                        false
                    </includesTestSourceRoots>
                </configuration>
            </plugin>

흠..그럼 pom에서 저렇게 플러긴의 groupId를 명시했으니까, 설정을 지워도 되겠군요.

3. mirrors

  <mirrors>
    <mirror>
      <id>Nexus</id>
      <name>Nexus Public Mirror</name>
      <url>http://www.opensprout.org:8082/nexus/content/groups/public</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
  </mirrors>

이렇게 설정되어 있습니다. mirrors는
Configuration of download mirrors for repositories.
저장소에 대한 다룬로드 미러들을 설정이로군요. 그럼. mirror는
A download mirror for a given repository.
하나의 저장소에 대한 하나의 미러 설정이군요. 각각의 속성들은

mirrorOf        The server ID of the repository being mirrored, eg "central". This MUST NOT match the mirror id.
name     The optional name that describes the mirror.
url     The URL of the mirror repository.
id     No description.

4. profiles

흠.. 이 녀석을 사용해서, JDK 버전 별 또는 OS 마다 빌드 구성을 달리 할 수 있는 거로군요. 하지만, 복잡하니까 나중에 다루기로 하고, pass

5. activeProfiles

   <activeProfiles>
     <activeProfile>dev</activeProfile>
</activeProfiles>

List of manually-activated build profiles, specified in the order in which they should be applied.
위에서 설정한 여러 프로파일중에서 직접 활성화 시킬 빌드 프로파일 목록. 설정한 순서대로 적용된다.

6. servers

  <servers>
    <server>
      <id>release</id>
      <username>admin</username>
      <password>---</password>
    </server>
    <server>
      <id>snapshot</id>
      <username>admin</username>
      <password>---</password>
    </server>
  </servers>

Configuration of server-specific settings, mainly authentication method. This allows configuration of authentication on a per-server basis.

서버와 관련된 설정으로, 주로 인증하는 방법을 제공. 이것을 통해 서버 당 인증 정보를 담고 있을 수 있다.

이 때, 위에서 사용한 id의 값은 pom에서 설정한 저장소의 id와 일치해야 하는 듯.. pom.xml을 보면 짐작할 수 습니다.

    <distributionManagement>
        <repository>
            <id>release</id>
            <url>http://www.opensprout.org:8082/nexus/content/repositories/releases</url>
        </repository>
        <snapshotRepository>
            <id>snapshots</id>
            <url>http://www.opensprout.org:8082/nexus/content/repositories/snapshots</url>
        </snapshotRepository>
    </distributionManagement>

신고
top


Maven을 활용한 배포

Build/Maven : 2008.09.08 10:31


배포도 여러 종류가 있겠지만, 우선은 개발시에 배포가 필요합니다. 톰캣이나 제티위에 웹 애플리키에션을 올려서 확인해봐야겠죠. 이렇게 배포한 것은 개발용도 이고, 오직 한 명의 개발자 용도로 배포하는 것이니 개발 환경 배포라고하겠습니다. 그리고 테스트 환경에 배포하여 다른 팀원 및 고객들도 공통으로 현재 돌아가는 웹 애플리케이션을 볼 수 있도록 배포할 수 있습니다. 팀 환경 배포라고 하겠습니다. 무슨 명칭이 따로 있었던 것 같은데, 기억이 안납니다. (장미를 꼭 장미라고 부를 필욘없죠. 로즈라고 하던 로젠이라고 하건,, 아메리카 원주민을 인도 사람-인디안-이라고 부르기도하는데 이정도야 뭐.. ㅋ) 그리고 최종 제품 단계에서 고객에게 배포하는 제품 환경 배포가 있겠습니다.

1. 개발 환경 배포

Maven으로 배포를 할 때 사용하는 플러긴은 war입니다. 기본적으로 세 가지 goal을 제공합니다.

war:war는 target 폴더 밑에 war 파일을 만들어 줍니다. 이 녀석을 톰캣홈/webapp 밑에 복사해서 배포할 수도 있겠지만, 상당히 불편한 작업입니다. 언제 그 파일 복사해서 톰캣 폴더 열고 복사하고 다시 띄우고;; 이러다가는 개발하기도 전에 지쳐버릴 겁니다.

war:exploded가 있습니다. 이 녀석은 개발할 때 편하게 target/app이름/WEB-INF 를 만들어 그 안에 war를 풀어해진(exploded) 형태로 배포해줍니다. 소스파일을 컴파일 해서 target/app이름/WEB-INF/classes 이 안에 넣어줍니다.

이 방법은 이클립스에서 톰캣 서버에 모듈 설정을 target/app이름 으로 잡아두고, 빌드 기본 디렉터리를 위의 classes 폴더로 잡아주면 상당히 편하게 개발을 할 수 있습니다. 하지만, target 폴더를 서버 홈으로 잡아 두는 건 그리 좋은 방법이 아닌것 같습니다. 왜냐면, 일단 src/main/webapp 밑에 개발해둔 jsp 파일과 WEB-INF 이하의 모든 파일을 target/app이름/ 밑으로 전부 복사를 하는데.. 파일이 많으면 이 복사 작업도 길어질 뿐더러, 개발시 xxx.jsp 파일을 찾으려고 Ctrl+F를 눌러서 검색해보면 파일이 두개 보입니다. 하나는 target에 위치한 녀석으로 수정하나 마나인 파일과 하나는 src/main/webapp에 있는 실제로 수정해야 하는 파일이죠. 이 둘을 잘 못 구분해서, 개발한 수고가 전부 날아가버린 경험이 몇 번 있습니다.

따라서 마지막 방법인 war:inplcae가 가장 적당합니다. war:inplcae는 war:exploded의 변종으로 src/main/webapp 밑에다가 그냥 배포를 합니다. 따라서 필요한 라이브러리를 src/main/webapp/WEB-INF/lib 폴더로 이동시키는 것 말고는 별다른 복사가 발생하지 않습니다. 수정해야 할 파일도 하나고 말이죠. 단 classes 폴더는 직접 생성해주고 그쪽으로 빌드 디렉토리를 잡아줘야 합니다. 서버 모듈 홈 디렉토리도 src/main/webapp로 잡아줘야 하구요. 이건 뭐 두 번째 방법을 사용하더라도 설정해 줘야 하는 것이기 때문에 부가적인 일이라고 볼 순 없습니다. 어쨌든~ 이렇게 하면 이슈가 하나 있는데, 빌드 패스에 메이븐 의존성과 webapp/WEB-INF/lib에 복사된 라이브러리 들끼리 충돌한다는 메시지가 나옵니다. 이 메시지는 빌드 패스에 가서 메이븐 의존성을 열어 보면 WEB-INF/lib도 참조하도록 되어 있는데 그 걸 빼주면 됩니다.

자 이렇게 설정을 해두면 이제 개발할 때 배포는.. 아주 간단합니다.

개발 -> 서버 실행 -> 확인 -> 서버 종료 -> 개발 -> pom.xml에 dependency 변경 -> WEB-INF/lib 폴더 제거 -> war:inplace -> 서버 실행 -> ... 이런식입니다.

2. 팀 환경 배포

CI를 하고 있다면 편하게 할 수 있습니다. 배번 빌들 할 때 마다 war:inplace로 배포를 하게 하고, 해당 폴더를 웹 서버에 모듈 홈으로 등록해두면 되겠죠. 대충 빌드는 이런식으로 짜면 될 겁니다.

clean test war:inplace

3. 제품 환경 배포

제품 환경에 배포하는 것은 조금 다릅니다. 빌드와도 관련이 없고(매번 빌드 할 때마다 제품 환경에 배포하진 않죠.) 어쩌면 이 때는 war로 패키징을 하던 어쩌던 별 상관이 없을 것 같지만, 제가 지금 다니는 회사에서 익힌 방법은 업데이트가 아주 용이한 방법입니다. 엄청나게 빠르게 에러를 잡고 제품에 반영해줄 수가 있습니다. 그야말로 Agile 방법입니다.

war 패키징은 전혀 빠르지 않습니다. 귀찮죠. 일단 이 거는 별도의 브랜치가 필요합니다. 개발과는 전혀 다른 브랜치로 소스 코드 관리를 하고 있어야 합니다. 조그만 애플리케이션이라면 굳이 그럴 필요는 없겠지만 일반적으론 나눠 두는게 좋겠습니다. 그래야 배포랑 개발을 구분할 수 있으니까요.

제품 배포 환경에 가서 배포용 프랜치를 commit 받습니다. 그리고 이렇게 받아둔 폴더를 중심으로 배포 환경 웹 서버에 모듈 홈을 등록합니다. 이게 초기 세팅입니다. 이대로 펼쳐진 상태로 배포가 끝납니다. war로 배포하지 않습니다.

그런 다음 이슈가 생기거나 문제가 있을 때 개밣 환경에서 테스트 하고, 팀 개발 환경에서 테스트 하고, 잘 돌아가면, 배포 용 브랜치에 작업을 합니다. 그리고 커밋 합니다. 그런 다음 배포 환경으로 가서 소스 코드 업데이트를 업데이트 받고 서버에 가서 해당 웹 모듈만 내렸다 켜면 됩니다. war로 묶고 그걸 옮기는 작업이 사라져서 한 결 빨라졌습니다. 이걸 응용하면 매번 실행할 때 마다 새로 업데이트 받아서 실행하는 클라이언트 프로그램도 짤 수 있습니다,
신고
top


pom.xml에서 bnd 설정 파일 분리하기

Spring DM/exercise : 2008.08.18 15:29


사용자 삽입 이미지


bnd 설정 파일을 pom.xml에서 분리하고 pom.xml의 bnd 플러긴 설정은 다음과 같이 수정합니다.

            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <extensions>true</extensions>
                <version>1.4.0</version>
                <configuration>
                    <instructions>
                        <_include>-osgi.bnd</_include>
                    </instructions>
                </configuration>
            </plugin>       

pom.xml은 훨씬 가벼워지고, bnd 설정과 pom.xml을 유지보수 할 때도 이렇게 나눠 두는게 좋을 듯 합니다.
신고
top

TAG Bnd, maven

Nexus - Maven Repository Manager 설치하기

Build/Maven : 2008.08.18 10:04


Sonatype에서 만든 메이븐 저장소 관리 툴입니다. Artifactory라는 툴도 있지만, 자꾸 UI가 벗겨지는 문제가 있어서.. 흠;; 어쨋든 소나타입이 만들었다고 하니 왠지 써보고 싶고, 사부님도 강추를 하고 있어서 설치했습니다.

설치 방법은 Artifactory 만큼이나 간단했습니다.

참조: http://nexus.sonatype.org/

1. 다운받기
2. 포트 설정 변경하기(option)
3. 실행하기
4. 로그인하기

1. 다운받기

http://nexus.sonatype.org/downloads/ 이리로 가셔서 원하는 파일 zip이든 tar.gz이든 받습니다. 리눅스에서 받으려면 링크 주소를 복사한 다음에 wget 사용하니까 편하더군요. 다운 받은 다음 압축을 풀어 줍니다.

2. 포트 설정 변경하기(optional)

기본으로 8081번 포트사용해서 Jetty가 돌려줍니다. 포트를 변경하고 싶다면, conf/plexus.properties 파일을 열어서 맨위에 있는 포트 번호를 바꿔주면 됩니다.

3. 실행하기

이게 좀 간단치가 않은데, 여러 플랫폼 마다 실행 스크립트를 만들어 둬서 각각의 플랫폼에 해당하는 스크립트를 찾아서 실행해줘야 합니다.

MacOS의 경우에는  ./bin/jsw/macosx-universal-32/nexus start
이밖에도 리눅스, 솔라리스, 윈도우 등.. 여러 OS에 따른 실행 스크립트가 있습니다.

사용자 삽입 이미지

동작 확인하기.

tail -f logs/wrapper.log

위 명령을 실행해서 쌓이는 로그파일을 참조하시면 됩니다.

4. 로그인하기

설치가 된거 같으면 http://서버IP or 도메인:설정한 포트번호/nexus/ 로 접속하시면 됩니다.
접속하신 다음, 오른쪽 위에 Log in 링크를 눌러서 admin/admin123 으로 로긴합니다. 기본 비번은 변경해주는게 안전하겠죠.
사용자 삽입 이미지
Ext-JS를 사용해서 UI를 만들었다고 하는데, 꽤 좋습니다. 드래그앤드랍도 되고, 탭 형식의 UI도 괜찮습니다.


신고
top

TAG maven, Nexus

JavaMail - pom.xml에 dependency 추가하기

모하니?/Coding : 2008.08.07 09:46


        <dependency>
            <groupId>javax.mail</groupId>
            <artifactId>mail</artifactId>
            <version>1.4</version>
        </dependency>

최신버전은 1.4.1 까지 release가 됐으나, maven repo에선 1.4까지만 받을 수 있었습니다. 로컬 리파 사용하시는 분들은 1.4.1을 아리훽터리나, 넥서스에 설치하신 담에 버전을 1.4.1로 바꿔주셔도 될듯.. 전 귀찮아서 구냥 1.4.

        <dependency>
            <groupId>javax.activation</groupId>
            <artifactId>activation</artifactId>
            <version>1.1</version>
        </dependency>

이건 뭔지 잘 모르겠는데, 메일에 첨부파일 붙일 때 사용하는 DataSource, FileDataSource, DataHandler 이녀석들이 여기에 들어있습니다.

둘 다 독립적인 라이브러리라서 다른 라이브러리는 전혀 끌고 오지 않습니다. 깔끔합니다.
신고
top


로컬에서는 무사히 빌드가 되는데, 왜 서버로 올라가서 CI가 돌리면 컴파일 에러가 날까

Build/Maven : 2008.07.28 14:45


이럴 때가 정말 황당하고 답답한데, 뭐 방법은 역시 에러 메시지를 잘~~ 살펴보면 됩니다. 아님, 사부님한테 물어보던지요.ㅋㅋ

문제 분석

일단 CI 서버에서 문제가 생기면, 로그 메시지를 보고 어느 Phase에서 에러가 난건지 확인 합니다. 컴파일 에러가 났으면 당연히 compile Phase에서 에러가 난거겠죠. 그럼 로컬에서는 어떤지 로컬에서 compile을 해봅니다. 즉 mvn compile 이라고 하면 되죠. 이 때 서버랑 똑같이 컴파일 문제가 생기면 아주 아주 좋은겁니다. 그런데 이 글의 제목처럼 로컬에서는 잘 돌아간다면, 약간 당황스러워 집니다. 이 때부턴 여태까지의 경험과 로그 분석으로 난국을 헤쳐나가야 합니다. mvn 로그를 보려면, -X를 추가해서 실행하면 됩니다. 서버로 가서 mvn -X compile 이라고 서버에서 실행하고 자세히 들여다 봅니다. 어떤 라이브러리들을 가져왔는지, 플러긴은 제대로 가져왔는지 등등..

문제 해결

0. 로컬에서 빌드가 제대로 돌았다는 사실을 의심해야 합니다.

"왜 서버에선 안 돌아갈까?" 전에.. "왜 로컬에서는 돌아가는거지?" 라는 생각을 먼저 해보는게 문제 해결의 지름길 입니다. '서버에서 돌린 스크립트를 그대로 돌렸나??' 라고 생각해본다거나, 이클립스에서 실행한건 아닌지.. 의심해야 합니다.

1. 인코딩 문제

로그를 보다가 UTF-8 뭐시기.. 인코딩 뭐시기 하는 메시지가 쭉~~~~~~~~~뜨는 경우가 있습니다. 이 때는 소스 파일 인코딩이랑 서버의 인코딩이 맞지 않아서 그런데, 리눅스의 경우 export LANG=ko_KR.eucKR 이런식으로 인코딩을 변경할 수 있으니, 인코딩을 변경한 다음에 다시 빌드를 해봅니다. 되면 귿!

2. 라이브러리 참조 문제

사용자 삽입 이미지

필요한 라이브러리들을 제대로 참조 했는지, 내가 원하던 버전을 참조하고 있는지 확인합니다. -X 옵션을 주면 볼 수 있으니까 잘 보면서 확인합니다.

2-1. 원하던 라이브러리가 없다.

<dependency> 엘리먼트 안 에 정의한 <scope>를 의심해보시기 바랍니다. <scope>에 test라고 입력했다면, 소스 코드 compile 시점이 아니라 테스트 코드 compile 시점에 참조하게 됩니다. 따라서 mvn compile 할 떄는 해당 라이브러리가 없겠죠.

2-2. deps 들이 꼬였다.

deps가 꼬일 일이 없으면 좋겠지만, 간혹... 정말 간혹.. 꼬일 수도 있습니다. managed deps 들이랑, transient deps들이 잘못해서 꼬이면 정말 찾기가 힘들지만, 어떻게 하겠습니까? 로그를 보면서 찾아야 합니다. 찾으면 그 담엔 제외 시키던지, 아니면 새로 deps를 정의해서 nearest first 전략을 활용하면 됩니다.

저의 에피소스

문제는 금요일 저녁에 발생했는데, 해결은 방금 전에 했습니다. 똑같은 컴파일 에러.. 똑같은 상황... 10번도 넘게 빌드를 해봤지만, 문제 원인은 쉽게 떠오르질 않고, 왜 자꾸 spring에 있는 mock 패키지를 못찾는 다고 하는 건지.. 로컬에선 잘 돌아갔는데.. mvn compile을 해도 돌아갔는데.. 대체 왜 이러니...

조금 전 연결이 된 사부님에게 문제 상황을 말씀 드렸더니, 저번에도 겪은 문제(deps가 꼬인 경우)가 아니겠냐고, -X 옵션으로 확인해보라는 대답을 들었습니다. 속으로는 '아.. 안 되는데.. 그 문제면 정말 귀찮은데...' 이러면서 확인해 봤더니, 컴파일에러에서 찾지 못한다는 그 클래스를 가진 라이브러리가 없었습니다. '뭐지.. 왜 spring-test.jar가 없지?' 제가 돌린 프로젝트는 스프링 테스트를 확장한 클래스(테스트 클래스가 아니라 그냥 일반 소스 코드로써의 클래스)를 가지고 있었기 때문에 spring-test.jar가 필요했습니다. '올커니... scope 때문이구나.' 아니나 다를까. pom.xml을 열어봤더니, 해당 라이브러리가 test 스콥으로 잡혀있었습니다. 해당 라인을 지워버리니까 빌드는 무사히 성공~
신고
top


메이븐 플러그인 탐험기1 - UMLGraph

Build/Maven : 2008.07.28 13:18


소스코드를 보고 UML을 만들어 주는 UMLGraph라는 툴을 메이븐 빌드 과정 중에 플러긴으로 설치해서 리포트를 뽑아내는게 목적입니다. 물론 최종 목적은 코드와 모델을 항상 최신의 상태로 똑같은 상태로 유지하는 것입니다. 코드 보다 그림이 보기 좋은데, 그림이 실제 코드랑 다른 상태에서 어떤 결정을 하게되면.......

그래서 소스 코드에서 UML을 뽑아내는 툴을 사용해보기로 결정했습니다. 구글 검색을 통해서 잘 정리해둔, 불어로 된 블로그의 글 발견. 어차피 코드만 있으면 되기 때문에..ㅋㅋ

1. 먼저. Graphviz를 설치합니다. 이 녀석은 .dot 파일을 .png 파일로 만들어준 녀석입니다. 실제 그림을 들고 다니는 것 보다 그림을 그릴 정보들을 텍스트로 들고 다니는게 가볍기 때문일까요?

http://www.graphviz.org/Download..php

2. 환경 변수 path에 위에서 설치한 Graphciz의 bin 폴더를 설정해줍니다. 그 안에 있는 dot 이라는 명령어를 사용해야 하기 때문입니다.

3. 누가 doc 명령어를 사용하냐면, UMLGraph 메이븐 플러긴이 사용합니다. maven에 UMLGraph 플러그인 설정은 간단합니다.

    <reporting>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <configuration>
                    <doclet>
                        gr.spinellis.umlgraph.doclet.UmlGraphDoc
                    </doclet>
                    <docletArtifact>
                        <groupId>gr.spinellis</groupId>
                        <artifactId>UmlGraph</artifactId>
                        <version>4.6</version>
                    </docletArtifact>
                    <additionalparam>
                        -inferrel -inferdep -quiet -hide java.*
                        -collpackages java.util.* -qualify
                        -postfixpackage -nodefontsize 9
                        -nodefontpackagesize 7
                    </additionalparam>
                </configuration>
            </plugin>
        </plugins>
    </reporting>

자세한 설정 값은.. 나중에 살펴보구요.

4. mvn javadoc:javadoc 또는 mvn site를 실행하면, target/site 폴더가 생기고 그 아래에 apidocs 폴더가 생겼을 겁니다. 거기부터가 javadoc 문서입니다.

5. 구경하기

사용자 삽입 이미지

귿~

신고
top


exclusion을 하까마까

Build/Maven : 2008.07.16 14:19


옛날에 애마좐(Amazon) 유역에 사는 '치카마카'라는 거미의 거미줄로 실을 짜서 쫄티를 만들었다는 분이 있었는데 그걸 보면서 정말 웃겨 죽는 줄 알았던 기억이 납니다. 생각난 김에 동영상을 추가해둘까요? ㅋㅋ

13분 정도 되는 동영상을 잼난 부분만 편집한 동영상인데도 8분이나 합니다.ㅋㅋ

Maven의 폼(pom.xml)관리를 하다보면, 겪게 되는 의존성 헬.. 의존성 헬을 해결하려고 exclusion을 하다보면 발생하는 XML 헬.. 지옥의 연속을 겪게 됩니다. 그런데, 오늘 사부님과 M2Eclipse 플러긴 얘기를 하다가 화장실에 갔을 때 갑자기 exclusion을 하지 않아도 되는 아이디어가 떠올랐습니다. 제가 왜 그동안 exclusion을 했는지 모르겠더군요.

먼저 메이븐 폼 관리를 하다보면 겪게 되는 의존성 헬이란, A-> B, C->B 이런 참조 구조에서 A와 C가 참조하는 B 라이브러리의 버전이 다를 경우에 발생하는 문제인데요. 이 문제를 헬이라고 표현하는 이유는 저런 참조 구조를 발견하는게 쉽지 않기 때문입니다. 얽히고 얽혀있는 라이브러리들 간의 의존 관계에서 저러한 참조 관계를 찾아 낸다는 것은 참으로 피곤한 일 중에 하나 일 겁니다. 그래서 pom.xml에 의존성을 추가할 때 같이 딸려오는 의존성들을 일일히 확인하면서 추가할 필요가 있습니다.

Maven을 쓴다고 해서 종속성을 안중에서 Out 시킬 수 있느냐?  (2)

저 같은 경우 일일히 추가하는 라이브러리들의 pom.xml을 열어서 그 안에서 어떤 라이브러리를 어떤 버전을 사용하는지 보고, 스프링을 기준으로 그 보다 하위 버전을 가져올 경우에는 전부 exclusion을 시켰었습니다. 그랬더니, 수 많은 exclusion 설정(특히 하이버네이트 추가할 때)으로 pom.xml이 상당히 길어지고, 가독성도 떨어졌습니다. 그래서 pom.xml에 정의되어 있는 의존성들을 별도의 pom으로 각각 빼내고, spring.pom와 hiber.pom을 만들어서 그 안에 정의한 의존성들을 하나의 superpom.xml에서 참조하도록 설정을 했습니다.

Managed dependency는 무슨 뜻인가요?  (0)
Managed Depedency 네 녀석의 정체를 드디어 알았다.  (0)
기본적인 managed dependency 사용법  (2)

이렇게 하니까 superpom.xml은 좀 간결해 졌지만, 의존성 정보를 분리한다는 것이 역시 쉽지 않은 일이었습니다. 어떤 라이브러리들에 대한 의존성을 spring.pom에 정의하고 어떤 라이브러리들을 hiber.pom에 정의할 지 분명하지가 않으니까요. 그래서 요즘은 다시 의존성 정보들을 다시 superpom.xml로 가져올까도 생각 중입니다.

그전에 우선 정리를 좀 해야겠죠.

그 정리 작업 중에 하나가 바로 불필요한 exclusion 설정을 없애는 겁니다. A라는 프로젝트가 있고 이 프로젝트의 의존성이 다음과 같다고 가정하겠습니다.

A -> B -> C(1.0)
A -> D -> E -> C(2.0)

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

먼저, Transitive Dependency 정책에 따라 A 프로젝트의 pom.xml에 B와 D에 대한 의존성만 추가해도, E와 C 라이브러리를 가져오게 될 겁니다. 그런데 문제는 C 라이브러리를 B도 참조하고 E도 참조하는데 서로 참조하는 버전이 다르다는 겁니다.

이럴 경우 위 링크의 Transitive Dependency에 있는 Dependency mediation 규칙에 따라 "가장 가까운" 의존성을 사용하게 됩니다. 따라서 C(1.0)을 사용하게 되는거죠. 그런데 만약 같은 뎁쓰에 있다면 어떻게 될까요?

A -> B -> C(1.0)
A -> D -> C(2.0)

이 경우에는 메이븐의 버전에 따라 좀 다릅니다. 2.0.4에는 저런 경우에 어떻게 해야 할지 정의해둔 뭔가가 없습니다. 그런데 2.0.5 부터는 "먼저 선언된 순서"에 따라서 A 프로젝트의 pom에 B에 대한 의존성을 먼저 선언했다면 C(1.0)을 참조하게 될 겁니다.

자 저런 상황에서 C(1.0)이 아니라 C(2.0)을 사용하려면 어떻게 해야 할까요?

저는 exclusion을 사용해서, B에 대한 의존성을 정의할 때 다음과 같이 선었했었습니다.

        <dependency>
            <groupId>note.whiteship</groupId>
            <artifactId>B</artifactId>
            <version>1.0</version>
            <exclusions>
                <exclusion>
                    <groupId>note.whiteship</groupId>
                    <artifactId>C</artifactId>
                </exclusion>
             </exclusions>
        </dependency>

참으로 번거롭고, XML 설정할 것이 참 많았습니다. 그런데 문제는 잘 생각해보면 정말 쉽게 해결할 수 있는 거였습니다.

A -> C(2.0)

이렇게 의존성을 하나 추가해주기만 하면 끝나는 거였죠. 그렇게 되면

A -> B -> C(1.0)
A -> D -> E -> C(2.0)
A -> C(2.0)

또는

A -> B -> C(1.0)
A -> D -> C(2.0)
A -> C(2.0)

이렇게 전체 설정이 될테고 그럼 "가장 가까운" 녀석이 우선시 되기 때문에 C(2.0)을 쓰고 나머진 무시하게 될테니까요. 설정에서도 exclusion을 사용할 필요 없이 그냥 A의 pom.xml에 하나의 <dependency></dependency> 덩어리를 추가해주기만 하면 됩니다.

        <dependency>
           <groupId>note.whiteship</groupId>
           <artifactId>C</artifactId>
           <version>2.0</version>
        </dependency>

이렇게요. 흠~ 괜찮지 않나요. 그래도 exclusion을 해야 할까요?
신고
top


Spring Dynamic Modules Maven Archetype

Spring DM/Appendix D : 2008.07.09 11:16


스프링 DM은 메이븐 아키타입archetype을 제공하여 스프링 DM 번들 개발 시에 사용할 수 있는 자바 프로젝트 기본 틀을 제공한다. 아키타입을 실행하려면 다음의 명령어를 사용하면 된다.

mvn archetype:generate

메이븐 플러그인이 가용한 archetype을 보여줄 것이다. 그 중에서 spring-osgi-bundle-archetype을 선택하면 된다.(현재 32번으로 설정되어 있다.) 그리고 프로젝트에 필요한 몇 가지 정보를 입력한다.(그룹id, 아티팩트id, 버전, 패키지) 가용한 모든 아키타입과 버전은 여기를 참조하라.

물론 archetype:create를 사용해서 직접 아키타입을 설정하여 프로젝트를 생성할 수도 있다.

mvn archetype:create \
-DarchetypeGroupId=org.springframework.osgi \
-DarchetypeArtifactId=spring-osgi-bundle-archetype \
-DarchetypeVersion=   \
-DgroupId=<your-project-groupId>  \
-DartifactId=<your-project-artifactId> \
-Dversion=<your-project-version>

(과연 누가 저렇게 쓸까;;; 오타 없아 커맨드 창에 저걸 전부 입력 할 수 있는 사람~?)

둘 모두 같은 프로젝트 구조를 생성해준다. 그 안에 두 개의 스프링 설정 파일 src/main/resources/META-INF/spring/bundle-context.xml 와 src/main/resources/META-INF/spring/bundle-context-osgi.xml 가 있다. 프로젝트는 OSGi 번들로 패키지 형태가 설정되어 있다.

프로젝트에 MANIFEST.MF 파일이 없는데, 이 건 메이븐의 bnd 플러그인으로 자동 생성한다. 따라서 번들을 생성하고 싶으면 다음과 같이 하면 된다.

mvn package

번들 말고, MANIFEST.MF 파일만 생성하고 싶을 때는 다음과 같이 한다.

mvn org.apache.felix:maven-bundle-plugin:manifest

D.1. 생성한 프로젝트 살펴보기
  • OSGi 번들로 패키징 함.
  • MATA-INF/MANIFEST.MF 는 자동 생성함.
  • src/main/java/<package> 번들이 공개할 패키지
  • src/main/java/<package>/internal 번들이 공개하지 않을 패키지
  • src/main/resources/META-INF/spring/bundle-context.xml 번들 내부에서 사용할 스프링 설정 파일
  • src/main/resources/META-INF/spring/bundle-context-osgi.xml OSGI 관련 스프링 설정 파일
  • .project, .classpath, 그리고 build.properties 파일은 이 프로젝트를 이클립스 PDE 플러긴 프로젝트로 인식하게 해 줌.



신고

'Spring DM > Appendix D' 카테고리의 다른 글

Spring Dynamic Modules Maven Archetype  (0) 2008.07.09
top


메이븐을 대체할 것인가~ Buildr

Build/Buildr : 2008.07.03 17:20


루비로 만들고 있다는 새로운 빌드 툴. 사부님 소개로 알게 되었는데 괜찮은 녀석 같아 보입니다. Maven 보다 빠르고 확장성 좋고 편하고 쉽게 같은 일들을 할 수 만 있다면 Maven에서 Buildr로 안 갈아탈 이유가 없겠죠.

메이븐은 좀더 편의성을 도모하지 않으면 앞으로 점차 JAR 저장소로만 그 이름을 이어가게 되지 않을런지...사실 메이븐 저장소라고 하기도 뭐하죠. 이미 Ivy에서는 Common Repository라고 호칭하지 Maven Repository라고 하진 않더군요.

http://incubator.apache.org/buildr/index.html

사용자 삽입 이미지
망치로 'r'을 표현하는 센스.
신고

'Build > Buildr' 카테고리의 다른 글

메이븐을 대체할 것인가~ Buildr  (0) 2008.07.03
top

TAG buildr, maven

Ivy로 메이븐 저장소를 사용하기



Maven이 의존성 관리나, 다양한 플러그인들, 기본 와꾸 만들어주기(아키타입) 등의 기능 면에서 좋긴 한데, 학습 곡선 높고(Ant에 비해), 적응 시간이 오래 걸린다는(역시 Ant에 비해) 단점이 있습니다.

의존성 관리는 사실 사람이 개입하지 않고서 자동으로 처리하기는 참으로 난감한데, 그래도 초기에 한 번 고생하고, 주기적으로 한 시간간 정도만 고생하면 모든 라이브러리들을 CVS나 SVN에 들고다니지 않아도 되서 정말 편합니다. 구글코드 같은 경우 jar 파일을 다운로드/업로드 하다가 인터넷 연결 끊어져서 다시 커밋하거나 업데이트 받아야 하는 불상사가 생기기도 하죠. 따라서, 어찌됐든 의존성들은 버전 관리 저장소에서 빼주는게 훨씬 편합니다. 그러면서도 버전관리까지 해주는 Maven이 고맙기도 하지만, 사실 개발자가 고생한거지 Maven은 그냥 시킨대로 해줬을 뿐입니다. 그래도 하나 고마운게 있다면, 저장소. 로컬 저장소에 없으면 원격 저장소에서 다운로드 받을 수 있는 그 저장소가 좋습니다.

그런데 Ant에서도 이 메이븐 저장소(본문에서는 Common Repository라는 단어를 사용하고 있는데, 메이븐만 이용할 수 있는 저장소가 아니니까 이게 더 맞는 표현 같네요. 번역은 "공공 저장소" 라고 하고 있습니다.)를 이용할 수 있습니다. 따라서 굳이 Maven을 학습하지 않고 Ant 서브프로젝트인 Ivy의 task 몇 개만 살펴보시면 됩니다.

http://www.ibm.com/developerworks/java/library/j-ap05068/index.html

현재 번역 중이며 7월 중에 IBM DeveloperWorks에 올라갈 것 같네요.

신고
top


Maven을 사용하세요. 코딩이 편해집니다.

Build/Maven : 2008.05.19 23:14


mvn eclipse:eclipse -DdownloadSources=true -DdownloadJavadocs=true

eclipse:eclipse는 단순하게 메이븐 프로젝트를 이클립스 프로젝트로 변화해주는 것 뿐만이 아니라 이런 사랑스럽기까지한 일도 해줍니다.

대부분 자바 프로젝트에서 수 많은 라이브러리들을 사용하고 계실 줄로 압니다. 그 중에서 오픈소스도 여럿 되고 그러다 보면 소스 코드도 볼 수 있는데, 이클립스에서 "Alt + 왼쪽 클릭"으로 링크를 타고 들어가듯이 소스를 네비게이션 하는 하루 일과 중에서도 꽤 큰 비중을 차지할 것입니다.

그런데 그렇게 하다보면 좀 답답하시죠? 소스 코드는 안 나타나고 벽에 부딪힌거 마냥 .class 파일이 나타나서 길을 가로막습니다. 그래도 뭐 방법은 있습니다. attach 머시기 메뉴를 사용해서 소스 코드가 있는 위치를 알려주면 됩니다. 귀찮죠.

그래서 위의 명령어가 멋진겁니다. 한 번 사용하시면 해당 프로젝트가 참조하는 라이브러리의 소스 파일과 javaDoc을 다운로드 해옵니다. 멋지죠. 저 명령어 한 번 사용하고 이클립스에서 F5키로 프로젝트 다시 로딩 해주고(이게 꼭 필요한 과정인지는 모르겠습니다. 전 습관처럼 콘솔창에서 프로젝트가지고 장난치면 이클립스에서 매번 F5키를 눌러줍니다.) 소스 네비게이션을 하다보면 감탄하게 될 겁니다.

아예 플러그인 기본값으로 파라미터 설정해서 mvn eclipse:eclipse만 실행해도 소스코드랑 JavaDoc을 받아오게 설정할 수 도 있습니다. 참조 
신고
top


Maven의 archetype:create DEPRECATED 되다.

Build/Maven : 2008.05.13 21:14


이런.. 아랫 글은 쓰자마자 Deprecated 해야겠네요.

mvn archetype:create 어쩌구 저쩌구를 실행하고 콘솔에 뜨는 메시지를 잘 보면, generate로 Deprecated 됐다는 메시지를 볼 수 있습니다. 돌리다가 나중에 해봐야지 그러고 그냥 지나쳤다가, 토비 사부님께서 언급하셔서 실행해보고 놀랐습니다.

사용자 삽입 이미지

처음엔 저렇게 중간에 한 번 확인하는 기능이 추가됐구나.. 어째 좀 귀찮을 수도 있겠는데.. 하고 넘어가려다 다시 mvn archetype:generate만 쳐보라고 하셔서 쳐봤더니..

어머나..
사용자 삽입 이미지

아키타입을 선택하고 그룹 아이디, 아티팩트 아이디, 버전, 기본 패지키를 입력할 수 있게 되었습니다. 잘 보시면 32번에 스프링 DM 프로젝트도 있습니다.

에구구.. 아랫글은 쓰자마자 삶이 끝나네요. 하루살이도 아니고 한시간살이급 포스팅이었습니다.

저 목록들은 archetype-catalog.xml에서 읽어오는데, Q4E 플러그인을 사용해서 커스텀 아키타입을 설정하는 방법도 있습니다.
신고
top


Maven으로 Spring DM Project 만들기(Eclipse에서 import 가능)

Build/Maven : 2008.05.13 18:03


참조
http://www.springframework.org/node/361
http://www.springframework.org/node/360
http://opensource.atlassian.com/confluence/spring/display/DOC/HowTo+build+Spring-Osgi+using+Maven+2
http://static.springframework.org/osgi/docs/1.1.0-m2/reference/html/appendix-archetype.html

기본 명령어는 다음과 같습니다.

mvn archetype:create \
-DarchetypeGroupId=org.springframework.osgi \
-DarchetypeArtifactId=spring-osgi-bundle-archetype \
-DarchetypeVersion=${version}   \
-DgroupId=<your-project-groupId>  \
-DartifactId=<your-project-artifactId> \
-Dversion=<your-project-version>

${version} 에는 배포된 스프링 DM 프로젝트 버전을 설정해주면 됩니다. 최신 버전인 1.1.0-m2 라고 설정하시면 되겠죠.

your-group-gourpId, your-project-artifactId, your-project-version 이 값들은 뭔지 아시리라.. 생각하고 생략하겠습니다.

그럼 대충 이런걸 타이핑해야 하는데... 정말 끔찍한 일이죠.

mvn archetype:create -DarchetypeGroupId=org.springframework.osgi -DarchetypeArtifactId=spring-osgi-bundle-archetype -DarchetypeVersion=1.1.0-m2 -DgroupId=whiteship -DartifactId=springdmweb -Dversion=1.0

이걸 어떻게 오타없이 타이핑하죠? 그래서 전 그냥 텍스트 파일에 붙여넣은 다음 확장자를 bat 파일로 바꿔서 dos 커맨드 창에서 createSpringDMProject.bat를 실행시킵니다.

필요하신 분들은 다운 받으신 다음에 groupdId와 artifactId 등을 수정하신 다음 사용하시면 됩니다. 그렇게 생성된 프로젝트는 이클립스에서 바로 import 해서 사용할 수 있습니다.

사용자 삽입 이미지
기본으로 테스트 클래스들까지 만들어 줍니다. 멋져부러...
신고
top


Q4E 플러그인 사용기 1

Build/Maven : 2008.04.19 09:30


맥용 이클립스 STS(Spring Tool Suite)에서 Q4E를 설치하고 add Maven dependency management를 해도 메이븐 라이브러리가 클래스패스에 생기지 않는 문제가 발생했습니다.

그럴 때는 프로젝트 루트 폴더에 있는 .classpath 파일에 다음의 한 줄을 추가해 주면 문제가 해결됩니다. .으로 시작하는 파일들을 보려면, Navigator 뷰에서 프로젝트를 보거나, Package Explorer의 필터에서 .* resources에 있는 체크를 없애면 됩니다.

<classpathentry kind="con" path="org.devzuz.q.maven.jdt.core.mavenClasspathContainer"/>



신고
top

TAG Eclipse, Mac, maven, Q4E

pom.xml에 종속성 추가하기





본 영상에서는 m2eclipse를 사용했지만, 사용한 기능은 매우 기본적이며 다른 기능들은 매우 미약하기 때문에, q4e 사용을 권장합니다.

위 동영상에서는 그냥 간단하게 라이브러리가 어떻게 추가되는건지만 확인해 보세요. 잘 보시면 transitive하게 spring-core가 의존하는 commons-logging을 가져온 것도 볼 수 있습니다. 바로 이러한 transitive dependency 추가 기능이 maven의 장점이면서 단점이 되기도 하는데요. 그걸 잘 다루면 별 일 안 생깁니다.
신고
top

TAG maven, pom.xml

이클립스용 Maven 플러그인 Q4E

Build/Maven : 2008.04.18 08:31


http://code.google.com/p/q4e/

플젝 홈이 구글에 있지만, 공식 이클립스 프로젝입니다. 이클립스 재단에 낸 제안서가 받아들여졌다고 합니다. 이걸 깜빡하고 m2eclipse 플러그인을 설치한 동영상까지 찍어놨는데 공개할까말까 말설여집니다. m2eclipse보다 훨씬 좋습니다.

사용자 삽입 이미지

m2eclipse의 허접한 중앙 저장소에서 검색/추가하는 기능은 없는 듯 하고 대신에 artifact를 로컬 저장소에서 검색하여 추가하는 기능이 있습니다.

사용자 삽입 이미지
그냥 보면서 감상하면 됩니다. 음.. 저게 저기서 물려오는군.. 등등의 정보를 한눈에 볼 수 있습니다.

사용자 삽입 이미지
이게 아주 유용합니다. 이걸 보면, exlusion을 어디다가 써야 할지 보입니다. 각 창이 유기적으로 물려있기 때문에, 해당 버전의 아티팩트가 어디, 어디서 끌려온 것인지, 같은 아티팩트의 다른 버전이 몇 종류나 존재하는지를 볼 수 있습니다.

이밖에도 메이븐 프로젝트 생성등. 여러가지 기능이 있습니다. Maven을 사용하시는 분들에게 강추합니다.
신고
top


기본적인 managed dependency 사용법

Build/Maven : 2008.04.17 15:22


사용자 삽입 이미지


A BOM은 오타가 아닙니다. Bill Of Material 이라는 뜻입니다. B POM은 그냥 보통의 POM 입니다. 위의 경우 A BOM(얘도 결국은 packing이 POM입니다.)을 B POM이 상속 받고 있습니다. 상속 받으면 모든 부모의 모든 속성을 자식 입장에서 사용할 수 있습니다. 따라서 A에 정의한 DM(dependecy management) 섹션도 B POM으로 상속이 됩니다.

B POM에서는 한 개의 라이브러리를 추가합니다. 그런데 버전과 스콥을 명시하지 않고 있습니다. 오호.. 이러면 안 되죠. 원래는 버전까지는 꼭 명시해줘야 합니다. 버전을 적어주지 않으면 메이븐이 종속성 추가하닥 에러 납니다. 그런데 위의 경우에는 에러가나지 않습니다. 명시한 groupId와 artifactId에 해당하는 종속성의 Bill Of Material이 DM 안에 들어있기 때문입니다. DM을 보구서.. 아항..whiteship의 a라는 라이브러리는 1.0이고 runtime scope으로 추가해야 하는 군... 이라고 알아챕니다.

이런게 언제 유용할 까요.

whiteship의 a라는 라이브러리를 runtime scope으로 참조하는 다른 프로젝트들 C POM, D POM, E POM 등이 있을 때 매번 C, D, E에도 다음과 같은 코드가 들어갈 겁니다.

<dependency>
<groupId>whiteship</groupId>
<artifactId>a</artifactId>
<version>1.0</version>
<scope>runtime</version>
</dependency>

그런데 위의 A BOM을 상속 받으면

<dependency>
<groupId>whiteship</groupId>
<artifactId>a</artifactId>
</dependency>

이렇게만 설정해 됩니다.

그런데.. Spring BOM, Hinbernate BOM, Test BOM과 같이 여러 종류의 BOM이 있으면 어떻게 해야 할까요? 단일 상속 밖에 안 되는데.. 그럼 managed dependency는 못 쓰는걸까요?

네 못 씁니다. Maven 2.0.9 이전까지는 그냥 일일히 버전과 scope 명시해 줘야 합니다. 그런데 몇일전에 2.0.9가 나왔죠. 캬캬캬. 몇일동안 끙끙 앓고있던 문제인데 풀고나니 별거 아니네요. 이론...

 이제 남은일은 이 기능을 이용해서 어떻게 효율적인 BOM과 POM을 구성하느냐 입니다.

봄폼봄폼봄폼봄폼봄폼폼폼봄봄봄폼봄폼봄봄봄폼폼
신고
top


Managed Depedency 네 녀석의 정체를 드디어 알았다.

Build/Maven : 2008.04.17 14:59


참조:
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism
http://maven.apache.org/ref/current/maven-model/maven.html#class_dependencyManagement

이 녀석의 정체는... depedency 정보(버전, Scope, 추이성)을 한 곳에 정리해둔=MANAGED 의존성=Denpendency을 사용하겠다는 것입니다. Maven 2.0.9에 추가된 import managed dependency는 바로 이 managed dependency에 관한 내용입니다.

이전에는 상속을 통해서 managed dependency를 이용할 수 있었습니다.

그런데 단일 상속만 되기 때문에 managed dependency를 사용하고 싶은 프로젝트가 여러 개일 때는 import scope을 이용해서 상속이 아닌 위임delegation을 사용해서 여러 개의 프로젝트를 import scope으로 dependencyManagement에 추가해두면, 해당 프로젝트들이 가지고 있는 managed dependency를 사용할 수 있습니다.

이 개념을 이해하기 위해.. 거의 삼일간 고생했네요.

처음에는

<dependencies>
  <dep..cy>
     ..
  </dep..cy>
  <dep..cy>
    ..
  </dep..cy
  ..
</dependencies>

이거랑

<dependencyManagement>
<dependencies>
  <dep..cy>
    ..
  </dep..cy>
  <dep..cy>
   ..
  </dep..cy
  ..
</dependencies>
</dependencyManagement>

이거랑 별 차이가 없는 건 줄 알았는데...

엄청나게 많은 차이가 있었습니다.
신고
top


Maven으로 이클립스 프로젝트 만들기 - Screen Cast





이 동영상도 만들어 둔지 한참인데 이제야 올려봅니다.


http://keessun.blip.tv/#836768
신고
top


Managed dependency는 무슨 뜻인가요?

Build/Maven : 2008.04.14 21:43


스프링 DM을 읽다가도 managed destroy라는 단어를 보고.. 이게 무슨 말인가 곰곰히 생각을 한 적이 있었는데요. 오늘도 저 단어를 만나서 고생을 했습니다. Maven 2.0.9에 새로 추가된 import managed dependency를 적용해보려고 했는데, 한바탕 Maven 지옥에 들락거리다 지쳐서 오늘은 실패를 기록하고 이만 집에 들어가려고 합니다.

Managed Dependency 넌 대체 무엇이니?
As an example, consider the following projects:

   1. ThirdParty 1.0 - contains declarations of third party jars.
   2. Project A 1.0 - A project that uses declarations in ThirdParty and produces some number of versioned artifacts.
   3. Project B 1.0 - A project unrelated to Project A. It also uses declarations in ThirdParty and produces some number of versioned artifacts.
   4. Project C 1.0 - Has dependencies on ThirdParty, Project A, and Project B.

In Maven 2 it is not possible for Project C to use the managed dependencies from both A and B since neither has any direct relationship to the other.
참조: http://docs.codehaus.org/display/MAVEN/Importing+Managed+Dependencies

이게 무슨 이야기인지 이해가 안 되고 있습니다.

C가 A랑 B를 dependency에 추가하면, A와 B가 사용하는 dependency들도 C에 추가되어서 C프로젝트에서도 사용할 수 있는데, 대체 MD가 뭐길래.. C에서 사용하는게 불가능한 걸까요.
신고
top


Artifactory 설치하기

Wiki : 2008.03.18 18:42


참조 : http://www.jfrog.org/confluence/display/RTF/Installing

필요조건
- JDK 1.5 이상
- FF 2.0, IE 7 이상

설치방법
- Jetty 사용해서 Standalone 형태로 설치
- Servlet Container에 배포(ex. Tomcat)

Jetty 사용해서 설치하기
- JAVA_HOME 환경변수가 세팅되어 있어야 함.
- Window에서 설치할 때는 bin 폴더의 artifactory.bat 실행.
- Linux에서 설치.
    - artifactoryctl check 로 환경 변수 세팅 제대로 되어 있는지 확인.
    - fore ground에서 실행: artifactory.sh
    - demon으로 실행: artifactoryctl check|start|stop
- Linux 서비스로 등록하기: install.sh
    - 서비스 등록됐는지 확인하기: service artifactory check 또는 /etc/init.d/artifactory check
    - 서비스 시작: service artifactory start 또는 /etc/init.d/artifactory start
    - 로그보기: tail -f $ARTIFACTORY_HOME/logs/artifactory.log

Tomcat에 설치하기
- ARTIFACTORY_HOME 환경변수를 추가하여 압축을 풀어제낀 폴더 경로를 설정.
vi /etc/profile
export ARTIFACTORY_HOME=풀어제낀 폴더
source /etc/profile
- 압축 풀어제낀 폴더/webapps/artifact.war을 컨테이너에 배포.

첫 번째 로그인 하기
- http://localhost:8081/artifactory (Standalone으로 설치했을 때)
- admin/password
신고

'Wiki' 카테고리의 다른 글

Clover 2.3.2(for Maven)  (4) 2008.09.22
Artifactory 설치하기  (0) 2008.03.18
Confluence 개인용은 공짜.  (2) 2007.11.27
Confluence Markup  (2) 2007.04.24
Confluence Calander 사용법  (4) 2007.03.12
Confluence에서 PDF로 빼낼 때 한글 깨짐 문제 해결  (6) 2007.02.13
Confluence User Guide  (0) 2007.02.12
Confluence 설치하기  (0) 2007.02.10
XWiki 설치  (0) 2007.01.25
JSPWiki 플러긴 설치  (0) 2007.01.07
JSPWiki 플러그인  (0) 2007.01.05
top

Wiki : 2008.03.18 18:42 Trackback. : Comment.

Maven + Clover

Good Tools : 2008.03.18 18:01


설치하기

  • 빌드 도구에 따라 설치하는 방법이 다르다.
  • Maven2에 설치하려면 플러그인을 pom,xml에 설정해주면 된다.
  • 라이선스 파일을 받아야한다.(다른 프로젝트나 계정의 라이선스도 동작하는지 확인.)

설정하기

  • settings.xml에 atlassian의 maven-clover 플러그인을 받을 수 있는 repository를 등록해준다.
<settings>
<pluginGroups>
<pluginGroup>com.atlassian.maven.plugins</pluginGroup>
</pluginGroups>
<profiles>
<profile>
<id>dev</id>
<pluginRepositories>
<pluginRepository>
<id>atlassian-m2-repository</id>
<name>Atlassian Maven 2.x Repository</name>
<url>http://repository.atlassian.com/maven2</url>
</pluginRepository>
</pluginRepositories>
</profile>
</profiles>
<activeProfiles>
<activeProfile>dev</activeProfile>
</activeProfiles>
</settings>
  • pom.xml에 플러그인을 설정한다.
<build>
<plugins>
<plugin>
<artifactId>maven-clover-plugin</artifactId>
<groupId>com.atlassian.maven.plugins</groupId>
<configuration>
<licenseLocation>clover.license</licenseLocation>
<generatePdf>false</generatePdf>
<generateXml>true</generateXml>
<generateHtml>true</generateHtml>
</configuration>
</plugin>
</plugins>
</build>

사용하기

  • mvn clover:instrument clover:clvoer
  • 테스트 커버리지를 강제할 수 있다.
  • 생성할 리포트를 선택할 수 있다.
  • Instrument 대상이 되는 자바 파일들을 필터링 할 수 있다.

참조

신고
top


Maven을 쓴다고 해서 종속성을 안중에서 Out 시킬 수 있느냐?

Build/Maven : 2008.03.03 19:03


그런데 요즘, Maven과 JIA, Confluence, Bamboo, Clover, FishEye를 사용해서 Continuous Integration을 하면서 매우 재밌는 일들(주로 Maven과 관련된)이 많이 발생하고 있습니다. 그 중 방금전에 있었던 Maven과 관련된 매우 따끈따끈한 이슈 하나를 소개해 드리고자 합니다.

프로젝트 라이브러리들 간의 종속성을 "Out of 안중"까지는 아니더라도.. 아~주 편하게 쓰려고 Maven을 공부하기 시작했었습니다. 그런데...

잘~ 돌던 빌드가 실패했다는 이메일이 저에게 날아왔습니다. 구글토크를 항상 켜두는 저는 Bamboo에서 빌드 결과를 매번 메일로 보내도록 설정해 두었기 때문에, 금방 알 수 있었습니다. 그리고 누가 작업을 한 것인지가 바로 이메일 제목에 나와있습니다. 정말 사용자가 원하는 정보를 원하는 위치에 보여주는 Atlasian의 Considerable Email(이런 용어 없습니다. 그냥 제가 붙인겁니다.)에 놀라지 않을 수가 없었습니다.

Anyway, 왜 빌드에 실패했는지 보기 위해 로그를 봤습니다. 빌드 과정을 Bamboo가 그대로 로깅 해두고, 보여주기 때문에 에러 메시지를 금방 확인할 수 있었습니다.

빌드 실패의 원인은 컴파일 실패. 컴파일 실패시 발생한 에러는

cannot find symbol: ClassUtils.

ClassUtils는 스프링에서 제공하는 수 많은 유틸성 클래스들(언제 한 번 싹다 정리하려고 합니다.) 중에 하나입니다.

ClassNotFound도 아니고..이게 무슨 에러인가 생각해보면서, 자바 기초가 이리도 없는가 하는 생각에 잠기기 시작하면서 구글에서 저 에러 메시지로 검색해서 어떤 상황에 발생할 수 있는지도 대강 살펴봤지만.. 그리.. 도움이 되는 메시지는 못봤습니다.

이 빌드 전에는 빌드가 성공했는데, 이번 빌드가 실패했다.

그럼 문제는 이번에 어떤 수정 사항으로 인한 것인데, 어떤 수정이 있었는지도 Bamboo에서 확인할 수 있습니다. (글을 쓰다보니 이게 Maven 이슈 글인지, Bamboo 마케팅 글인지 점점 햇갈리네요.) 암튼 거길 보니까 pom.xml밖에 없습니다.

pom.xml을 보니까, spring-security 라이브러리가 추가되었습니다. 그래.. 문제는 여기 있을꺼다. 라고 거의 확신을 하고, 이전에도 Maven 종속성 출동 문제 때문에, 일일히 라이브러리르 뒤져본적이 있었기 때문에, 이번에는 그나마 좀 수월하게, spring-security의 pom.xml 파일을 찾을 수 있었습니다.

그 파일을 열어보니, spring을 모듈별로 가져와서 사용하고 있는데, 버전도 명시가 되어 있지 않고, 이미 이 프로젝트에 추가되어 있는 라이브러리들도 중복해서 가져오고 있었습니다. 그것만 보고는 100% 확신할 수는 없었지만. 대략 정리가 되었습니다.

ClassUtils가 이미 있는데, spring-secutiry가 또 가져오고(spring-support 모듈에서), 그래서 두 개의 다른 버전의 클래스가 존재하는데 이 둘 중에 뭘 써야 할지 모르니까. Cannot find symbol 이군..

그래서 현 프로젝트의 pom.xml을 수정해서 spring-security를 가져올 때, 이미 프로젝트에 존재하는 라이브러리들은 가져오지 않도록 설정을 해주었습니다. 비록 이 작업이 한 문장으로 표현이 되긴 하지만, 결코 엘레강트한 작업은 아닙니다.

1. 일일히 어떤 라이브러리들을 가져오는지 pom.xml에서 확인하고, 현재 프로젝트의 pom.xml에 존재한 녀석인지 확인하고, 있으면 빼줍니다. exclunsion 엘리먼트를 사용합니다.

2. 현 프로젝트의 pom.xml에 없는 라이브러리인데, spring의 pom.xml에 optional로 등록되어 있다. 그럼 그 중에 버전이 높은 녀석을 등록해줍니다.

3. 현 프로젝트의 pom.xml에 없는 라이브러리이고, spring의 pom.xml에 optional로도 등록되어 있지 않다. 그러면 추가합니다. 추가할 때는 별도의 코드를 적을 필요는 없습니다. 다만 주석으로 어떤 라이브러리가 추가되는지 적어두면 나중에 용이하겠죠.

자.. 이 정도되면, 제목에 대한 답은 안해도 되겠죠?
신고
top







티스토리 툴바