'개발/Maven'에 해당되는 글 9건

Maven으로 Tomcat에 배포하는 경우 보통 mvn install 키워드로 war파일로 패키징 한 후,  

만들어진 파일을 원격지에 접속하여 FTP / SCP등으로 Tomcat의 webapps폴더에 넣어서 배포를 하게 됩니다.

매번 FTP / SCP 등으로 원격지에 접속해서 파일을 넣는게 비효율적인 일 같아서,

이것저것 알아보던 중 Tomcat Maven plugin이라는 것을 알게 되었습니다.

지금까지 비효율적이었던 일들을 mvn tomcat7:redeploy 명령어만으로,  

로컬 환경에서 원격지의 톰캣 webapps폴더를 찾아서, 바로 배포를 해주는 강력한 플러그인입니다.

일단 Tomcat Manager관련 세팅이 필요합니다.

톰캣이 설치된 폴더의 conf/tomcat-users.xml에 계정 등록을 해주고, 해당 계정에 매니저 권한을 주어야 합니다.  

(여러계정으로 관리하여, 권한을 달리 설정할 수도 있는 것으로 보입니다.)

아래와 같이 설정해줍니다.

[tomcat-users.xml]

<tomcat-users>
   <role rolename="manager-gui" />
   <role rolename="manager-script" />
   <role rolename="manager-status" />
   <role rolename="manager-jmx" />
   <user username="사용할 아이디" password="사용할 패스워드" roles="admin-gui,manager-gui,manager-script,manager-status,manager-jmx" /> 
</tomcat-users>

어플리케이션의 pom.xml로 돌아와서, 세팅을 해줍니다. 

[pom.xml]

<build>
    <plugins>
        <groupId>org.apache.tomcat.maven</groupId>
                <artifactId>tomcat7-maven-plugin</artifactId>
                <version>2.2</version>
                <configuration>
                    <path>배포할 경로</path>
                    <url>톰캣이 설치된 원격지의 접속 url/manager/text</url>
                    <username>톰캣매니저에 설정한 아이디</username>
                    <password>톰캣매니저에 설정한 패스워드</password>
                </configuration> 
    </plugins> 
</build>

위와 같이 설정을 마친 후, mvn tomcat7:redeploy (deploy, undeploy가 따로따로 있습니다만, 저는 귀찮아서 undeploy -> deploy기능을 동시에 하는, redeploy를 사용합니다.)를 해주면, 지정한 원격지에 배포가 됩니다.

웹 접속 기반으로 파일을 올리는 것이기 때문에, 웹 접속 IP에 대한 방화벽만 오픈하시면 어디서든 사용이 가능합니다.

어플리케이션을 하나 출시하기 위해서, 세팅되는 작업환경은 보통 아래와 같을 것이다.

Local, Dev, QA, Live

보통 DB정보와, Server to Server를 이용하는 API의 URL은 각 환경마다 다를 가능성이 매우 크다.

하지만, 매번 배포할때마다 이것을 수정하는 것은 매우 귀찮은 일이고, 비효율적이다.

(물론 이렇게 쓰는사람이 있을까 싶긴 하다;;)

Maven의 Profile 관리 기능과 War Plugin을 이용하면, 매우 편리하게 설정파일 등을 폴더에 넣어두고

각 환경에 맞게 -P 옵션만으로, 원하는 환경이 세팅되게 하는 것이 가능하다.

[pom.xml]

<profiles>
     <profile>
          <id>dev</id>
          <build>
                <plugins>
                    <plugin>
                        <artifactId>maven-war-plugin</artifactId>
                        <configuration>
                            <containerConfigXML>src/main/webapp/META-INF/dev/context.xml</containerConfigXML>
                            <webResources>
                                <resource>
                                    <directory>src/main/webapp/META-INF/dev</directory>       <!-- 현재 프로젝트의 폴더 위치 -->
                                    <filtering>true</filtering>     <!-- 여기서는 그냥 true인데, 특정 파일만을 필터링 하는 기능도 지원 -->
                                    <targetPath>META-INF</targetPath>     <!-- 배포가 된 후 폴더의 위치  -->
                                </resource>
                            </webResources>
                        </configuration>
                    </plugin>
                </plugins>
            </build> 
     </profile>
     ... 
