I Love Salsa~~

1. git$ git rm --cached -r directory_name
    or
    git$ git rm --cached file_name

2. git commit -m "delete directory"

3. git push origin branch_name

3번 부분을 진행하지 않으면 원격 저장소에 반영이 되지 않는다.

Git 명령어로 생성된 브랜치로 옮길 때 에러 발생

현상 : 

1. Git Bash 에서 새로운 브랜치로 push할 디렉토리로 이동

2. [git]$ git init

3. [git]$ git remote add url

4. gitlab 웹 페이지에서 브랜치  'test1' 생성

5. [git]$ git checkout new_branch

error: pathspec 'test1' did not match any file(s) known to git

조치 방안 :

1. [git]$ git remote update

2. [git]$ git fetch

3. [git]$ git checkout test1

매번 잊어먹어서 내 블러그에 정리하고자 작성함.

1. 이클립스의 프로젝트에서 마우스 우측 버튼 클릭 > Team > Share Project... 클릭

2. SVN을 선택하고 Next 버튼을 클릭

3. "Create a new repository location"을 선택하고 Next 버튼을 클릭

4. URL은 "프로젝트 이름으로 추가되는 상위 주소까지"를 입력하고 사용자 계정을 입력한 후 Next 버튼을 클릭

5. URL 주소가 정확한지 확인한 후 Next 버튼을 클릭

6. 프로젝트 추가에 따른 주석을 확인한 후 Finish 버튼을 클릭

7. commit 로그를 남긴 후 OK 버튼을 클릭

윈도우즈의 서비스로 등록한 톰캣을 시작한 후 "catalina.시작일자.log"를 살펴보면 다음과 같은 오류가 발생할 때가 있다.

이때는 설정값을 변경하는 것도 있지만, ~CATALINA/work/Catalina/localhost 디렉토리에 위치한 모든 정보들을 삭제하고, 서비스를 재시작 또는 중지한 후에 시작을 하면 위와 같은 에러 로그는 출력되지 않는다.

해결은 -Dfile.encoding=UTF-8 이였다. (간단한 거)

보통 사이트는 대부분 리눅스 또는 유닉스 환경이다.

이번에 특정 사이트가 윈도우 서버이기에 연구소 설치 담당자가 작성한 윈도우 서비스 설치 가이드대로 설치가 되었으나, 데이터를 받으면 이상하게 한글이 깨지는 현상이 발생하였다.

이미 다른 사이트를 통해서 윈도우 서버에 윈도우 서비스로 등록을 하여 데이터에 대한 한글이 깨지지 않음을 확인이 되었기에 살짝 황당하였다.

그래서 기존의 내가 알고 있는 방식으로 톰캣의 인코딩 설정 정보를 확인 및 추가해 보았으나 해결 방안이 되지 못한 상태로 지난 주를 마무리를 지었다.

그래서 한번 더 확인을 해 본 결과 JvmOptions에 -Dfile.encoding=UTF-8 옵션을 추가하는 방법이 있어서 service.bat의 JvmOptions의 맨 마지막에 위와 같은 옵션을 추가를 하였으나, 여전히 데이터의 한글은 깨져서 도출이 되었다. (-Dfile.encoding=UTF-8 옵션은 알고는 있었으나 무작적 옵션의 맨 마지막에 추가를 했던 거이였다. 하기와 같이)

이에 옆 동료(이전 회사에서 자사의 솔류션을 설치 등등을 전문적으로 담당했었다) 직원의 권유로 다음과 같은 명령어로 JvmOptions를 추가해 보았다.

결과는 만족, 데이터의 한글이 깨짐 없이 정상적으로 출력이 되었던 것이였다.

궁금했었다. 분명히 JvmOptions의 마지막에 관련 옵션을 추가하였기 때문이다.

혹시나 해서 이거 저거 중에 설정한 값을 바꿔보았다.

음.. 데이터의 한글이 정상적으로 출력이 되는 것이였다.

이 JvmArgs 가 무엇인지 확인해 볼려고 했으나, 관련 정보는 보이지 않고, 또한 service.bat의 JvmArgs가 set으로도 설정이 되어 있지 않음을 확인하였다.

아마도 여기서 문제가 발생하여 -Dfile.encoding=UTF-8 옵션 설정이 잡히지 않은 것으로 판단이 된다.

