2015-09-28 146 views
11

如果您正在寻找样本gradle protobuf项目看here简单protobuf编译与gradle

我有很难与gradle这个和protobuf的, 我想创建一个简单的项目的gradle将从默认src/main/protosrc/test/proto据此采取任何原始文件,并将其编译成src/main/javasrc/test/java,再包变成一只罐子并发布到本地回购。

不幸的是,我是新来的gradle,不能弄清原始项目是如何组成的。

这是我未完成的build.gradle文件

apply plugin: 'java' 
apply plugin: "com.google.protobuf" 

buildscript { 
    repositories { 
     mavenCentral() 
    } 
    dependencies { 
     classpath 'com.google.protobuf:protobuf-gradle-plugin:0.7.0' 
    } 
} 

repositories { 
    mavenCentral() 
} 

dependencies { 
    compile 'com.google.protobuf:protobuf-java:3.0.0-beta-1' 
} 

sourceSets { 
    main { 
     proto { 
      srcDir 'src/main/proto' 
     } 
     java { 
      srcDir 'src/main/java' 
     } 
    } 
    test { 
     proto { 
      srcDir 'src/test/proto' 
     } 
     proto { 
      srcDir 'src/test/java' 
     } 
    } 
} 

protobuf { 
    // Configure the protoc executable 
    protoc { 
     // Download from repositories 
     artifact = 'com.google.protobuf:protoc:3.0.0-alpha-3' 
    } 
    generateProtoTasks { 
     // all() returns the collection of all protoc tasks 
     all().each { task -> 
      // Here you can configure the task 
     } 

     // In addition to all(), you may get the task collection by various 
     // criteria: 

     // (Java only) returns tasks for a sourceSet 
     ofSourceSet('main') 

    } 
} 

乳宁jar任务后,我们有这样的:

enter image description here

,你可以看到gradle这个建立测试和主PROTOS相同的classes目录(红色箭头),在jar中我可以看到包含两个生成的类(而测试应该跳过)。

但主要的问题是,我想使直接编译原文件到相应的源目录(蓝色箭头),后普通构建会做正确的事情......毕竟我们需要这些类的SRC来在业务逻辑中使用它们...

所以我们只需要一个任务,将proto编译到合适的src目录中......仅此而已。

src/main/proto to src/main/java 
src/test/proto to src/test/java 

当前的项目,因为它位于here。请帮助配置这一点,我很确定很多人以后会需要它...

+0

请问你能分享一个可运行的例子吗?我知道这将是未完成的。 – Opal

+0

肯定在一瞬间 – vach

+0

@Opal https://github.com/vach/sample-gradle-protobuf我会留下最后的工作版本供其他人使用 – vach

回答

12

如果我不误解你的问题,它很容易解决。如果你不想让自己和所产生的来源进行区分,你只需要添加设置generatedFileBaseDir这样generateProtoTasks.generatedFilesBaseDir = 'src'

所以整个生成文件的样子:

// ... 

protobuf { 
// Configure the protoc executable 
protoc { 
    // Download from repositories 
    artifact = 'com.google.protobuf:protoc:3.0.0-alpha-3' 
} 

generateProtoTasks.generatedFilesBaseDir = 'src' // <- that line 

generateProtoTasks { 
    // all() returns the collection of all protoc tasks 
    all().each { task -> 
     // Here you can configure the task 
    } 

比你的文件夹的样子:

  • 的src /主/ JAVA/COM/vach /试用/ AddressBookProtos.java
  • 的src /主/ JAVA/COM/vach /试用/ protobuf的/ Main.java

但是: 这可能不是混合生成与手工源代码的最佳主意。所以我的建议是将源代码生成到自己的目录中,如generatedSources,并将此目录添加到java sourceSet。构建文件应该是这样的:

sourceSets { 
    main { 
     proto { 
      srcDir 'src/main/proto' 
     } 
     java { 
      // include self written and generated code 
      srcDirs 'src/main/java', 'generated-sources/main/java'    
     } 
    } 
    // remove the test configuration - at least in your example you don't have a special test proto file 
} 

protobuf { 
    // Configure the protoc executable 
    protoc { 
     // Download from repositories 
     artifact = 'com.google.protobuf:protoc:3.0.0-alpha-3' 
    } 

    generateProtoTasks.generatedFilesBaseDir = 'generated-sources' 

    generateProtoTasks { 
     // all() returns the collection of all protoc tasks 
     all().each { task -> 
      // Here you can configure the task 
     } 

     // In addition to all(), you may get the task collection by various 
     // criteria: 

     // (Java only) returns tasks for a sourceSet 
     ofSourceSet('main') 

    } 
} 

您的目录会这个样子

  • 的src/main /原/ DTOS。原
  • 的src /主/ JAVA/COM/vach /试用/ protobuf的/ Main.java
  • 产生来源/主/​​ JAVA/COM/vach /试用/ AddressBookProtos.java

好用侧效果是你可以忽略这个生成源目录在你的git配置中。不要发布生成的源代码总是一个好主意。

+0

我不太明白为什么它认为不好生成的代码附近手工,即使是默认行为将它分离到不同的目录......后来protobuf是一种工具来生成DTOs是有效地序列化和反序列化自己...你在你的手工代码中使用它们...如果你将它们分开到不同的目录,你需要配置ide来了解aditional源代码目录...我没有看到足够好的理由这样做... – vach

+0

我打算使用protobuf的方式是有一个小项目,其中包含将dtos.jar暴露给本地回购和其他项目的所有DTOs ... – vach

+0

@vach关于您的第一个问题 - 你为什么要从'书面代码'中分离生成的代码:这是一个有趣的事情。你可以在这里找到一个讨论:[http://stackoverflow.com/questions/893913/should-i-store-generated-code-in-source-control]。除了较小的提交之外,有些可能会意外更改生成的代码。此外,删除类型会变得更加困难(您必须删除原始文件和Java文件)。 – TobiSH