• Eclipse Plugin
• Eclipse 플러그인은 Eclpise IDE 설정 파일을 생성하여, Eclipse로 프로젝트를 import할 수 있도록 한다(File - Import … - Existing Projects into Workspace).
• 외부 의존성과 프로젝트 의존성을 모두 고려하여 설정 파일을 생성한다.
• 웹프로젝트는 eclipse-wtp 플러그인으로 분리되었다. 따라서, WTP 프로젝트를 생성하려면 eclipse-wtp 플러그인도 적용해야 한다.
• eclipse-wtp를 적용하면 eclipse 플러그인은 명시하지 않아도 자동 적용된다.
• eclipse 프로젝트는 어떤 다른 플러그인이 설정돼 있느냐에 따라 다르게 반응한다.

apply plugin: 'eclipse'
 
// 혹은
apply plugin: 'eclipse-wtp'

Eclipse용 Gradle 플러그인을 원한다면

• Eclipse Buildship : Eclipse 공식 Gradle Plugin Buildship
• Eclipse Integration Gradle. 잘 작동하는 듯 하며, 이 플러그인 자체가 Gradle Eclipse 플러그인에 의존하고 있는 듯 하다.

• Gradle Eclipse Plugin으로 멀티 프로젝트를 구성한 뒤에 gradle eclipse를 실행하고서 각 프로젝트를 Eclipse에서 “Existing Projects into Workspace”로 임포트할 수 있다.
• 단, 이때 Eclipse 4.2 이하 버전은 최상위 프로젝트에 .project 파일이 있을 경우 하위 프로젝트들을 일괄적으로 가져오는 것이 안된다. 이로 인해 각각의 하위 프로젝트를 하나씩 Import 해야한다.
• 하지만 최상위 프로젝트에서 .project 파일을 일시적으로 삭제하고, 최상위 경로로 일괄 Import를 한 뒤에 다시 .project 파일을 되살려 주면 이 문제를 해결할 수 있다.
• Eclipse 4.3에서는 이런 과정없이 Multi Project import가 잘 된다.

현재 (1.2) WTP 프로젝트가 의존하고 있는 일반 Java 프로젝트에도 eclipse-wtp를 apply하지 않으면 의존 라이브러리를 제대로 배포(Deployment Assembly)에 추가하지 못하는 문제가 있다. /GRADLE-1880 참조.

따라서 eclipse-wtp를 사용하려면 의존관계가 엮이는 모든 프로젝트에 apply plugin: “eclipse-wtp”를 해줘야 한다.

• 많은 태스크가 있으나 기본적으로 eclipse와 cleanEclipse를 알면 된다.

• eclipse 태스크 실행전에 다른 태스크를 실행하고자 한다면 eclipseProject 태스크에 의존성을 지정한다. eclipse 태스크에는 의존성 지정이 안 된다.

  eclipseProject.dependsOn myTaskName

  • Gradle 1.5 현재 tasks.eclipse.dependsOn myTask 형태로 의존성 지정 된다.

• 각 모델을 참조하면 된다.
• Eclipse와 다른 Gradle 특징들과의 연동에 관한 예제들이 위키 문서에 퍼져 있다. 백링크로 확인한다.

• eclipse.wtp.component/facet은 war 플러그인이 적용된 상태일때만 접근 가능하다.

sourceSets의 java와 resources에 srcDir로 소스 디렉토리를 추가하면 이클립스에서도 자동으로 소스 디렉토리로 만든다.

sourceSets {
    main {
        resources {
            srcDir "src/main/resources-appcontext" // resources-appcontext가 소스 디렉토리로 추가됨
        }
    }
}

eclipse {
    classpath {
        defaultOutputDir = file("${buildDir}/classes/main")
    }
}

eclipse.classpath.file.whenMerged { cp ->
	def testSrcs = cp.entries.findAll {
		it instanceof org.gradle.plugins.ide.eclipse.model.SourceFolder &&
		 it.path.startsWith("src/test/")
	 }
 
	 testSrcs.each {
                // 멀티 프로젝트에서는 꼭 project.relativePath 로 호출해야 한다.
                // 안그러면 Root 프로젝트에 대한 상대경로가 지정됨면서 하위 모듈의 프로젝트이름이 이중으로 들어감.
	 	it.output = project.relativePath("${buildDir}/classes/test")
	 	it.exported = false // Deployment Assembly에서 제외
	 }
         // 중복 엔트리 삭제. gradle eclipse를 두 번이상 실행하면 test 관련 디렉토리가 중복 생성된다.
         cp.entries.unique()
}

eclipse {
  classpath {
    //default settings for downloading sources and Javadoc:
    downloadSources = true
    downloadJavadoc = false
  }
}

eclipse {
    wtp {
        component {
            contextPath = project.name // 원하는 contextPath 지정. 단, 빈 컨텍스트패스는 '/' 로 지정
        }
        facet {
            facet name: 'jst.web', version: '2.5' // Servlet Spec Version 지정
            facet name: 'jst.java', version: '1.6' // Java Version 지정, 1.7 ...
        }
    }
}

