
Korean: 
[음악 재생]
크리스 와링턴: 안녕하세요
저는 크리스 와링턴이고
제롬과 자비에와 함께 왔습니다
Gradle API와 AGP API에 관해 
이야기해보려고 합니다
좋아요
기술적인 세부사항을 알아보기 전에
약간의 동기를 부여하고 싶습니다
왜 Gradle API와 AGP API에 관해
이야기하는지 말이에요
이전에 Gradle 빌드를 
확장해보셨다면
아마 작업 개념에 익숙하실 거예요
입력과 출력을 정의하고
해당 입력에서 출력에 이르기까지
필요한 작업을 정의하시겠죠
그러면 작업이 끝났겠죠?
그럼 작업을 조합하고 빌드했어요
물론 이보다 섬세한 작업이죠
사실 문제는 이럴 때 발생해요
여러 다른 팀이 있거나
여러 다른 플러그인을
보유하면서 확장할 때 말이에요

Japanese: 
ようこそ
Chris Warringtonです
こちらにいるのは JeromeとXavierです
私たちの話は
Gradle APIとAGP APIについてです
さて
詳細に入る前に
今日の話の
背景について話そうと
思います
これまでにGradleビルドを
拡張したことのある人なら
タスクの考え方はわかっている
と思います
入力を定義し
出力を定義し
入力から出力を得るのに必要な
アクションを定義します
それだけですよね？
これらを組み合わせれば
ビルドができます
もちろん実際は
それよりは少し込み入っています
複数のチームで作業を始めたり
プラグインを拡張し始めたりすると
色々と問題が出てきます

Chinese: 
[播放音乐]
欢迎大家
我是Chris Warrington
我旁边是Jerome和Xavier
我们将讨论Gradle API和AGP API
好的
在深入探讨一些技术细节之前
我想解释一下
我们为什么要讨论这个问题
如果您曾经扩展过Gradle构建文件
可能会熟悉任务的概念
您需要定义输入、输出
定义从这些输入实现这些输出
所需的操作
这样就可以了
您将它们组合起来，就获得了一个构建文件
实际情况肯定比这复杂
但是，当您有多个不同的团队
或多个相互扩展的不同插件时
这可能会出现问题

Indonesian: 
[ALUNAN MUSIK]
CHRIS WARRINGTON: Selamat datang.
Saya Chris Warrington, 
di sini saya bersama Jerome dan Xavier.
Dan kita akan membahas 
tentang Gradle API dan AGP API.
Bagus.
Jadi sebelum kita menyelami lebih dalam 
beberapa detail teknis,
Saya ingin memberikan 
sedikit motivasi
tentang alasan kita 
membahas ini.
Jadi jika Anda telah memperluas
build Gradle sebelumnya,
Anda mungkin terbiasa dengan 
konsep tugas, bukan?
Jadi Anda tentukan input,
Anda tentukan output,
Anda tentukan tindakan yang Anda perlukan
untuk membuat input tersebut
menjadi sebuah output.
Lalu selesai, kan?
Anda dapat mengombinasi keduanya, 
dan Anda mendapatkan build.
Tentu, lebih terperinci daripada itu.
Tetapi sebenarnya hal ini
bisa jadi bermasalah
saat Anda mulai memiliki 
beberapa tim berbeda
atau beberapa plugin berbeda
yang saling memperluas.

English: 
[MUSIC PLAYING]
CHRIS WARRINGTON: Welcome.
I'm Chris Warrington I'm
here with Jerome and Xavier.
And we're going to talk about
Gradle APIs and AGP APIs.
Great.
So before we kind of delve into
some of the technical details,
I kind of want to give
a bit of motivation
about why we're
talking about this.
So if you've extended
Gradle builds in the past,
you're probably familiar with
the concept of a task, right?
So you define inputs,
you define outputs,
you define the action you
need to get from those inputs
to an output.
And you're done, right?
You can kind of combine
them, and you've got a build.
Obviously, it's a bit
more subtle than that.
But actually, this kind
of gets problematic
when you start having
multiple different teams
or multiple different
plugins extending each other.

Spanish: 
Bienvenidos.
Soy Chris Warrington,
y ellos son Jerome y Xavier.
Hablaremos sobre las API de Gradle y AGP.
Antes de entrar en detalles técnicos,
quiero motivarlos un poco
con el porqué de esta charla.
Si ya extendieron compilaciones
de Gradle,
probablemente
conozcan el concepto de tarea.
Definen entradas y salidas,
y la acción
que debe ir de esas entradas a una salida.
Y listo.
Las combinan y obtienen una compilación.
Obviamente es algo más sutil que eso.
De hecho, se torna problemático
cuando empiezan a tener varios equipos
o distintos complementos
que se extienden entre sí.

Portuguese: 
Bem-vindos.
Sou Chris Warrington e estou
aqui com Jerome e Xavier.
Vamos falar sobre
APIs Gradle e APIs AGP.
Antes de nos aprofundarmos em
alguns dos detalhes técnicos,
gostaria de dar algumas informações
sobre o motivo de estarmos
falando sobre isso.
Se vocês já fizeram
compilações no Gradle,
devem estar familiarizados
com o conceito de tarefas.
Vocês definem entradas, saídas
e a ação que têm que
tomar dessas entradas para uma saída.
E pronto.
Vocês as combinavam
e tinham uma compilação.
É um pouco mais complexo que isso.
Na verdade, isso se torna um problema
quando começamos a ter equipes diferentes
ou diferentes plug-ins
estendendo uns aos outros.

Korean: 
의도하지 않아도 결국엔
커플링하기 때문이에요
원하지 않았던 방식으로요
좋은 예를 보여드리죠
이게 아니네요
무시해 주세요
Android Gradle 플러그인에서
이런 문제를 꽤 많이 봐왔어요
Android Gradle 플러그인을
확장하려고 할 때예요
작업을 찾아보거나 변경할 수 있는
액세스 권한을 여러분에게 준다면
저희가 Gradle 플러그인을 분할하거나
작동 방식을 바꾸려 할 때
할 수 있는 일이 제한됩니다
또한 여러 다른 문제도 야기되죠
성능 향상을 위해
호환성을 무시해도 되는지
사용자를 마이그레이션할 때까지
두 부분 모두 유지해야 하는지에 대해서요
그래서 Gradle은
이러한 새로운 API를 도입했죠
그럼 아티팩트 사이를 오가는 방법 대신
아티팩트 자체에 대해
이야기해보겠습니다
첫 번째는 제공자입니다
매개변수화된 유형의 제공자이죠
그렇습니다
제공자는 여러분이
이야기하는 유형의 값을 제공하며

Spanish: 
Porque pueden terminar
acoplando elementos accidentalmente,
de un modo que no querían.
Este es un buen ejemplo.
No, este no es el ejemplo.
No me hagan caso.
Vimos esto varias veces,
en el complemento de Gradle para Android
donde otros quieren extenderlo
pero, si les dimos acceso
a nuestras tareas
para verlas o cambiarlas,
y luego decimos que queremos dividir esto
o cambiar la manera en que funciona,
realmente limita lo que podemos hacer.
Genera muchos problemas para decidir
si cambiar compatibilidad
por mejor rendimiento
o mantener ambos por un tiempo
hasta poder migrar a los usuarios.
En lugar de ello, Gradle realmente
introdujo estas nuevas API
donde en vez de hablar
sobre cómo cambiar entre artefactos,
hablamos sobre los artefactos en sí.
Primero está el proveedor.
Es un elemento parametrizado.

Indonesian: 
Karena Anda dapat secara tidak sengaja 
mengaitkan satu hal dengan yang lainnya
dengan cara yang mungkin
tidak Anda inginkan.
Jadi, berikut adalah contoh yang bagus.
Oh, tidak, ini bukan contohnya.
Abaikan saja.
Ya, kita pernah melihat 
plugin Gradle Android ini
lumayan sering, di mana orang lain 
ingin memperluas
plugin Grade Android, tapi jika kami 
sudah memberi Anda akses pada tugas kami
untuk melihat-lihat atau mengubahnya,
lalu, misalkan kita ingin memisahkan
atau kita ingin mengubah
cara kerjanya,
ini akan sangat membatasi 
hal yang dapat kita lakukan.
Akses ini menyebabkan
banyak masalah,
haruskah kita merusak kompatibilitas
untuk performa yang lebih baik?
Haruskah kita mempertahankan 
keduanya untuk sementara
sampai kita dapat 
memigrasikan orang-orang?
Jadi, Gradle 
sebenarnya telah
memperkenalkan API baru yang,
alih-alih membahas tentang
cara berada di antara artefak,
kita membahas tentang artefak
itu sendiri.
Jadi yang pertama adalah penyedia.
Jadi penyedia jenis berparameter.
Jadi, ya.

English: 
Because you can end up
unintentionally coupling things
in a way that maybe
you didn't want.
So here's a good example.
Oh, no, this is not the example.
Ignore me.
Yeah, we've seen this in
Android Gradle plugin quite
a few times, where other people
want to extend the Android
Gradle plugin, but if we have
given you access to our tasks
to be able to kind of poke
around at them or change them,
and then we were like, oh,
we want to split this up,
or we want to change
the way this works,
it really restricts
what we can do.
It causes lots of
issues in terms of,
do we break compatibility
for better performance?
Do we keep both parts
around for a while
until we can migrate people?
And so instead,
Gradle has actually
introduced these new APIs where,
rather than talking about how
to get between artifacts,
we talk about the artifacts
themselves.
So the first one
is the provider.
So provider of a
parametrized type.
So yeah.

Portuguese: 
Porque você pode acabar
acoplando coisas acidentalmente
de um jeito não intencional.
Aqui está um bom exemplo.
Esse não é o exemplo. Esqueçam.
Vimos isso no plug-in
do Android para Gradle algumas vezes.
Outras pessoas
querem estender o plug-in.
Mas se déssemos
acesso às nossas tarefas
para vocês darem uma olhada ou mudá-las
e, depois quiséssemos separar
ou mudar o funcionamento,
isso nos restringiria.
Teríamos muitos problemas.
Como relação
entre compatibilidade e desempenho...
Ou manter duas partes até
poder migrar as pessoas.
Em vez disso, o Gradle
trouxe novas APIs.
Em vez de tratar
sobre a escolha entre artefatos,
falamos sobre os artefatos em si.
A primeira coisa é o provedor.
Provedor de um tipo parametrizado.

Chinese: 
因为您可能会无意中
进行意外的耦合
这里有一个很好的例子
不对，这不是示例
请忽略
使用Android Gradle插件时
常常会有人希望扩展这个插件
但是如果我们允许您访问我们的任务
让您扩展或更改它
我们可能就要拆分它
或改变它的运行方式
这会大大限制我们的操作
并导致很多问题
例如，是否要牺牲兼容性来提高性能？
可否让两个部分共存一段时间
直至完成迁移？
为此，Gradle引入了
这些新的API
将关注点从工件之间
转移到工件本身
首先是提供程序
参数化类型的提供程序
是的

Japanese: 
気づかないうちに
やりたくなかったような
依存関係を作ってしまって
いたりします
ひとつ例を挙げます
あっ、やめときます
忘れてください
Android Gradleのプラグインでは
よくあることですが
他の人がAndroid Gradleプラグインを
拡張しようとしていて
あなたが私たちのタスクに
アクセスできて
修正できるような状況で
私たちが これを2つに分けよう
動きを変えようと思っても
できることが
極めて限られてしまいます
パフォーマンスを上げるために
互換性を無視すると
たくさんの問題が生じます
人が移動できるようになるまで
どちらのバージョンも残して
おくのがいいのでしょうか？
Gradleでは かわりに
新たなAPIが導入され
アーティファクト間の違いを
議論するのではなく
アーティファクトそのものを
議論します
最初はプロバイダです
パラメタライズされたタイプの
プロバイダです
そうです

Indonesian: 
Jadi akan disediakan nilai
jenis yang Anda katakan.
Bisa dikuerikan.
Anda bisa panggil get, semacam
bertindak seperti supplier.
Ini memiliki konten 
yang sudah disetel atau belum.
Jadi get atau null 
jika Anda ingin menyetelnya,
daripada rusak jika tidak disetel.
Anda bisa mengkueri di mana keberadaannya.
Dan Gradle 4.0 memperkenalkan ini.
Jadi jika Anda menggunakan
AGP baru,
ini akan tersedia 
dalam Gradle sehingga
Anda terpaksa menggunakannya.
Dan selain itu,
kita memiliki properti.
Jadi properti adalah provider.
Dan ini adalah versi yang dapat
dikonfigurasi dan diubah.
Jadi Anda bisa panggil set.
Dan Anda bisa menyetelnya
dengan nilai konkret,
atau Anda bisa menyetelnya
dengan provider lain.
Jadi Anda bisa saling mengaitkan hal ini.
Jadi, ya.
Ini mengimplementasikan provider
sejak Gradle 4.3.
Sekali lagi, jika Anda 
menggunakan versi terbaru Gradle,
Anda sudah dapat mengaksesnya.
Jadi kembali lagi pada contoh
mengapa hal ini berguna,
jadi bayangkan Anda

Korean: 
쿼리될 수도 있어요
get을 호출할 수 있으므로 
일종의 공급자 역할도 합니다
set인지의 여부에 관한 내용도 담고 있어요
set으로 설정하고 싶으면
get이나 null을 삽입합니다
set이 아닌 경우 날려버리지 않아도 되죠
해당 위치를 쿼리할 수 있습니다
Gradle 4.0에서 가능합니다
따라서 다소 새로운 AGP를 사용하는 경우
Gradle에서 이용할 수 있는데
Gradle에서 이 새로운 AGP를
사용하게끔 할거예요
거기에다 속성이 하나 있는데
속성은 제공자입니다
이 속성은 구성 가능한 변형 버전이라
set을 호출할 수 있어요
구체적인 값으로 설정하거나
다른 제공자를 설정할 수 있습니다
이를 통해 연결할 수 있는 거죠
그리고
제공자를 구현해요
그리고 Gradle 4.3 이후 버전에서는
최신 버전의 Gradle을 사용하는 중이라면
이미 이 버전에 액세스할 권한이 있어요
예로 다시 돌아가서
왜 이 속성이 유용한지 알아봅시다

Portuguese: 
Ele fornece um valor do tipo desejado.
Ele pode ser consultado.
Você pode chamar "get", e
ele age como um fornecedor.
Tem um conteúdo relativo
a estar ou não definido.
Então, se quiserem que seja definido,
vocês têm "get" ou "null"
ou "blow up", se não quiser definido.
Vocês podem consultar se
isso deve estar presente.
O Gradle 4.0 introduziu isso.
Se você está usando um AGP novo,
ele estará disponível no Gradle
e você deverá usá-lo.
Além disso, você tem uma propriedade.
Uma propriedade é um provedor.
É uma versão mutável configurável.
Você pode chamar "set".
Você a define com um valor concreto
ou com outro provedor.
Você pode encadear essas coisas.
Ele implementa o provedor
desde o Gradle 4.3.
Se você usa uma versão recente do Gradle,
já tem acesso a ele.
Então, de volta ao meu exemplo
sobre a utilidade disso.

Spanish: 
Proporciona valor del tipo que indiquen.
Se lo puede consultar.
Lo pueden llamar.
Actúa como proveedor de servicios.
Tiene un contenido
sobre si está establecido o no.
Se define cómo se establece.
Pueden consultar dónde está presente.
Y Gradle 4.0 lo introdujo.
Si usan un AGP más nuevo,
estará disponible en el Gradle
que los obligue a usar.
Y además, tenemos una propiedad.
Una propiedad es un proveedor.
Una versión
que se puede cambiar y configurar.
Se puede definir con un valor concreto
o con otro proveedor.
Se puede unir todo esto.
Implementa al proveedor
desde Gradle 4.3.
Si se usa una versión reciente
de Gradle,
ya se tiene acceso a esto.
Volvamos al ejemplo
de por qué esto es útil.

Japanese: 
そのタイプの値を提供します
クエリもできます
Getを呼べるので
少しサプライヤのような動作をします
セットをするかどうか
のコンテントを持ちます
セットしたい場合
その値もしくはnullをゲットします
セットしてない場合
ブローアップはしません
存在していれば
クエリできます
Gradle4.0で導入された機能です
新しいAGPを使っている人なら
AGPが指定したGradleではその機能が
自然に使えるようになっています
また その上に
プロパティがあります
プロパティはプロバイダです
コンフィグ可能で
ミュータブルなバージョンです
setを呼べます
具体的な値をセットすることもできますし
別のプロバイダでセットすることもできます
これらをつなぐこともできます
Gradle4.3から プロバイダがインプリメントされます
Gradleの最近のバージョンを使っていれば
この機能が使えます
どこが便利か 例で示しましょう

English: 
So it provides a value
of the type you say.
It can be queried.
You can call get, so it kind
of acts a bit like a supplier.
It has a content of
whether it's set or not.
And so it's get it or
null if you want it set,
rather than blow
up if it's not set.
You can query where
that's present.
And Gradle 4.0 introduced this.
So if you're using
a newish AGP, this
will be available in
the Gradle that it
will be forcing you to use.
And then on top of that,
we have a property.
So a property is a provider.
And it is a configurable
mutable version.
So you can call set.
And you can set it
with a concrete value,
or you can set it
with another provider.
So you can chain
these things up.
So yeah.
It implements provider
and since Gradle 4.3.
So again, if you're using
a recent version of Gradle,
you have access to this already.
So you're going
back to my example
of why this is useful,
so imagine that you

