[TMS] $ /bin/sh -xe /tmp/jenkins2697039887893472079.sh + /home/jyeory/app/shell/afterBuildPf.sh rm: cannot remove '/home/jyeory/app/tomcat-instances/tomcatPf/webapps/ROOT': Permission denied cp: failed to access '/home/jyeory/app/tomcat-instances/tomcatPf/webapps/ROOT.war': Permission denied Build step 'Execute shell' marked build as failure

Jenkins에서 빌드 후 스크립트를 실행 할 때 오류가 난다.

권한이 문제인데, 우선 Jenkins를 실행하는 사용자는 jenkins이고, 배포 디렉토리의 사용자는 jyeory로 권한이 없을만 하다.


이를 해결하기 위해 jenkins, jyeory 모두 dev라는 그룹으로 묶어주고.... 

배포 디렉토리의 그룹도 dev로 변경, 마지막으로 배포 디렉토리의 그룹 권한을 rwx(7)로 바꿔주어야 한다.


이후 jenkins를 재시작하면 오류가 발생하지 않는다.


Maven 빌드 중 아래 오류가 발생함.

[DEBUG] incrementalBuildHelper#beforeRebuildExecution

[INFO] Compiling 47 source files to C:\dev\workspace-class\spring-mybatis-grid\target\classes

[DEBUG] incrementalBuildHelper#afterRebuildExecution

[INFO] /C:/[경로]/java/com/edu/test/NamingReflection.java: C:\dev\workspace-class\spring-mybatis-grid\src\main\java\com\edu\test\NamingReflection.java uses unchecked or unsafe operations.

[INFO] /C:/[경로]/java/com/edu/test/NamingReflection.java: Recompile with -Xlint:unchecked for details.

[INFO] -------------------------------------------------------------

[ERROR] COMPILATION ERROR :

[INFO] -------------------------------------------------------------

[ERROR] /C:/[경로]/java/com/edu/test/DepartmentsServiceTest.java:[12,17] package org.junit does not exist

[ERROR] /C:/[경로]/java/com/edu/test/DepartmentsServiceTest.java:[13,24] package org.junit.runner does not exist

[ERROR] /C:/[경로]/java/com/edu/test/DepartmentsServiceTest.java:[14,40] package org.springframework.test.context does not exist

[ERROR] /C:/[경로]/java/com/edu/test/DepartmentsServiceTest.java:[15,47] package org.springframework.test.context.junit4 does not exist

[ERROR] /C:/[경로]/java/com/edu/test/DepartmentsServiceTest.java:[20,2] cannot find symbol symbol: class RunWith

[ERROR] /C:/[경로]/java/com/edu/test/DepartmentsServiceTest.java:[21,2] cannot find symbol symbol: class ContextConfiguration


오류나는 클래스를 살펴보니 모두 TEST 케이스에서만 에러난다.

패키지를 못 읽어 오는 것이기에 pom.xml 을 수정해야 한다.

<dependency> <groupId>org.springframework</groupId> <artifactId>spring-test</artifactId> <version>${spring.version}</version> <scope>test</scope> </dependency>

에서 scope 를 삭제한다. 아래처럼  

<dependency> <groupId>org.springframework</groupId> <artifactId>spring-test</artifactId> <version>${spring.version}</version> </dependency>



http://maven.apache.org/ant-tasks/download.html
 에서 최신 버전을 다운로드 받자.

해당 jar 파일은 ant에서 maven 의존성 관리를 위해 필요하다. 

만약 build.xml의 위치가 아래와 같다면 



다운 받은 jar 파일의 위치는 build.xml에서 바라보는 경로를 명시해 주어야 한다. 


	

위 classpath 처럼 build.xml위 위치에서 jar파일 위치를 적어주면 ant에서 maven 사용이 가능하다.


	
	

${main.project.root}는 build.properties에 정의한 것인데 그냥 프로젝트 절대 경로이다. 
예로 윈도우일 경우 D:\project 일 수도 있고 Linux 일 경우 /home/project/ 일 수도 있다.

pom.xml을 pom이란 id로 정의를 했고, 정의한 ID pom을 이용하여 의존성을 관리하겠다고 선언하였다.


	
	
		
		    	
	    		
	  	
	

위 task는 maven을 이용하여 라이브러리를 실제 프로젝스 서비스 경로의 WEB-INF/lib에 복사하는 task이다.
( ${deploy.home}은 쉽게 말해.. 내가 서비스 하고 있는 Tomcat의 프로젝트 경로 )
 

이 작업까지 끝난 후에 컴파일을 하여야 한다.

	



java 파일이 위치한 경로를 src에 넣어주고, 컴파일한 class 파일이 위치하여야 할 Tomcat의 프로젝트 경로를 적어준다.


Maven이 편하다지만 나는 Ant가 제일 편하네..

예전에 ivy를 사용한 경험이 있는데 요새 뉴스거리에 가끔 maven이 올라 오길래 검색해보았다.
maven을 사용해 본 경험이 없어 비교하기가 그랬으나 누군가 경험적 비교를 해놔서 살펴보니..

난 ivy가 좋을 것 같다...
우스갯소리로 ivy는 dependency 추가가 한줄인데 maven은 5줄이상이다... 여기에서 부터 호불호가 갈렸다;;



경험을 바탕으로 간단히.. maven(maven2) vs ivy 장단점 비교를 해보겠습니다.

-  의존성 다운로드
1) ivy : 선택에 의해서 다운로드 가능. 해당 jar외엔 아무것도 받지 않겠다라고 쓸 수 있음. 명시적인 lib 관리 가능
2) maven : 불필요한 jar도 다운받을 수 있습니다. 쓰지 않더라도 선언때문에 다운 받을 수 있고, 상황에 따라서는 exclude 해줘야 함. 
(운영상..  maven을 못 쓴 이유가 바로 이런 불편함이었습니다. 쉽게 운영을 위해서는 명시적인 lib 외엔 다른 것을 쓰지 않도록 하는 것이 더 편리하고 명확합니다. )

- 라이브러리 경합
1) ivy : 유연성 제공, 같은 라이브러리, 버젼일 때, conflict manager 사용가능
2) maven : 같은 라이브러리라도 다른 버젼이면 맨 처음 선언된 artifact에 맞춰 다운로드 됩니다. maven plugin에서는 이 부분이 달라진다.. 결국 버젼 관계를 설정할 방법이 없습니다.

- 의존성 lib 기술 방법
1) ivy : property 이용. 
2) maven : element 단위.

- 이클립스 상
1) ivy : jar만 다운받으면, ant 상에서 빌드 가능, 플러그인 설치 필요 없음
2) maven : m2 플러그인 설치를 통해서 빌드 해야 함

- 장점
1) ivy : ant와 동시에 쓰면서 세밀한 작업이 가능함. 디렉토리 위치를 편하게 관리. 복잡해질 수 있는 소지. ant 의 condition 같은 구린 것이 if / else로도 쓸 수 있도록 지원.
2) maven : 플러그인을 편하게 쓸 수 있음. 간단한 구조에 좋음.

- ivy의 단점 : 파일 이름에 명시적인 패턴을 요구 합니다.


* ant + ivy는 spring 3 에서 사용하고 있습니다. 그 외에서 reference하는 곳는 많지는 않은 듯 합니다.


* 경험상..
maven은 작은 모듈에 적합
ant+ivy는 배포서버나, 세밀함이 필요한 곳에 적합


<볼만한 ivy 이야기>

+ Recent posts