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 지침을 따르게 되면 스프링부트에거 구성된 정적 컨텐츠 매핑 사용이 중단된다.

정리

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

참고


문제

그레이들gradle 으로 구성한 멀티프로젝트를 이클립스에서 불러오게 되면 Classpath Dependency Validator 가 검증되지 않은 클래스패스 상에 의존성을 가진 프로젝트가 있다는 메시지를 던진다.

꽤 거슬린다. ㅡ_-);;

이에 대해서 인터넷 검색을 해봤다.

여기서 해답을 보면 프로젝트를 선택하고 gradle cleanEclipse eclipse 를 해서 이클립스가 그레이들 네이처를 잊어 먹도록 한 후에 수동으로 처리하도록 하는 수를 쓰고 있다.



해결책

해결방법은 간단하다.

[Preference] - 'Validation' - 'Classpath Dependency Validator' 비활성화



하면 끝난다.

경고를 무시해도, 그레이들에 의해서 프로젝트 의존성이 처리가 되기 때문에 큰 문제는 없다.

현재 개발하고 있는 프로젝트의 빌드도구는 그레이들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 경로를 프로젝트별로 정의하는 것이 가능해진다.

그레들Gradle 2.6을 처음 실행하면 하단에 다음과 같은 문구가 나온다.

honeymon@honeymon-blog (develop)*$ ./gradlew check
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:backend:compileJava UP-TO-DATE
:backend:processResources UP-TO-DATE
:backend:classes UP-TO-DATE
:backend:compileTestJava UP-TO-DATE
:backend:processTestResources UP-TO-DATE
:backend:testClasses UP-TO-DATE
:frontend:compileJava UP-TO-DATE
:frontend:processResources UP-TO-DATE
:frontend:classes UP-TO-DATE
:frontend:jar UP-TO-DATE
:backend:test UP-TO-DATE
:backend:check UP-TO-DATE
:frontend:compileTestJava UP-TO-DATE
:frontend:processTestResources UP-TO-DATE
:frontend:testClasses UP-TO-DATE
:frontend:test UP-TO-DATE
:frontend:check UP-TO-DATE
 
BUILD SUCCESSFUL
 
Total time: 11.503 secs
 
This build could be faster, please consider using the Gradle Daemon: https://docs.gradle.org/2.6/userguide/gradle_daemon.html

이 빌드가 더 빨라질 수 있다, 그레들 데몬은 실행하는 것을 고려하라!https://docs.gradle.org/2.6/userguide/gradle_daemon.html

그레들 빌드가 조금 굼뜬 느낌이 있었는데, 빨라진다면!! 바로 위의 링크로 이동했다.

글을 쭈욱 내리고 '난이도'를 살펴봤다.



아래 명령어만 운영체제에 맞춰서 커맨드라인에서 실행하면 된다. 그레들 홈디렉토리에 데몬실행속성을 활성화하는 (org.gradle.daemon=true) gradle.properties 파일을 추가생산하는 것으로 간단하게 처리가 되었다.

  • Windows

    (if not exist "%HOMEPATH%/.gradle" mkdir "%HOMEPATH%/.gradle") && (echo "org.gradle.daemon=true" >> "%HOMEPATH%/.gradle/gradle.properties")
  • Linux or Unix

    touch ~/.gradle/gradle.properties && echo "org.gradle.daemon=true" >> ~/.gradle/gradle.properties

The Gradle Daemon is not enabled by default. However, once it is enabled it is sometimes desirable to disable for some projects or for some build invocations.

그레들 데몬은 기본설정은 활성화되지 않는다. 그러나, 한번 활성화 되고 나면 몇몇 프로젝트 빌드요청에서는 비활성화 하고 싶을 것이다.

The --no-daemon command line switch can be used to force that a Daemon not be used for that build. This is rarely used, but can sometimes be useful when debugging issues with certain builds or Gradle plugins. This command line switch has the highest precedence when considering the build environment.

커맨드라인 스위치 --no-daemon 강제로 사용하는 데몬을 빌드시 사용하지 않도록 할수 있다. 이것은 거의 사용되지 않고, 특정 빌드 또는 Gradle 플러그인 문제를 디버깅 할 때 때때로 유용 할 수 있다.

보다 상세한 내용은, https://docs.gradle.org/2.6/userguide/gradle_daemon.html 를 읽어보시길...

+ Recent posts