gradle task - bootJar, build 비교 메모

젠킨스에서 토이프로젝트 jar 생성을 위해 ./gradlew bootJar로 사용하다 ./gradlew build 로 변경했는데 테스트 실패 오류가 빵빵 터졌다.

그렇다면 bootJar는 test를 안해서 그동안 성공을 했던건가??

동일한 모듈을 실행해보고 로그를 비교해보자!!

• bootJar : Assembles an executable jar archive containing the main classes and their dependencies.

8:11:17 오전: Executing task 'bootJar'...

> Task :module-domain:initQuerydslSourcesDir
> Task :module-domain:compileQuerydsl UP-TO-DATE
> Task :module-domain:compileJava UP-TO-DATE
> Task :module-domain:processResources UP-TO-DATE
> Task :module-domain:classes UP-TO-DATE
> Task :module-domain:jar UP-TO-DATE
> Task :module-web:initQuerydslSourcesDir
> Task :module-web:compileQuerydsl UP-TO-DATE
> Task :module-web:compileJava UP-TO-DATE
> Task :module-web:processResources UP-TO-DATE
> Task :module-web:classes UP-TO-DATE
> Task :module-web:bootJar UP-TO-DATE
...
BUILD SUCCESSFUL in 1s
10 actionable tasks: 2 executed, 8 up-to-date

• build : Assembles and tests this project.

8:13:01 오전: Executing task 'build'...

> Task :module-domain:initQuerydslSourcesDir
> Task :module-domain:compileQuerydsl UP-TO-DATE
> Task :module-domain:compileJava UP-TO-DATE
> Task :module-domain:processResources UP-TO-DATE
> Task :module-domain:classes UP-TO-DATE
> Task :module-domain:jar UP-TO-DATE
> Task :module-web:initQuerydslSourcesDir
> Task :module-web:compileQuerydsl UP-TO-DATE
> Task :module-web:compileJava UP-TO-DATE
> Task :module-web:processResources UP-TO-DATE
> Task :module-web:classes UP-TO-DATE
> Task :module-web:bootJar UP-TO-DATE

> Task :module-web:jar SKIPPED
> Task :module-web:assemble UP-TO-DATE
> Task :module-web:compileTestJava
> Task :module-web:processTestResources NO-SOURCE
> Task :module-web:testClasses
> Task :module-web:test
> Task :module-web:check
> Task :module-web:build
...
BUILD SUCCESSFUL in 35s
12 actionable tasks: 4 executed, 8 up-to-date

• bootJar와 비교했을 때 빨간 부분이 추가되었다. 일단 설명만 봐도 test를 한다고 써있다!!

  • bootJar는 실행 가능한 jar만 생성하는 것으로 보여진다.

  상황에 맞게 task 를 잘 선택하자!!

• 다음과 같이 그룹 및 task를 쉽게 추가할 수 있으며 기존 task 활용, 순서 등 다양하게 활용할 수 있다.

  • 설정하지 않아도 보여지는 task 그룹들은 build.gradle 에 추가한 플러그인들을 통해 기본으로 보여지는 것 같음
  • 프로젝트 환경에 따라 build 구성을 할 수 있다.
  • 다음에 해보는 걸로...
  • 
    
    

Entity 생성 - 컬럼에 default 값 관련 메모

Entity - 컬럼에 default 값

토이프로젝트 중 컬럼에 기본 값을 넣고 싶어서 다음과 같은 어노테이션을 사용하였는데, 내가 생각하는 null을 insert 하였을 때 기본 값이 들어가지 않았다.

@Column(columnDefinition="varchar(10) default 'N'")
private Long flag;

테이블 스키마 생성에만 관여하고 insert할 때는 영향이 없는 것 같다. (이유는 더 찾아봐야겠따...)

김영한님은 다음과 같이 사용하신다고 한다. https://www.inflearn.com/questions/83662

...
제가 신규로 진행하는 프로젝트들은 테이블이 제공하는 default를 거의 사용하지 않습니다.

엔티티에 중심으로 개발하다 보니, 객체에 값을 넣는 방식으로 주로 진행합니다.

쉽게 이야기해서 생성자에서 기본값을 미리 설정하는 방식을 사용합니다.

