Big +1 to Kenneth's idea on a cookbook for common tasks, it is easy to
feel frustrated with gradle when we cannot achieve easily some of the
tasks we need to, like overwriting a configuration property. The case
that Romain mentioned above is a common one, e.g. I used to test kafka
with a different version of the client quickly by doing this with
maven:
mvn verify -Prelease -Dkafka.clients.version=0.10.0.1 -pl
'sdks/java/io/kafka'
but I don't have any idea of how to do this on Gradle.
Of course everybody has a different workflow, but I am pretty sure
there are some common tasks that we can document for people (like me)
that are new to gradle. (I agree that documentation can become
outdated but it is better to have it that don't).
Some ideas for the cookbook:
Apart of the obvious tasks (updating the contribution guide), maybe we
can have some section for 'advanced' tricks:
- How to skip the Java/Python/Go build depending on your priorities.
- How to run an individual IntegrationTest or ValidatesRunner test.
- How to skip findbugs,checkstyle,javadoc gneeration, etc. To have an
ultra quick build.
Regards,
Ismaël
On Tue, Jan 23, 2018 at 9:34 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote:
> Good idea. It sounds like a simple and good improvement to me.
>
> Regards
> JB
>
> On 01/23/2018 09:29 AM, Romain Manni-Bucau wrote:
>> Yep,
>>
>> a compromise can be to ensure all custom tasks have a description maybe:
>>
>> diff --git a/examples/java/build.gradle b/examples/java/build.gradle
>> index 0fc0b17df..001bd8b38 100644
>> --- a/examples/java/build.gradle
>> +++ b/examples/java/build.gradle
>> @@ -130,7 +130,7 @@ def preCommitAdditionalFlags = [
>> dataflowStreamingRunner: [ "--streaming=true" ],
>> ]
>> for (String runner : preCommitRunners) {
>> - tasks.create(name: runner + "PreCommit", type: Test) {
>> + tasks.create(name: runner + "PreCommit", type: Test, description: "Run
>> tests
>> for runner ${runner.replace('Runner', '')}") {
>> def preCommitBeamTestPipelineOptions = [
>> "--project=apache-beam-testing",
>> "--tempRoot=gs://temp-storage-for-end-to-end-tests",
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau>
>> |
>> LinkedIn <https://www.linkedin.com/in/rmannibucau>
>>
>> 2018-01-23 8:45 GMT+01:00 Jean-Baptiste Onofré <j...@nanthrax.net
>> <mailto:j...@nanthrax.net>>:
>>
>> Hi Romain,
>>
>> I think we are pretty close: agree to add some explicit tasks & projects
>> names.
>>
>> We can add additional tasks like skipAudit, for instance.
>>
>> As reminder, gradle tasks provides the list of tasks and gradle projects
>> provides the list of projects/modules.
>>
>> Regards
>> JB
>>
>> On 01/23/2018 08:12 AM, Romain Manni-Bucau wrote:
>> > Hmm, I have to admit docs dont have my favor cause they are easily
>> outdated and
>> > hard to search but you hit a good point. Starting by renaming properly
>> the tasks
>> > and maybe writing what is done in build files - since it is code and
>> even "api
>> > for dev", it requires as much comments than the main api - can be
>> better to start.
>> >
>> > Also a big switch flag to bypass checkstyle/findbugs/... can be good
>> while in
>> > dev since these phases cost a looot for nothing while you validates
>> your code in
>> > runners modules for instance.
>> >
>> > Le 23 janv. 2018 07:15, "Kenneth Knowles" <k...@google.com
>> <mailto:k...@google.com>
>> > <mailto:k...@google.com <mailto:k...@google.com>>> a écrit :
>> >
>> > On Mon, Jan 22, 2018 at 10:03 PM, Romain Manni-Bucau
>> <rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>
>> > <mailto:rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>>>
>> wrote:
>> >
>> > @Kenneth: why not dropping the doc for a script with comments
>> in the
>> > project? A "RUNME.sh" ;).
>> >
>> >
>> > That's cool, too, but also any shell one liner can be a gradle one
>> liner or
>> > mvn two/three liner :-). it is just trading one command that you
>> cannot
>> > guess easily for a different one that you still can't guess easily.
>> >
>> > For example, are the SparkRunner ValidatesRunner tests in the
>> SparkRunner or
>> > the core SDK or a third module that integrates the two? And why
>> would you
>> > know that the example ITs are called "sparkRunnerPreCommit"? It
>> doesn't even
>> > make sense really to have "precommit" or "postcommit" except as
>> aliases to
>> > make it easy to repro Jenkins' behavior - they have no other
>> intrinsic
>> meaning.
>> >
>> > So I was proposing a mapping from "full sentence + description" to
>> one
>> liner
>> > to help people navigate the targets that we set up. Some web page
>> or doc
>> > that people can just quickly scan to find out to do common things,
>> easier
>> > than groovy or XML.
>> >
>> > Kenn
>> >
>> >
>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org <mailto:jbono...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
