Whiteship's Note

'Build'에 해당되는 글 51건

  1. 2010.08.19 [메이븐 프로파일] 운영시 배포할 설정 파일과 개발시 배포할 설정 파일 샤샥 (1)
  2. 2010.02.25 [Maven] 빌드 할 떄 특정 폴더 삭제하기 (2)
  3. 2010.02.16 [Maven] Exec Maven Plugin 사용하여 자바 프로그램 실행하기 (2)
  4. 2009.11.04 [메이븐] 하이버네이트 플러그인
  5. 2009.07.27 메이븐에서 컴파일이 되지 않을 땐, 인코딩 의심하기 (2)
  6. 2009.06.09 AspectJ 메이븐 플러그인
  7. 2009.05.19 메이븐 배포나 설치시 소스 코드 배포하기 (2)
  8. 2009.05.14 메이븐 상식: 기본 페이스(phase) (2)
  9. 2009.02.19 메이븐 Maven 2.0.10 배포! (6)
  10. 2008.11.03 아키타입(메이븐 프로젝트 베이스) 만들기
  11. 2008.10.23 Maven 프로젝트 의존성 파일들 패키징하기 (2)
  12. 2008.10.21 Maven 같지 않은 Maven 프로젝트 만들기 (2)
  13. 2008.10.20 Maven 멀티 모듈 프로젝트 구성하기 (2)
  14. 2008.10.14 OSAF 메이븐 저장소 사용하기 (13)
  15. 2008.09.29 메이븐 settings.xml 살펴보기
  16. 2008.09.08 메이븐으로 원격 저장소에 라이브러리 배포하기 (6)
  17. 2008.09.08 Maven을 활용한 배포
  18. 2008.08.18 Nexus - Maven Repository Manager 설치하기 (8)
  19. 2008.07.28 로컬에서는 무사히 빌드가 되는데, 왜 서버로 올라가서 CI가 돌리면 컴파일 에러가 날까
  20. 2008.07.28 메이븐 플러그인 탐험기1 - UMLGraph
  21. 2008.07.24 Maven 2.0.10 배포 임박!!! (8)
  22. 2008.07.16 exclusion을 하까마까
  23. 2008.07.03 메이븐을 대체할 것인가~ Buildr
  24. 2008.05.19 Maven을 사용하세요. 코딩이 편해집니다. (11)
  25. 2008.05.13 Maven의 archetype:create DEPRECATED 되다.
  26. 2008.05.13 Maven으로 Spring DM Project 만들기(Eclipse에서 import 가능)
  27. 2008.04.19 Q4E 플러그인 사용기 1 (2)
  28. 2008.04.18 이클립스용 Maven 플러그인 Q4E (10)
  29. 2008.04.17 기본적인 managed dependency 사용법 (2)
  30. 2008.04.17 Managed Depedency 네 녀석의 정체를 드디어 알았다.

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

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


[Maven] 빌드 할 떄 특정 폴더 삭제하기

Build/Maven : 2010.02.25 18:15


http://maven.apache.org/plugins/maven-clean-plugin/examples/delete_additional_files.html

어헉...

빌드할 때 가끔 pom.xml에서 라이브러리 올렸는데 버전만 다르고 여러 개개 lib 폴더에 들어가는 바람에 에러나 생기는 현상이 종종 있는데;;

그걸 방지하기 위해

            <plugin>
                <artifactId>maven-clean-plugin</artifactId>
                <version>2.4</version>
                <configuration>
                    <filesets>
                        <fileset>
                            <directory>web/WEB-INF/lib</directory>
                        </fileset>
                        <fileset>
                            <directory>web/WEB-INF/classes</directory>
                        </fileset>
                    </filesets>
                </configuration>
            </plugin>

여기서 clasess 폴더는 빠져도 되지만 lib 폴더는 꼭 넣도록 합시다.

저녁 약속을 깜빡하는 바람에 초스피드 블로깅
저작자 표시
신고
top


[Maven] Exec Maven Plugin 사용하여 자바 프로그램 실행하기

Build/Maven : 2010.02.16 11:07


참조: http://www.vineetmanohar.com/2009/11/02/3-ways-to-run-java-main-from-maven/