Chinese: 
它提供指定类型的值
可供查询
您可以对它调用get，功能与提供程序相似
它还包含是否set的内容
如果要set，就使用getOrNull
如果没有set，也不会出现故障
您还可以查询它现在的位置
Gradle 4.0引入了这一功能
如果您使用的是新版AGP
Gradle中会提供这一功能
系统会强制您使用它
此外，还有一个属性
属性是一个提供程序
是可配置的可变版本
您可以调用set
将它设置为具体的值
或者设置为另一个提供程序
实现关联
是的
从Gradle 4.3开始，它可以实现提供程序
如果您使用的是最新版Gradle
就可以使用该功能
再来看看我的示例
为什么这很有用

Spanish: 
Imaginen que tienen una extensión o tarea.
Pueden usarla como entrada
o salida para las tareas.
Gradle creará instancias de eso.
Si hacen abstracta la extensión o tarea,
Gradle creará una clase secundaria,
la relacionará con su clase y listo.
Solo tienen que vincularlas.
Este vínculo, la relación
que ustedes crean, es dinámico.
No significa que lo definen
y se lee el valor.
Más adelante, alguien más
puede definir el valor de la extensión
y no se realizarán consultas
hasta que se ejecute la tarea.
Entonces, el orden de configuración
es menos relevante
y permite coordinar mucho de antemano.
Luego, lo hacen dinámico
y todo se resuelve sin esfuerzo
y en el momento correcto,
en lugar de estar atento a todo,
como qué complemento se ejecuta primero,
si se usa mi objeto afterEvaluate
antes que el tuyo,

Japanese: 
エクステンションまたは
タスクがあるとします
これをタスクの入力あるいは
出力に使えます
Gradleがインスタンス化 
してくれます
この場合 
自分のエクステンションやタスクを
抽象化すると
Gradleが自分のクラスの
サブクラス化をしてくれるので
リンクだけやればいいので 便利です
このリンク つまり作った関係性は
ダイナミックです
セットを呼んで値を読む
ということではありません
誰か他の人が後で
エクステンションの値をセットし
タスクが実際に走るまでは
クエリされません
つまり コンフィグの順番が
ほとんど関係なくなり
色々な問題が
事前に解消されます
ダイナミックにしておけば
特に何もしなくても
あまり気にすることなく
その都度解決されます
まず どのプラグインが最初に
起こっただとか
私のafterEvalulateとあなたのと
どちらが先だったとか

Korean: 
확장 또는 작업이 있다고 가정해보겠습니다
단순히 작업의 입력
또는 출력으로 사용할 수 있고
Gradle에서 작업을 인스턴스화합니다
따라서 이 경우에는 확장 또는 작업을
추상화한다고 하면
Gradle에서 클래스에 따라
하위 클래스를 작성하고 그럼 완료됩니다
연결하기만 하면 되기 때문에 간편하죠
연결, 즉 여러분이 생성하는 관계는
동적입니다
따라서 set을 호출하고
값을 읽는 것이 아닙니다
다른 사람이 나중에
확장 값을 설정할 수 있고
작업이 실제로 실행될 때까지는
쿼리되지 않습니다
즉, 구성 순서가
훨씬 관련성이 적고
많은 내용을 사전에 처리하기 
한결 쉽게 해주죠
그러고 동적이 되어 모든 게
적시에 여유있게 해결되죠
주의할 필요가 없어요
어떤 플러그인이 먼저 발생하는지
afterEvaluate이 상대보다 먼저 발생하는지

Indonesian: 
memiliki ekstensi atau tugas.
Anda dapat 
menggunakan ini sebagai input
atau output Anda untuk tugas.
Gradle akan 
membuat instance untuk Anda.
Dalam hal ini, jika Anda membuat
ekstensi atau abstrak tugas
dan membiarkannya 
tetap abstrak,
Gradle akan menjadi subclass
dalam kelas Anda, lalu selesai.
Dan ini lumayan mudah, karena 
Anda tinggal menautkannya saja.
Dan penautan ini, 
hubungan yang Anda buat
bersifat dinamis.
Jadi, bukan berarti Anda memanggil set
dan nilainya akan terbaca.
Orang lain bisa menyetel
nilai ekstensi nantinya,
dan tidak akan dikuerikan 
sampai tugasnya benar-benar berjalan.
Jadi ini berarti bahwa
urutan konfigurasi
jauh kurang relevan, dan jauh 
lebih mudah untuk menyelesaikan
banyak hal sebelumnya,
lalu hanya perlu
menjadikannya dinamis dan 
membuat semuanya terselesaikan
tepat waktu, alih-alih
harus agak
berhati-hati, plugin mana 
yang mulai terlebih dahulu,
apakah afterEvaluate saya
mulai lebih dulu daripada milik Anda,

Portuguese: 
Imagine que você
tenha uma extensão ou uma tarefa.
Você só pode usá-la como entradas
ou saídas para tarefas.
O Gradle vai instanciá-las para você.
Nesse caso, se você tornar
sua extensão ou tarefa abstrata,
o Gradle dividirá sua classe e pronto.
Isso é legal, porque você pode vinculá-las
E essa ligação, a relação que você cria,
é dinâmica.
Isso não significa que você
chame "set" e lê o valor.
Outra pessoa pode definir o
valor da extensão depois
e isso não será consultado até
que a tarefa seja executada.
Isso significa que a ordem da configuração
é menos relevante, facilita definir
várias coisas antecipadamente e depois
a torna dinâmica, e tudo
é resolvido depois,
no momento certo, em vez de ter que
se preocupar com o plug-in
que vem primeiro...
Se meu "afterEvaluate" vem antes do seu...

Chinese: 
假设有一个扩展或任务
您可以将它直接用作任务的
输入或输出
Gradle会为您进行实例化
在这个例子中，如果要将扩展或任务抽象化
您只需定义抽象类即可
Gradle会为您的类创建子类，然后操作完成
这非常棒，因为您可以将它们关联起来
而且这种关联，这样创建的关系
是动态的
并不是说，您调用了set就会读取值
可以由其他人稍后设置扩展值
并且在任务实际运行之前无法查询
因此，配置顺序的重要性显著降低
并且可以更轻松地
预先设置很多内容
然后使其具有动态性，在合适时
慢慢解决所有问题，不用担心
应先使用哪个插件
或这个afterEvaluate
是否发生在那个afterEvaluate之前

English: 
have an extension or a task.
You can just use
this as your inputs
or your outputs for tasks.
Gradle will instantiate
them for you.
So in this case, if you make
your extension or your task
abstract, and just
make them abstract,
Gradle will subclass to thing
to your class, and you're done.
And this is kind of nice,
because you can just link them.
And this linking, the
relationship you create
is dynamic.
So it doesn't mean that you call
set and that reads the value.
Someone else can set the
extension value later,
and it won't be queried until
the task is actually run.
So this means that the
order of configuration
is a lot less relevant, and
makes it a lot easier to settle
a lot stuff up
beforehand, and then just
have it be dynamic and have
everything be resolved lazily
at the right time, rather than
having to kind of be really
careful about, which
plugin happens first,
does my afterEvaluate
happen before yours,

English: 
and all of that mess
that I'm sure some of you
encountered before.
So in this case, you
might also say, actually,
my extension is my API.
I don't want you to change
the value of a task,
because maybe I have multiple
tasks that should all
be the same.
So you can call disallowChanges.
This doesn't resolve
the final value.
This just means that
you can't call set again
on that property.
But it will still reflect the
value of the other property
if that's set later.
OK.
And then there are
specializations of this.
So you can represent
directories and regular files.
It kind of gives you a
more strongly typed way
of reasoning about these
for task inputs and outputs.
And critically,
properties and providers
contain the task dependency.
So say we have two tasks
that we're going to link.
The way we might
have done this before
is, we have a file that's
the output of a producer task
and the input of
the consumer task.

Spanish: 
y todo ese lío
que seguramente algunos ya conocen.
En este caso, también podrían decir:
"Mi extensión es mi API".
No quiero que cambien el valor de la tarea
porque puede que tenga varias
que deberían ser la misma.
Pueden llamar a disallowChanges,
pero no resuelve el valor final.
Significa que no pueden
volver a llamar al conjunto
para esa propiedad.
Pero seguirá reflejando
el valor de la otra propiedad
si se define más adelante.
Luego, tenemos especializaciones.
Pueden representar
directorios y archivos regulares.
Ofrecen una manera de escritura más sólida
del razonamiento para las entradas
y las salidas de la tarea.
Las propiedades y los proveedores
contienen la dependencia de la tarea.
Supongamos que tenemos dos tareas
que vamos a vincular.
La manera en la que lo habríamos
hecho antes es la siguiente:
tenemos un archivo, que es la salida
de una tarea de productor,
y la entrada de una tarea de consumidor.

Indonesian: 
dan semua masalah itu
saya yakin beberapa dari Anda
pernah menemuinya.
Dalam hal ini, Anda bisa
mengatakan bahwa,
ekstensi saya adalah API saya.
Saya tidak ingin Anda
mengubah nilai tugas,
karena mungkin saya memiliki
beberapa tugas yang semuanya
harus sama.
Jadi Anda dapat 
memanggil disallowChanges.
Hal ini tidak 
menyelesaikan nilai akhir.
Hanya saja Anda 
tak bisa memanggil set lagi
pada properti tersebut.
Tetapi akan tetap 
mencerminkan nilai properti lain
jika disetel nantinya.
Oke.
Lalu ada spesialisasinya.
Jadi Anda dapat merepresentasikan
direktori dan file reguler.
Sehingga memberi Anda 
cara berpikir bertipe kuat
tentang hal ini untuk input 
dan output tugas.
Dan yang sangat penting,
properti dan penyedia
berisi dependensi tugas.
Jadi misalkan kita memiliki 
dua tugas yang ingin ditautkan.
Cara yang mungkin 
pernah kita lakukan sebelumnya
adalah, kita memiliki file 
yang merupakan output dari tugas produsen
dan input dari tugas konsumen.

Portuguese: 
E toda essa bagunça
que alguns de vocês já viram.
Nesse caso, vocês poderiam dizer:
"Minha extensão é minha API."
"Não quero que mudem
o valor de uma tarefa,
porque talvez várias tarefas
precisem ser as mesmas."
Chamem "disallowChanges".
Isso não resolve o valor final.
Significa que
não podem chamar "set" novamente
nessa propriedade.
Isso ainda refletirá o valor
da outra propriedade,
se ela for definida depois.
Depois, há especializações disso.
Vocês podem representar diretórios
e arquivos regulares.
Isso dá a vocês uma maneira mais forte
de considerar essas entradas
e saídas de tarefas.
As propriedades e os provedores
têm a dependência de tarefas.
Por exemplo, temos duas tarefas
para vincular.
Antes era assim:
temos um arquivo que é a saída
de uma tarefa do produtor
e a entrada da tarefa do consumidor.

Korean: 
이전에 겪었던 모든 문제를
생각하지 않아도 된다는 것이죠
이 경우에는 확장을
API라고 말할 수도 있겠네요
작업 값을 변경하지 마세요
여러 작업이 동일해야 하기
때문이죠
따라서 disallowChanges를 호출할 수 있는데
그렇다고 최종값을 해결하는 것은 아닙니다
다시 set을 호출할 수 없음을
의미하는 것 뿐이죠
해당 속성에서 말이에요
그러나 다른 속성의 값은 여전히 반영해요
나중에 설정되다면 말이죠
좋아요
속성의 전문화가 있어서
디렉터리와 일반 파일을 나타낼 수 있습니다
더 강력한 유형의 추론 방식을 제공합니다
작업 입력과 출력에 관한 것으로요
중요한 점은 속성과 제공자는
작업 종속성을 포함한다는 것입니다
연결할 두 가지 작업이 있다고 가정해 봅시다
이전에 이 작업을 수행한 방식은
생산자 작업의 출력과
소비자 작업의 입력 파일이 있었죠

Chinese: 
所有这些烦恼
大家之前肯定都遇到过
在这种情况下，您也可以说
我的扩展就是我的API
我不希望您更改任务值
因为我可能有多个任务应该保持
一样的值
这时您可以调用disallowChanges
这不会解析最终值
仅仅意味着无法再针对该属性
调用set
但是如果稍后设置，它仍然会反映
其他属性的值
好的
然后是特化
您可以表示目录和常规文件
这有助于实现针对任务输入和输出的
强类型推理
至关重要的是，属性和提供程序
包含任务依赖项
假设我们要关联两项任务
之前的处理方式是
我们有一个文件，它是生产者任务的输出
和消费者任务的输入

Japanese: 
今までのような
面倒なことを
気にする必要がなくなります
このような例では
自分のエクステンションがAPIだとも言えます
複数のタスクで使っている可能性があるので
タスクの値を変えないほうが
いいと思います
disallowChangesを呼ぶことができます
これは最終的な値をレゾルブしません
そのプロパティで
セットが呼べなくなるということです
後でセットすれば
他のプロパティの値を 依然として反映します
さて
これの特殊化もあります
ディレクトリや通常ファイルを表現できます
タスクの入力や出力に対して
これらについて
よりタイプを意識した推論方法を
使えるようになります
重要なことですが
プロパティやプロバイダには
タスク依存性が含まれています
リンクする2つのタスクがあるとして
今までの方法なら
プロデューサの出力であるファイルと
コンシューマタスクの入力があって

Chinese: 
有了文件之后
我们使用位置调用tasks.register
然后在消费者任务中
也使用该位置
消费者任务必须通过手动方式
依赖于生产者任务
当插件之间存在拆分时
这会变得很混乱
如果生产者位于插件A中
消费者位于插件B中
我需要位置和任务信息
才能正确表达依赖关系
相反，如果使用属性，就能将两者关联起来
就像这样
我们有一个文件
那么可以在消费者任务中放入什么？
通过flatMap
将任务提供程序转换成输出文件后
我们可以保留任务依赖项
并且无需对任务进行实例化
由此实现关联
这对API来说非常有用

Spanish: 
Y tenemos nuestro archivo.
Llamamos a tasks.register
con la ubicación.
Y en la tarea de consumidor
también usamos esa ubicación.
Y mi tarea de consumidor
tiene que depender manualmente
de mi tarea de productor.
Esto se complica cuando hay una división
entre complementos.
Si el productor está en el complemento A
y el consumidor, en el B,
necesito que la ubicación y la tarea
puedan expresarlo correctamente.
En lugar de eso, si usamos propiedades,
podemos vincularlas.
Algo así.
Entonces, tenemos un archivo y, luego,
¿qué colocamos
para la tarea de consumidor?
En realidad, si adaptamos el proveedor
de la tarea a este archivo de salida,
preservamos la dependencia de la tarea
sin generar una instancia en ella.
Y podemos expresarlo.
Y eso es mucho mejor para la API.

Japanese: 
ここにファイルがあります
場所を指定して
task.registerを呼びます
そして コンシューマのタスクでも
そのロケーションを使います
コンシューマのタスクの
プロデューサのタスクへの依存性を
マニュアルで指定する必要があります
この作業は プラグインの間でスプリットがあると
本当に厄介です
プロデューサがプラグインAに
コンシューマがプラグインBにあったとすると
ロケーションとタスクにそのことを正確に
反映させなければなりません
その代わり ここでプロパティを使えば
次のように関連づけることができます
ファイルがあって
コンシューマタスクに何をいれましょうか？
タスクプロバイダをその出力ファイルにすると
タスクをインスタンス化することなく
タスクの依存関係を保存できます
そのとおりに書くだけです
そのほうがAPIにとっては
ずっと良いことです

Portuguese: 
Temos nosso arquivo.
Chamamos "task.register" com o local.
Na tarefa do consumidor, dizemos:
"Use esse local também".
Minha tarefa de consumidor
tem que depender manualmente
da minha tarefa do produtor.
Isso fica confuso quando há
uma separação entre os plug-ins.
Se o produtor está no plug-in A
e o consumidor está no plug-in B,
preciso que o local e a tarefa possam
distribuir isso corretamente.
Em vez disso, se usarmos propriedades,
podemos uni-las, mais ou menos assim.
Temos um arquivo.
Mas, e agora,
o que colocar para a tarefa do consumidor?
Na verdade, se nivelamos o provedor
de tarefas no arquivo de saída
correspondente, mantemos uma
dependência de tarefas
sem, na verdade, instanciá-la.
Podemos só distribuir.
Isso é muito mais legal para a API.

Indonesian: 
Oke, kita memiliki file 
kita sendiri.
Kita memanggil 
tasks.register dengan lokasi.
Lalu di tugas konsumen
kita, misalkan,
juga menggunakan 
lokasi tersebut.
Dan tugas konsumen saya 
harus bergantung secara manual
pada tugas produsen saya.
Ini bisa bermasalah saat
ada pemisah antar plugin.
Jadi jika produsen
berada di plugin A
dan konsumen 
berada di plugin B, sekarang saya
memerlukan lokasi 
dan tugas agar dapat
mengaturnya dengan benar.
Jadi, jika kita menggunakan properti
di sini, kita bisa menggabungkannya,
seperti ini.
Jadi, kita memiliki sebuah file, 
lalu, apa yang harus
kita letakkan di tugas konsumen?
Sebenarnya, jika kita meratakan
penyedia tugas menjadi file output,
kita mempertahankan
dependensi tugas
tanpa harus 
membuat instance tugas.
Dan kita tinggal mengaturnya.
Dan itu sangat berguna untuk API.

