IDE 에서 생성한 rebel.xml 이 프로젝트와 맞지 않아서 제대로 되지 않았는데, 이를 해결할 수 있는 방법을 찾았다.

build.gradle 에 아래 스크립트를 추가하면 war 태스크가 실행될 때 war 의존성을 걸어둔 generateRebel 가 호출되면서 build/resources/main 아래에reble.xml 이 생성된다. 프로젝트의 클래스패스와 웹경로의 항목들을 출력하는 특징을 가진다.

이 태스크가 실행되기 위해서는 프로젝트에 war 플러그인이 설치되어 있어야 한다. 

apply plugin: 'war'
// 생략

task generateRebel << {
    def rebelFile = sourceSets.main.output.classesDir.absolutePath + '/rebel.xml'
 
    def srcWebApp = project.webAppDir.absolutePath
    def writer = new FileWriter(rebelFile)
    new groovy.xml.MarkupBuilder(writer).application() {
        classpath{
            dir( name:sourceSets.main.output.classesDir.absolutePath )
        }
        web{
            link(target:'/'){
                dir(name:srcWebApp)
            }
        }
    }
}
war.dependsOn generateRebel
$ ./gradlew build   // or war 만 실행해도 됨
:processResources
:classes
:generateRebel
:war
생성된 rebel.xml
<?xml version="1.0" encoding="UTF-8"?>
<application generated-by="intellij" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.zeroturnaround.com" xsi:schemaLocation="http://www.zeroturnaround.com http://update.zeroturnaround.com/jrebel/rebel-2_1.xsd">
 
<classpath>
<dir name="/Users/honeymon/workspace/prototype-boot/build/classes/main"></dir>  (1)
<dir name="/Users/honeymon/workspace/prototype-boot/src/main/resources"></dir>  (2)
</classpath>
 
</application>

컴파일된 클래스 핫스와핑

변경된 설정파일 모니터링




http://blog.jetbrains.com/kotlin/2016/05/gradle-meets-kotlin/

그레이들이 코틀린Kotlin을 DSL 로 사용하게 되면 그루비는 찬밥...이 되겠다. @_@)>

그루비보다는 코틀린을 익혀야할 분위기가 무루 익어가고 있다.


