gradle에 대한 학습의욕은 그득하나, 어떻게든 시작은 해보자.

gradle 처음 시작에 대한 이야기를 했었지만, 차근히 살펴보지 못했었는데, 이번 기회에 하나하나 꼬리에 꼬리를 물고 살펴보자.



gradle은 꾸준하게 업그레이드가 진행되고 있다. 1.10 나온지 얼마 되지도 않았는데 어느새 1.11이 2월 11일에 나오고…
어느 정도의 버전호환성은 유지되고 있다. 어느정도 안정화는 되었지만, [incubating] 되고 있는 기능들이 종종 사라지는 경우도 있으니 gradle 버전이 업그레이드될 때마다 한번씩 릴리즈 노트를 살펴보는 것이 중요하다.

오늘은 간단하게 gradle을 통해서 프로젝트를 구성하고 준비하자.
maven의 경우에는 최초 프로젝트를 생성하기 위해서 pom.xml 이 존재해야 한다. 혹은 How do I make my first Maven project?와 같이 archtype을 지정해야 한다. 물론 검색해서 찾아야 하는 번거로움이 있다.

mvn archetype:generate \ -DarchetypeGroupId=org.apache.maven.archetypes \ -DgroupId=com.mycompany.app \ -DartifactId=my-app

gradle의 경우는 Build init plugin에서 지원하는 5가지 유형(‘pom(Maven의 pom.xml을 바탕으로 build.gradle 을 생성)’, ‘java-library(자바의 관례적인 프로젝트 형태로 구성)’, ‘scala-library(스칼라)’, ‘groovy-library(그루비)’, ‘basic(build.gradle과 settings.gradle만 생성)’)을 제공한다.

나는 자바 개발자니까 gradle을 이용해서 java 프로젝트를 생성해보겠다.

$ gradle init --type java-library

이 명령어의 수행결과는 다음과 같다.


build.gradle

/*
 * This build file was auto generated by running the Gradle 'init' task
 * by 'ihoneymon' at '14. 2. 26 오전 12:59' with Gradle 1.10
 *
 * This generated file contains a sample Java project to get you started.
 * For more details take a look at the Java Quickstart chapter in the Gradle
 * user guide available at http://gradle.org/docs/1.10/userguide/tutorial_java_projects.html
 */

// Apply the java plugin to add support for Java
apply plugin: 'java'

// In this section you declare where to find the dependencies of your project
repositories {
    // Use 'maven central' for resolving your dependencies.
    // You can declare any Maven/Ivy/file repository here.
    mavenCentral()
}

// In this section you declare the dependencies for your production and test code
dependencies {
    // The production code uses the SLF4J logging API at compile time
    compile 'org.slf4j:slf4j-api:1.7.5'

    // Declare the dependency for your favourite test framework you want to use in your tests.
    // TestNG is also supported by the Gradle Test task. Just change the
    // testCompile dependency to testCompile 'org.testng:testng:6.8.1' and add
    // 'test.useTestNG()' to your build script.
    testCompile 'junit:junit:4.11'
}

settings.gradle

/*
 * This settings file was auto generated by the Gradle buildInit task
 * by 'ihoneymon' at '14. 2. 26 오전 12:59' with Gradle 1.10
 *
 * The settings file is used to specify which projects to include in your build.
 * In a single project build this file can be empty or even removed.
 *
 * Detailed information about configuring a multi-project build in Gradle can be found
 * in the user guide at http://gradle.org/docs/1.10/userguide/multi_project_builds.html
 */

/*
// To declare projects as part of a multi-project build use the 'include' method
include 'shared'
include 'api'
include 'services:webservice'
*/

rootProject.name = 'gradle'

의 그래들 스크립트가 자동생성된 것을 볼 수 있다. build.gradle 에서 apply plugin: 'java'가 다음 이야기를 할 대상이다.

다음에는 gradle의 플러그인을 살펴보자.


참고


  • 참고 : A successful git branching model

  • 깃git의 기본 브랜치는 master에서 시작합니다.

  • master는 태그Tag를 기록하기 위한 기본브랜치로 사용됩니다.
  • 개발을 위해서는 develop 브랜치를 생성합니다.

    개발자들이 실제로 소스코드를 공유하는 브랜치가 됩니다.

    //master 브랜치에서 develop 브랜치를 생성합니다.
    (master)$ git checkout -b develop
    (develop)$
    
  • 소스코드를 push하기 전에 하는 기본적인 동작방식은 다음과 같습니다.

    1. 소스코드를 스태징 상태로 변경
      (develop)$ git add .
      
    2. 소스코드를 커밋함 - 가급적이면 개발한 내용을 상세기록하시는 걸 추천함
      (develop)$ git commit
      이후 커밋메시지 등록
      //혹은
      (develop)$ git commit -m '소스코드 중 친구목록 반환시 기준변경'
      
    3. 원격저장소(remote repository)에서 당겨오기(pull)
      (develop)$ git pull origin develop
      
    4. 별다른 충돌conflict가 발생하지 않았다면 push
      (develop)$ git push origin develop
      
  • 기능개발시 브린치 생성

    1. 브랜치 생성 - 웹 애플리케이션 설정을 하는 단계의 브랜치
      (develop)$ git checkout -b feature/web-application-config
      (feature/web-application-config)$
      
    2. 소스코드 변경작업 후 스태징 상태로 변경
      (feature/web-application-config)$ git add .
      
    3. 소스코드 커밋
      (feature/web-application-config)$ git commit -m '웹 애플리케이션 설정완료 web.xml 등 설정'
      
    4. develop 브랜치로 체크아웃
      (feature/web-application-config)$ git checkout develop
      (develop)$
      
    5. feature/web-application-config 브랜치 병합merge
      (develop)$ git merge feature/web-application-config
      
    6. feature/web-application-config 브랜치 삭제
      (develop)$ git branch -d feature/web-application-config
      

이런 형태로 기능개발하실 때에 기능 브랜치(feature)를 생성해서 작업하신 후에 커밋하시고 develop 브랜치로 체크아웃하셔서 머지merge를 해주시면 큰 충돌없이 develop에서 소스코드를 유지하실 수 있을겁니다.

깃에 익숙치 않으시다면, 소스트리sourcetree와 같은 GUI 클라이언트를 사용하시는 것을 추천드립니다.

+ Recent posts