English: 
And OK, we have our file.
We call tasks.register
with the location.
And then in the consumer
task we say, OK,
also use that location.
And my consumer task
has to manually depend
on my producer task.
This gets really
messy when there's
a split between plugins.
So if the producer
is in plugin A
and the consumer is
in plugin B, now I
need the location and
the task to be able
to word that up correctly.
So instead, if we use properties
here, we can then wire them up,
something like this.
So we have a file,
and then, OK, what do
we put for the consumer task?
Actually, if we flatten out the
task provider into its output
file, we preserve
a task dependency
without actually
instantiating the task.
And we can just word that up.
And that's a much
nicer thing to the API.

Korean: 
여기 파일이 있어요
위치를 사용하여 tasks.register를 호출한 다음
소비자 작업에서도
해당 위치를 사용합니다
그리고 여기서 소비자 작업은 생산자 작업에
수동으로 의존해야 합니다
정말 지저분해지죠
플러그인 사이에 분할이 있는 경우예요
따라서 생산자가 플러그인 A에 있고
소비자가 플러그인 B에 있다면
이제는 위치와 작업이 필요합니다
올바르게 연결하려면 말이죠
여기서 두 속성을 대신 사용하면
이렇게 연결할 수 있습니다
파일을 가지고 있으니
소비자 작업에 무엇을 입력할까요?
작업 제공자를 출력 파일로 평면화하면
작업 종속성이 유지됩니다
작업을 인스턴스화하지 않아도 되고
간단히 연결할 수 있죠
API에게는 훨씬 더 좋은 일이죠

Korean: 
이제 이 출력은 저희가
제공하는 API가 될 수 있어요
소비자 작업은 없어요
구현 세부사항이에요
작업 제공자는 신경 쓰지 않는거죠
하나의 작업이거나
여러 작업일 수도 있죠
아티팩트 변환일 수 있고
구성에서 나올 수도 있어요
이런 사항은 중요하지 않습니다
바로 거기에 있어서 사용할 수 있어요
그렇습니다
지연적이며
작업 종속성을 유지합니다
작업을 인스턴스화하지 않기 때문에
발전시켜 나가고
모든 생태계를 옮기길 바라는
그런 멋진 신세계이죠
작업 제공자는 일반 파일의
제공자를 반환하기만 하며
작업 종속성을 가지고 있습니다
자 이제 자비에가
더 고급 내용과 자세한 내용을
알려드릴 것입니다
자비에 듀크로헷: 감사합니다
좋아요
크리스는 속성을 설정할 수 있다고 했어요
같은 유형의 제공자를 통해 말이죠
정말로 중요해요
아마도 여러분이 생각하고 있는
첫 번째 일은 구성에서
지연 계산을 하는 것입니다
하지만 저는 구성에서는
아무것도 하지 말라고 하죠
작업에서 수행하라고요

Portuguese: 
Essa saída pode agora ser
a API que fornecemos.
Não há nenhuma tarefa para o consumidor.
É um detalhe da implementação.
Poderia ser uma ou várias tarefas.
Uma transformação de artefato,
uma configuração.
Não importa.
Está lá, e você pode usar.
Isso é um processo lento.
Mantém a dependência.
Não instancia a tarefa.
Esse é o novo e maravilhoso mundo
que estamos processando e
para o qual estamos movendo o ecossistema.
Isso retorna um provedor
de um arquivo regular.
E há uma dependência de tarefas anexada.
Agora, vou chamar o Xavier, que vai
falar um pouco sobre
coisas mais avançadas.
Obrigado.
Chris disse que uma propriedade pode
ser definida por meio de um
provedor do mesmo tipo.
Isso é realmente importante.
A primeira coisa que devem pensar é:
"Posso criar uma computação lenta
na minha configuração."
Eu repito: não faça nada na configuração.
Faça nas tarefas.

English: 
So this output can now be
the API that we provide.
There's no task there
for the consumer.
It's an implementation detail.
They don't care.
It could be one task.
It could be many.
It could be an
artifact transform.
It could come from
a configuration.
It doesn't matter.
It's just there,
and you can use it.
Yeah.
And this is lazy.
It keeps the task dependency.
It doesn't instantiate the task,
so this wonderful new world
that hopefully we're progressing
to and moving all the ecosystem
to.
So this just returns a
provider of a regular file.
And it has a task
dependency attached.
So now I'm going to pass
it on to Xavier, who's
going to talk a bit
more about more advanced
things you can do with this.
XAVIER DUCROHET: Thank you.
OK.
So Chris said that
a property can
be set via a provider
of the same type.
And so it's really important--
the first thing you're
probably thinking about
is like, ooh, I can
make lazy computation
in my configuration.
And I keep telling you, don't
do anything in configuration.
Do it in tasks.

Chinese: 
此时输出可以是我们提供的API
消费者没有任务
这是一个实现细节
不用太在意
它可能是一项任务
也有可能是多项任务
它可能是工件转换
它可能来自配置
没关系
它就在那里，您可以使用它
而且
它具有延迟性
可以保留任务依赖项
不会对任务进行实例化，这是一个精彩的新领域
我们在朝它发展，并希望将所有生态系统迁移到
其中
这里仅返回常规文件的提供程序
并且附加了任务依赖项
接下来交给Xavier
他将详细介绍可以使用此功能执行的
高级操作
谢谢
好的
Chris提到，可以通过相同类型的
提供程序来设置属性
这非常重要
您首先想到的可能是
我可以在配置中进行
延迟计算
我们反复强调，不要在配置中执行任何操作
而应在任务中执行操作

Spanish: 
Esta salida ahora puede ser la API
que proporcionamos.
No hay ninguna tarea para el consumidor.
Es un detalle de implementación.
No les importa.
Podría ser una tarea o varias,
ser la transformación de un artefacto
o venir de una configuración.
No importa.
Está allí y pueden usarlo.
Sí. Y es diferido.
Mantiene la dependencia de la tarea
y no genera instancias.
Es un mundo nuevo y maravilloso
hacia el que avanzamos y hacia el que
mudamos todo el ecosistema.
Muestra el proveedor de un archivo regular
y tiene adjunta una dependencia de tarea.
Ahora seguirá Xavier,
que nos contará un poco más
sobre tareas más avanzadas
que pueden hacer.
Gracias.
Chris dijo
que una propiedad se puede definir
mediante un proveedor del mismo tipo.
Así que es muy importante…
Lo primero que están pensando
probablemente sea: "puedo programar
de forma diferida desde la configuración".
Y siempre les digo que no hagan nada allí,
sino en las tareas.

Japanese: 
したがって この出力がAPIになります
コンシューマのタスクはありません
インプリメンテーションの詳細です
問題ありません
タスクは1つだったり
たくさんあったり
アーティファクトの変換だったり
コンフィグレーション由来の
ものだったりしますが
関係ありません
そこにあるものであれば
使ってかまいません
そうです
レイジーです
タスクの依存関係は保存されます
タスクをインスタンス化しない
便利な世界です
こんな世界になっていけばよいと
思います
通常ファイルのプロバイダを
返すだけです
タスク依存性が付属しています
ここでXavierと交替します
これを使った
もっと高度なことについて
話してくれます
ありがとう
Chrisが言っていたように
プロパティは
同じタイプのプロバイダで
セットできます
重要なことですが
多分 こんなことを考えて
いるのではないでしょうか
コンフィギュレーションで
レイジーコンピュ－テーションが
できるのではと
繰返しますが
コンフィギュレーションでやらずに
タスクでやってください

Indonesian: 
Jadi output ini sekarang
dapat menjadi API yang kita sediakan.
Tidak ada tugas
untuk konsumen.
Ini adalah 
detail implementasi.
Mereka 
tidak peduli.
Ini bisa jadi 
satu tugas.
Ini bisa jadi 
banyak tugas.
Ini bisa jadi 
transformasi artefak.
Ini bisa berasal
dari konfigurasi.
Ini bukan masalah.
Ini sudah tersedia di sana,
dan Anda dapat menggunakannya.
Ya.
Dan ini mudah.
Dependensi tugas
dipertahankan.
Proses ini tak membuat instance tugas, 
jadi dunia baru yang indah ini,
harapannya kita berkembang 
dan memindahkan
ekosistem ke sana.
Jadi, proses ini menampilkan
penyedia file reguler.
Dan dependensi tugas
terpasang pada proses ini.
Jadi sekarang saya berikan 
pada Xavier,
yang akan membahas
sedikit lebih jauh tentang hal-hal
yang bisa
Anda lakukan di sini.
XAVIER DUCROHET: Terima kasih.
Oke.
Jadi, Chris mengatakan
properti dapat
disetel melalui penyedia
dengan jenis yang sama.
Jadi ini sangat penting--
hal pertama yang mungkin
anda pikirkan
seperti, oh, saya dapat
membuat komputasi mudah
di konfigurasi saya.
Dan saya sarankan, jangan 
melakukan apa pun di konfigurasi.
Lakukan di tugas.

Indonesian: 
Jadi apakah API baru
benar-benar dapat membantu saya?
Dan jawabannya adalah iya.
Dan ini sebenarnya
sangat penting.
Gradle mengerjakan
eksekusi instan.
Ini adalah fitur baru 
Gradle
yang akan memungkinkan kita 
melakukan serialisasi grafik tugas untuk--
jadi kita lakukan serialisasi
di build pertama.
Pada build kedua kita 
lakukan nonserialisasi
pada grafik tugas tanpa
mengulangi semua komputasi
yang Anda lakukan 
di konfigurasi.
Jadi, bisa lebih cepat
untuk memulai build aktual.
Masalahnya,
ini adalah sesuatu
yang bisa Anda lakukan, menyetel string.
Sempurna.
Tapi jika Anda ingin membuat sesuatu
seperti itu, yang dasarnya
menyetel penyedia string
ke dalam properti,
pada dasarnya proses ini
menggabungkan callable ke dalam
penyedia string.
Dan ini bukan sesuatu 
yang mudah untuk dilakukan serialisasi,
karena kita tidak tahu
input computeValue.
Jadi, susah untuk melakukan serialisasi 
dan menonaktifkan cache sesuai kebutuhan
berdasarkan pada 
waktu perubahan input.
Jadi yang dilakukan 
Gradle adalah,
Gradle akan memanggil
computeValue,
lalu mendapatkan 
nilai string
dan melakukan 
serialisasi pada nilai.
Jadi jika Anda
berharap komputasinya

Chinese: 
那么新的API能帮到我吗？
答案是肯定的
事实上，这很重要
Gradle采用即时执行方式
这是Gradle的一项新功能
我们可以借此将任务图序列化
如果我们在第一个构建文件上进行序列化
在第二个构建文件上就只需对任务图反序列化
无需重新执行
在配置中执行的所有计算操作
从而更快地开始实际构建过程
不过也有问题
您可以设置字符串
很好
但是，如果要将字符串的
提供程序设置为属性
就要将可调用项封装到字符串的
提供程序中
而这很难序列化
因为我们不知道computeValue的输入
难以序列化的同时，也很难根据输入的变化
在需要时停用缓存
Gradle的做法是
直接调用computeValue
获取字符串值
然后对该值序列化
如果您希望在每个构建文件上

Spanish: 
Y ¿en verdad ayuda esa API nueva?
Sí.
Y es muy importante.
Gradle trabaja
en una ejecución instantánea.
Es una función nueva de Gradle
que nos permitirá
serializar el gráfico de tareas
en la primera compilación.
En la segunda, anularemos la serialización
del gráfico de tareas,
en vez de volver a programar
toda la configuración.
Así, iniciar la compilación real
será mucho más rápido.
El problema es que se trata de algo
que pueden hacer: definir la string.
Perfecto.
Pero si quieren hacer algo así,
como definir un proveedor de la string
en una propiedad,
básicamente se envuelve un elemento
invocable en un proveedor de la string.
Y no es algo
que se pueda serializar con facilidad
porque no sabemos
cuál es la entrada de computeValue.
Es difícil serializar e inhabilitar
la memoria caché según sea necesario
en función de cuándo cambia la entrada.
Gradle invocará a computeValue.
Va a obtener el valor de la string
y a serializar el valor.
Así que si esperan que la programación

English: 
So can that new API
actually help me?
And the answer is yes.
And it's really
important, actually.
Gradle is working on
instant execution.
It's a new feature
of Gradle that
will allow us to serialize
the task graph in order to--
so we serialize it
on the first build.
On the second build we
will just this deserialize
the task graph instead of
redoing all the computation
that you're doing
in configuration.
So it's going to be much faster
to start the actual build.
The problem is that
this is something
that you can do, set string.
Perfect.
But if you want to do something
like that, which is basically
setting a provider of
string into a property,
this thing basically wraps
a callable into a provider
of string.
And this is really not something
we can easily serialize,
because we don't know the
input of computeValue.
So it's hard to serialize and
disable the cache as needed
based on when the
input are changing.
So what Gradle is going
to do is, they're just
going to call
computeValue, they're
going to get the string
value, and they're
going to serialize the value.
So if you expect
that computation

Portuguese: 
Essa nova API pode, de fato, ajudar?
A resposta é "Sim".
Ela é muito importante.
O Gradle está trabalhando em
execução instantânea, um novo recurso que
vai nos permitir serializar o
gráfico da tarefa para
serializamos na primeira versão.
Na segunda versão,
desserializaremos
o gráfico de tarefas, em vez de refazer
a computação feita na configuração.
Ficará muito mais rápido
iniciar a versão real.
O problema é que isso é algo
que vocês podem fazer: definir a string.
Perfeito.
Mas, para fazer algo assim, 
que é basicamente
definir um provedor de string
como uma propriedade,
isso basicamente une um componente
que pode ser chamado em um
provedor de string.
Não é algo que podemos
serializar com facilidade.
porque não sabemos a entrada
de "computeValue".
É difícil serializar e desativar
o cache, quando necessário,
com base na mudança das entradas.
O que o Gradle vai fazer é
chamar "computeValue".
Ele vai pegar o valor da string
e serializá-lo.
Não esperem que essa computação

Korean: 
그렇다면 새로운 API가
실제로 도움이 될까요?
네, 도움이 되고 있어요
아주 중요합니다
Gradle은 즉각적인
실행을 위해 노력하고 있어요
Gradle의 새로운 기능으로
작업 그래프를 직렬화할 수 있도록 하죠
첫 번째 빌드에서 직렬화하고
두 번째 빌드에서는
작업 그래프의 직렬화를 해제합니다
구성에서 수행하는 모든 계산을
다시 실행하는 대신해서 말이에요
실제 빌드를 시작하는 것이 훨씬 빠릅니다
그렇다면 문제는 여러분이 할 수 있는 일인데,
문자열을 설정하는 것입니다
완벽합니다
하지만 기본적으로 문자열 제공자를
속성으로 설정하고 싶다면
호출 가능자를 문자열 제공자로
묶는 것입니다
이렇게 하면 쉽게 직렬화할 수 없어요
ComputValue의 입력값을 모르기 때문이죠
따라서 캐시를 필요에 따라
직렬화하고 비활성화하는 것은 어렵습니다
입력이 변경되는 시점을 기준으로요
그래서 Gradle은
ComputValue를 호출하고
문자열 값을 얻어
해당 값을 직렬화합니다
그래서 모든 빌드에서 계산이

Japanese: 
この新しいAPIが役に立つかどうか
という質問の答えは
イエスです
これは重要です
Gradleは即時実行に取り組んでいます
Gradleの新しい機能で
タスクグラフをシリアル化します
最初のビルドでシリアル化します
2回目のビルドではタスクグラフを
コンフィグレーションで行っていた計算をすべて
やり直す代わりに
非シリアル化します
実際のビルドをやるのに この方がずっと高速です
問題は
ストリングの設定などはできます
完璧です
基本的にストリングのプロバイダを
プロパティに設定する場合
基本的にコーラブルをストリングのプロバイダに
ラップします
これは簡単にシリアル化できません
computeValueの入力を
知らないからです
入力がいつ変わるかを基に 
シリアル化して
必要に応じてキャッシュを無効化するのは
困難です
そこで Gradleがどうするかというと
computeValueを呼んで
ストリングの値をゲットし
値をシリアル化します
ビルドごとにその計算が違うことが
予期される場合は

Japanese: 
うまく行きません
なので この方法は使わないほうがいいです
幸いにも5.6から
新しい方法ができました
プロパティは@inputをつけても
タスク依存性に従います
以前は@inputファイルがあるタスクには
Gradleはその入力内の依存性を見て
そのタスク依存性に従って
タスクグラフをビルドしていました
@input内ではなくです
そこで5.6ではその機能を加えました
5.6は 最新の安定版と同様です
何ができるかというと
エクステンションがあって
プロパティとストリングがあります
これが公開されるAPIで
これがストリングです
これに何か入れてください
計算をして
すこし時間がかかります
バージョンコードやバージョン名です
git値を入れる人も多いでしょう
コミットの数字やgitチャイルド１などです
今までは コンフィグレーションで
やっていましたが
今はストリング プロデューサ タスクを作って

Chinese: 
进行不同的计算，这是行不通的
实际上我们不希望您这样做
好消息是，从5.6开始
有一种新的处理方式
即使放置了@Input
属性现在也会遵循任务依赖项
之前，在使用@Input文件执行任务时
Gradle会查看该输入中的依赖项
并遵循任务依赖项来构建任务图
但是Gradle不会在@Input中执行该操作
5.6中添加了该功能
就像当前的稳定版本一样
您现在可以执行的操作是
假设已有一个扩展和属性字符串
这是您公开的API，由于已有一个字符串
请填写一些内容
然后使用一些信息进行计算
那要花些时间
比如，填写版本号、版本名称
许多人会放置Git值
例如提交次数或Git子项1
等等
过去，您会在配置中执行该操作
现在，我要创建一个字符串生产者任务