다른 예를 들어드리면, 실무에서 @Index(인덱스 조건)도 DDL을 생성할 때만 사용하기 때문에 사실은 적을 필요가 없지만, 
그래도 엔티티에 이 애노테이션이 있으면, 개발자분들이 엔티티만 보고 인덱스를 생각하고 JPQL을 작성할 수 있기 때문에 사용합니다. 
말씀하신 default도 그런 관점에서 저는 적으면 좋겠다고 생각합니다.
...

위 내용과 같이 생성자에서 값을 그냥 넣어주던가 이렇게 사용하는 방법도 있다.

@Column
private Long flag = "N";

샘플데이터 생성하기

 로컬에서 조회 기능 확인할 때 자동으로 생성되는 샘플데이터가 있으면 편하다.

다음과 같이 생성하자

@Component
@RequiredArgsConstructor
public class InitContents {

    private final InitContentsService initContentsService;

    @PostConstruct
    public void init(){
        initContentsService.init();
    }

    @Component
    static class InitContentsService{

        @PersistenceContext
        private EntityManager em;

        @Transactional
        public void init(){

            Board board = new Board("board1");
            em.persist(board);

            Topic topic1 = new Topic("topic1", board);
            Topic topic2 = new Topic("topic2", board);
            em.persist(topic1);
            em.persist(topic2);


            Card card1 = new Card("card1", "des1", topic1);
            Card card2 = new Card("card2", "des2", topic1);
            Card card3 = new Card("card3", "des3", topic2);
            Card card4 = new Card("card4", "des4", topic2);
            Card card5 = new Card("card5", "des5", topic2);
            Card card6 = new Card("card6", "des6", topic2);
            em.persist(card1);
            em.persist(card2);
            em.persist(card3);
            em.persist(card4);
            em.persist(card5);
            em.persist(card6);

            CheckList checkList1 = new CheckList("checkList1", card1);
            CheckList checkList2 = new CheckList("checkList2", card1);
            em.persist(checkList1);
            em.persist(checkList2);

            CheckItem checkItem1 = new CheckItem("checkItem1",checkList1);
            CheckItem checkItem2 = new CheckItem("checkItem2",checkList1);
            CheckItem checkItem3 = new CheckItem("checkItem3",checkList1);
            CheckItem checkItem4 = new CheckItem("checkItem4",checkList2);
            CheckItem checkItem5 = new CheckItem("checkItem5",checkList2);

            checkItem1.update("checkItem1", "N", "Y");
            checkItem2.update("checkItem2", "N", "Y");

            em.persist(checkItem1);
            em.persist(checkItem2);
            em.persist(checkItem3);
            em.persist(checkItem4);
            em.persist(checkItem5);

            checkList1.addCheckItem(checkItem1);
            checkList1.addCheckItem(checkItem2);
            checkList1.addCheckItem(checkItem3);
            checkList2.addCheckItem(checkItem4);
            checkList2.addCheckItem(checkItem5);

            Label label1 = new Label("label1", "green");
            Label label2 = new Label("label2", "red");
            Label label3 = new Label("label3", "blue");

            em.persist(label1);
            em.persist(label2);
            em.persist(label3);

            CardLabel cardLabel1 = new CardLabel(card1, label1);
            CardLabel cardLabel2 = new CardLabel(card2, label2);
            CardLabel cardLabel3 = new CardLabel(card1, label3);
            CardLabel cardLabel4 = new CardLabel(card4, label3);

            card1.addCardLabel(cardLabel1);
            card2.addCardLabel(cardLabel2);
            card1.addCardLabel(cardLabel3);
            card4.addCardLabel(cardLabel4);

        }
    }
}

• 왜 바로 @PostContruct 에 넣지 않고 따로 빈을 만들었는가?

  • 스프링 라이플 사이클에 의해 @Transacational 과 같이 사용할 수 없다고한다.

  • https://github.com/spring-projects/spring-framework/issues/10670

  This is as defined, actually: init methods (such as @PostConstruct methods) are always called on the target instance itself.
  The proxy will only be generated once the target instance has been fully initialized...
  In other words, the @Transactional proxy isn't even created at the point of the @PostConstruct call yet.
  
  
  @PostConstructor 는 인스턴스 자체에서 호출됨
  프록시는 인스턴스가 완전히 초기화된 후에 생성됨
  그래서 @Transcational 프록시는 @PostConstruct 호출 시점에 생성되지 않음

