https://docs.gradle.org/5.0/release-notes.html

Gradle 5.0 이 나왔습니다.

Java 11 및 운영가능한 수준으로 Kotlin DSL 1.0 를 지원합니다.

그레이들 래퍼를 이용하면 프로젝트 구성원들이 일일이 그레이들을 설치는 번거로움을 피할 수 있다(한명만 고생하면 된다). 다음과 같이 실행하면 로컬에 설치되어 있는 그레이들 버전을 기준으로 그레이들 래퍼가 설치된다.

$ gradle wrapper
$ cat gradle/wrapper/gradle-wrapper.properties
#Fri Mar 24 21:30:00 KST 2017
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-2.14-bin.zip

하지만 그레이들 래퍼의 버전은 간단한 인자변경을 통해 손쉽게 할 수가 있다. 다음 명령어를 이용한다.

$ gradle wrapper --gradle-version={version}

3.4.1 버전을 설정한다고 치면!

$ gradle wrapper --gradle-version=3.4.1
:wrapper

BUILD SUCCESSFUL

Total time: 0.724 secs
$ cat gradle/wrapper/gradle-wrapper.properties
#Fri Mar 24 21:28:35 KST 2017
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-3.4.1-bin.zip

다음과 같은 형태로 설치되고, 이후에 그레이들 빌드를 진행하면 자연스럽게 래퍼를 변경한다.


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 로 사용하게 되면 그루비는 찬밥...이 되겠다. @_@)>

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


얼마전까지 프로젝트에서 클라이언트에서 사용되는 웹 라이브러리(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 지침을 따르게 되면 스프링부트에거 구성된 정적 컨텐츠 매핑 사용이 중단된다.

정리

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

참고


+ Recent posts