Indonesian: 
akan berbeda di setiap build,
maka itu tidak akan berhasil.
Jadi, kami benar-benar
tidak ingin Anda melakukan ini.
Kabar baiknya adalah,
mulai dari 5.6,
ada cara baru untuk melakukan banyak hal.
Sekarang properti akan 
mengikuti dependensi tugas,
meskipun Anda meletakkan @Input.
Sebelumnya, ketika Anda
memiliki tugas dengan file @Input,
Gradle akan melihat
dependensi pada input tersebut
dan mengikuti dependensi tugas
untuk membuat grafik tugas.
Tetapi ini tidak akan 
berfungsi di @Input.
Jadi mereka 
menambahkan di 5.6,
yang merupakan
rilis stabilnya saat ini.
Sekarang yang bisa Anda lakukan,
mari bayangkan
Anda punya ekstensi,
dan Anda memiliki properti itu, string.
Dan ini API yang Anda
tunjukkan, saya memiliki string.
Lalu isi dengan sesuatu.
Dan Anda ingin
melakukan komputasi dengan sesuatu
yang butuh waktu lama.
Jadi katakanlah, 
kode versi, nama versi.
Banyak dari Anda mencoba
untuk meletakkan nilai git,
seperti jumlah commit,
atau turunan git 1,
dan nilai-nilai tersebut.
Jadi, sebelumnya Anda 
akan melakukannya di konfigurasi.
Sekarang saya ingin
membuat string tugas produsen

Portuguese: 
seja diferente em cada versão.
Não queremos que vocês façam isso.
A boa notícia é que, a partir da 5.6,
haverá um novo jeito de fazer as coisas.
As propriedades agora seguirão
essa dependência de tarefas,
mesmo com @input.
Antes, em uma tarefa
com um arquivo @input,
o Gradle olhava para a
dependência nessa entrada
e a seguia
para criar um gráfico de tarefas.
Mas não fazia isso em @input.
Isso foi adicionado na 5.6, que é
a versão estável atual.
Agora, imaginem
que vocês tenham sua extensão
e essa propriedade, string.
Essa é a API que você expõe como:
"Eu tenho uma string.
Preencha isso com algo."
E vocês querem compilar isso com algo
que dure algum tempo.
Como código ou nome da versão.
Muitos estão tentando
colocar valores git,
como o número de commits
ou o git "child 1'" e esses valores.
Antes, vocês fariam
isso na configuração.
Agora, eu crio uma tarefa de produção

English: 
to be different on every build,
it's just not going to work.
So really, we don't
want you to do this.
So the good news is
that, starting in 5.6,
there's a new way to do things.
So properties now will
follow task dependency,
even when you put @Input.
So before, when you had
a task with @Input file,
Gradle would look at
dependency in that input
and follow task dependency
to build a task graph.
But it would not
do it in @Input.
So they added that
in 5.6, which is
like the current stable release.
So now what you can do
is, so let's imagine
you have your extension, and
you have that property, string.
And this is the API you
expose as, I have a string.
Please fill it with something.
And you want to go and
compute that with something
that takes some time.
So let's say, version
code, version name.
A lot of you are trying
to put git values,
like the number of commit,
or the git child 1,
and those values.
So in the past you would
do that in configuration.
Now what I want to do is I want
to create a string producer

Spanish: 
sea diferente en cada compilación,
no va a funcionar.
No queremos que lo hagan.
La buena noticia es que
a partir de la versión 5.6,
hay una nueva manera
de hacerlo.
Las propiedades ahora seguirán
la dependencia de la tarea,
incluso cuando pongan @Input.
Antes, cuando tenían una tarea
con el archivo @Input,
Gradle observaba la dependencia
en esa entrada
y seguía la dependencia de la tarea
para compilar un gráfico.
Pero no lo hacía en @Input.
Así que se agregó eso en la Gradle 5.6,
que es la versión estable actual.
Ahora lo que pueden hacer es…
Imaginemos que tienen su extensión
y esa string de propiedad.
Y esta es la API
que exponen como una string.
Complétenla con algo.
Y la programan con código,
lo que les lleva tiempo.
Código de versión o nombre de versión.
Muchos intentan poner valores Git,
como el número de confirmaciones
o un valor Git secundario
y esos valores.
Antes, eso se hacía en la configuración.
Ahora se crea una tarea
de productor de string

Korean: 
다를 것으로 예상되면 작동하지 않습니다
이렇게 하지 않기를 바랍니다
좋은 소식은 5.6 버전부터는
문자열을 설정화하는 새로운 방식이 있어서
속성이 작업 종속성을 따르게 
된다는 것입니다
@Input을 넣었을 때도 말이에요
이전에 @Input 파일로 작업을 할 때
Gradle은 해당 입력에서 의존성을 보고
작업 종속성을 따라
작업 그래프를 작성했지만
@Input에서는 그렇지 않습니다
그래서 5.6 버전에 추가되었어요
현재 안정적인 릴리스와 버전에서요
그렇다면 이제 가정해 봅시다
확장, 속성, 문자열이 있다고 말이죠
이 API는 문자열이
있을 때 노출하는 API로요
API를 채워본다고 해보죠
그리고 시간이 좀 걸리는 것을 이용하여
계산해 봅시다
버전 코드, 버전 이름을 예로 들어 보죠
여러분 중 많은 수가 git 값을 넣으려고 하겠죠
커밋 수나 git child 1과 같은
git 값을요
과거 구성에서는 이렇게 했을 거예요
그러나 이제는 그 값을 반환하는 문자열 생성자

Japanese: 
それにダイナミックに計算させ
値を返させます
ビルドするごとにです
また タスクで自分の入力プロパティを宣言し
最新の値に更新させます
そこで問題となるのが
これら2つをどうマッピングするかです
ここで 自分のタスクを
同じように作成しています
通常の方法です
前と同じように
flatMapを呼ぶことができて
あなたのタスクプロバイダ--
タスクのプロバイダですからです
レイジーですね
出力ファイルの上の
レイジーなプロバイダです
その結果 通常のファイルにも
タスク依存性が含まれ
関連づけることができ
マッピングが行われ
同じ値が得られます
つまり マッピングとflatMapと
の違いは
マップのコンテントがタイプを
返すことです
ここにストリングがあります
マッピングでは そのタイプの
プロバイダに返しますが
flatMpでは
[不明]を仮定すると
すでに何かのプロバイダを
返します
やっていることは簡単ですよね？
そのファイルのコンテントが必要です
そこで出力を呼び出します

Korean: 
작업을 생성하면 빌드할 때마다 동적으로
계산됩니다
또한 해당 생성자 작업은
작업 자체 입력이 올바르게 선언되어
최신 상태로 작동합니다
그렇다면 두 가지를 어떻게 함께 매핑할까요?
여기 보시면 작업을 생성하고 있어요
평소에 할 법한 방식으로요
앞서 동일한 방식으로 flatMap을 호출하여
작업 제공자로 얻을 수 있었죠
매우 지연된
출력 파일 위의 지연 제공자이죠
해당 일반 파일 말이에요
작업 종속성을 포함하고 있어
파일을 연결하고 여기에서
매핑을 수행하고
동일한 값을 얻을 수 있는 거죠
따라서 매핑과 flatMap의 차이점은
여기서 매핑의 콘텐츠를 예상하여 
유형을 반환하는 것이죠
여기 해당 문자열이 있어요
그런 다음 매핑은 해당 유형의
제공자에서 반환하고 flatMap은
어떤 제공자를 이미
반환하는 거예요
매우 간단한 일이죠?
파일의 콘텐츠가 필요하고
출력을 호출하고 있고요

Spanish: 
que muestre ese valor
y que se programe dinámicamente
durante cada compilación.
Y esa misma tarea puede tener
su propia entrada bien declarada
de modo que funcione la actualización.
La pregunta ahora es:
¿cómo los mapeamos juntos?
Crearé una tarea de la misma manera
que lo hacen normalmente.
Y de la misma forma que antes
podíamos llamar a flatMap
y recibirla del proveedor de tareas,
que es un elemento muy diferido.
Un proveedor diferido encima del archivo
de salida…
Ese archivo regular…
Se incluyen también dependencias
de la tarea
para que puedan vincularla.
Aquí pueden mapear
y obtener el mismo valor.
La diferencia entre map y flatMap
es que aquí esperan
que el contenido de map muestre un tipo.
Esta es una string.
Luego, map muestra un proveedor
de ese tipo
mientras que suponen que flatMap
muestra un proveedor de algo.
Lo que hago aquí es muy simple.
Necesito el contenido de ese archivo.
Invoco una salida que obtenga…

English: 
task that returns that value,
and it's computed dynamically
every time I build.
And that also task can have its
own input properly declared,
so that up-to-date is
working and all that.
So the question now is, how
do we map those two together?
So here I'm creating
my task same way
as you would do it normally.
And the same way earlier we were
able to call flatMap and to get
from your task provider-- which
is a provider of task and is
very lazy--
a lazy provider on top
of the output file--
so that regular file--
and include also
task dependencies
so that you can
wire it, here you
can do map and get
the same value.
So the difference
between map and flatMap
is that here you expect
the content of map
to return a type.
This is a string here.
And then map returns
on a provider
of that type, while
flatMap, you're
supposing the [INAUDIBLE]
to return already
a provider of something.
So here what I'm doing
is very simple, right?
I need the content of that file.
So I'm just calling
output that gets--

Portuguese: 
de strings que retorne o valor
e seja computado dinamicamente
em cada compilação.
Essa tarefa também pode ter
uma entrada própria devidamente declarada
para que a atualização esteja sendo
criada e coisas assim.
A pergunta agora é:
"Como mapeamos as duas juntas?"
Aqui estou criando a minha tarefa como
faria normalmente.
Antes, podíamos chamar
"flatMap" e "get"
no provedor de tarefas, que é
um provedor de tarefas e é
muito lento.
Um provedor lento,
além do arquivo de saída...
esse arquivo regular...
e incluem também dependências de tarefas
para poder conectá-las.
Aqui você pode mapear e ter o mesmo valor.
A diferença entre "map" e "flatMap"
é que aqui você espera que
o conteúdo de "map"
retorne um tipo.
Há uma string aqui.
Depois, "map" retorna um provedor
desse tipo, enquanto "flatMap"...
É de se supor que
um provedor seja retornado.
Estou fazendo algo simples.
Preciso do conteúdo do arquivo.
Só chamo a saída que...

Chinese: 
来返回该值，并在每次构建时
进行动态计算
此外，该任务还可以适当声明自己的输入
从而能够适时更新，正常运行
现在的问题是，如何将两者map在一起？
在这里，我按照常规方式
创建任务
和之前一样，我们可以调用flatMap
通过延迟较大
位于输出文件之上的
任务提供程序
获取常规文件
和任务依赖项
从而实现关联
完成map并获取相同的值
map与flatMap之间的区别在于
map的内容
会返回一个类型
这里是一个字符串
然后map会返回该类型的提供程序
而使用flatMap时
假设[听不清]已返回
某种提供程序
我的操作非常简单
我需要该文件的内容
便直接调用输出

Indonesian: 
yang menampilkan nilai itu,
dan terkomputasi secara dinamis
setiap saya membuatnya.
Dan tugas dapat memiliki inputnya 
sendiri yang dinyatakan secara tepat,
jadi semua yang terbaru berfungsi baik.
Sekarang pertanyaannya adalah,
bagaimana caranya memetakan kedua hal ini?
Jadi, di sini saya
membuat tugas
sama seperti yang biasa Anda lakukan.
Dan sama seperti sebelumnya, kita bisa 
memanggil flatMap dan untuk mendapatkan
dari tugas penyedia-- 
yang merupakan penyedia tugas
dan sangat mudah--
penyedia yang mudah
selain file output--
sehingga file reguler--
dan juga termasuk 
dependensi tugas
agar Anda dapat
menyambungkannya,
di sini Anda dapat memetakan 
dan mendapatkan nilai yang sama.
Jadi perbedaan antara peta
dan flatMap
adalah di sini Anda
berharap konten peta
bisa menampilkan jenis.
Di sini ada sebuah string.
Lalu peta kembali pada
penyedia jenis itu, 
sementara flatMap,
misalkan Anda [TIDAK TERDENGAR]
untuk mengembalikan
penyedia sesuatu.
Jadi, yang saya lakukan di sini 
sangat sederhana, bukan?
Saya memerlukan konten file itu.
Jadi, saya memanggil
output yang dapat--

Korean: 
출력 파일은 일반 파일의 제공자이기 때문에
일반 파일을 제공해주죠
파일은 Java io 파일을 제공합니다
그리고 readText는 확장 기능으로
파일을 읽어요
여기에서 제공자는 기본적으로
작업 종속성을 포함합니다
myExtension에서 설정할 수 있습니다
@Input이 있는 문자열의 속성을
포함하는 소비자이거나
크리스가 앞서 보여준 것처럼 
동적으로 연결된 소비자는
생성한 사람에 따라 자동으로 종속됩니다
다시 말씀드리지만
이 API는 정말 멋진 API입니다
이제 여러분은 API에 노출할 수 있어요
문자열이든, 정수든, 원하는 모든 것을 말이죠
그리고 어떤 작업을 통해
만들 수도 있거나
앞에서 보여드린 것과 같은
문자열로 설정할 수도 있죠
my String을 사용해서 설정하는 거죠
소비자로서 정말로 신경 안 써도 됩니다
이 방식은 정말 좋은 방식입니다
한 가지 주목할 점은
TaskAction 내부에서
get만 호출해야 한다는 것입니다
구성에서 호출한다면
아직 존재하지 않는 파일을
읽을 수 있기 때문에

Chinese: 
输出文件是常规文件的提供程序
该操作为我提供了常规文件
而该文件又提供了Java io文件
readText是一种[听不清]扩展功能
它基本上只读取文件
这个提供程序包含
任务依赖项
我可以在扩展中设置它
如果消费者的输入
带有字符串属性并包含@Input
或消费者使用@Input
或消费者与@Input动态关联
就像Chris刚才讲的那样
该消费者就会自动依赖于@Input的生产者
同理，这个API非常好用
因为现在可以在API中公开一些内容
无论是字符串、整数还是任何其他内容
它实际上可能是由任务创建的
也可能像我刚才介绍的一样
用字符串设置
作为消费者，您实际上不关心这些
因此这种处理方式非常方便
需要注意的一点是
只应在TaskAction中调用get
如果在配置中执行该操作，您会读取
可能尚不存在的文件

Portuguese: 
O arquivo de saída é
o provedor do arquivo regular.
Isso me dá o arquivo regular.
O arquivo me dá o arquivo Java IO.
"readText" é uma função
da extensão Kotlin
que basicamente só lê o arquivo.
Esse provedor aqui basicamente contém
a dependência de tarefas.
Posso definir isso na minha extensão.
Qualquer consumidor que
tenha uma entrada que
seja uma propriedade da string
com @Input, que a consome
ou que seja dinamicamente vinculada,
como Chris mostrou,
dependerá automaticamente de quem a criou.
Novamente, essa é uma API bem legal,
porque, agora, vocês
podem expor na API algo,
seja uma string, um número inteiro
ou o que quiserem, e dizer:
"Isso pode ser
criado por uma tarefa."
Ou definido com uma string,
com minha string.
Como consumidor, isso não importa.
Esse é um jeito muito legal
de fazer as coisas.
Uma coisa importante é que você só deve
chamar "get" na "TaskAction",
porque se você fizer isso
na configuração, lerá
um arquivo que talvez não exista.

Spanish: 
El archivo de salida es el proveedor
del archivo regular.
Eso me da el archivo regular,
del cual obtengo
el archivo de entrada y salida de Java.
Y readText es una función de extensión
que lo lee.
Este proveedor contiene
la dependencia de la tarea.
La puedo definir en mi extensión.
Y cualquier consumidor
que tenga una entrada
que sea una propiedad de la string
con @Input, que la consume
o que se vincula de manera dinámica
con ella, como mostró Chris antes,
dependerá automáticamente de quien
sea que la haya creado.
Esta es una API muy agradable,
porque ahora
pueden exponer contenido en la API,
ya sea una string, un valor entero
o lo que quieran
y pensar que tal vez lo creó una tarea
o se puede definir con una string,
como mostré antes.
Esto no tiene que ver
con los consumidores.
Es una excelente manera de hacer cosas.
Deben tener en cuenta que únicamente
deberían llamar a get en TaskAction,
porque si lo hacen en la configuración,
leerán un archivo
que tal vez aún no exista.
No es recomendable.

Japanese: 
出力ファイルが 通常ファイルの
プロバイダです
したがって 通常ファイルが得られます
そのファイルがJavaのioファイルになります
そしてreadTextが
エクステンション関数であり
それが基本的にファイルを読みます
このプロバイダにタスク依存性が
基本的に含まれます
それを自分のエクステンションに設定できます
コンシューマで@inputのついたストリングの
プロパティである入力を
持つものはどれでも
または ダイナミックにリンクされているものは
Chrisがさっき見せてくれたように
生成したのが何であれ それに自動的に依存する
ようになります
これは本当に優れたAPIです
なぜなら 自分のAPIに
ストリングであれ 整数であれ
自分が好きな物なら何でも
公開できるからです
実際にタスクで生成されたものや
さっきお見せしたような
ストリングで設定したものでも
大丈夫です
コンシューマにとっては
どれでも構いません
非常にうまいやり方です
1つ注意することは
getをコールするときに
TaskActionの中でコールすることです
コンフィグレーションの中でコールすると
まだできていないファイルを
読もうとすることなります