@NoArgsConstructor(access = AccessLevel.PROTECTED)

@NoArgsConstructor(access = AccessLevel.PROTECTED) 쓰는 이유

• JPA는 기본적으로 디폴트 생성자가 필요함(파라미터가 없는 생성자)

  • protected 까지만 허용됨
  • @NoArgsConstructor(access = AccessLevel.PROTECTED) 을 통해 가능

• 그렇다고 public 으로 만들면 객체 생성이 일관하지 않게 막 생성될 수 있음!

  • 그래서 protected로 제한하자. (JPA에 필요하기 때문에 private X)

// title이 필수인데 실수로 누락될 수 있음
// 혹은 이상한 곳에서 setter로 인해 엔티티 값이 변경될 수 있음
Board board1 = new Board();
board1.setContent("content1");


// setter를 사용하지 말고 이렇게 사용하자
Board board2 = Board.builder()
  .title("title1")
  .content("content1")
  .build();

board2.updateInfo("updateTitle", "updateContent");

Maven이란?

Maven : 프로젝트 객체 모델(Project Object Model)이라는 개념을 바탕으로 프로젝트 의존성 관리, 라이브러리 관리, 프로젝트 생명 주기 관리 기능 등을 제공하는 프로젝트 관리 도구

플러그인을 기반으로 소스 코드로부터 배포 가능한 산출물을 만들어 내는 빌드 기능 뿐만 아니라 레포팅 및 documentation 작성 기능 등을 제공한다.

>>내가 사용할 라이브러리 뿐만아니라 해당 라이브러리가 작동하는데 필요한 라이브러리들도 자동으로 받아줌

장점

• 뛰어난 의존성 관리 
 - 의존성 자동 업데이트 
 - 저장소를 통한 라이브리 일괄 관리 
• 모든 프로젝트에 걸쳐 쉽게 적용 가능한 일관적인 사용법 
• 라이브러리 및 메타 데이터 저장을 위한 지속적으로 확장 되고 있는 저장소 
• 쉽게 작성 가능한 플러그 인을 통한 확장성 
• 동시에 다수의 프로젝트 핸들링 할 수 있는 쉬운 설정 기반의 메커니즘
• 간단한 설정을 통한 배포 관리 
• Java, C++ 등 다수의 프로그래밍 언어 지원

단점

• Repository 관리의 불편함 
 - Maven 프로젝트의 급속한 발전으로 central repository가 제공하는 라이브러리들이 빠르게 증가하고 있으나 아직 3rd 파티 라이브러 등 미제공 라이브러리들이 있음 
• pom.xml 파일 관리 
 - 메이븐 프로젝트 관리에 대한 모든 내용이 pom.xml 파일에 담기게 되믄로 길고 장황하게 될 수 있음 
• 프로젝트에 특화된 복잡한 빌드 기능 제약 
 - 메이븐 프로젝트 특성상 소프트웨어 빌드에 통용되는 라이프 사이클을 제공하고 있어 세부 항목 또는 특화된 빌드 환경에 대한 지원이 미약함

pom.xml(Project Object Model) 

프로젝트 정보, 빌드 설정, 빌드 환경 등 프로젝트 라이브러리의 의존관계 관리하는 프로젝트 정보 기술.

<scope> 

compile : 컴파일 할때 필요. 테스트 및 런타임에도 클래스 패스에 포함 된다. scorp 을 설정 하지 않는 경우 기본값이다.
runtime : 런타임에 필요. JDBC 드라이버 등이 예가 된다. 컴파일 시에는 필요하지 않지만, 실행 시에 필요한 경우.
provided : 컴파일 시에 필요하지만, 실제 런타임 때에는 컨테이너 같은 것에서 제공되는 모듈. servlet, jsp api 등이 이에 해당. 배포시 제외된다.
test : 테스트 코드를 컴파일 할때 필요. 테스트시 클래스 패스에 포함되며, 배포시 제외된다

출처 및 참고
https://opentutorials.org/module/867/6383

http://egloos.zum.com/laydios/v/2789441


http://maven.apache.org/what-is-maven.html