'gradle'에 해당하는 글 13건

Intellij 한글 깨짐

Daily/Prog 2019. 10. 24. 21:11

이 거지같은 한글 깨짐은 20년 동안 사라지질 않네.ㅋㅋ (한글 디스 아님!)




사건발단


1. 오늘 몇년전 프로젝트를 열었다가 IntelliJ 콘솔에서 우연히 한글깨짐을 발견했다.

2. 최근 프로젝트에서도 한글을 써보니 콘솔에서 한글깨짐이 발생했다. (한동안 영어만 쓰고 살았음...ㅡㅡv)

3. gradle 의 clean 작업을 실행하면서 build.gradle 의 한글이 깨졌으니 tomcat 의 문제는 아니다.

4. IntelliJ 가 실행될 때의 어느 곳에 있는 자바 옵션이 실행되는지를 체크하고 인코딩을 설정해야 한다. -Dfile.encoding=UTF-8



삽질


1. 시스템 환경변수 세팅

2. C:\Program Files\JetBrains\IntelliJ IDEA 2019.2.1\bin 의 idea.exe.vmoptions 과 idea64.exe.vmoptions

3. IntelliJ - Run/Debug Configurations - VM options


다 필요없음...



해결


IntelliJ - Help -  Edit Custom VM Options...  메뉴 열고  -Dfile.encoding=UTF-8  를 추가하여 해결.

파일위치는 C:\Users\username\.IntelliJIdea2019.2\config\idea64.exe.vmoption

오우... 사용자마다 세팅이 가능하게 되어 있나... 아니면 IntelliJ 사용자 등록하면서 별도 세팅이 되었던지...

암튼 이렇게 해결~~






WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  6개가 달렸습니다.
  1. 차분하게꾸준히 2020.02.19 04:52
    오... 도움 됐어요 감사합니다!
  2. 따봉!
  3. 감사합니다 2020.02.26 12:11
    드뎌 해결 되었네요!
secret

devtools 는 이름처럼 어플리케이션 개발시 유용한 기능들을 포함하고 있는 Spring Boot 모듈이다.

개발 도중 결과를 확인하기 위해 build 를 수동으로 실행하고 브라우저를 새로고침 하여 결과를 확인하는 동작을 자동화하는 것이 특히 유용하다.

gradle 에서 devtools 를 사용하려면 dependency 에 아래처럼 한 줄만 추가한다.


configurations {     developmentOnly     runtimeClasspath {         extendsFrom developmentOnly } }

dependencies {
    developmentOnly("org.springframework.boot:spring-boot-devtools")
}
cs


그리고 IDE 마다 설정이 약간씩 틀린데 어플리케이션 실행 중 자동 빌드에 관련한 옵션을 설정한다. (아래: Intellij)


  • File -> Settings [Ctrl-Alt-S] -> 검색 Compiler -> Build project automatically 체크
  • [Ctrl-Shift-A] -> Registry... -> compiler.automake.allow.when.app.running 체크
  • Run - Edit Configurations... - On 'Update' action / On frame deactivation: 적절히 선택 (Update classes and resources 등...)


이제 mainClass 를 실행(run) 시키고 코드를 수정하면 수초 뒤 변경 사항을 브라우저를 새로고침 하여 확인할 수 있다. 패키지(archive) 된 어플리케이션을 실행하면 production 모드로 간주하고 devtools 를 비활성화 하기 때문에 java -jar 나 bootRun 등을 이용하여 어플리케이션을 실행하면 devtools 는 동작하지 않는다. devtools 는 클래스 패스에 존재하는 코드 변경만 주시하므로, 특정 디렉토리의 코드만 자동 빌드가 되지 않는다면 클래스 패스에 추가하는 등의 방법으로 해결해야 한다.



Live Reload


spring-boot-devtools 모듈에는 리소스가 변경 될 때 브라우저가 새로 고침을 할 수 있게 하는 LiveReload 서버가 포함되어 기본으로 활성화 되어 있다.