Indonesian: 
file output adalah 
penyedia file reguler.
Jadi saya mendapatkan 
file reguler.
File memberi saya file Java io.
Lalu, readText adalah sebuah 
[TIDAK TERDENGAR] fungsi ekstensi
yang pada dasarnya membaca file.
Jadi, penyedia ini pada dasarnya berisi
dependensi tugas.
Saya dapat menyetel ini di ekstensi saya.
Dan semua konsumen 
yang memiliki input yang
merupakan properti string dengan 
@Input di dalamnya, yang menggunakannya,
atau yang terhubung secara dinamis, 
seperti yang sudah ditunjukkan
Chris sebelumnya,
akan secara otomatis bergantung 
pada siapa pun yang membuatnya.
Dan lagi, ini adalah API yang bagus,
karena sekarang Anda bisa 
memaparkan sesuatu di API Anda,
apakah itu string, bilangan bulat, 
atau apa pun yang Anda mau,
dan misalkan, mungkin 
itu dibuat oleh sebuah tugas
atau mungkin disetel oleh 
string seperti yang saya tunjukkan
sebelumnya, disetel dengan string saya.
Dan sebagai konsumen 
Anda tidak begitu peduli.
Jadi, ini adalah sebuah cara 
terbaik untuk melakukan berbagai hal.
Satu hal yang harus 
diperhatikan adalah Anda hanya harus
memanggil get ke dalam TaskAction, 
karena saat Anda melakukannya
di dalam konfigurasi, Anda akan membaca
file yang mungkin belum ada.

English: 
so output file is the
provider of regular file.
So that gives me
the regular file.
File gives me the Java io file.
And then readText is a
[INAUDIBLE] extension function
that just basically
reads the file.
And so this provider
here basically contains
the task dependency.
I can set it on my extension.
And any consumer that
has an input that
is a property of string with
@Input on it, that consumes it,
or that is dynamically linked
to it, as Chris showed earlier,
will automatically depend
on whoever created it.
And so again, this
is a really nice API,
because now you can expose
in your API a thing,
whether it's a string, an
integer, or whatever you want,
and say, hey, it may be
actually created by a task,
or it may be set with
a string like I showed
earlier, set with my string.
And as a consumer you
really don't care.
And so this is really a
great way to do things.
So one thing to note
is that you should only
call get inside the TaskAction,
because if you do it
in the configuration,
you're going to read
a file that may not exist yet.

Korean: 
구성에서 호출하지 않는 것이 좋아요
Gradle은 최신 검사 중에
처음으로 호출했을 때를 기억하므로
다시 할 필요가 없습니다
따라서 상당히 빠를 것입니다
AGP에서 새 API를 많이 사용할 것입니다
크리스가 저희 목표에 대해 조금 얘기했지만
많은 작업을 변경했어요
작업을 API로 간주하지 않으므로
사용하지 마시기 바랍니다
그래도 지금은 사용해야 해요 그렇죠?
그래서 모든 AGP 작업을 변경했듯이
많은 것을 변경할 것입니다
사용하지 마시기 바랍니다
지금 할 일은
새로운 변형 API를 만드는 것입니다
모든 입력의 변형을 포함하는 API로요
여기 버전 코드가 Int의 속성이 됩니다
채우고자 하고 보유한 코멘트 수가 있다면
제가 보여드린 방식으로
작업을 생성하고 매핑하면
매우 안전하고
인스턴트 실행과 작동하기 때문에
아주 만족할 것입니다
이제 제롬이 API에 관한 
더 많은 이야기를 해줄 것입니다
제롬 도체즈: 알겠습니다
앞서 배운 내용에서 볼 수 있듯이

English: 
So you don't want to do that.
Gradle will memorize
it the first time
it calls for it during
up-to-date checks,
so you don't have
to do it again.
So it's going to be fairly fast.
And we're going to
use that a lot in AGP.
And so, you know, Chris talked
a little bit about our goals.
But really, we changed
a lot of tasks.
They are not considered APIs,
so please don't use them.
But right now you have
to use them, right?
So we're going to
change a lot of things,
like we changed all of AGP task.
Don't use them.
And so what we're
going to do is,
we're going to make a new
variant API contain basically
all the inputs as variants.
So here the version code
will be a property of int.
And if you want to fill that,
if you had the number of comment
that you have, create a task,
map it the way I've showed you,
and then it would
be really safe.
It will work with
instant execution,
and it would be great.
And that, Jerome will
talk about more APIs.
JEROME DOCHEZ: OK.
Yeah, so from the lessons
we learned earlier,

Portuguese: 
E você não quer fazer isso.
O Gradle memoriza isso
durante as verificações de atualização.
Não é preciso fazer novamente.
Será muito rápido.
Vamos usar isso bastante no AGP.
Chris falou um pouco dos nossos objetivos.
De fato, mudamos muitas tarefas.
Elas não são consideradas APIs.
Portanto, não as utilizem.
Mas agora vocês têm que usar.
Vamos mudar muitas coisas.
Por exemplo, mudamos
as tarefas do AGP.
Não as utilizem.
O que vamos fazer é
criar uma nova API de variantes
que contém basicamente
todas as entradas como variantes.
O código da versão será
uma propriedade de int.
Se quer preencher isso
e tem o número de comentários
que recebeu, crie uma tarefa,
mapeie-a como mostrei e pronto.
Vai funcionar com
execução instantânea e será ótimo.
Agora, Jerome vai falar
mais sobre APIs.
OK.
Das lições que aprendemos antes,

Indonesian: 
Tentu Anda tidak 
ingin melakukan itu.
Gradle akan mengingatnya 
saat pertama kali
memanggilnya selama 
pemeriksaan terkini,
jadi Anda tidak perlu 
melakukannya lagi.
Ini akan berjalan cukup cepat.
Dan kita akan banyak 
menggunakannya di AGP.
Jadi, Chris berbicara 
sedikit tentang tujuan kami.
Tetapi, kami benar-benar 
mengubah banyak tugas.
Dan tugas tersebut tidak dianggap API, 
jadi jangan gunakan.
Tetapi, sekarang Anda 
harus menggunakannya, bukan?
Jadi, kita akan mengubah banyak hal,
seperti mengubah semua tugas AGP.
Jangan gunakan tugas tersebut.
Jadi, yang akan kita lakukan adalah,
kita akan membuat varian API 
baru yang pada dasarnya berisi
semua input sebagai varian.
Jadi, di sini kode versinya 
akan menjadi properti int.
Dan jika ingin mengisinya, 
jika memiliki jumlah komentar
yang Anda miliki, buat tugas, 
petakan dengan cara
yang sudah saya tunjukkan
lalu semua akan jadi sangat aman.
Serta bekerja dengan eksekusi instan,
dan akan sangat menyenangkan.
Sekarang, Jerome akan 
berbicara lebih tentang API.
JEROME DOCHEZ: Oke.
Jadi, dari pelajaran 
yang kita dapat sebelumnya,

Japanese: 
これをやってはいけません
Gradleは更新チェックをするとき
最初のコール時に記憶するので
再度行う必要はありません
なのでとても速くなります
AGPで頻繁に使います
Chrisが私達の目標のことについて
少し触れました
タスクをたくさん変更しました
APIとはみなされませんので
使わないでください
今すぐに使う必要があるのですね？
そこで 多くを変更します
AGPタスクをすべて変更したようにです
それらは使わないでください
そこで どうするかと言うと
新しいバリアントを作ります
APIは すべての入力を基本的にバリアントとして
含みます
ここでバージョンコードはintのプロパティです
それを埋めたければ
コメントの番号があったら
タスクを生成して
さっきと同じ方法でマッピングします
そうすれば 安全です
即時実行が使えて
すぐれものです
JeromeがAPIについて
もっと話してくれます
OK
これまでの教訓から

Spanish: 
Gradle lo memorizará
la primera vez que lo llame
al comprobar actualizaciones
así no tienen que volver a hacerlo.
Va a ser bastante rápido.
Y vamos a usarlo bastante en AGP.
Chris habló un poco
sobre nuestros objetivos
pero en verdad cambiamos muchas tareas.
No se consideran las API,
así que no las usen.
Pero ahora tienen que usarlas, ¿sí?
Vamos a cambiar muchas cosas,
como cambiamos todas las tareas de AGP.
No las usen.
Lo que vamos a hacer es lo siguiente:
haremos una variante de API nueva
que contenga
todas las entradas como variantes.
El código de versión
será una propiedad de Int.
Y, si quieren completarla, si tuvieran
el número de confirmaciones,
creen una tarea, mapéenla como les mostré
y estará bien hecho.
Funcionará con la ejecución en el instante
y andará de maravillas.
Y eso es todo.
Jerome les hablará sobre otras API.
Bien. Partimos
de lo que se aprendió antes,

Chinese: 
这种操作应该避免
在更新检查期间
Gradle会在第一次调用时记住它
您无需重复执行操作
处理过程会非常快
我们会在AGP中经常使用这种方法
Chris之前简单谈到了我们的目标
但实际上，我们更改了很多任务
它们不是API，请不要使用
不过目前大家不得不使用
因此我们会进行大量更改
例如，我们更改了所有AGP任务
请不要使用这些任务
我们打算
创建一个新的变体API
其中所有输入都是变量
版本号将是int属性
如果要填写版本号
可以创建一项任务
按照我展示的方式进行映射
这会非常安全
它可以即时执行
并且效果很好
接下来Jerome将详细讨论API
好的
从前面的内容可以知道

Chinese: 
任务显然不是API
这不是我们前进的方向
我们要做的是授予
中间文件的访问权限
我们认为，在Android构建过程中
有许多文件是相对稳定的
例如合并清单、类文件或DEX文件
将始终以这样或那样的
方式存在
我们希望向您
提供这些中间文件的访问权限
以便您在这些工件之上
插入行为
例如
我想获取合并清单
并且想更改它的版本
我希望使用合并清单的人
获取我提供的清单文件新版本
我们将通过枚举为您提供访问权限
所有我们希望您
能使用、替换或转换的文件
会有一个公共枚举
要注意的是，这个枚举是类型化的
它可以是常规文件，也可以是目录

Korean: 
앞의 작업은 저희가 원하는
API가 아닙니다
저희가 원하는 것은
액세스를 제공하는 거예요
중간 파일에 대한 액세스죠
많은 파일이 있을 겁니다
Android 빌드 중 상대적으로 안정적이고
병합된 manifest, 클래스 파일
또는 DEX 파일과 같은 파일이요
항상 이렇게 저렇게 있기
마련이니까요
중간 파일에 대한
액세스 권한을 부여하려고 합니다
이러한 아티팩트 위에 동작을
연결할 수 있도록 말이죠
예를 들어
병합된 manifest를 보유하고
버전을 변경하고 싶다면
병합된 manifest를 소비하는 사람 누군가가
최신 버전의 manifest 파일을 갖기를 바라죠
그래서 enum을 통해 액세스를 제공할 거예요
모든 파일의 enum은 공개될 것이고요
소비하거나 교체하거나
변환할 수 있는 파일이죠
여기서 중요한 것은 입력된다는 것입니다
일반 파일이거나 디렉터리일 수 있습니다

Japanese: 
タスクは 私たちが目指している
APIではありません
そうではなく 私たちが
やろうとしているのは
中間ファイルへのアクセスです
Androidのビルドの間
すでに安定なファイルが
いくつもあると思います
たとえば
結合されたマニフェスト またはクラスファイル
DEXファイルなどです
これらのファイルは とにかく
いつも存在しています
これらの中間ファイルに
アクセスできるようにして
これらのアーティファクトの上に
ビヘイビアを
プラグインできるようにします
例えば
結合したマニフェストで
バージョンを変えたいとします
結合されたマニフェストを使っている人に
新しいバージョンのマニフェストファイルを
入手させたいとします
enumでアクセスできるようします
あなたがコンシュームするか
レプレースするか 変換できるようにする
ファイルのパブリックenumが
あるとします
重要なことは 全部タイプが
決まっていることです
通常のファイルであっても
ディレクトリであっても構いません

Spanish: 
que las tareas claramente no son una API
que queremos hacer avanzar.
Lo que queremos hacer, en cambio,
es brindar acceso
a los archivos intermedios.
Pensamos que hay una cantidad de archivos
relativamente estables
en la compilación de Android,
como el manifiesto combinado
o los archivos de clase o archivos DEX,
que son algo que siempre va a estar
de una manera u otra.
Queremos darles acceso
a estos archivos intermedios
para que puedan conectar su comportamiento
encima de estos artefactos.
Podrían decir, por ejemplo,
que quieren el manifiesto combinado
y cambiar la versión.
Y, luego, que quieren que el objeto
que consuma el manifiesto combinado
obtenga su versión más reciente
del archivo de manifiesto.
Así que vamos a darles acceso
a través de un listado.
Habrá un listado público
de todos los archivos
que hayamos decidido que queremos
que ustedes puedan consumir,
reemplazar o transformar.
Lo importante
es que estos tendrán un tipo.
Podrá ser un archivo regular
o un directorio.

Indonesian: 
seperti tugas yang sudah pasti bukan API
yang ingin kita gunakan.
Tetapi yang kita lakukan 
adalah memberi akses
ke file intermediate.
Jadi kita berpikir kalau ada sejumlah file
yang relatif stabil selama build Android,
seperti manifes gabungan, 
atau file kelas, atau file DEX,
adalah hal-hal yang akan selalu ada
bagaimana pun caranya.
Jadi kita akan memberi Anda 
akses ke file intermediate ini
agar Anda bisa 
memasang perilaku pada
artefak-artefak ini.
Jadi, Anda bisa bilang, misalnya,
saya ingin manifes gabungan,
dan saya ingin mengubah versinya.
Lalu saya ingin siapa pun 
yang memakai manifes gabungan
agar mendapatkan versi 
terbaru dari file manifes saya.
Jadi, kita akan memberi 
Anda akses melalui enum.
Jadi, akan ada enum 
publik untuk semua file
yang kita ingin agar Anda bisa
menggunakan, atau mengganti,
atau mentransformasi.
Dan yang penting adalah 
semua itu akan bertipe.
Jadi, itu bisa jadi sebuah file reguler, 
atau itu bisa jadi sebuah direktori.
Hal yang sangat penting 
adalah saat Anda mengganti file,

Portuguese: 
por exemplo, que as tarefas não
são exatamente uma API,
queremos avançar um pouco.
O que queremos fazer é dar acesso
aos arquivos intermediários.
Achamos que há vários arquivos
estáveis durante a
compilação do Android,
como o manifesto combinado,
arquivos de classes ou DEX.
São coisas que estarão sempre lá.
Queremos dar
acesso aos arquivos intermediários
para que vocês possam vincular
seu comportamento aos artefatos.
Vocês poderiam dizer, por exemplo, 
que querem o manifesto combinado.
E querem mudar a versão dele.
E querem que a pessoa
que esteja consumindo o manifesto
receba a versão mais nova
do arquivo de manifesto.
Daremos a vocês acesso
por meio de uma enumeração.
Haverá uma enumeração
pública de todos os arquivos
que queremos que vocês possam
consumir, substituir ou transformar.
O importante é que eles terão tipos.
Pode ser um arquivo regular
ou um diretório.

English: 
like the tasks are
clearly not an API
that we want to move forward.
And instead what we want
to do is to give access
to the intermediate files.
So we think that there
is a number of files
that are relatively stable
during the Android build,
like the merged manifest, or the
class files, or the DEX files,
are things which are going
to always be there one
way or another.
So we want to give you access
to these intermediate files
so that you can plug
your behavior on top
of these artifacts.
So you could say,
well, for instance,
I want to have the
merged manifest,
and I want to
change its version.
And then I want whoever is
consuming the merged manifest
to get my newer version
of the manifest file.
So we are going to give
you access through an enum.
So there will be a public
enum of all the files
that we decide we want
you to have the ability
to consume, or to
replace, or to transform.
And what is important is
that they will be typed.
So it can be a regular file,
or it can be a directory.

Portuguese: 
É importante
substituir um arquivo por outro.
Não substitua
um arquivo por um diretório
porque quem está esperando
consumir essa versão intermediária
específica, o manifesto combinado,
está esperando um arquivo,
não um diretório, e
não sabe o que tem lá.
Tem tipo.
É muito seguro.
O valor de enumeração dirá
a você que tipo é para facilitar.
Ele também tem cardinalidade.
Poder ser para um ou muitos.
Não é possível substituir
uma cardinalidade de um pela de muitos
porque as tarefas do consumidor
esperam apenas um.
Então, isso é importante.
Será parte da API,
e teoricamente não há riscos
de usar o tipo errado
ou uma cardinalidade diferente.
O que queremos fornecer a vocês com isso
é a capacidade de leitura, ou seja,
você terá acesso
a elas, mas poderá fazer algo
que seja realmente independente
do restante da versão.
Por exemplo, você pode querer o APK.

Spanish: 
Es muy importante
que cuando reemplacen un archivo,
lo reemplacen por otro archivo.
No pueden reemplazar un archivo
por un directorio, porque el objeto
que espera consumir
esa compilación intermedia específica,
el manifiesto combinado,
espera un archivo.
No espera un directorio
y no sabe qué contiene.
Por eso tiene un tipo.
Es muy seguro.
El valor del listado indicará el tipo,
así que no podrán confundirse.
También tiene cardinalidad.
Así que pueden tener uno o varios.
Nuevamente, no pueden reemplazar
una cardinalidad de 1
por la cardinalidad de muchos,
porque las tareas del consumidor
esperan solo 1.
Es importante.
Va a ser parte de la API.
Y, en teoría,
no podrán generarse problemas
usando la cardinalidad
o el tipo incorrecto.
Lo que vamos a proporcionarles con esto
es la capacidad de lectura,
por lo que tendrán acceso a ellos,
pero podrán hacer nada independiente
del resto de la compilación.
Así que podrían querer el tipo APK

Korean: 
파일을 교체할 때 파일로 바꾸는 것이
매우 중요합니다
파일을 디렉터리로 바꿀 수 없어요
병합된 manifest와 같은 
특정 중간 빌드를 소비할 것으로
예상되는 사람은 파일을 기대하지
디렉터리를 기대하는 것이 아니고
그 안에 무엇이 있는지 알지 못하기 때문이죠
그래서 입력되었고
매우 안전합니다
enum 값은 어떤 유형인지 알려주므로
유형을 망칠 일은 없어요
cardinality도 있습니다
1개만 있을 수도
많이 있을 수도 있습니다
다시 말하지만 하나의 cardinality를
여러 cardinality로 바꿀 수 없습니다
소비자 작업은 하나만 예상하기 때문이죠
그래서 중요합니다
그러나 cardinality는 API의 일부가 됩니다
이론상으로 잘못된 유형이나
다른 cardinality를 사용하여
스스로 망칠 수는 없을 거예요
이를 통해 여러분은 읽는 능력을
제공받게 되어
작업 출력에 액세스할 수 있어도
나머지 빌드와는
독립적인 작업을 할 수도 있습니다
예를 들어 APK를 원한다고 가정하고

Japanese: 
ファイルと置き換えるときは
ファイルと置き換えることが
重要です
ファイルをディレクトリと置き換える
ことはできません
なぜなら このビルド中間体や結合した
マニフェストをコンシュームしようとする人は
ファイルを期待しているのであり
ディレクトリは期待していません
中身が何かも知りません
タイプが決まっていなければなりません
そうすれば安全です
enumの値でどのタイプか分かる
ごちゃごちゃにはなりません
また カーディナリティもあります
1かもしれませんし
色々な値があります
カーディナリティが1のものは
他の値のものとはリプレースできません
なぜなら コンシューマータスクが
予期するのは1だけだからです
これは重要です
しかし これはAPIの一部なので
タイプや カーディナリティを
正しく扱わなければなりません
ここで必要となってくるのは
リードする能力です
つまり
アクセスはできますが
ビルドの残りとは独立したことを
してよいということです
例えば APKがやりたいとします

English: 
It's very important that
when you replace a file,
you replace it with a file.
You can't replace a
file with a directory,
because whoever is expecting to
consume this particular build
intermediate, say, the merged
manifest, is expecting a file,
is not expecting a directory and
not knowing what is in there.
So it's typed.
It's very safe.
The enum value will tell
you which type it is,
so you can't really mess it up.
It also has cardinality.
So you have maybe one.
You can have many.
Again, you can't replace
a cardinality of 1
with the cardinality of many,
because, again, the consumer
tasks are expecting only 1.
So it's important.
But it's going to
be part of the API,
and you will not be
able to, in theory,
shoot yourself in the foot
by using the wrong type
or different cardinality.
So what we're going to
provide you through this
is the ability to read, meaning
that you will have access
to them, but you
may do something
which is really independent
of the rest of the build.
So for instance, you could
say, oh, I want the APK.

Indonesian: 
Anda menggantinya 
dengan sebuah file.
Anda tidak dapat mengganti 
file dengan direktori,
karena siapa pun mengharapkan untuk 
menggunakan build tertentu tersebut,
katakanlah, manifes gabungan, 
mengharapkan file,
bukan mengharapkan direktori dan 
tidak mengetahui apa yang di dalam sana.
Jadi itu sudah tertulis.
Itu sangat aman.
Nilai enumnya akan 
memberi tahu Anda jenisnya,
jadi Anda tidak bisa mengacaukannya.
Itu juga memiliki kardinalitas.
Jadi, Anda mungkin memiliki satu.
Anda dapat memiliki banyak.
Sekali lagi, Anda tidak 
bisa mengganti kardinalitas 1
dengan kardinalitas 
banyak, karena, sekali lagi,
tugas konsumen hanya mengharapkan 1.
Itu penting.
Tapi itu akan menjadi bagian API,
dan Anda tidak akan bisa, secara teori,
merugikan diri sendiri 
dengan jenis yang salah
atau kardinalitas yang berbeda.
Jadi apa yang akan 
kami sediakan untuk Anda adalah
kemampuan untuk membaca, 
yang berarti Anda akan memiliki akses
tetapi Anda dapat melakukan sesuatu
yang benar-benar 
independen dari sisa build.
Jadi, sebagai contoh, Anda 
mungkin bilang, oh, saya ingin APK.

Chinese: 
替换文件时，要用另一个文件来替换
这一点非常重要
不能使用目录来替换文件
因为要使用合并清单等
特定中间构建文件的人需要的是文件
而不是目录
他们不知道其中的具体内容
所以要指定类型
这非常安全
枚举值会显示文件所属的类型
所以您不会弄错
它还具有基数
基数可能是“1”
也可能是“多”
同样，不能使用基数“多”
替换基数“1”，因为消费者任务
只希望获取“1”
这很重要
但它将成为API的一部分
从理论上来说您无法使用
错误的类型或不同的基数
去自找麻烦
我们将通过这种方式为您提供读取能力
这意味着您可以访问它们
实际上，您可以执行一些
与构建的其余部分无关的操作
例如，获取APK之后

Chinese: 
您可以用自己的
签名机制来签名
就不会有其他人来使用这个已签名的APK
这就是您的构建目的
您还可以转换
或添加内容
我来展示一些示例
这是转换工件的示例
这是目前的处理方式
您在AGP中找到了原始任务，一个插件
它会生成一些内容
最后，两项任务会使用它
假设
您非常喜欢该任务生成工件的方式
例如合并清单
前面举过例
但您还想执行另一项任务
该任务将获取合并清单并对其进行处理
例如，为并非来自Google的
[听不清]添加一些特殊条目或
额外条目
并且您希望替换它
很显然，您执行该操作的方式是
让新的生产者任务
能够使用原始任务的输出
也就是原始合并清单

Portuguese: 
Depois decidir que
vai assiná-lo com um mecanismo próprio
e, talvez, ninguém vai consumir
esse APK assinado.
É o fim da versão para você.
Ou pode dizer
que quer transformar ou anexar.
Vou mostrar alguns exemplos.
Quero transformar um artefato.
Vocês podem ver como funciona hoje.
Você tem a tarefa original
no AGP, o plug-in.
Ele produz algo.
Há duas tarefas o consumindo.
O que eu quero fazer é:
eu gosto do jeito que
essa tarefa está produzindo
os artefatos, ou seja,
o manifesto combinado,
para manter o exemplo.
Mas queria ter outra tarefa, que
pegasse o manifesto combinado
para fazer algo com ele,
talvez adicionar entradas
especiais ou extras
a um lugar que
não venha do Google, por exemplo.
E quero substituí-la.
Para fazer isso,
é preciso que a nova tarefa de produtor
possa consumir a saída da original.
Esse será o manifesto combinado original.

Spanish: 
y luego decidir que van a firmarlo
con su propio mecanismo de firma.
Y después tal vez
nadie vaya a consumir ese APK firmado.
Este es el fin de la compilación, ¿sí?
También podrían querer transformarlo.
O adjuntarlo.
Voy a mostrarles algunos ejemplos.
Este es un ejemplo
de transformación de un artefacto.
Pueden ver cómo funciona hoy.
Tienen la tarea original
en el AGP, el complemento.
Y produce algo.
Luego, habrá dos tareas que lo consumen.
Y aquí sería ideal decir:
"Me encanta
cómo esta tarea genera los artefactos",
como el manifiesto combinado,
para seguir con el ejemplo.
"Pero me gustaría tener otra tarea
que tome ese manifiesto combinado
y haga algo con él.
Tal vez agregar entradas especiales
o algunas adicionales
para un lugar
que no provenga de Google", por ejemplo.
Y quieren reemplazarlo.
La manera de hacerlo, obviamente,
es que la nueva tarea de productor
pueda consumir la salida de la original,
ese será su manifiesto combinado original,

Indonesian: 
Lalu Anda mungkin 
menentukan apakah Anda
akan menandatanganinya dengan 
mekanisme penandatanganan Anda sendiri,
dan mungkin tidak akan ada yang 
menggunakan APK bertanda tangan ini.
Ini adalah akhir dari build 
untuk Anda, bukan?
Atau Anda bisa berkata,
saya ingin transformasi.
Atau, saya ingin menambahkan.
Tapi saya akan menunjukkan 
beberapa contoh.
Jadi, ini adalah contohnya, saya 
mentransformasi sebuah artefak.
Jadi, Anda bisa melihat 
caranya bekerja.
Anda telah memiliki 
tugas asli di AGP, plugin.
Dan ini menghasilkan sesuatu.
Dan akhirnya ada 
dua tugas yang memakainya.
Dan yang ingin Anda 
lakukan adalah berkata,
aku sangat suka dengan 
cara tugas ini menghasilkan
artefak, misalnya saja
manifes gabungan,
untuk memberikan contoh yang sama.
Tapi saya ingin 
memiliki tugas lain,
yang mengambil manifes 
gabungan itu, melakukan sesuatu padanya,
mungkin menambahkan 
entri spesial atau beberapa entri tambahan
untuk [TIDAK TERDENGAR] 
yang tak berasal dari Google,
contohnya.
Dan Anda ingin menggantinya.
Jadi, cara Anda melakukan ini adalah
Anda ingin tugas produser baru Anda
dapat menggunakan output yang asli.
Jadi, itu akan menjadi 
manifes gabungan asli Anda.

Japanese: 
自分のサインメカニズムを使って
APKにサインすれば
他の人は使えません
ビルドはこれで終わりですか？
変換したり
アペンドしたりしたい場合もあります
例をお見せします
アーティファクトを変換する例です
現在 どのような仕組みになっているか
わかると思います
AGPにオリジナルのタスク 
プラグインがあります
何かプロデュースします
最終的に これをコンシュームするタスクが
2つあることになります
どうするかと言うと
このタスクが生成するアーティファクトが
気に入ったので
同じ例をキープするのに
結合したマニフェストにするとします
しかし結合したマニフェストを使う 
別のタスクもあって
それで何かをやって
何か特別なエントリーを加えたり
たとえばグーグル以外の
追加のエントリーを
加えたりしたくなるかもしれません
そしてリプレースしようと思います
これをやろうとすると 明らかに
新しいプロデューサータスクが
元の出力もコンシュームできればいいと
考えるでしょう
すると 元のマニフェストと結合したものが
出来上がります

English: 
And then you could
decide that you
were going to sign them with
your own signing mechanism,
and then maybe nobody is going
to consume this signed APK.
This is the end of the
build for you, right?
Or you could say, I
want to transform.
Or, I want to append.
But I'm going to show
you some examples.
So here is the example of, I
want to transform an artifact.
So you can see how
it is working today.
So you've got the original
task in the AGP, the plugin.
And it produces something.
And eventually there's
two tasks consuming it.
And what you want
to do is to say,
well, I really like the way
that this task is producing
the artifacts, say merged
manifest for instance,
to keep the same example.
But I would really like to
have another task, which
is going to take that merged
manifest, do something with it,
maybe add some special
entries or some extra entries
for a place [INAUDIBLE] which
is not coming from Google,
for instance.
And you want to replace it.
So the way you do
this, obviously,
is that you want
your new producer
task to be able to consume the
output of the original one.
So that's going to be your
original merged manifest.

Korean: 
나만의 서명 메커니즘으로
서명하기로 결정한다면
아무도 서명된 APK를 소비하지 않을 겁니다
이게 보통 빌드의 끝이에요
아니면 변환을 하거나
추가하고 싶을 수도 있습니다
하지만 일부 예를 보여 드리죠
여기 보시면 아티팩트를 변환하려는 예가 있습니다
오늘 작동 방식을 확인할 수 있는데
AGP의 기존 작업인 플러그인이 있고
뭔가를 만들어내고
결국 소비하는 데 두 가지 작업이 있습니다
다음 할 작업은
저는 이 작업이 아티팩트를
생성하는 방식이 좋습니다
예를 들어 manifest를 병합하는 거죠
동일한 예를 유지하려고요
또 다른 작업을 하려고 합니다
병합된 manifest를 가져와서
무언가를 할 수도 있습니다
예를 들어 Google에서 오지 않는 장소에 대한
특별한 항목이나 추가 항목을
추가할 수도 있습니다
그리고 이 작업을 교체하려 하죠
따라서 이렇게 교체하겠죠
새 생산자 작업에서
원본 작업의 출력을 사용하려고 말이죠
그럼 원래 병합된 manifest가 되는 거죠

Japanese: 
すると関連づけをしようと考え
コンシューマーが結合されたマニフェストの
新しいバージョンにアクセスできるようにします
その時点で
当然 もとのリンクは削除されます
したがって コンシューミングタスクは
もとのプロデューサーのものを
コンシュームしなくなります
ただ消えるだけです
これが 新しい仕組みの流れです
さっき説明したように
この仕組みはすべて
プロバイダーとプロパティを通して実現され
依存性に関して
リンキングがうまく働きます
2つのコンシュームするタスクのうちの1つが
結合されたマニフェストにアクセスしようとして
カスタムプラグインを呼び出すと
そのプラグインはオリジナルのものを
呼び出します なぜなら
結合されたマニフェストの最初のものが
必要になるからです
このようにして すべてのチェーンが正しく
つながります
これが 最新のAPIが動く例です
TransformTaskがあって
これには 入力ファイルと
出力ファイルがあって
わかりやすいと
思います
ここにはアクションがあって

Indonesian: 
Lalu, Anda ingin hal-hal jadi terhubung,
sehingga konsumen memiliki 
akses ke versi manifes gabungan
yang lebih baru.
Jadi, pada tahap ini, tentunya,
link asli terhapus.
Sehingga tugas pemakaian tidak akan
memakai link dari
produsen asli.
Dan tugas itu menghilang begitu saja.
Jadi, ini adalah alur baru dari
hal-hal yang akan terjadi.
Dan seperti yang telah kami jelaskan
sebelumnya, semua ini
akan selesai melalui penyedia
dan properti,
sehingga penautan yang benar
dalam hal dependensi
akan bekerja dengan benar.
Sehingga satu dari dua
tugas pemakaian
mencoba mengakses
manifes gabungan,
hal ini akan memproses plugin
khusus,
yang dengan sendirinya memanggil
yang asli, karena
memerlukan manifes gabungan
asli yang pertama.
Sehingga semua rangkaian ini
akan bekerja dengan benar.
Jadi ini adalah contoh
API seperti yang terlihat hari ini.
Jadi, Anda memiliki
TransformTask di sini,
yang secara relatif
mudah dipahami,
dengan infile dan outfile.
yang akan mentransformasi
infile ke outfile.

Spanish: 
Y, luego, quieren que todo se vincule
para que el consumidor tenga acceso
a la nueva versión
del manifiesto combinado.
Y en este punto, ya se quitaron
los vínculos originales,
así que las tareas de consumidor
no consumirán las del productor original.
Simplemente desaparecen.
Este es el nuevo flujo que tendrá lugar.
Como lo explicamos anteriormente,
todo esto se hará
mediante el proveedor y la propiedad,
para que la vinculación adecuada
en cuanto a la dependencia
funcione correctamente.
Una de las dos tareas de consumidor
intenta acceder al manifiesto combinado.
Invocará el complemento personalizado
que, a su vez, invocará al original,
porque requiere el original
del manifiesto combinado.
Todo este encadenado
funcionará correctamente.
Este es el ejemplo de la API
según se ve hoy.
Aquí tienen una tarea de transformación,
que es relativamente fácil de entender,
con un archivo de entrada
y otro de salida.
Desde ya, aquí habrá una acción
que transformará
el archivo de entrada en el de salida.

English: 
And then you want somehow
things to be wired,
so that the consumer
have access to the newer
version of the merged manifest.
So at that point, obviously,
the original links are removed.
So the consuming
tasks are not going
to consume the ones from
the original producer.
And they just disappear.
So this is the new flow of
things that will happen.
And like we explained
earlier, all of this
will be done through provider
and through property,
so that the right linking
in terms of dependency
will work correctly.
So one of the two
consuming tasks
tries to access the
merged manifest,
it will invoke the custom
plugin, which itself
is invoking the
original, because it
requires the first original
of the merged manifest.
So all this chaining
will work correctly.
So this is the example of
the API as it looks today.
So you have a
TransformTask here,
which is relatively
easy to understand,
with an in file and out file.
Of course, there will
be an action here

Chinese: 
然后实现关联
让消费者可以访问
合并清单的新版本
此时，很明显，原始关联已删除
消费者任务不会使用
原始生产者的任务
这些任务会消失
这就是新流程
前面说过，所有这些操作
都将通过提供程序和属性来完成
从而正确地关联依赖项
正确地完成操作
两项消费者任务中的一项
尝试访问合并清单
它将调用自定义插件
该插件本身将调用原始清单
因为它需要第一份原始合并清单
所有这些链接都将正常运行
我们现在看到的API就是这样的
这里有一项TransformTask
相对而言比较容易理解
带有一个输入文件和一个输出文件
当然，这里会有一项将输入文件

Portuguese: 
Depois, tudo precisa estar conectado
para o consumidor ter acesso à versão
mais recente do manifesto combinado.
Nesse ponto, obviamente,
os links originais são removidos.
As tarefas de consumidor
não consumirão as do produtor original.
Elas apenas desaparecem.
Esse é o novo fluxo.
Como explicamos anteriormente, tudo isso
será feito por um provedor
e uma propriedade
para que a vinculação certa
em termos de dependência
funcione corretamente.
Uma das duas tarefas de consumidor
tenta acessar o manifesto combinado e
invocará o plug-in personalizado, que já
está invocando o original, porque
exige a primeira versão
do manifesto combinado.
Todo esse encadeamento
funcionará corretamente.
É um exemplo da API hoje.
Vocês têm uma "TransformTask" aqui,
que é fácil de entender,
com um arquivo de entrada e um de saída.
Claro, haverá uma ação aqui
que transformará
o arquivo de entrada no de saída.

Korean: 
그다음 어떻게든 연결하고자 하기 때문에
소비자는 액세스 권한을 가지는 거예요
최신 버전의 병합된 manifest이에요
따라서 이때 기존 연결이 제거됩니다
기존 소비자 작업은
기존 생산자의 작업을 소비하지 않습니다
그냥 사라질 뿐이죠
이 흐름이 앞으로 일어날 새로운 흐름입니다
앞서 설명한 것처럼
이 모든 것은 제공자와 속성을 통해 실행되므로
종속성 측면에서 적절한 연결이
올바르게 작동하게 될 것입니다
따라서 두 가지 소비 작업 중 하나가
병합된 manifest에 액세스하려고 하면
알아서 원본을 호출하는
맞춤 플러그인을 호출합니다
병합된 manifest의 첫 번째
원본이 필요하기 때문이죠
따라서 모든 연결이 올바르게 작동합니다
이 예가 바로 오늘 선보이는 API의 예입니다
여기에 TransformTask가 있는데
비교적 이해하기 쉬운 거예요
인 파일 및 아웃 파일을 사용하기 때문이죠
물론 변환하는 액션도 있죠
인 파일을 아웃 파일로 말이에요

Indonesian: 
Bagian yang menarik adalah
bagian kedua, yang pada dasarnya
adalah panggilan transformasi.
Sehingga ini di API kekerasan.
Dan Anda akan
bilang, di sini, lihat,
saya akan mengambil
manifes gabungan,
dan saya ingin manifes ini diproses
ke tugas transformasi ini, di mana
versi saat ini 
akan diproses ke infile.
Dan tolong ambil
versi yang lebih baru
dari artefak itu
di outfile.
Oke.
Jadi itu secara relatif
sangatlah mudah.
Lagi, semua ini
bertipe kuat.
Jadi manifes gabungan itu
adalah properti file reguler.
Jadi Anda tahu bahwa infile
dan outfile seharusnya
menjadi properti file reguler.
Dan API akan mengecek itu.
Hal lain yang dapat
Anda lakukan, yang
mungkin juga sangat menarik,
adalah untuk mengganti artefak.
Jadi, kali ini Anda
bahkan tidak ingin menggunakan
versi manifes gabungan kami.
Anda ingin melakukannya sendiri.
Baik, boleh juga.
Jika Anda ingin melakukan ini,
pada tahap ini
tugas produser asli
digantikan oleh tugas
produser plugin kustom.
Lalu tugas dalam hal ini
sebenarnya sedikit lebih sederhana.

Chinese: 
转换为输出文件的操作
有趣的是第二部分
转换调用
它位于变体API上
假设
我想获取合并清单
作为这个转换任务的输入
也就是最新版本将输入到输入文件中
同时，请在输出文件中检索
该特定工件的新版本
好了
这相对比较简单
同样，所有这些都应指定类型
合并清单是常规文件属性
那么输入文件和输出文件
必须是常规文件属性
API会检查这一项
另一项非常有趣的操作是
替换工件
您可能不想使用
我们的合并清单版本
您想自己来
很好
要执行该操作
请将原始生产者任务替换为
自定义插件生产者任务
这种情况下的任务实际更简单一些

English: 
that would transform the
in file into the out file.
The interesting part is the
second part, which is basically
the transform call.
So it's on the violent API.
And you're going
to say, here, look,
I would like to take
the merged manifest,
and I would like it to be fed
into this transform task, where
the current version will
be fed into the in file.
And please retrieve
the newer version
of that particular
artifact in the out file.
OK.
So that's relatively
straightforward.
Again, all of this
is very typed.
So the merged manifest is
a regular file property.
So you know that the in
file and out file have
to be a regular file property.
And the API will check that.
Another thing you
could do, which
might be also very interesting,
is to replace an artifact.
So this time you
don't even want to use
our merged manifest version.
You want to do it yourself.
Well, fine enough.
If you want to do
this, at that point
the original producer task
is replaced with your custom
plugin producer task.
And then the task in this case
is actually a little simpler.

Japanese: 
入力ファイルを出力ファイルに
変換します
面白いところは 2番目の部分で
基本的には
トランスフォームの呼び出しです
バイオレントAPIに関するものです
これは
マージされたマニフェストを
この変換タスクにフィードして
そこでは 最新のバージョンが
入力ファイルにフィードされます
それから そのアーティファクトの
最新版を
出力ファイルにとっておきます
そんなにむずかしくないですね
前と同じで すべてタイプは決まっています
結合したマニフェストは
通常ファイルのプロパティです
入力ファイルと出力ファイルも
通常ファイルプロパティでなければ
なりません
これはAPIがチェックします
他にできることで
大変面白いものに
アーティファクトとの
リプレースがあります
私達の用意した 
結合したマニフェストバージョンは
使いません
自分でやります
そうです
これがやりたければ
その時点で
オリジナルのプロデューサタスクを
自分の専用の
プラグインプロデューサタスクと
入れ替えます
この場合 タスクは実際
すこし簡単なものです

Korean: 
흥미로운 부분은 두 번째 부분인데
기본적으로 변환 호출로
강력한 API에 있습니다
여기 보시다시피
병합된 manifest를 가져와
이 변환 작업에 공급하고자 합니다
여기서 현재 버전이 인 파일로 공급되는데
출력 파일에서 특정 아티팩트의
최신 버전을 검색하시기 바랍니다
좋습니다
비교적 간단하죠
모두 입력되었어요
병합된 manifest는 일반 파일 속성입니다
따라서 인 파일과 아웃 파일은
일반 파일 속성이어야 합니다
그럼 API가 확인하겠죠
또 다른 작업은
아티팩트를 교체하는 것인데
매우 흥미로울 거예요
이번에는 병합된 manifest 버전을
사용하지 않고
직접 교체하는 거예요
좋아요
교체하는 경우에 해당 시점에서
기존 생산자 작업이 맞춤 플러그인
생산자 작업으로 바뀝니다
그럼 작업은 좀 더 간단해집니다

Spanish: 
Lo interesante es la segunda parte,
que es la invocación de transformación.
Está en la variante de API.
Y ustedes dirán: "Me gustaría
tomar el manifiesto combinado,
y que alimente la tarea
de transformación,
donde la versión actual
alimentará el archivo de entrada.
Y quiero obtener la versión más reciente
de ese artefacto particular
en el archivo de salida".
Es relativamente directo.
De nuevo,
todo está bien definido en tipos.
Así, el manifiesto combinado
es una propiedad de archivo regular.
Saben que los archivos
de entrada y salida
deben tener propiedades
de archivos regulares.
Y la API lo comprobará.
Otra cosa que podrían hacer,
muy interesante,
es reemplazar un artefacto.
Esta vez ni siquiera se recomienda
que usen el manifiesto combinado.
Recomendamos que lo hagan ustedes mismos.
Si quieren hacerlo, en este punto,
se reemplaza la tarea de productor original
por la del complemento personalizado.
Y la tarea, en este caso,
es en verdad un poco más simple.

Portuguese: 
O interessante é a segunda parte,
que é a chamada de transformação.
Isso está na API de variantes.
E você diria:
"Quero o manifesto combinado
e gostaria que ele fosse alimentado
nessa tarefa de transformação, em que
a versão atual será alimentada
no arquivo de entrada.
E, por favor, recupere
a versão mais recente
desse artefato específico
no arquivo de saída."
Isso é relativamente simples.
Todos os elementos têm tipos.
O manifesto combinado é uma
propriedade de arquivo regular.
Vocês sabem que os arquivos de
entrada e saída têm
que ser uma propriedade
de arquivo regular.
A API verificará isso.
Outra coisa que você faria e que
seria muito interessante
é substituir um artefato.
Nesse ponto, você não quer usar
nossa versão do manifesto combinado.
Quer criar a sua.
Tudo bem.
Para fazer isso, neste ponto,
a tarefa do produtor original
é substituída pela sua tarefa
personalizada do produtor no plug-in.
Nesse caso, a tarefa é, na verdade,
um pouco mais simples.

Portuguese: 
Como você não está consumindo
a versão produzida,
terá apenas uma saída.
A API de variante permitirá
que você faça a substituição,
em que terá que fornecer um
provedor de tarefas,
criado por meio de um registro...
Vocês já devem saber disso agora...
e especifica onde recuperar
a nova versão do arquivo.
Você precisa informar em qual artefato
quer aplicar isso.
É interessante perceber que
a tarefa de produtor real
não será executada.
Como ninguém quer a saída
da tarefa de produtor,
ela não é executada.
Talvez a gente perceba,
porque vamos executar a tarefa
de criação depois que
executarmos a API de variantes,
que há um novo produtor
para esse artefato específico.
Talvez nem registremos
mais a tarefa de produtor,
porque ela será substituída.
Então, para quê registrá-la?
A próxima coisa que
vocês podem fazer
quando têm uma
cardinalidade de muitos

Spanish: 
Dado que ustedes no consumen la versión
que producimos, solo tendrán una salida.
Y de nuevo, la variante de API
les permitirá realizar el reemplazo,
donde únicamente deberán proporcionar
un proveedor de la tarea,
que se crea mediante un registro…
Y probablemente a esta altura ya lo sepan…
Especifican dónde se obtiene
la versión nueva del archivo.
Una vez más,
tienen que indicar a qué artefacto
quieren aplicar esto.
Lo que nos interesa aquí
es que no se ejecutará
la tarea de productor real.
Como nadie quiere la salida
de la tarea de productor,
en realidad no se ejecutará.
Quizás nos demos cuenta
porque ejecutaremos la creación
de la tarea
después de ejecutar la variante de API.
Puede ocurrir
que notemos un productor nuevo
para este artefacto específico.
Y tal vez ni siquiera
registremos la tarea de productor
porque sabemos
que se está reemplazando.
¿Para qué hacerlo?
Lo siguiente que podrían hacer…
Y eso es cuando tienen 
una cardinalidad de muchos…

Indonesian: 
Karena Anda tidak menggunakan
versi yang kami produksi,
Anda hanya akan memiliki output.
Dan lagi, API varian akan
memungkinkan Anda melakukan penggantian,
di mana Anda hanya harus
menyediakan penyedia tugas,
yang dibuat
melalui register--
dan Anda mungkin
mengetahuinya sekarang--
dan Anda menentukan
di mana akan mengambil
versi baru file tersebut.
Dan lagi, Anda harus
mengatakan di artefak mana
Anda ingin menerapkannya.
Yang menarik
untuk disadari
adalah bahwa tugas produser
yang sebenarnya tidak akan dijalankan.
Karena tidak ada yang ingin
output tugas produser,
itu tidak akan berjalan.
Itu mungkin menjadi
hal yang kita sadari,
karena kita akan menjalankan
pembuatan tugas setelah kita
menjalankan API valiant,
kita mungkin sebenarnya
menyadari bahwa ada
produser baru
untuk artefak tertentu ini.
Dan kita mungkin tidak mendaftarkan
tugas produser lagi,
karena kita tahu
tugas ini sedang diganti.
Mengapa kita harus
mendaftarkannya, kan?
Hal selanjutnya yang dapat Anda lakukan--
dan itu ketika Anda memiliki
banyak kardinalitas--

Chinese: 
由于您不会使用我们生成的版本
只会有一项输出
同样，变体API会允许您替换
您只需提供通过寄存器创建的
任务提供程序
接下来的操作您可能已经知道了
指定到哪里检索
新版文件
同样，必须明确指出要在
哪个工件上应用该操作
有意思的是
系统不会执行实际生产者任务
因为没有人需要生产者任务的输出
因此它实际上不会运行
事实上，我们可能会发现
因为我们运行变体API之后
会运行任务创建
该特定工件
会有一个新的生产者
我们甚至不用再注册生产者任务
因为它已被替换
没有注册的必要
如果基数为“多”
接下来您可以

Korean: 
생산하는 버전을 사용하지 않기 때문에
출력만 하면 됩니다
또한 변형 API를 사용하면 
교체 작업을 할 수 있습니다
이 경우 레지스터를 통해 생성된
작업 공급자를 제공해야 하는데
이제는 아마 아실 거예요
새 버전의 파일을 검색할
위치를 지정하면 됩니다
다시 한번 어떤 아티팩트를
적용하고 싶은지 입력해야 합니다
흥미로운 사실은 바로
실제 생산자 작업이
실행되지 않는다는 것입니다
아무도 생산자 작업의 출력을 
원하지 않기 때문에
실제로는 실행되지 않습니다
강력한 API를 실행한 후
작업 생성을 실행하기 때문에
실제로는 이 특정 아티팩트에 대한
새로운 생산자가 있음을
알 수 있습니다
더 이상 생산자 작업을 
등록하지 않아도 되는데
작업이 교체되고 있는 것을 알기 때문이죠
등록할 이유가 없어요
다음으로 할 수 있는 작업은
cardinality가 많은 경우에 
기존 아티팩트 목록에

Japanese: 
私達がプロデュースしているバージョンを
コンシュームしていないので
アウトプットがあるだけです
今回も バリアントAPIを使うことにより
置き換えができ
レジスターで生成された
タスクプロバイダをプロバイドするだけです
もう気がついた人もいるかもしれませんが
新しいバージョンのファイルを
保存する場所を
指定します
ここでも これをどのアーティファクトに
適用するのかを
決めなければなりません
面白いことに
実際のプロデューサタスクは
実行されません
プロデューサタスクの出力を欲しがる人は
誰もいないので
実際には実行されません
この場合 分かると思いますが
タスク生成の実行は
バリアントAPIの実行後なので
このアーティファクトに関しては
新しいプロデューサがあります
また プロデューサタスクを
登録することもありません
なぜなら置き換えられるのが
分かっているからです
登録する必要はありません
次にできることは
複数のカーディナリティがある場合

English: 
Since you are not consuming
the version we are producing,
you'll just have an output.
And again, the variant API will
allow you to do the replace,
where you just have to
provide a task provider,
which is created
through a register--
and you probably
know that by now--
and you specify
where to retrieve
the new version of the file.
And again, you have to
say on which artifact
you want to apply this.
What is interesting
to realize there
is that the actual producer
task will not be executed.
Because nobody wants the
output of the producer task,
it will actually not run.
It might actually be the
case that we will realize,
because we will run the
task creation after we will
run the valiant API,
we might actually
realize that there
is a new producer
for this particular artifact.
And we might not even register
the producer task anymore,
because we know
it's being replaced.
Why are we even
registering it, right?
The next thing you could do--
and that's when you have
a cardinality of many--

Chinese: 
将新工件添加到现有工件列表中
典型例子包括文本文件、类文件等等
在这些文件中，容易出现
突然要向现有列表添加新元素的情况
这里是另一个示例
相对较为简单
该生产者任务仅生成一个元素
但是它会被添加到元素列表中
该特定DEX工件的所有消费者
都会收到新列表
我们生成的原始元素以及自定义插件元素
将被添加到一个列表中
并输入到消费者任务中执行
最后一个API是
获取工件
这可能是大家想要的
最有趣的功能之一
也就是从构建过程中
检索中间文件
例如

Spanish: 
Es adjuntar un artefacto nuevo
a una lista de artefactos existentes.
Los mejores ejemplos podrían ser
los archivos de texto, de clase,
cosas de ese tipo, donde, de repente,
quieren adjuntar algún elemento
nuevo a una lista existente.
Este es un ejemplo.
Es relativamente simple.
Esta tarea de productor
genera únicamente un objeto,
pero se agrega a la lista de elementos.
Y a todos los consumidores
de ese artefacto DEX particular
se incorporará la lista nueva,
donde se adjuntará la original que produjimos
más el complemento personalizado
a una única lista
y se agregará a la ejecución
de la tarea de consumidor.
Obviamente, hay una API final
que es la obtención de un artefacto.
Y esa es probablemente
una de las más interesantes
que esperan los usuarios.
Se trata de la capacidad
de obtener un archivo intermedio
del proceso de compilación.
Aquí pueden ver, por ejemplo,

Korean: 
새 아티팩트를 추가하는 것입니다
가장 좋은 예로 텍스트 파일, 클래스 파일,
이러한 파일을 들 수 있겠네요
기존 목록에 갑자기
새로운 요소를 추가하려는
이런 종류 말이죠
여기 보시면 또 다른 예가 있습니다
비교적 간단해요
이 생산자 작업은
하나의 요소만 생성하지만
요소 목록에 추가됩니다
특정 DEX 아티팩트의 모든 소비자에게는
실제로 새 목록이 제공됩니다
여기서 저희가 만든 기존 플러그인과 
사용자 정의 플러그인은
단일 목록에 추가되어
소비자 작업 실행에 공급됩니다
당연히 아티팩트를 얻는
최종 API가 하나 있고
아마도 사람들이 찾는
가장 흥미로운 것 중 하나일 거예요
빌드 프로세스에서 중간 파일을
검색하는 기능입니다