이 플러그인을 사용하기 전까지 주로 사용하던 방법은 main() 메서드를 가지고 있는 자바 파일을 만들지 않고 그냥 테스트 클래스를 만드는 겁니다. 그러면 mvn test를 실행할 때 자동으로 실행되죠ㅋㅋ. 하지만 이 방법은 왠지 편법 같아서 main() 메서드를 가지고 있는 클래스를 실행해볼까 해서 찾아봤더니 exec 플러그인이 있더군요.

http://mojo.codehaus.org/exec-maven-plugin/index.html

1. pom.xml에 플러그인 추가하기

<plugins>
...
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>exec-maven-plugin</artifactId>
                <version>1.1.1</version>
            </plugin>
...
</plugins>

2. goal

이 플러그인이 제공하는 goal은 세 가지가 있습니다.

exec:exec 외부 프로그램 실행하기
exec:help exec 플러그인 도움말 보기
exec:java 현재 VM에 있는 메인 클래스 실행하기

3. 사용하기

흠.. compile은 별도로 해줘야 하기 때문에 mvn:compile 정도를 한 뒤 mvn:java -Dexec.mainClass="실행할 클래스명"을 할 수도 있지만... 불편하죠;

mvn test만 사용해서 실행하도록 executions를 이용해서 test Phase에 java Goal을 끼워줍니다. 즉 pom.xml에 플러그인 설정을 다음과 같이 해줍니다.

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>exec-maven-plugin</artifactId>
                <version>1.1.1</version>
                <executions>
                    <execution>
                        <phase>test</phase>
                        <goals>
                            <goal>java</goal>
                        </goals>
                        <configuration>
                            <mainClass>whiteship.backup.BackupRunner</mainClass>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

그럼 이제 mvn test을 실행하는 .bat 파일 만들어 놓고 윈도우의 '예약작업'으로 주기적으로 실행하도록 해놓으면 백업 배치 끝!! (리눅스라면 cron으로..블라 블라)

ps1: 어떻게보면 이 방법이 자바 애플리케이션을 서버처럼 띄워서 스케줄링하는 것 보다 시스템도 효율적으로 쓰는 것 같고 간편하네요.

ps2: 특히 윈도우의 예약작업은 리눅스의 cron처럼 공부하지 않아도 쓸 수 있으니.. 이럴 땐 윈도우도 좋네요.
신고
top


[메이븐] 하이버네이트 플러그인

Build/Maven : 2009.11.04 10:34


참조:
http://kwon37xi.springnote.com/pages/2275410
http://mojo.codehaus.org/maven-hibernate3/hibernate3-maven-plugin/componentproperties.html

1. 메이븐 pom.xml 에 플러그인 추가하기

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>hibernate3-maven-plugin</artifactId>
                <version>2.2</version>
                <configuration>
                    <componentProperties>
                        <drop>false</drop>
                        <create>true</create>
                        <format>true</format>
                        <export>false</export>
                        <jdk5>true</jdk5>
                        <outputfilename>schema.ddl</outputfilename>
                        <configurationfile>src/hibernate.cfg.xml</configurationfile>
                        <propertyfile>database.properties</propertyfile>
                    </componentProperties>
                    <components>
                        <component>
                            <name>hbm2ddl</name>
                            <implementation>annotationconfiguration</implementation>
                        </component>
                    </components>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>postgresql</groupId>
                        <artifactId>postgresql</artifactId>
                        <version>8.2-507.jdbc3</version>
                    </dependency>
                </dependencies>
            </plugin>

굵은 글씨 부분은 사용하시는 프로젝트에 맞게 변경해야 할 부분입니다.

일단, 구조를 보면 configuration에 크게 두가지가 들어있는데, 하나는 component들을 담고 있는 components이고, 다른 건 componentProperties입니다. 제가 사용하려는건 hbm2ddl이기 때문에 hbm2ddl 컴포넌트만 등록해 두었습니다. 그와 관련된 설정은 componentProperties여기에 들어있죠.

먼저, drop은 기존의 DB의 테이블 들을 깔끔하게 날려버릴 sql을 만들지 여부를 나타냅니다. 기본 값은 false기 때문에 위와 같은 설정에서는 생략해도 됩니다.

create는 뭔지 아시겠죠? 패스. 기본값은 true입니다.

format은 보기 좋은 형태로 SQL 출력 형태를 다듬어 줍니다. 기본 값은 false입니다.