아무튼 큰 이슈 해결을 찾은 것은 아니였나, 지난 주 부터 오늘까지 반나절을 소비했는 부분이라 글로 남겨 보왔다.

한글로 검색되는 Jenkins Plugin의 결과들은 maven으로 작업을 한 뒤에 eclipse에서 import 하는 식으로 나와 있다.

아직 영문을 검색해 보진 못하였지만,

그래서 많이 나오는 것 위주로 진행해 보았으나 BUILD FAILED 결과를 맞고 말았다.

일단 최초 시도한 것부터 열거해 보면 다음과 같다.

그전에 테스트 환경부터 정리해 본다.

1. Jenkins repository용도의 settings.xml 파일 설정

maven repository에 settings.xml을 설정하는 내용이 최초로 소개가 된다. (여기서 settings.xml의 정보는 %MAVEN_HOME%conf 디렉토리에 있는 settings.xml과는 다른 것이다.)

그러나, 본인의 컴은 집에서 개인용이 아닌 사무실 작업용 컴퓨터여서 선듯, settings.xml 정보를 기 사용중인 reposigitory에 설정하기가 두려웠다. (repository가 한번 꼬이면 이전에 작업했던 거, 작업 중인 것들이 다 초기화를 해야하는 두려움 때문에)

그래서 찾아보니 Jenkins용 workspace 아래에 해당 settings.xml을 놔두면 꼬이는 현상이 없을 거이라는 글을 확인하고 바로 진행하였다.

위의 디렉토리에 settings.xml 파일을 만들고 다음과 같은 내용을 채웠다.

2. Plugin 생성

이제 Plugin을 생성할 단계인데 다음과 같은 명령어를 수행해야한다고 나옵니다.

이렇게 하면 앞서 생성한 settings.xml 파일이 repository에 존재하지 않기 때문에 문제가 발생합니다.

따라서, 다음의 추가 명령어를 더붙여서 진행합니다.

그러나 역시 BUILD FAILED가 발생합니다.

여기서 환경 설정을 변경할 생각을 못했습니다.....(환경 설정이 변경되었어도 여전히 BUILD FAILED가 발생한다.)

다시 검색에 들어가 보니 Jenkins에서 제공하는 방법이 있는데 이게 2번에 수행한 명령어와 상이합니다.

그래도 일단 끝을 봐야 하니 해당 명령어로 변경하여 다시 진행해 봅니다. (https://www.jenkins.io/doc/developer/tutorial/create/)

이것도 앞서와 같이 "-s settings.xml"을 덧붙여서 진행합니다.

BUILD FAILED가 발생합니다.

로그를 보니 maven 버전을 요구하고 있네요 (maven 3.3.3)

- 캡쳐된 로그가 없습니다.

maven 버전을 다음과 같이 변경합니다. (기타 프로젝트는 어찌될 지 모르겠지만...)

다시, Plugin 생성을 진행한 결과 드디어 BUILD SUCCESS가 떨어집니다.

3. acrtifact 명으로 생성된 디렉토리 명 변경

참고한 Jenkins 사이트에서는 특별한 사정이 있어서 디렉토리 명을 바꿔주길 바라네요.

4. mvn verify

혹시나 싶어 "-s ..\settings.xml"을 추가했더니 실제 MAVEN의 settings.xml 파일을 찾고 싶어하는 로그가 보이더군요.

그래서 이 명령어에는 "-s ..\settings.xml" 옵션을 빼고 진행해 보았으나, BUILD FAILED가 발생하였습니다.

로그에서 %JAVA_HOME%lib\tools.jar 파일이 존재하지 않는다고 합니다.

검색을 해 보니 JRE는 tools.jar 파일이 존재하지 않기 때문에 JDK로 설정되어야 한다고 합니다.

%JAVA_HOME% 환경 파일을 다음과 같이 변경합니다.

생성된 디렉토리를 삭제한 후 2번부터 재 진행하여 BUILD SUCCESS가 떨어지는 것을 확인하였습니다.

5. 이클립스로 import가 가능한 작업 진행 (https://blog.naver.com/PostView.naver?blogId=kylepark77&logNo=220042836459)

다음의 명령어를 진행한다.

BUILD SUCCESS

그렇지만, 이클립스에서 import 하면 에러 및 경고 등이 발생

더 이상 진행하지 못함

다음편으로 ...

1. 이클립스 4.5 ~ 4.6.2 이하 버전에 다음과 같은 오류가 발생한다 (따라서 4.2 버전 이하나  4.6.2 이상 버전을 요구하고 있다.)

"Only a type can be imported. hudson.model.Job resolves to a package".

https://bugs.eclipse.org/bugs/show_bug.cgi?id=495598

2. 플러그인에 라이센스를 명확하게 식별하도록 해야 한다.

다음의 여러 사례 중 하나 또는 여러개를 사용하도록 권장하고 있다.

아무것도 정의되지 않은 경우 코드는 MIT 라이선스​(https://en.wikipedia.org/wiki/MIT_License) 조건에 해당하는 것으로 간주한다.

풋 스위치를 하나 구매하였다.

기타 앰프에 맞게끔 마샬 MG 시리즈로다.

과연 내가 생각한 그  사운드?가 나와 줄까 오늘 밤이 기대가 된다. 

Step 1. Repository 생성

1. 오른쪽 상단의 + 표시를 누른 뒤 New repository를 선택

2. Repository name 입력

3. Description 입력

4. Initialize this repository with a README 선택

5. Create repository 버튼 클릭

Step 2. Branch 생성

GitHub는 기본값으로 repository에 master라는 branch를 가지고 있다.

그러나 다른 branch를 생성하여 master에 commit하기 전에 테스트 및 수정하기 위해서 사용된다.

1. master라고 되어 있는 콤보 메뉴를 클릭

2. 새로운 branch 이름 기입(예로 sub-branch)

3. Create branch : sub-branch from 'main' 버튼을 클릭하면 branch가 생성됨

이제 branch는 두개(master와 sub-branch)가 생성이 되었으며, master의 복사본인 sub-branch branch가 생긴 것이다.

이제 새로운 branch에 변경 사항을 추가한다.

Step 3. 변경 사항 commit

1. READM.md를 클릭

2. 내용을 수정하기 위해서 우측의 Editthis file 버튼을 클릭

3. 수정할 내용을 입력

4. 변경 사항에 대하여 commit message을 입력한 후 Commit changes 버튼 클릭

이제 이 변경된 README 파일은 sub-branch branch에만 적용이 되며, master의 내용과 다른 내용이 생기게 된다.

Step 4. Open Pull Request

이제 master branch와 변경 사항이 발생하였기에 pull request를 열 수 있다.

Pull request를 통해서 변경된 내용을 리뷰하고, 프로젝트 소유자(해당 코드 담당자)가 master branch로 pull request merge를 할 수 있다.

1. 상단 메뉴 중 Pull request 메뉴를 누르고, 이어서 New pull request 버튼을 클릭

2. Compare changes 화면 상단의 compare: main을 클릭하여 sub-branch로 선택

3. 비교 페이지에서 변경 사항에 대하여 확인 가능

4. 변경 사항에 대하여 확인이 되었으면 상단의 Create pull request 버튼을 클릭

5. 변경 사항에 대하여 추가 설명이 있으면 입력한 후, 하단에 위치한 Create pull request 버튼을 클릭

Step 5. Merger pull request

변경 사항에 대하여 리뷰가 문제없이 끝났으므로 main branch에 merge를 해야 한다.

1. Merge pull request 버튼을 클릭

2. Comfirm meger 버튼을 클릭

3. main branch로 merge가 완료 되었으므로, Delete branch 버튼을 클릭하여 sub-branch에 대하여 삭제를 진행한다.

4. sub-branch가 삭제되었다는 메시지를 확인

5. 상단 메뉴에서 Code를 클릭한 후 main 콤보 박스를 선택하면 sub-branch branch가 삭제됨을 확인 가능

이상 여기까지가 GitHub의 Pull request를 통한 코드 리뷰 방법을 사용하는 방법을 테스트 해 보았다.

지금까지 찾아본 방법은 Ignored Resource 전부다 다음과 같았다.

Window > Preferences  > Team > Ignored Resources에 패턴을 추가하는 방법이였다.

하지만, 위와 같은 방법으로는 Synchronize에서는 제거되지가 않는다.

다음의 방법을 사용할 경우 Synchronize에서 불필요한 폴더들을 제거가 가능하다.

Synchronize View에 나오는 폴더 중 불필요한 정보는 해당 위치에 마우스 클릭한 후 마우스 우클릭을 클릭하여 팝업 메뉴 중 "Add to svn:ignore..." 메뉴를 클릭하면 더이상 Synchronize 폴더에서 나타나지 않게 된다.