Indonesian: 
adalah menambahkan artefak baru
ke daftar artefak yang ada.
Jadi, mungkin contoh terbaik
adalah file teks, file class,
hal-hal seperti ini, 
di mana Anda tiba-tiba
ingin menambahkan beberapa
elemen baru ke daftar yang ada.
Jadi, ini dia,
lagi, sebuah contoh.
Ini relatif sederhana.
Tugas produser ini
hanya memproduksi satu elemen,
tapi tugas tersebut ditambahkan
ke daftar elemen.
Dan semua konsumen
artefak DEX tertentu
akan diberi daftar baru, di mana
daftar asli yang kami produksi
ditambah plugin kustom
akan ditambahkan
ke satu daftar
dan diproses ke eksekusi
tugas konsumen.
Jelas, ada satu API terakhir,
yang memperoleh artefak.
Dan itu mungkin salah 
satu hal yang paling menarik,
saya kira, yang dicari orang.
Itu adalah kemampuan 
untuk mengambil file intermediate
dari proses build.
Jadi, Anda dapat
melihat, contohnya,
bahwa Anda ingin mengambil
manifes gabungan.

Japanese: 
既存のアーティファクトのリストに新しいものを
追加することです
おそらく 一番いい例は
テキストファイルやクラスファイルなどで
すでにあるリストに
新しい要素を
加えたくなった場合です
ここに例を示します
比較的簡単なものです
このプロデューサタスクは
要素を１つしかプロデュースしませんが
要素のリストに加えます
その特定のDEXアーティファクトの
すべてのコンシューマが
新しいリストとともにフィードされ
そこでは
私達がプロデュースしたもとのリストと
カスタムのプラグインのものが
一つのリストにまとめられて
コンシューマタスクの実行に
フィードされます
最終的に一つのAPIとなり
これが得られたアーティファクトです
これが 一番おもしろいと
感じる例だと思います
ビルドプロセスから
中間ファイルを取り出せることです
たとえば

Portuguese: 
é anexar um novo artefato
a uma lista dos já existentes.
Os melhores exemplos são
arquivos DEX e de classes,
coisas assim, em que vocês possam
anexar um elemento novo a
uma lista já existente.
Aqui está outro exemplo.
Ele é relativamente simples.
A tarefa de produtor está
produzindo apenas um elemento,
mas ele é adicionado a uma
lista de elementos.
Todos os consumidores desse
artefato DEX específico
serão realmente alimentados
com a nova lista, em que
o original que produzimos
e o plug-in personalizado
serão anexados a uma única lista
e alimentados na execução da
tarefa de consumidor.
Claro que há uma API final, que
é a obtenção de um artefato.
Essa á uma das coisas mais interessantes
que as pessoas estão procurando.
É a capacidade de recuperar
um arquivo intermediário
do processo de compilação.

English: 
is to append a new artifact
to a list of existing ones.
So probably the best examples
are text files, class files,
kind of things like
this, where suddenly you
want to append some new
element to an existing list.
So here this is,
again, an example.
It's relatively simple.
This producer task is
producing only one element,
but it gets added to
a list of elements.
And all the consumers of
that particular DEX artifact
will actually be fed
with the new list, where
the original one we produced
plus the custom plugin one
will be appended
into a single list
and fed into the execution
of the consumer task.
Obviously, there is
one final API, which
is the obtaining an artifact.
And that's probably one of
the most interesting one,
I guess, that people
are looking for.
It's the ability to retrieve
an intermediate file
from the build process.
So here you can
see, for instance,

English: 
that you want to retrieve
the merged manifest.
And this time you don't
really want to change it.
You may just want to retrieve
it because you want to check
things, or you want to--
whatever you want to do with it.
But you just want to
have access to it, right?
So here is the example.
You've got a consumer task
with a normal input file
as a regular file property.
And then you have
registered a build.
What is interesting
here is that, if you
say-- so this consumer task.
Let's say you register
it as my consumer task
when you create it
with the Gradle APIs.
If you invoke Gradle
my consumer task,
it will then create and
execute all the tasks that
produce the merged manifest.
You don't have to remember that
the merged manifest is actually
produced by a task called
merged manifest debug, whatever,
coming from our plugin.
You just invoke it
with your task name.
And because the
dependencies are chained,
the actual task from the
AGP will actually be called.

Indonesian: 
Dan kali ini Anda tidak
benar-benar ingin menggantinya.
Anda mungkin hanya ingin mengambilnya
karena Anda ingin mengecek
sesuatu, atau Anda ingin--
apa pun yang Anda ingin lakukan dengannya.
Tetapi Anda hanya ingin
memiliki akses ke manifes itu, bukan?
Jadi begini contohnya.
Anda telah mendapat tugas konsumen
dengan file input normal
sebagai properti file reguler.
Lalu Anda telah
mendaftarkan build.
berkata-- jadi ini tugas konsumen.
ketika Anda membuatnya
dengan Gradle API.
Jika Anda memanggil tugas konsumen saya
dari Gradle,
lalu hal ini akan membuat dan
mengeksekusi semua tugas yang
memproduksi manifes gabungan.
Anda tidak perlu mengingat bahwa
manifes gabungan itu sebenarnya
diproduksi oleh tugas yang disebut
debug manifes gabungan, yang
berasal dari plugin kami.
Anda hanya memanggilnya
dengan nama tugas Anda.
Dan karena
dependensinya terhubung,
tugas yang sebenarnya dari
AGP akan terpanggil.

Portuguese: 
Aqui, você pode ver
que quer recuperar o manifesto combinado.
Neste ponto, você não quer mudá-lo.
Quer recuperá-lo, porque quer
fazer uma verificação ou outras coisas.
Você só quer ter acesso a ele, certo?
Aqui está um exemplo.
Uma tarefa de consumidor
com um arquivo de entrada normal
como propriedade de arquivo regular.
E registrou uma versão.
O interessante é o seguinte.
Digamos que você a registre
como minha tarefa de consumidor
ao criá-la com as APIs do Gradle.
Se você invocar
minha tarefa de consumidor do Gradle,
ele criará e executará todas as tarefas
que produzem o manifesto combinado.
Você não precisa lembrar que
o manifesto combinado
é produzido por uma tarefa chamada
"depuração de manifesto combinado".
Basta invocá-la com o nome da tarefa.
Como as dependências são encadeadas,
a tarefa real do AGP será chamada.

Spanish: 
que quieren obtener
el manifiesto combinado.
Y esta vez no quieren cambiarlo.
Tal vez
solo quieren obtenerlo
por que quieren comprobar cosas,
lo que sea que quieran hacer con él.
Pero solo quieren
tener acceso a él, ¿no?
Este es el ejemplo.
Tienen una tarea de consumidor
con un archivo de entrada normal
como propiedad de archivo regular
y luego registraron una compilación.
Lo interesante aquí es, supongamos,
esta tarea de consumidor.
Digamos que la registran
como mi tarea de consumidor
cuando la crean con las API de Gradle.
Si invocan a Gradle
para la tarea de consumidor,
creará y ejecutará todas las tareas
que produzca el manifiesto combinado.
No tienen que recordar
que al manifiesto combinado
lo produjo una tarea invocada
de eliminación de errores
o lo que sea que provenga
de nuestro complemento.
Simplemente la invocan
con el nombre de la tarea.
Y, dado que las dependencias
están encadenadas,
se invocará la tarea real de la API.

Chinese: 
您要检索合并清单
而且这次您不想更改它
您可能只想检索它，以便检查
或者
执行任何其他操作
但是您只需要访问它
这里是示例
您有一项消费者任务，它有一个普通输入文件
该文件具备常规文件属性
然后，您注册了一个构建文件
有趣的地方在于
假设您使用Gradle API创建
这项消费者任务时
将其注册为我的消费者任务
如果通过Gradle调用我的消费者任务
它会创建并执行
用于生成合并清单的所有任务
您不用记住合并清单的生产者
实际是插件中的任务
合并清单调试
您只需使用任务名称调用它
由于依赖项是链接在一起的
系统会调用AGP中的实际任务

Japanese: 
結合されたマニフェストを取り出したいとき
今回は変更しませんが
取り出す目的は
中味をチェックすることであって
あるいは
どんな目的であれ
とにかくアクセスしたいという状況です
例をお見せします
通常のインプットファイルがある
コンシューマタスクがあって
プロパティは通常ファイルプロパティです
ビルドの登録もしています
面白いところは
このコンシューマタスクです
あなたがGradle APIで作ったとき
私のコンシューマタスクとして
登録したとします
あなたがGradleを立ち上げると
私のコンシューマタスクは
結合したマニフェストを
プロデュースするタスクを
すべて実行することになります
結合されたマニフェストは実際は
私たちのプラグインからくる
結合マニフェストデバッグと
呼ばれるタスクによって
実行されますが
気にする必要はありません
あなたは自分のタスク名で
起動するだけです
依存性はチェーンに
なっていますから
AGPからの実際のタスクが
実際に呼ばれます

Korean: 
예를 들어 여기 보시면
검색할 병합된 manifest가 있고
이번에는정말로 변경하지 않고
단지 검색하고자 할거예요
왜냐면 뭔가를 확인하려 하거나
병합된 manifest를 이용하여
원하는 무엇이든 하려 하기 때문이죠
하지만 그냥 병합된 manifest에 
액세스하고 싶은 거죠
그럼 예를 들어 보겠습니다
일반 입력 파일을 
일반 파일 속성으로 사용하는
소비자 작업이 있습니다
그런 다음 빌드를 등록했습니다
여기서 흥미로운 점은
이 소비자 작업입니다
소비자 작업으로 등록한다고 가정해 봅시다
Gradle API를 이용하여 생성하는 경우에 말이죠
Gradle 소비자 작업을 호출하면
병합된 manifest를 생성하는
모든 작업을 생성하고 실행합니다.
병합된 manifest가 실제로 
플러그인에서 제공되는
병합된 manifest 디버그라는
작업에서 생성된다는 것을
기억할 필요가 없습니다
여러분의 작업 이름으로 호출합니다
종속성이 연결되어 있기 때문에
AGP의 실제 작업이 호출되는 거죠

Korean: 
그리고 마지막으로
7초밖에 없기 때문에 빨리 할게요
DSL 파싱을 할 때
DSL 콜백을 하기 때문에 콜백을 통해
DSL을 빠르게 확장할 수 있습니다
그런 다음 객체를 잠궈
더 이상 객체를 변경할 수 없도록 합니다
이때 변형 객체를 만드는 거예요
그럼 변형 객체를 사용할 수 있죠
변형 콜백을 통해서 말이에요
이 콜백은 저희가 호출한 것과
자비에가 보여준 것과 비슷한 거죠
다시 해당 객체를 다시 잠궈
작업을 만듭니다
이렇게 하면 안전해져
작업이 너무 늦지 않게 되죠
또한 작동할 것 같지만
실제로는 그 값이 더 이상 
사용되지 않을 수도 있습니다
예를 들어 변형 데이터가 생성되면
DSL 객체를 완전히
쓸모없는 것으로 간주하게 되고
이때 제거할 수 있는 거죠
좋아요
오늘은 여기까지 하겠습니다
질문이 있으시면 저희를 찾아와주세요
위층 빌드 스피드 부스에
많은 직원이 상주하고 있습니다
부스를 방문하셔서 
Gradle에 관한 다른 질문을 하셔도
괜찮습니다
감사합니다
[박수]

Indonesian: 
Dan terakhir, singkat 
saja karena saya hanya
memiliki tujuh detik, apa 
yang akan kita lakukan adalah
saat Anda melakukan penguraian DSL, kami
akan melakukan callback 
DSL sehingga Anda bisa segera
menambah DSL Anda dengan 
cepat melalui callback.
Lalu kami mengunci objek, 
yang berarti Anda tidak
bisa mengubahnya lagi.
Itulah saat kami akan 
membuat objek varian.
Jadi objek variannya akan
tersedia melalui callback varian, yang
kurang lebih seperti
yang kami panggil
dan apa yang Xavier 
tunjukkan pada Anda.
Yang kemudian akan terkunci kembali,
dan kami akan membuat tugas kami.
Jadi, semua ini akan membuatnya
benar-benar aman,
bahwa Anda tidak terlambat,
dan Anda berpikir itu akan berhasil,
tetapi pada kenyataannya, mungkin 
nilai-nilai itu tidak digunakan lagi.
Jadi, sebagai contoh, 
saat data varian sudah dibuat,
kami akan menganggap 
objek DSL tidak berguna.
dan kami bisa 
menghilangkannya pada saat itu,
Oke.
Dan saya pikir itu cukup.
Silakan jika ada pertanyaan.
Ada sekumpulan orang 
di booth di lantai atas
yang disebut Build Speed.
Tapi Anda bisa datang dan bertanya kepada 
kami untuk pertanyaan Gradle lainnya,
tentunya.
Terima kasih.
[TEPUK TANGAN]

Spanish: 
Lo último que haremos,
muy rápido porque solo tengo 7 segundos,
es que cuando hagan el análisis de DSL,
se hará una devolución de llamada
para que puedan aumentar rápido su DSL.
Luego, bloqueamos los objetos,
lo que significa
que no podrán volver a cambiarlos.
Ahí es cuando crearemos
los objetos de variante,
que estarán disponibles
mediante la devolución de llamada,
que es más o menos lo que explicamos
y lo que les estaba mostrando Xavier.
Y luego se volverán a bloquear,
y crearemos nuestras tareas.
Todo esto hará que sea muy seguro.
No lo harán demasiado tarde,
y piensen que va a funcionar,
pero, de hecho, tal vez esos valores
no se usen más.
Por ejemplo, cuando se hayan creado
los datos de variante,
consideraremos que los objetos de DSL
son completamente inútiles.
Y, en este punto, podríamos
deshacernos de ellos.
Creo que eso es todo por hoy.
Estaremos aquí por si surgen dudas.
Habemos varias personas
en el puesto de arriba
que se llama "Build Speed".
Pero igual pueden hacernos llegar
otras dudas sobre Gradle.
Gracias.

Chinese: 
快速说一下最后一点
只剩7秒钟了
执行DSL解析时
我们会执行DSL回调
以便通过回调快速扩展DSL
然后我们会锁定对象
您将无法再更改这些对象
这时我们会创建变量对象
然后通过变量回调
使用变量对象
这就是
Xavier刚才展示的内容
然后它们会被再次锁定
之后我们会创建任务
所有这些操作都非常安全
也不会太晚
您认为它会执行
但实际上这些值也许不会再使用
例如，创建变量数据后
我们会认为完全不会再用到DSL对象
因此可以删除
好了
这就是今天的内容
大家有问题可以找我们
楼上的Build Speed展位
也有我们的同事
大家可以来询问有关Gradle的
其他问题
谢谢大家
[掌声]

Portuguese: 
Por fim, muito rápido,
porque tenho sete segundos,
quando vocês fizerem
uma análise DSL,
faremos um callback DSL para que
vocês possam aumentar
a DSL por meio de um callback.
Bloqueamos os objetos,
e não será mais possível alterá-los.
É quando criamos os objetos de variantes.
Esses objetos estarão disponíveis
por meio do callback de variantes,
que o Xavier mostrou.
Depois, serão bloqueados novamente
e criaremos nossas tarefas.
Tudo isso vai ficar muito mais seguro,
vocês não terão atrasos
e saberão que vai funcionar.
Na verdade, esses valores
não serão mais usados.
Por exemplo, quando os dados de
variantes forem criados,
os objetos DSL
serão considerados inúteis.
E poderemos nos livrar deles.
Acho que é isso por hoje.
Podem fazer perguntas.
Temos várias pessoas no
estande lá em cima,
chamado Build Speed.
Mas vocês podem vir e nos
fazer outras perguntas sobre o Gradle.
Obrigado.

English: 
And the last, very
quickly because I only
have seven seconds,
what we will do
is that when you do
DSL parsing, we're
going to do a DSL callback
so you can quickly augment
your DSL through a callback.
Then we lock the objects,
which means that you will not
be able to change them anymore.
That's when we'll create
the variant objects.
So the variant
objects will then be
available through the
variant callback, which
is more or less
what we called you
and what Xavier was showing you.
And then they will
be locked again,
and then we will
create our tasks.
So all this will make
it very, very safe,
that you don't do
things too late,
and you think that
is going to work,
but in fact, maybe those
values are not used anymore.
So for instance, when the
variant data has been created,
we will consider the DSL
objects completely useless.
And we could basically get
rid of them at that point.
OK.
And I think that's it for today.
We'll be around
for more questions.
And we have a bunch of
people at the booth upstairs
which is called Build Speed.
But you can go come and ask
us for other Gradle questions,
obviously.
Thank you.
[APPLAUSE]

Japanese: 
最後に 取り急ぎ
あと7秒しかありせんが
DSLパーシングをするとき
DSLコールバックをするので
コールバックで自分のDSLを
手軽に拡張できます
次に オブジェクトをロックします
つまり もう変更できません
このタイミングで
バリアントオブジェクトを生成します
すると バリアントオブジェクトが
バリアントコールバックから
使えるようになります
おおかた
Xavierがお見せしたようなものです
それから再びロックされて
自分のタスクを作成します
その結果 とても安全になります
手遅れにならないうちにやっておけば
うまくいくものです
しかし そのような値は
もう使われないかもしれません
例えば バリアントデータが作られたとき
DSLオブジェクトは全く使い物にならないと
考えるでしょう
基本的にはその時点で処分してしまうと
思います
今日は この辺で終わりにします
質問があれば お願いします
上の階のブースには何人もいます
Build Speedというブースです
もちろん
Gradleに関する他の質問にも
お答えします
ありがとう

Indonesian: 
[ALUNAN MUSIK]

Korean: 
[음악 재생]

English: 
[MUSIC PLAYING]

Chinese: 
[播放音乐]