서버브라우저에 liveReload 확장 프로그램을 설치하면, 코드 수정 후 사용자가 브라우저를 새로고침 하지 않아도 자동으로 새로고침 되어 보여진다.



Cache disabled


Spring Boot 의 몇가지 라이브러리는 성능 향상을 위해 캐시를 사용하는데, devtools 를 사용 중에는 사용자가 자동 빌드를 즉시 확인할 수 있도록, 알려진 템플릿 관련 캐시를 모두 비활성화 하는 것을 기본값으로 한다. application.properties 에 명시하여 수정도 가능하다. (예: spring.thymeleaf.cache=false)


아래는 devtools 의 자동화에 관련된 기본값이다. application.properties 파일에서 수정할 수 있다.


spring.devtools.livereload.enabled=true

spring.devtools.restart.enabled=true




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  4개가 달렸습니다.
  1. developmentOnly
    runtimeClasspath {
    extendsFrom developmentOnly
    }
    configurations{}에 위에 것은 왜 추가 안 하나요? 예제보면 저렇게 하라고 나와있던데? 하고 안 하고 차이가 없나요?
    • 수정했습니다. developmentOnly 를 위와 같이 수정한 경우 프로젝트에서 사용되는 다른 모듈에 적용되는 것을 방지할 수 있습니다.
  2. 개발자 2019.10.08 01:37
    안녕하세요, livereload 적용 했는데 새로고침까지 4~5초 정도가 걸립니다ㅠㅠ 소스 수정시 바로 반영되게 할 수 없을까요??
    • 어떤 IDE 를 사용하시는지, 컴파일이 필요한 수정을 하신건지 모르겠어서 답변이 어렵네요; 해당 IDE 설정으로 검색을 해보시는게 좋겠어요 ^^;
secret

Gradle exclude packages

Daily/Prog 2018. 10. 24. 00:40

gradle 프로젝트에서 가져온 종족성의 크기가 어마무시하게 크다면...

Instagram 크롤링 때문에 instagram4j 라이브러리를 가져온 적이 있었는데 추가 종속성들의 크기가 200MB 가 넘었다. ㅡㅡ;;

필요한건 getUsers / getMedias 정도였는데 동영상 업로드 관련 기능들 때문에 각종 코덱 패키지들이 죄다 다운로드 되고 빌드됐다.


이럴 때 사용할 수 있는 것이 exclude 이다.


// https://mvnrepository.com/artifact/org.brunocvcunha.instagram4j/instagram4j
compile ('org.brunocvcunha.instagram4j:instagram4j:1.7') {
    exclude group: 'org.bytedeco.javacpp-presets', module: 'opencv'
    exclude group: 'org.bytedeco'
}
cs


exclude group 한 줄 덕분에 관련 패키지들은 종속성에서 제외됐다. 

위 예제에 주석 처리한 것처럼 그룹이 아닌 특정 모듈만 제외할 수도 있다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Spring Boot


Spring Boot 는 production 급의 독립형 Spring 어플리케이션을 쉽게 만들 수 있으며, spring 설정이 거의 필요없다.(고 하지만 이거슨 거짓말! ㅜ)

아래는 간략한 Spring Boot 의 특징이다.


  • 독립 실행형 Spring 어플리케이션 생성.
  • Tomcat, Jetty, Undertow 등의 WAS 포함. (WAR 파일 배포 불필요)
  • 자동으로 Spring 설정.
  • 상태 확인, 측정 및 외부 구성과 같은 production 기능을 제공.
  • 코드를 생성하거나, XML 설정 파일이 불필요.



Spring Boot Gradle Plugin


Spring Boot 2.0 이상에서 gradle 로 시작하려 할 때, Spring Boot Gradle Plugin 을 사용하려면 Gradle 4.0 이상이 필요하며 다음과 같은 잇점이 있다.


  • Spring-boot-dependencies 가 제공하는 종속성 관리 가능
  • 실행 가능한 jar 또는 war 아카이브를 패키지화
  • Spring Boot 어플리케이션 실행