</profiles> 

대충 위와 같이 context설정은 가능하고, properties나 logging관련 파일들도 resource element를 만들어서 참조하게 하면,

-P 만으로 각 환경에 맞게 리소스가 컨트롤이 가능함.

작년에 했던 것들인데 이제서야 정리... 

클라든 서버든 어플리케이션 버전의 경우 0.0.1 등으로 표시를 한다.

이럴 경우 DB에서는 >, < 등 범위 연산을 어느 정도 지원을 하지만, Java단에서는 "." 단위로 Split를 해서 각각 비교를 해야 되는 번거로움이 존재하는데, 이를 편리하게 해주는 라이브러리가 있었다.

1. 의존성 추가 

<dependency>
            <groupId>org.apache.maven</groupId>
            <artifactId>maven-artifact</artifactId>
            <version>3.2.3</version>
</dependency>

2. 확인 

@Test
public void test_stringCompareVersion() {
        DefaultArtifactVersion currentVersion = new DefaultArtifactVersion("0.0.27");
        DefaultArtifactVersion preVersion = new DefaultArtifactVersion("0.0.1");
        DefaultArtifactVersion nextVersion = new DefaultArtifactVersion("0.0.84");
        DefaultArtifactVersion sameVersion = new DefaultArtifactVersion("0.0.27");
        
        System.out.println(currentVersion.compareTo(preVersion));    // 앞에 버전보다 뒤에 버전이 작은 경우 1
        System.out.println(currentVersion.compareTo(nextVersion));    // 앞에 버전보다 뒤에 버전이 큰 경우 -1
        System.out.println(currentVersion.compareTo(sameVersion));    // 같으면 0
}

메이븐에서 만든것이니 내가 만드는거 보단 낫겠지;;

어느정도 믿고 사용하자. 

Nexus는 팀 단위 프로젝트에서 라이브러리 공유 등을 할 때 유용하게 사용할 수 있는 무료 Repository이다.

Maven을 사용하는 경우 Pom.xml에서 의존성을 넣으면, Maven Central Repository에서 의존성을 가져오게 되는데,

Nexus를 사용하는 경우 Nexus가 Proxy역할을 해주고 원격지 라이브러리를 로컬에 캐싱하기 때문에, 의존성을 가져오는 데 걸리는 시간도 단축될 수 있다.

3rd party library도 Nexus에 등록해두고 사용하면, 따로 라이브러리 파일을 관리해야하는 이슈가 없어진다. 

설치 법에 대해 알아보자.

1. 다운로드 및 설치 

 - http://www.sonatype.org/nexus/go/에서 파일을 다운 받은 후에 압축을 풀어준다.

2. 실행

 - 압축이 풀어진 폴더에 보면 bin폴더가 있는데, 그 안에 nexus를 실행해준다.

(root로 실행하는 경우에만) root권한으로 실행하는 것은 비권장한다고 하면서 팅긴다. vi 에디터 등으로 nexus파일을 직접 열어서 RUN_AS_USER부분의 주석을 풀고 root을 넣어주면 실행이 가능하다.

3. 확인 및 로그인

 - jetty기반으로 되어 있고, 포트는 8081이다. http://localhost:8081/nexus로 확인이 가능하다.

   아이디, 비밀번호는 초기설정이 admin / admin123이다.

4. 웹 UI 접근에 성공하였으면, Repositories메뉴로 들어가서 Public Repositories를 선택 후, Configuration탭으로 들어간다.

 - Available Repositories로 Central만 남기고 모두 옮겨준다. Save버튼 클릭 

5. 이제 상단의 Central을 선택 후, Configuration탭으로 들어간다.

 - Download Remote Indexes옵션을 True로 바꿔준다. (False인 경우 리모트에 접속해서 받아오는 데, True로 하면 인덱싱 되어 있는 목록에서 가져와서 다운로드 속도가 빨라진다고 한다.) Save버튼 클릭 

6. 4, 5의 설정을 마치면, Nexus가 동기화 작업을 수행한다.  

 - 매우 오래걸리는 작업이며, 작업 진행 상황 확인은 좌측 메뉴의 Administration/Scheduled Tasks에서 확인이 가능

(개발 머신이 드럽게 느려서, 13분이나 걸림 ㅋㅋㅋㅋ;; 센트럴에 있는거를 전부 땡겨오는듯)

7. pom.xml에 repositories 명시해두고 쓰면 된다.

<repositories>
 <repository>
  <id>mycompany.internal.repo</id>
  <url>http://host/nexus/content/repositories/releases/</url>
  <releases>
   <enabled>true</enabled>
  </releases>
 </repository>
</repositories>

공통 모듈 같은 경우 별도의 프로젝트로 떼어내서, 해당 소스만 배포하고, 나머지 프로젝트에서 import하여 사용하면, 편리하게 사용이 가능한 것 같음.

3rd party library를 등록해서 사용하면 꽤 유용할 것 같다.

우리 프로젝트에서 제대로 사용하려면, 공통 모듈 분리에 대해서 고민해봐야 할 것 같다.   

Nexus에 Repository를 하나 생성한다.

ID, Name은 대충 적어줘도 되지만, Repository Policy에서 정책을 자신이 원하는것과 다른걸로 지정해주면

Deploy시 실패하게 되므로 주의하자.

Repository가 생성되었으면, 해당하는 url을 우리가 공유해야 할 프로젝트의 pom.xml에 넣어준다. (보통 공통모듈 프로젝트)

아래와 같이..  

<distributionManagement>
        <repository>
            <id>CommonModule</id>
            <name>CommonModule</name>
            <url>http://localhost:8081/nexus/content/repositories/commonModule</url>
        </repository>
</distributionManagement>

당연히, Nexus에 만들어둔 repository와 id, name, url이 일치해야 한다.

그리고 상단에 groupId, artifactId, version이 다른 사람이 의존성을 주입해서 사용할 때,

넣는 이름이 되므로, 신중하게 결정하자.

version의 경우 위에서 설명한 Repository Policy에 해당하는 단어가 포함되어 있어야 한다.

(RELEASE로 했을 경우 0.0.1-RELEASE와 같이 해준다. 정책이 RELEASE인데 SNAPSHOT이 포함되어 있으면, Deploy시에 repository정책이 일치하지 않아서 실패한다.)

이렇게 해주고, mvn clean deploy를 해주면, Nexus에 내 프로젝트가 등록이 되어, 다른 팀원과 공유가 가능해진다.

하지만, 다른 팀원들이 내부 소스를 보지 못하는 이슈가 있으므로, maven-source-plugin, maven-deploy-plugin을 이용하여, 소스까지 업로드 해주는 것이 좋다.

(이건 다음 포스팅에서 작성하는 걸로..) 

이제 공통모듈쪽 프로젝트 작업은 끝났고, 다른 팀원들이 사용할 수 있게 해줘야 하는데,

사전 작업이 약간 필요하다.

1. .m2폴더의 settings.xml을 열어서, nexus repository에 대한 정보를 등록한다. (.m2폴더는 이클립스 기준으로 External 등의 설정을 하지 않았다면, 윈도우 사용자 폴더\.m2 경로에 존재한다.)

아래와 같이 추가해준다.

  <servers> 
    <server>
        <id>commonModule</id>      <!-- 이것도 물론 아까 nexus에 만들어둔 id와 동일해야 함. -->
        <username>admin</username>
        <password>admin123</password>
    </server>
  </servers>

2. 공통모듈 프로젝트의 의존성을 주입할 프로젝트의 pom.xml을 열어서 아래와 같이 추가해줌.

<repositories>
      <repository>
            <id>commonModule</id>  <!-- 동일해야함! -->
            <url>http://localhost:8081/nexus/content/repositories/commonModule</url>
        </repository> 
  </repositories>
 
  <dependencies>
      <dependency>
           <!-- 공통 모듈 프로젝트의 pom.xml 상단에 있는 정보와 동일해야함. artifactId, version도 마찬가지--> 
          <groupId>companyName</groupId>      
          <artifactId>commonModule</artifactId>
          <version>0.0.1-SNAPSHOT</version> 
      </dependency> 
  </dependencies>