export는 현재 DB에 적용을 할꺼냐는 건데.. 위험하기 때문에 일단은 false가 좋겠습니다. 그런데 기본값은 true입니다. 하지만, DB 마이그레이션 자동화가 되어있다면 true로 놓고 매번 DB 스키마를 새롭게 업데이트 한 다음 백업했던 데이터를 채워주면 되겠습니다.

jdk5는 역시 패스. 기본값은 false입니다.

outputfilename는 ddl을 출력할 파일 이름인데, 이 파일은 프로젝트/target/hibernate3/sql 밑에 생깁니다.

configurationfile는 하이버네이트 설정 파일 위치를 알려줍니다.

propertyfile는 하이버네이트가 DB에 접근할 때 필요한 프로퍼티를 가지고 있는 파일 위치를 알려줍니다.

2. 하이버네이트 설정 파일 만들기

<!DOCTYPE hibernate-configuration SYSTEM
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

<hibernate-configuration>
    <session-factory>
        <mapping class="springsprout.domain.Member" />
        <mapping class="springsprout.domain.Comment" />
        <mapping class="springsprout.domain.Resource" />
        <mapping class="springsprout.domain.Right" />
        <mapping class="springsprout.domain.Role" />
        <mapping class="springsprout.domain.wiki.Histories" />
        <mapping class="springsprout.domain.wiki.History" />
        <mapping class="springsprout.domain.wiki.WikiDocument" />
        <mapping class="springsprout.domain.study.Study" />
        <mapping class="springsprout.domain.study.Presentation" />
        <mapping class="springsprout.domain.study.Meeting" />
        <mapping class="springsprout.domain.study.Attendance" />
        <mapping class="springsprout.domain.seminar.Seminar" />
        <mapping class="springsprout.domain.seminar.SeminarComer" />
        <mapping class="springsprout.domain.notice.Notice" />
        <mapping class="springsprout.domain.main.Graffiti" />
        <mapping class="springsprout.domain.file.UploadFile" />
    </session-factory>
</hibernate-configuration>

애노테이션기반으로 설정한 경우에는 위와 같이 애노테이션으로 맵핑한 클래스들을 알려줍니다.

3. 하이버네이트 프로퍼티 추가하기

hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
hibernate.connection.username=***
hibernate.connection.password=***
hibernate.connection.driver_class=org.postgresql.Driver
hibernate.connection.url=***

이런 설정을 프로퍼티 파일에 추가하거나 새로운 프로퍼티 파일을 만들어서 추가해줍니다.

끝!!!

이제 hbm2ddl 골을 실행할 수 있습니다.

제가 원한건 새로운 스키마용 ddl이 아니라, 기본 DB에서 수정할 것들만 알려주는 수정용 ddl인데 어떻게 설정해야 되는지 잘 모르겠군요. 그런 기능을 지원해주는 건지 아닌지도 몰겠고.. componentProperties를 보면 update 속성이 있긴한데, 이 녀석에 true를 줘버리면 ddl 자체가 안 만들어집니다. @_@;;


신고
top


메이븐에서 컴파일이 되지 않을 땐, 인코딩 의심하기

Build/Maven : 2009.07.27 12:59


mvn compile을 했는데.. 다음과 같은 에러가 발생하는 경우가 있습니다.


직관적으로 인코딩 문제인지.. 의심할 수가 없는 에러 메시지지만, javac를 이용해서 직접 컴파일을 하려고 들면 한글이 깨진 상태로 컴파일이 되지 않는 모습을 볼 수 있습니다.

구글신을 통해 같은 문제를 겪은 분의 글을 보고 이 문제 원인을 알 수 있었습니다. 어딜가나.. 이놈의 인코딩 문제는 정말 괴롭습니다.

해결책은 매우 간단합니다. 메이븐 컴파일러 플러그인의 configuration에 encoding 엘리먼트를 추가해주면 해결됩니다.

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>${java.version}</source>
                    <target>${java.version}</target>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>


신고
top


AspectJ 메이븐 플러그인

Build/Maven : 2009.06.09 12:21


aj 파일들은 AspectJ Runtime을 이용해서 컴파일 해줘야 합니다. 이 작업을 일반적인 java 컴파일 이전에 수행해줘야 제대로 빌드 할 수 있겠죠.

메이븐에 다음과 같이 설정해주면 됩니다.

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>aspectj-maven-plugin</artifactId>
                <version>1.1</version>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                    <compliancelevel>1.6</compliancelevel>
                    <encoding>UTF-8</encoding>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                            <goal>test-compile</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