• 프로젝트에 다른 위치의 파일이나 경로를 링크해서 마치 자기 프로젝트의 파일이나 경로처럼 사용할 수 있는 기능.
• EclipseLinkedResource를 참조로 설정한다.
• type은 1은 파일 2는 디렉토리이다.
• name, type, location* 모두 String 타입이다.

eclipse {
  project {
    linkedResource name: '프로젝트에상대적인경로', type: '1|2, locationUri: 'file://someUri' // URI 기반
    linkedResource name: '프로젝트에상대적인경로', type: '1|2', location: '/some/location' // 파일의 절대 경로 기반.
  }
}

Eclipse 플러그인은 이클립스 설정 메타 데이터 파일을 생성하면서 커스터마이징 할 수 있도록 지원해준다.

이미 존재하는 이클립스 설정 파일의 부분들은 어떤 부분이냐에 따라 수정 혹은 덮어쓰기의 대상이다. 나머지 부분은 있는 그대로 내버려 둔다.

이클립스 설정 파일을 항상 완전히 덮어 쓰려면 gradle cleanEclipse eclipse를 한다. 간단히 tasks.eclipse.dependsOn(cleanEclipse)로 지정해 놓고 gradle eclipse를 실행해도 된다.

특정 파일별로 덮어 쓰기를 하려면 gradle cleanEclipseClasspath eclipseClasspath 형태로 각 부분을 명시해 주면 된다.

이클립스 플러그인은 Gradle이 생성하는 이클립스 파일의 모델링을 하는 객체를 제공해 준다. 파일 생성 라이프사이클은 다음과 같다.

1. 설정 파일을 읽는다, 존재하지 않으면 Gradle이 생성하는 기본 버전을 사용한다.
2. beforeMerged 훅이 설정 파일을 나타내는 도메인 객체를 인자로 실행된다.
3. 이미 존재하는 컨텐츠가 Gradle 빌드에서 생성되었거나 eclipse DSL에서 정의한 설정과 병합된다.
4. whenMerged 훅이 설정 파일을 나타내는 도메인 객체를 인자로 실행된다.
5. withXml 훅이 저장될 설정 파일의 XML을 인자로 실행된다.
6. 최종 XML이 저장된다.

• 고급 설정 훅

• WtpComponent.wbModuleEntries는 WbDependentModule,WbResource, WbProperty, WbSource 등의 객체의 리스트
• Classpath.entries는 ClasspathEntry를 구현한 Output, SourceFolder, Container, Library 등이다.

beforeMerged 훅을 사용하여 기존에 존재하는 컨텐츠의 특정 부분만 덮어쓸 수 있다. beforeMerged는 말 그대로 기존에 존재하는 데이터에 대해서만 접근할 수 있다. Gradle이 신규 생성하는 것들에는 접근할 수 없다.

• 클래스패스의 일부 의존성 제거 build.gradle

  eclipse.classpath.file {
      beforeMerged { classpath ->
          classpath.entries.removeAll { entry -> entry.kind == 'lib' || entry.kind == 'var' }
      }
  }

그 결과 생성되는 .classpath 파일은 원본 파일에 있는 의존성 엔트리는 모두 제거하고 Gradle이 생성한 것만 가지게 된다. .classpath의 다른 부분은 그대로 남아서 병합된다. .project 파일도 마찬가지로 할 수 있다.

• .project 부분 덮어쓰기 build.gradle

  eclipse.project.file.beforeMerged { project ->
      project.natures.clear()
  }

whenMerged 훅으로 완전히 생성된 도메인 객체를 관리할 수 있다. 보통 이 방식을 주로 쓴다.

• 의존성 export 변경 build.gradle

  eclipse.classpath.file {
      whenMerged { classpath ->
          classpath.entries.findAll { entry -> entry.kind == 'lib' }*.exported = false
      }
  }

withXmlhook을 사용하여 메모리에 있는 XML을 디스크에 쓰기 전에 제어할 수 있다. whenMerged가 좀 더 편하다. 하지만 생성되는 파일에서 모델에 들어가지 않는 부분들에 대한 완전한 제어권을 가질 수 있게 된다.

• XML 수정 build.gradle

  apply plugin: 'eclipse-wtp'
   
  eclipse.wtp.facet.file.withXml { provider ->
      provider.asNode().fixed.find { it.@facet == 'jst.java' }.@facet = 'jst2.java'
  }

• Run → External Tools → External Tools Configurations 에서
• gradle cleanEclipse eclipse clean 명령을 외부 프로그램으로 등록해준다.
• 등록시 Refresh 탭에서 “Refresh resources upon completion.”을 체크하고 “The entire workspace”를 선택해둔다. “Recursively include sub-folders”도 체크된 상태.
• 등록시 Common 탭에서 “Display in favorites menu”의 “External Tools”체 체크해둔다.
• 이제부터는 gradle 설정이 변경 되었을 때 이 명령만 실행하면 최종적으로 새로고침까지 모두 자동으로 수행된다.

• http://forums.gradle.org/gradle/topics/is_it_possible_to_have_gradle_mark_the_build_directory_as_derived_in_eclipse #TODO 테스트

Gradle + Eclipse Expert 더 정리