1. Spring-boot-gradle-plugin 시작


Spring Boot Gradle Plugin 은 간단하게 plugins 블럭을 사용하여 프로젝트에 적용할 수 있다.


plugins {
    id 'org.springframework.boot' version '2.0.6.RELEASE'
}
cs


buildscript 블럭을 사용할 경우 다음과 같이 사용한다.


buildscript {
    repositories {
        maven { url "https://plugins.gradle.org/m2/" }
    }
 
    dependencies {
        classpath 'org.springframework.boot:spring-boot-gradle-plugin:2.0.6.RELEASE'
    }
}
apply plugin: 'org.springframework.boot'
cs



2. Spring-boot-dependencies 가 제공하는 종속성 관리


dependency-management 플러그인을 사용하면 특정 Spring boot 버전에 호환되는 종속성을 자동으로 가져오며 각 버전을 관리해 주기 때문에, 종속성 마다 버전을 기입할 필요가 없다. 아래처럼 최소한의 플러그인을 적용한다.


apply plugin: 'java'
apply plugin: 'io.spring.dependency-management'
 
dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
}
cs


implementation 에는 종속성만 기입할 뿐 버전을 정의하지 않았다.


종속성의 다른 버전을 사용하고 싶은 경우 properties 를 지정하여 사용자 정의할 수 있으며, 호환성 문제를 꼭 체크하도록 한다.


ext['slf4j.version'= '1.7.20'
cs



3. 실행 가능한 jar 또는 war 아카이브 패키지화


Spring Boot Gradle Plugin 은 어플리케이션의 모든 종속성을 포함하는 실행 가능한 jar / war 파일을 생성하고 실행할 수 있다.


  • 실행 가능한 jar : java 플러그인이 적용될 때 bootJar task 가 생성되며 이를 사용하여 jar 파일을 빌드할 수 있다. build task 를 실행하면 bootJar task 도 실행된다.
  • 실행 가능한 war : war 플러그인이 적용될 때 bootWar task 가 생성되며 이를 사용하여 war 파일을 빌드할 수 있다. build task 를 실행하면 bootWar task 도 실행된다.


BootJar / BootWar task 는 Jar / War task 의 하위 클래스이다.


외부 컨테이너에서 java -jar 를 사용하여 war 파일을 실행하고 배포할 수 있도록 패키지화 하려면 서블릿 컨테이너 종속성을 providedRuntime 에 추가해야 한다.


dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat'
}
cs


기본적으로 bootJar / bootWar task 가 구성되면, jar / war task 는 비활성화 되는데 이를 활성화 시켜 실행 가능한 아카이브와 일반 아카이브를 동시에 빌드하도록 구성할 수 있다. 두 아카이브가 겹치지 않도록 둘 중 하나의 분류자(classfier) 를 구성할 수 있다.


jar {
    enabled = true
}
 
 
bootJar {
    classifier = 'boot'
}
cs


실행 가능한 아카이브의 main 클래스는 task 의 classpath 에서 public static void main(String[]) 메소드를 가진 클래스를 찾아 자동으로 구성되는데 mainClassName 속성을 사용하여 명시적으로 구성할 수도 있다.


bootJar {
    mainClassName = 'com.example.ExampleApplication'
}
cs


처음에 아카이브를 빌드하지 않고도 bootRun task 를 사용하여 어플리케이션을 실행할 수 있다.


bootRun {
    main = 'com.example.ExampleApplication'
}
cs


또는 Spring Boot DSL 의 mainClassName 속성을 사용하여 프로젝트 전체에서 기본 클래스 이름을 구성할 수도 있다.


springBoot {
    mainClassName = 'com.example.ExampleApplication'
}
cs