1.6을 메이븐 properties를 이용해서 다음과 같이 수정해주는게 좋겠죠.

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>aspectj-maven-plugin</artifactId>
                <version>1.1</version>
                <configuration>
                    <source>${java.version}</source>
                    <target>${java.version}</target>
                    <compliancelevel>${java.version}</compliancelevel>
                    <encoding>UTF-8</encoding>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                            <goal>test-compile</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

1.5 미만은 다음과 같이 최소 설정만 해도 되지만.. 별로 그럴 일은 없을 것 같네요.

            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>aspectj-maven-plugin</artifactId>
                <version>1.1</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                            <goal>test-compile</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

사용법은...mvn compile 또는 mvn test-compile
해당 페이스 실행할 때 자동으로 aspectj:compile이 동작합니다.

신고
top


메이븐 배포나 설치시 소스 코드 배포하기

Build/Maven : 2009.05.19 11:11


            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-source-plugin</artifactId>
                <executions>
                    <execution>
                        <id>attach-sources</id>
                        <goals>
                            <goal>jar</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

이렇게 플러그인 하나만 추가하면 끝납니다.
참~ 쉽죠~

jar 골에 maven-source-plugin을 실행하도록 설정한 겁니다. 따라서 mvn install 또는 mvn delpoy를 할 때 소스도 같이 올라가게 되고, 이 라이브러리를 참조하는 쪽에서..

            <plugin>
                <artifactId>maven-idea-plugin</artifactId>
                <version>2.1</version>
                <configuration>
                    <downloadSources>true</downloadSources>
                    <downloadJavadocs>true</downloadJavadocs>
                    <dependenciesAsLibraries>true</dependenciesAsLibraries>
                    <useFullNames>false</useFullNames>
                </configuration>
            </plugin>

이런 식으로 설정해 두었다면, 라이브러리르 가져올 때 소스 코드도 같이 가져오게 됩니다. 그럼 이클립스에서 소스 코드 참조도 쉽게 할 수 있겠죠.
신고
top


메이븐 상식: 기본 페이스(phase)

Build/Maven : 2009.05.14 13:36


참조: http://www.sonatype.com/books/maven-book/reference/lifecycle.html#lifecycle-sect-structure

달달달 외워야 할 것.


맨 처음에 clean을 하지않는 군요. target 폴더를 깨끗하게 청소하고 빌드 하려면, mvn clean verify 형태로 입력하면 되겠습니다. 그럼 위에서부터 쫘르륵~~ 실행해주죠.

validate ->
source -> resource -> compile -> classes ->
test-source -> test-resource -> test-compile -> test ->
pre-pacage -> package -> post-package ->
pre-intefration-test -> integration-test -> post-integration-test ->
verify -> install -> deploy

대충 이렇군요.

신고
top


메이븐 Maven 2.0.10 배포!

Build/Maven : 2009.02.19 11:16


http://maven.apache.org/release-notes.html
자세한 내용은 위 링크에서 참조하세요~

버그 30개 가량 고쳤고 10개 가량의 개선 사항이 있었군요. 기존 빌드에 영향을 줄 수 있는 것 두 가지를 요약해 뒀는데..

한 가지는 settings.xml에서 미러 저장소 설정할 때 문서에 나와있는던 내용과 다르게 맨 마지막에 대응하는 저장소를 사용했었는데 그걸 다시 수정해서 맨 처음에 대응하는 저장소를 사용하도록 고쳤다는 내용이고,

다른 하나는 pom 모델에서 hashmap을 사용하여 의존성 순서 판단 하던것을 linkedHashMap을 사용하도록 변경했다는 내용입니다.

@_@ 둘 다 잘 모르는거네요.
신고
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


OSAF 메이븐 저장소 사용하기

Build/Maven : 2008.10.14 15:04


참조 : http://www.sonatype.com/book/reference/repository-manager.html#sect-conf-maven-nexus

기본으로 메이븐 저장소를 사용하게 되는데, 멀리 있어서 느린데다가, 라이브러리 업데이트도 느리기 때문에 최신 라이브러리를 참조할 수가 없습니다. 반면, 최신 라이브러리를 빠르게 참조할 수 있는 OSAF 메이븐 저장소를 간편하게 사용하실 수 있습니다.

일단 .m2 폴더(자기 계정 기본 폴더에 히든 폴더로 생깁니다.)에 settings.xml 파일을 열고(없으면 만들고.)

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

이렇게 하나의 미러 사이트를 추가해주시면 됩니다. 기본 메이븐 저장소, 아파치, 코드하우스, 아틀라시안, 스프링, 스프링 DM 등 유명한 메이븐 저장소를 전부 프록시로 등록해뒀기 때문에, 저렇게 설정하시면 기본 설정에서 보다 더 많은 최신 라이브러리를 쉽고 빠르게 참조하여 사용할 수 있으실 겁니다.

간혹, 정말 간혹 다운받지 못하는 라이브러리가 있을 때는, 저한테 요청하시면 (원하는 그룹 iD와 원하는 artifactID, 버전으로..)라이브러리 설치 서비스도 해드립니다.ㅋㅋㅋ  라이브러리 설치야 워낙 간단하기 땜시~
신고
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


메이븐으로 원격 저장소에 라이브러리 배포하기

Build/Maven : 2008.09.08 18:10


팀에서 사용하는 공통의 메이븐 저장소에 jar 파일을 패키징해서 올려야 다른 PC에 있는 사람들도 해당 프로젝트를 다운받아서 다른 패키지의 라이브러리로 이용할 수 있습니다. 그러려면 배포를 해야죠. 배포 방법은 간단합니다.

mvn deploy

depoly는 라이프싸이클의 거의 끝자락인지 완전 끝인지.. 그 쯤에 있습니다. 그래서 컴파일 부터 테스트까지 모든 과정을 통과하고 로컬에도 배포하고 원격에 최종적으로 배폴르 합니다. 물론 그렇게 흘러가다 하나라도 잘 못되면 원격에 배포가 되지 않습니다.

배포할 원격 저장소를 설정해야합니다. 원격 저장소 설정은 pom.xml에서 합니다.

사용자 삽입 이미지

m2eclipse 플러긴을 쓰면 pom 편집기에서 간ㄷ나하게 등록할 수 있습니다. 캬~ m2eclipse가 q4e를 물리친 것 같네요. 하지만 전 왠지.. 그냥 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>


이런식으로 직접 pom.xml에 등록해도 됩니다.

그리고 해당 저장소에 로긴할 수 있는 id를 settings.xml에 설정합니다. 이 파일은 로컬 리파지토리 루트에 있습니다. 보통 로컬 리파지토리 루트는 홈계정/.m2 폴더에 들어있습니다. 히든폴더기 때문에 잘 찾아보시기 바랍니다.

<settings>
  ...
  <servers>
    <server>
      <id>releases</id>
      <username>deployment</username>
      <password>deployment123</password>
    </server> 
    <server>
      <id>snapshots</id>
      <username>deployment</username>
      <password>deployment123</password>
    </server> 
    <server>
      <id>thirdparty</id>
      <username>deployment</username>
      <password>deployment123</password>
    </server>
  </servers>
  ...
</settings>

이런 식으로 등록하면 됩니다. 간단 간단..
신고
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


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

로컬에서는 무사히 빌드가 되는데, 왜 서버로 올라가서 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


Maven 2.0.10 배포 임박!!!

Build/Maven : 2008.07.24 10:37


참조: http://blogs.sonatype.com/brian/2008/07/23/1216860133767.html



중요 변경 사항
# [MNG-2562] - expose current time as a property for POM interpolation
# [MNG-3652] - set a user agent for Maven HTTP requests
# [MNG-3571] - Allow use of ! when deactivating profiles
# [MNG-3268] - Command line doesn't handle multiple -P correctly
# [MNG-3314] - offline build not running, when having SNAPSHOT dependencies
# [MNG-2068] - Multiple inheritance fails to find "grand" parent in ../../pom.xml when the groupIds differ (Test Case Attached)

그러다 저것들 보다 훨씬 더 중요한 변경 사항이 있었으니.. 그것은 바로!! 두둥!!!
http://jira.codehaus.org/browse/MNG-3520

사용자 삽입 이미지

캬캬캬. 바로 한국어 메시지 프로퍼티 파일의 추가!! 누가 번역해서 올렸는지 참.. 착하죠?
신고
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


메이븐을 대체할 것인가~ 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

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

이클립스용 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







티스토리 툴바