2012-10-12 2 views
2

아직 잘 알지 못하고 지금 당장이라도려고하고 있습니다. 나는 ... 더 간결한 gradle을 작성하는 방법은 무엇입니까?

task staging(type: Sync) { 
    from(stagingDir) {} 
    into toStagingDir 
} 

task syncJars(type: Sync) { 
    from(configurations.compile) {} 
    from(fixedLibDir) {} 
    into toStagingLibsDir 
} 

task copyMainJar(type: Copy) { 
    from(libsDir) {} 
    into toStagingLibsDir 
} 

task myZip(type: Zip) { 
    archiveName "bacnet.zip" 
    from(buildDir) { 
     include project.name+'/**' 
    } 
} 

syncJars.dependsOn('staging') 
copyMainJar.dependsOn('syncJars') 
myZip.dependsOn('copyMainJar') 
assemble.dependsOn('myZip') 

는 아마도 이런 식으로 쓰기 위해 어떻게든지있다 ... 다음 Gradle을 이제 제대로 작동하지만를 작성하는 더 간결한 방법이 있는지 궁금가

task prepareStaging { 
    staging from stagingDir into toStagingDir 
    syncJars from configurations.compile from fixedLibDir into toStagingLibsDir 
    copyMainJar from libsDir into toStagingLibsDir 
    myZip archiveName "bacnet.zip" from buildDir { include project.name+'/**' } 
} 

assemble.dependsOn('prepareStaging') 

이상적으로는, 나는 스스로 문서화하는 코드를 좋아한다. 이 두 번째 예제에서는 다음 개발자에게 재사용이 불가능한 각각의 작은 작업을 의미합니다. 이는 매우 명확합니다 (즉, 자체 문서화). 첫 번째 방법으로 나는 그 프로젝트가 다른 프로젝트 파일에서 재사용 될 수 있기 때문에 확실히 명확하지 않은 코드를 작성했다.

더 간단한 형태로 쓰려면 어떨까요?

참고 : 모든 UP-DATE 검사가 평소와 같이 이루어지기를 바랍니다. 다음, 아래 당신에 상응하는 일을해야

덕분에, 딘

답변

1

내가 제대로 이해하면, 그리고 toStagingDirtoStagingLibDir은 (myZip 작업 단위) buildDir 디렉토리에 생성되는 일시적인 디렉토리입니다

task myZip(type: Zip){ 
    archiveName "bacnet.zip" 
    into('staging'){ 
    from stagingDir 
    } 
    into('staging/libs'){ 
    from fixedLibDir 
    from configurations.compile 
    from libsDir 
    //or this, if you just want to include current projects jars 
    from jar.outputs.files 
    } 
} 

여기서 생각해 볼 수있는 것은 임시 디렉토리를 직접 만들지 않고 gradle이 대신 해줍니다.

cleanMyZip으로 전화를 걸지 않는 한 최신 검사를 수행하고 최소한 만 수행합니다. 지난 번 내가 Zip을 체크했을 때 더 이상 소스에 존재하지 않는 zip 파일을 제거한다는 점에서 Sync과 매우 유사하게 동작했습니다. 이것은 copyMainJar 작업과 약간 다르게 동작 할 수 있습니다. 유형이 Copy이기 때문에 libsDir에서 파일을 삭제하는 경우 제 경우에는 지퍼에서 사라지지만 코드에서는 사라집니다.

이 당신이 요구하는지에 근처에도 있는지 알고하지만 희망 약간 사용 :

정교화의 적어도하지 마십시오 Gradle을에서

작업은 항상으로 공용 AFAIK 디자인. enhancement request이 있지만 주위에 많은 조치가 없습니다. 비공개 가시성을 지원하는 표준 그루비 메서드를 사용할 수 있지만 작업만큼 강력하지는 않습니다.

def function = { 
    println "function here!" 
} 

task myTask(dependsOn: function) << { 
    println "myTask here!" 
} 

가 발생합니다 : :하지만 당신은 당신이 좋아하는 물건을 할 수 tasks can depend on groovy functions and more (또는 아무것도 call() 방법으로는) 것을 찾을 수 있습니다

function here! 
:a:myTask 
myTask here! 

이것은 당신에게 유연성을 제공해야하지만, 경우 정말 정말 정말 당신이 어떤 더러운 해킹 (I가 Gradle을들이 XX 나를 미워 알고를) 할 수있는 개인 작업을 필요로 여기 있습니다 ... :

//Create a factory for creating tasks 
import org.gradle.api.internal.project.taskfactory.ITaskFactory 
def taskFactory = project.services.get(ITaskFactory) 

//You can use the factory to create tasks without adding them to 
//project.tasks, which will make them invisible to most irrelevant 
//parts of your code, and they will not come up in `gradle tasks` list: 

//Equivalent of: 
// task myTask << { 
// println "i'm invisible" 
// } 
def privateTask = taskFactory.createTask([name: 'myTask']).doLast { 
    println "i'm invisible" 
} 

//Equivalent of: 
// task myCopyTask(type: Copy){ 
// from configurations.compile 
// into 'libs' 
// } 
def privateCopyTask = taskFactory.createTask([name: 'myCopyTask', type: Copy]) 
          .configure { 
    from configurations.compile 
    into 'lib-test' 
} 

//You can depend on the above tasks as usual from your public tasks: 
task publicTask(dependsOn: [privateTask, privateCopyTask]) << { 
    println "I'm public task" 
} 

참고 : 보인다 Gradle 1.2에서 작동하지만 사용자의 책임하에 사용하십시오!

행운을 빈다.

+0

분명히 유용하게 사용할 것입니다.하지만 실제로 궁금한 점은 다음 개발자에게 실제로 작업 단위라는 의사 소통을 위해 작업에 작업을 쓰는 방법이 있는지입니다. 함께 묶여 있어야합니다. –

+0

나는 본다. 정교한 내용을 원문으로보십시오. – rodion

관련 문제