참고로 이클립스를 사용하는 경우, 같은 workspace에 공통모듈 프로젝트가 포함되어 있는 경우  

의존성이 주입된 원격 Nexus에 있는 라이브러리를 참조하는 것이 아니라, 바로 그 프로젝트의 라이브러리를 참조하는 것 같다.

디버깅하기도 편하고 더 좋은듯..

이제 CI툴과의 연동을 진행해봐야겠다. 

공통 모듈 프로젝트를 분리해서, Nexus에 Deploy하는 경우

의존성이 주입된 라이브러리들과 모든 기능들을 사용은 할 수 있지만,

내부는 볼 수가 없다.

소스가 없기 때문인데.. 이를 해결하기 위해 Maven Source Plugin이라는 것이 있었다.

아래와 같이 하니깐, 소스까지 배포가 되더라. (퍼온거라 그냥 대충 복붙;;) 

<plugin>
        <artifactId>maven-source-plugin</artifactId>
        <version>2.3</version>
        <executions>
             <execution>
             <id>attach-sources</id>
             <phase>verify</phase>
             <goals>
                <goal>jar</goal>
             </goals>
             </execution>
        </executions>
</plugin>             
<plugin>
        <artifactId>maven-deploy-plugin</artifactId>
        <version>2.8.2</version>
        <executions>
              <execution>
               <id>deploy</id>
               <phase>deploy</phase>
                </execution>
        </executions>
 </plugin>

이 작업으로 인해, 공통 모듈에서 뭔가 이상한 것 같다라는 말이 나오면,

소스를 직접 열어서 디버깅해보라고 할 수 있어서 귀찮음이 반감될 것 같다. 

매번 업데이트 하도록 업데이트 정책인 updatePolicy옵션을 always로 바꾸어준다.

이렇게하면 매번 빌드 시마다 라이브러리를 받게 된다.

<repositories>
        <repository>
            <id>nexus</id>
            <url>{host}</url>
            <snapshots>
                <enabled>true</enabled>
                <updatePolicy>always</updatePolicy>
            </snapshots> 
        </repository>
    </repositories>

아무것도 설정을 건드리지 않은 상태에서 maven으로 빌드를 하면, 앞에 프로젝트명-SnapShot-0.0.1.war 이런식으로 붙게 된다.

저 파일을 was에 올리면 was도 별 다른 설정이 없으면 localhost:8080/프로젝트명-SnapShot-0.0.1 이런식으로 url이 따지게 되어,

매번 프로젝트명.war로 rename을 해서 올렸던 기억이 있다.

이 작업을 maven단에서 자동으로 해주는 옵션이 존재한다. 

아래 내용만 pom.xml에 추가해주면 프로젝트명.war로 깔끔하게 패키징이 된다.

<build>
    <finalName>프로젝트명</finalName>
</build>

귀찮아서 Shell로 만들어서 매번 Rename했었는데, 위 옵션을 추가함으로써, 뻘짓을 안하게 되었다.

Eclipse(STS)기준으로 설명함.

Maven 명령어나 Eclipse의 Maven Build등을 이용하여 실행되어야 할 파일을 한 번 실행해준다.

(한 번 실행이 되어야, 이후에 나올 메뉴에서 빌드 선택이 가능하다.)

프로젝트 우클릭 후, Export를 선택한다.

발생하는 팝업에서 [Java] - [Runnable JAR file] 을 선택 후 [Next]버튼 클릭

Launch configuration에서는 아까 Maven Build로 실행했던 것을 선택해주고, 

Export destination에는 jar파일을 어디로 뽑을지 입력한다.

나머지 설정은 Default로 유지해준다.

Finish를 누르면, destination 위치에 jar파일이 생성되고, java -jar 만들어진파일.jar 로 실행해도

manifest가 지정되지 않았다는 등의 메시지는 뜨지 않는다.