주변 개발자들이 ZSH(http://www.zsh.org/) 으로 많이 넘어갔다.

이직하는 팀에서도 ZSH 를 사용하자는 이야기에 오늘 설치를 진행한다.

1. ZSH 설치

1.1. 우분투

$ sudo apt install zsh

1.2. 맥Mac

$ brew install zsh

2. oh-my-zsh 설치

2.1. curl

sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

2.2. wget

sh -c "$(wget https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O -)"

3. zsh 사용하도록 정의

chsh -s /bin/zsh

4. 재시작


그후 터미널에서 사용하는 명령어의 선택항목을 탐색시 탭<tab> 키를 누르면 선택항목들을 볼 수 있다.

명령어 입력 후 '-' 를 입력하면 해당 명령어로 실행한 이력도 확인가능하다.


'Tools' 카테고리의 다른 글

[log] 싱크패드 울트라나브(블루투스)  (3) 2018.10.25
[atom] asciidoc-preview 한글처리  (0) 2015.10.29
얼마전까지 프로젝트에서 클라이언트에서 사용되는 웹 라이브러리(jquery, bootstrap) 등에 대한 관리를 제대로 하지 않았다. 화면 개발 및 적용을 다른이에게 맡기고 있었다가 고전적인 방식으로 웹 라이브러리 의존성을 그대로 프로젝트에 추가하여 버전관리시스템에 올라와있는 모습을 보게 되었다. 이렇게 프로젝트의 버전관리에 포함된 웹라이브러리는 버전이 업그레이드되면 버전을 업글하기가 쉽지 않다.

이런 상황을 타개할 수 있는 방법으로 WebJars 를 고려해보게 되었다.


http://www.webjars.org/

webjars 란 무엇인가?

WebJars 는 클라이언트에서 사용하는 웹라이브러리(jquery 와 bootstrap) 를 JAR 파일 안에 패키징한 것이다.

  • JVM 기반의 웹 애플리케이션에서 클라이언트측 의존성을 손쉽게 관리할 수 있음
  • JVM 기반 빌드툴을 사용하여 클라이언트측 의존성을 다운로드
  • 사용하고 있는 클라이언트측 의존성을 파악할 수 있음
  • 수동적인 종속성을 자동으로 해결하고 선택적으로 RequireJS를 통해 적재
  • 메이븐 중앙저장소를 통해 배포된다.
  • JSDELIVR 에서 제공하는 공개 CDN 사용이 가능하다.

webjars 사용

webjars 탐색

webjars 를 사용하기 위해서는 http://www.webjars.org/ 접근하여 제공하는 라이브러리를 탐색하여 사용한다.

webjars 에서 제공하는 세가지 유형 중에 한가지를 선택한다.

  • NPM WebJars

    • 즉각적인 생성 및 배포
    • 누군가의 요청에 의해 출시
    • 아티팩트 컨텐츠는 NPM package를 통해 제공
  • Bower WebJars

    • 즉각적인 생성 및 배포
    • 누군가의 요청에 의해 출시
    • 아티팩트 컨텐츠는 Bower package를 통해 제공
  • Classic WebJars

    • 규정에 따른 생성 및 배포
    • Webjars 팀에 요청으로 출시
    • RequireJS 구성을 사람이 작성

기본적인 Classic WebJars 를 기준으로 설명한다.


  • jquerybootstrap 을 추가하는 것을 가정하도록 한다.


  • 탐색 Build Tool 항목에서 자신이 사용하는 빌드툴을 선택한다.

  • jquery 탐색 'filter' 항목에 찾으려 하는 jquery 입력


  • bootstrap 탐색 'filter' 항목에 찾으려 하는 bootstrap 입력


의존성 추가

  • build.gradle 에서 dependencies 항목에 다음과 같이 추가한다.

    dependencies {
      // 생략
      /**
       * webjars
       */
      compile 'org.webjars:jquery:2.2.1'
      compile 'org.webjars:jquery-ui:1.11.4'
      compile 'org.webjars:bootstrap:3.3.6'
     
      // 생략
    }

  • 완료된 후 프로젝트의 라이브러리 항목에서 'Gradle dependencies' 를 살펴보면 build.gradle 에서 추가한 라이브러리들이 등록되어 있는 것을 확인할 수 있다.

  • 추가된 라이브러리 중에서 jquery를 열어보면 다음과 같은 구조로 되어 있다.



의존성 추가된 webjar 참조하기

다음과 같은 형식으로 작성을 추가할 수 있다. 위에서 추가한 jquery 의 경우에는 /webjars/jquery/2.2.1/jquery.min.js 으로 접근할 수 있다.

<html>
 
<head>
  <title>Sample</title>
  <link rel='stylesheet' href='/webjars/bootstrap/3.3.6/css/bootstrap.min.css'>
</head>
 
<body>
  <div class="container">
    <div>
      <h1>WebJars Starter</h1>
      <p class="lead">test</p>
    </div>
 
  </div>
 
  <script src="/webjars/jquery/2.2.1/jquery.min.js"></script> 
  <script src="/webjars/bootstrap/3.3.6/js/bootstrap.min.js"></script> 
  <script type="text/javascript">
    $(function () {
      console.log("jQuery ready");
    });
  </script> 
</body>
 
</html>




정상적으로 적용되었는지는 화면의 구성요소를 확인해서 스타일이 제대로 적용되었는지, 콘솔창에 jQuery ready 메시지가 출력되는 것을 확인할 수 있다.

스프링부트에서는 JARs 에 있는 클래스패스 /META-INF/resources/webjars/webjars 로 요청을 연결하도록 자동구성된다.

스프링부트 프로젝트에서 스프링MVC 지침을 따르게 되면 스프링부트에거 구성된 정적 컨텐츠 매핑 사용이 중단된다.

정리

  • 프로젝트에 라이브러리를 추가하고 버전관리시스템을 이용해서 관리하던 방식 대신
  • 빌드툴을 이용한 버전관리 방식으로 전환할 수 있다.
  • 프론트 웹 개발이 별도로 진행된다면 프론트엔드 빌드툴을 이용하는 방식이 더 적절할 것이다.

참고


현재 개발하고 있는 프로젝트의 빌드도구는 그레이들GRADLE(https://gradle.org/) 이다.

그리고 프로젝트를 빌드할 때 사용되는 것은 프로젝트 안에 포함되어 있는 그레이들 래퍼Gradle wrapper 이다.

그레들 래퍼를 이용해서 빌드환경에 별도로 그레이들을 설치하지 않아도 그레이들의 빌드를 이용할 수 있다. 이때, 시스템변수를 읽어들이는데 그 중 영향을 받는 것 중에 하나가 JAVA_HOME 변수다.

이 빌드에 사용되는 JAVA_HOME 변수 정보를 gradle.properties 에 정의하여 빌드 시에만 참조하도록 할 수 있다.

특정 프로젝트를 $PROJECT_HOME 이라고 했을 때, 프로젝트 상위경로에 gradle.properties 를 생성하고

org.gradle.java.home=<JAVA_HOME 경로>

을 지정해두면 빌드시 그레이들의 JAVA_HOME 변수를 대체하게 된다. 이 프로젝트를 버전관리하고 있다면 gradle.properties 는 무시ignore 처리를 해두면, 개발자마다 미묘하게 다른 JAVA_HOME 경로를 프로젝트별로 정의하는 것이 가능해진다.

+ Recent posts