application 플러그인이 적용된 경우 mainClassName 프로젝트 속성을 사용하여 동일한 목적으로 사용할 수도 있다.


mainClassName = 'com.example.ExampleApplication'
cs


task 의 manifest 에 Start-Class 속성을 구성할 수 있다.


bootJar {
    manifest {
        attributes 'Start-Class''com.example.ExampleApplication'
    }
}
cs



Spring Boot 프로젝트에 java plugin 이 함께 쓰이면, Spring boot plugin 은 다음과 같이 동작한다.

  • bootJar task 생성. jar 파일은 main 소스셑의 런타임 클래스패스 상의 모든 소스를 포함하며, 클래스는 BOOT-INF/classes 에 패키징되고 jar 파일들은 BOOT-INF/lib 에 패키징 됨.
  • jar task 비활성화.
  • 어플리케이션을 실행하는 bootRun task 생성.
  • bootJar task 에 의해 생성된 아티팩트를 포함하도록 bootArchives 를 생성.
  • JavaCompile task 가 UTF-8 을 사용하도록 구성.
  • JavaCompile task 가 파라미터(-parameters) 를 사용하도록 구성.


Spring Boot 프로젝트에 war plugin 이 함께 쓰이면, Spring boot plugin 은 다음과 같이 동작한다.

  • bootWar task 생성. 표준 구성에 더하여 providedRuntime 구성이 WEB-INF/lib-provided 에 패키징 됨
  • war task 비활성화.
  • bootArchives 구성에 bootWar task 에 의해 생성된 아티팩트를 포함하도록 구성.


Spring Boot 프로젝트에 application plugin 이 함께 쓰이면, Spring boot plugin 은 다음과 같이 동작한다.

  • main 속성 규칙으로 mainClassName 속성을 사용하도록 booRun task 구성.
  • manifest 의 Start-Class 규칙으로 mainClassName 속성을 사용하도록 bootJar / bootWar task 구성.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

FAILURE: Build failed with an exception.


* What went wrong:

Execution failed for task ':Project:bootRun'.

> A problem occurred starting process 'command 'C:\Java\jdk1.8.0_65\bin\java.exe''


* Try:

Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.


BUILD FAILED


Total time: 2.332 secs

CreateProcess error=206, The filename or extension is too long. (파일 이름이나 확장명이 너무 깁니다.)

오전 10:58:49: Task execution finished 'bootRun'.


gradle library 추가 후 bootrun 실행시 발생한 오류. 뭔 파일 이름이나 확장명이 길다는건지; --debug 는 봐도 모르겠고...

검색 결과 클래스패스 종족성이 너무 길다는거 같은데, 클래스패스를 찍어 봤더니 약 33000자가 넘었다.ㅋㅋ;

Windows 에 CreateProcess 의 limit 가 32767 인거 같음.

Bootrun 시작 명령이 java -jar MyApp.jar -classpath a.jar,b.jar,c.jar,... 처럼 나열되는데 그럼 라이브러리를 몇 개 빼야하나;



해결책은 하나의 jar 파일에 저 종속성들을 나열하는 manifest 파일을 만들고 명령문에는 그 jar 파일 하나만을 호출하면 끝!

Gradle.build 코드는 다음과 같다.


task pathingJar(type: Jar) {
    dependsOn configurations.runtime
    appendix = 'pathing'
 
    doFirst {
        manifest {
            attributes "Class-Path": configurations.runtime.files.collect {
                it.toURI().toString().replaceFirst(/file:\/+/, '/')
            }.join(' ')
        }
    }
}
 
bootRun {
    dependsOn pathingJar
    doFirst {
        classpath = files("$buildDir/classes/main", "$buildDir/resources/main", pathingJar.archivePath)
    }
}
cs


이제 bootrun 을 실행하면 아래와 같이 manifest 파일이 담긴 pathing.jar 파일로 모든 종속성을 실행하게 된다.


> java -jar MyApp.jar -classpath pathing.jar
cs




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret