Hi guys, checked the snapshot pom today and there are issues:
1. no parent (so 2 is hard to handle, no properties etc) 2. too much noise informations (all the parent data should be in the parent) 3. wrong scopes (all is compile) - which is likely a leak of gradle scripts 4. missing important configuration (properties and or plugin) like the ones defining the java versions I didn't check the profiles but it makes already some work ;) Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book 2018-04-11 6:50 GMT+02:00 Romain Manni-Bucau <rmannibu...@gmail.com>: > > > Le 11 avr. 2018 02:30, "Reuven Lax" <re...@google.com> a écrit : > > Actually I always found the right-click to run tests to only sometimes work > in Maven, especially if there were changes to dependent AutoValue classes > where code had to be generated. Too often it would fail, and I would then > need to use Maven to rebuild the whole project. It would be cool if Gradle > could do this more reliably than Maven did. > > > Hmm, i exactly experiment the opposite. Testes with idea 2017 and 2018. > > > Reuven > > On Tue, Apr 10, 2018 at 8:46 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: >> >> @jb: what did you change? I re-imported the project like 3 times earlier >> today and never got it working acceptably :( >> >> Personally if importing the project and right click on a test+debug works >> as good as maven in idea id be happy. I can manage other stuff in a console >> even if gradle reporting is not that efficient for me for now. >> >> Le 10 avr. 2018 21:37, "Reuven Lax" <re...@google.com> a écrit : >>> >>> There are a lot of ideas on how to increase usability, but I think >>> they'll get lost in the thread. I suggest we try to capture them in Jiras. >>> >>> I suggest we also find out what common use patterns are (people on this >>> thread are probably sufficient), as different people will have different >>> workflows. We can then make sure that all common workflows are documented. >>> As an example, one task I often do is to run just checkstyle over a module >>> or the entire project. >>> >>> Reuven >>> >>> On Tue, Apr 10, 2018 at 7:18 PM Jean-Baptiste Onofré <j...@nanthrax.net> >>> wrote: >>>> >>>> FYI, I did a new attempt and it works fine (pretty long). Previous try >>>> failed. >>>> >>>> Regards >>>> JB >>>> >>>> On 10/04/2018 19:52, Kenneth Knowles wrote: >>>> > I've been on Idea+Gradle for ~two months, around the time I added >>>> > https://github.com/apache/beam/pull/4583 and >>>> > https://github.com/apache/beam/pull/4626 to make the import require >>>> > zero >>>> > user work. I have no fear of deleting my project any time and >>>> > re-importing. >>>> > >>>> > I agree with not having auto-import on. It is just too slow. I can't >>>> > remember if it was importing too often due to build outputs or if it >>>> > was >>>> > just that I was messing with the build.gradle files. Anyhow it doesn't >>>> > really add much value. >>>> > >>>> > The gradle runner _is_ able to use submodules and run individual tests >>>> > methods, and all that. >>>> > >>>> > Kenn >>>> > >>>> > >>>> > On Tue, Apr 10, 2018 at 9:31 AM Romain Manni-Bucau >>>> > <rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>> wrote: >>>> > >>>> > Runner a test doesnt have the right classpath (idea uses out/ >>>> > instead >>>> > of build/) then when you switch on gradle runner the launching >>>> > uses >>>> > gradle which is not able to use submodules directly but reconsider >>>> > the >>>> > whole project which is quite slow for normal dev iterations >>>> > compare to just run the test with the right classpath and a fast >>>> > compile step if needed. I lost literally 1h for something simple >>>> > with >>>> > that tooling, this is way too much to be acceptable on my side >>>> > since >>>> > I'm sadly not paid to work on beam (one day maybe ;)). >>>> > >>>> > Romain Manni-Bucau >>>> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >>>> > >>>> > >>>> > 2018-04-10 18:27 GMT+02:00 Reuven Lax <re...@google.com >>>> > <mailto:re...@google.com>>: >>>> > > Romain, >>>> > > >>>> > > Can you detail what's not working. I switched my IntelliJ over >>>> > to >>>> > Gradle >>>> > > about two weeks ago, and haven't had any trouble. >>>> > > >>>> > > Reuven >>>> > > >>>> > > On Tue, Apr 10, 2018 at 4:20 PM Romain Manni-Bucau >>>> > <rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>> >>>> > > wrote: >>>> > >> >>>> > >> Ok, didn't find a way to make it working properly (only >>>> > workaround >>>> > >> with direct commands and no good idea integration for >>>> > debugging). I'm >>>> > >> back with maven, if anyone knows how to properly solve it >>>> > let's >>>> > do it. >>>> > >> If not I think JB point is to consider more than any other >>>> > criteria. >>>> > >> >>>> > >> Romain Manni-Bucau >>>> > >> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >>>> > >> >>>> > >> >>>> > >> 2018-04-10 16:41 GMT+02:00 Romain Manni-Bucau >>>> > <rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>>: >>>> > >> > side note: do NOT use auto-import until you are sure you >>>> > can, >>>> > it locks >>>> > >> > regularly on beam (pby too big for idea?) and makes idea >>>> > ready >>>> > to be >>>> > >> > killed :( >>>> > >> > >>>> > >> > Romain Manni-Bucau >>>> > >> > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >>>> > >> > >>>> > >> > >>>> > >> > 2018-04-10 16:40 GMT+02:00 Jean-Baptiste Onofré >>>> > <j...@nanthrax.net <mailto:j...@nanthrax.net>>: >>>> > >> >> It's what I did, I'm trying a complete reload now (maybe >>>> > this >>>> > step >>>> > >> >> failed). >>>> > >> >> >>>> > >> >> On 10/04/2018 16:38, Lukasz Cwik wrote: >>>> > >> >>> >>>> > >> >>> beam-site PR/414 updates the instructions for using >>>> > Intellij >>>> > and how >>>> > >> >>> to >>>> > >> >>> import a module: >>>> > >> >>> >>>> > >> >>> 1. Create an empty IntelliJ project outside of the Beam >>>> > source tree. >>>> > >> >>> 2. Under Project Structure > Project, select a Project >>>> > SDK. >>>> > >> >>> 3. Under Project Structure > Modules, click the + sign to >>>> > add a module >>>> > >> >>> and >>>> > >> >>> select "Import Module". >>>> > >> >>> 1. Select the directory containing the Beam source >>>> > tree. >>>> > >> >>> 2. Tick the "Import module from external model" >>>> > button >>>> > and select >>>> > >> >>> Gradle >>>> > >> >>> from the list. >>>> > >> >>> 3. Tick the following boxes. >>>> > >> >>> * Use auto-import >>>> > >> >>> * Create separate module per source set >>>> > >> >>> * Store generated project files externally >>>> > >> >>> * Use default gradle wrapper >>>> > >> >>> 4. Delegate build actions to Gradle by going to Settings > >>>> > Build, >>>> > >> >>> Execution, >>>> > >> >>> Deployment > Build Tools > Gradle and checking >>>> > "Delegate IDE >>>> > >> >>> build/run >>>> > >> >>> actions to gradle". >>>> > >> >>> >>>> > >> >>> On Tue, Apr 10, 2018 at 10:34 AM Jean-Baptiste Onofré >>>> > <j...@nanthrax.net <mailto:j...@nanthrax.net> >>>> > >> >>> <mailto:j...@nanthrax.net <mailto:j...@nanthrax.net>>> wrote: >>>> > >> >>> >>>> > >> >>> That's a very important issue for contribution. Up to >>>> > now, I used >>>> > >> >>> Maven >>>> > >> >>> for setup IntelliJ (and it works just fine). If we >>>> > remove the >>>> > >> >>> pom.xml, >>>> > >> >>> we have to support Eclipse and IntelliJ "smoothly". >>>> > >> >>> >>>> > >> >>> Let me try in IntelliJ. >>>> > >> >>> >>>> > >> >>> Regards >>>> > >> >>> JB >>>> > >> >>> >>>> > >> >>> On 10/04/2018 15:21, Romain Manni-Bucau wrote: >>>> > >> >>> > You dont have issue due to the build setup with >>>> > that >>>> > option. I >>>> > >> >>> get: >>>> > >> >>> > >>>> > >> >>> > avr. 10, 2018 3:20:10 PM >>>> > >> >>> > >>>> > org.apache.beam.runners.direct.DirectTransformExecutor run >>>> > >> >>> > GRAVE: Error occurred within >>>> > >> >>> > >>>> > org.apache.beam.runners.direct.DirectTransformExecutor@66761b7a >>>> > >> >>> > com.google.common.util.concurrent.ExecutionError: >>>> > >> >>> > java.lang.NoClassDefFoundError: >>>> > net/bytebuddy/NamingStrategy >>>> > >> >>> > >>>> > >> >>> > ? >>>> > >> >>> > >>>> > >> >>> > Romain Manni-Bucau >>>> > >> >>> > @rmannibucau | Blog | Old Blog | Github | LinkedIn >>>> > | >>>> > Book >>>> > >> >>> > >>>> > >> >>> > >>>> > >> >>> > 2018-04-10 15:13 GMT+02:00 Lukasz Cwik >>>> > <lc...@google.com <mailto:lc...@google.com> >>>> > >> >>> <mailto:lc...@google.com <mailto:lc...@google.com>>>: >>>> > >> >>> >> I have found that the simplest setup is to >>>> > delegate the >>>> > >> >>> build/test actions >>>> > >> >>> >> to Gradle. This allows you to run unit tests very >>>> > easily and >>>> > >> >>> since its in >>>> > >> >>> >> the same manner that Gradle would have, you know >>>> > that if its >>>> > >> >>> passing it will >>>> > >> >>> >> pass on the command line and on Jenkins. Here is >>>> > one >>>> > site that >>>> > >> >>> discusses how >>>> > >> >>> >> to set this up: >>>> > >> >>> >> >>>> > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> > >>>> > http://mrhaki.blogspot.com/2016/11/gradle-goodness-delegate-build-and-run.html >>>> > >> >>> >> >>>> > >> >>> >> >>>> > >> >>> >> On Tue, Apr 10, 2018 at 8:45 AM Romain Manni-Bucau >>>> > >> >>> <rmannibu...@gmail.com <mailto:rmannibu...@gmail.com> >>>> > <mailto:rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>>> >>>> > >> >>> >> wrote: >>>> > >> >>> >>> >>>> > >> >>> >>> What's the plan to make idea supporting gradle on >>>> > beam >>>> > >> >>> project? >>>> > >> >>> Do we >>>> > >> >>> >>> import the workaround mentionned in >>>> > >> >>> >>> https://youtrack.jetbrains.com/issue/IDEA-175172? >>>> > >> >>> >>> For the ones who didn't see this issue in action: >>>> > idea will >>>> > >> >>> compile in >>>> > >> >>> >>> out/ instead of build/ and you will just miss all >>>> > the >>>> > >> >>> resources >>>> > >> >>> you >>>> > >> >>> >>> need like some SPI registration which are used by >>>> > all our >>>> > >> >>> registrar => >>>> > >> >>> >>> no way to run tests in idea without hacking the >>>> > configuration >>>> > >> >>> quite >>>> > >> >>> >>> deeply :( >>>> > >> >>> >>> >>>> > >> >>> >>> Romain Manni-Bucau >>>> > >> >>> >>> @rmannibucau | Blog | Old Blog | Github | >>>> > LinkedIn >>>> > | Book >>>> > >> >>> >>> >>>> > >> >>> >>> >>>> > >> >>> >>> 2018-04-10 10:08 GMT+02:00 Etienne Chauchot >>>> > >> >>> <echauc...@apache.org <mailto:echauc...@apache.org> >>>> > <mailto:echauc...@apache.org <mailto:echauc...@apache.org>>>: >>>> > >> >>> >>>> > >> >>> >>>> As a gradle beginner, I could not agree more ! >>>> > >> >>> >>>> +1 >>>> > >> >>> >>>> Etienne >>>> > >> >>> >>>> Le lundi 09 avril 2018 à 18:47 +0200, >>>> > Jean-Baptiste Onofré a >>>> > >> >>> écrit : >>>> > >> >>> >>>> >>>> > >> >>> >>>> Hi all, >>>> > >> >>> >>>> >>>> > >> >>> >>>> I did multiple gradle build since last week and >>>> > I >>>> > would like >>>> > >> >>> to share >>>> > >> >>> >>>> one of my concern: it's about the communities. >>>> > >> >>> >>>> >>>> > >> >>> >>>> If I think our users won't see any change for >>>> > them >>>> > due to >>>> > >> >>> Gradle build >>>> > >> >>> >>>> (I think that most of our users will still use >>>> > Maven with >>>> > >> >>> artifacts >>>> > >> >>> >>>> provided by Gradle), I'm more concerned by the >>>> > dev >>>> > community >>>> > >> >>> and the >>>> > >> >>> >>>> contribution. >>>> > >> >>> >>>> >>>> > >> >>> >>>> Maven is well known and straight forward for a >>>> > large part of >>>> > >> >>> potential >>>> > >> >>> >>>> contributors. I think we have to keep in mind >>>> > that >>>> > we still >>>> > >> >>> have to grow >>>> > >> >>> >>>> up our contributors community. >>>> > >> >>> >>>> >>>> > >> >>> >>>> Today, maybe I'm wrong, but I have the feeling >>>> > that gradle >>>> > >> >>> build is not >>>> > >> >>> >>>> straight forward (build.gradle includes >>>> > build_rules.gradle, >>>> > >> >>> gathering >>>> > >> >>> >>>> all taks all together). >>>> > >> >>> >>>> >>>> > >> >>> >>>> I would like to add a task in the gradle >>>> > "migration" >>>> > >> >>> process: >>>> > >> >>> simplify >>>> > >> >>> >>>> the gradle structure and files, and document >>>> > this. >>>> > >> >>> >>>> >>>> > >> >>> >>>> I know we already have a Jira about the >>>> > documentation part, >>>> > >> >>> but I would >>>> > >> >>> >>>> like to "polish" and use a clean structure for >>>> > the >>>> > Gradle >>>> > >> >>> resources. As >>>> > >> >>> >>>> already quickly discussed, I think that having >>>> > one >>>> > gradle >>>> > >> >>> file >>>> > >> >>> per tasks >>>> > >> >>> >>>> in the .gradle directory would be helpful. >>>> > >> >>> >>>> >>>> > >> >>> >>>> The goal is really to simplify the contribution. >>>> > >> >>> >>>> >>>> > >> >>> >>>> Do you agree if I add a Jira about "Gradle >>>> > polish" ? >>>> > >> >>> >>>> Thoughts ? >>>> > >> >>> >>>> >>>> > >> >>> >>>> Regards >>>> > >> >>> >>>> JB >>>> > >> >>> >>>> >>>> > >> >>> >>>> On 07/04/2018 04:52, Scott Wegner wrote: >>>> > >> >>> >>>> >>>> > >> >>> >>>> Here's an end-of-day update on migration work: >>>> > >> >>> >>>> >>>> > >> >>> >>>> * Snapshot unsigned dailies and signed release >>>> > builds are >>>> > >> >>> working (!!). >>>> > >> >>> >>>> PR/5048 [1] merges changes from Luke's branch >>>> > >> >>> >>>> * python precommit failing... will >>>> > investigate >>>> > python >>>> > >> >>> precommit >>>> > >> >>> >>>> Monday >>>> > >> >>> >>>> * All Precommits are gradle only >>>> > >> >>> >>>> * All Postcommits except performance tests and >>>> > >> >>> Java_JDK_Versions_Test >>>> > >> >>> >>>> use gradle (after PR/5047 [2] merged) >>>> > >> >>> >>>> * Nightly snapshot release using gradle is >>>> > ready; >>>> > needs >>>> > >> >>> PR/5048 to be >>>> > >> >>> >>>> merged before switching >>>> > >> >>> >>>> * ValidatesRunner_Spark failing consistently; >>>> > investigating >>>> > >> >>> >>>> >>>> > >> >>> >>>> Thanks for another productive day of hacking. >>>> > I'll >>>> > pick up >>>> > >> >>> again on >>>> > >> >>> >>>> Monday. >>>> > >> >>> >>>> >>>> > >> >>> >>>> [1] https://github.com/apache/beam/pull/5048 >>>> > >> >>> >>>> [2] https://github.com/apache/beam/pull/5047 >>>> > >> >>> >>>> >>>> > >> >>> >>>> >>>> > >> >>> >>>> On Fri, Apr 6, 2018 at 11:24 AM Romain >>>> > Manni-Bucau >>>> > >> >>> >>>> <rmannibu...@gmail.com >>>> > <mailto:rmannibu...@gmail.com> <mailto:rmannibu...@gmail.com >>>> > <mailto:rmannibu...@gmail.com>> >>>> > >> >>> <mailto:rmannibu...@gmail.com >>>> > <mailto:rmannibu...@gmail.com> <mailto:rmannibu...@gmail.com >>>> > <mailto:rmannibu...@gmail.com>>>> >>>> > >> >>> wrote: >>>> > >> >>> >>>> >>>> > >> >>> >>>> Why building a zip per runner which its >>>> > stack >>>> > and just >>>> > >> >>> pointing out >>>> > >> >>> >>>> on that zip and let beam lazy load the >>>> > runner: >>>> > >> >>> >>>> >>>> > >> >>> >>>> --runner=LazyRunner --lazyRunnerDir=... >>>> > >> >>> --lazyRunnerOptions=... (or >>>> > >> >>> >>>> the fromSystemProperties() if it gets >>>> > merged >>>> > a day ;)) >>>> > >> >>> >>>> >>>> > >> >>> >>>> Le 6 avr. 2018 20:21, "Kenneth Knowles" >>>> > <k...@google.com <mailto:k...@google.com> >>>> > >> >>> <mailto:k...@google.com <mailto:k...@google.com>> >>>> > >> >>> >>>> <mailto:k...@google.com >>>> > <mailto:k...@google.com> <mailto:k...@google.com >>>> > <mailto:k...@google.com>>>> a >>>> > >> >>> écrit : >>>> > >> >>> >>>> >>>> > >> >>> >>>> I'm working on finding a solution for >>>> > launching the >>>> > >> >>> Nexmark >>>> > >> >>> >>>> suite with each runner. This doesn't >>>> > have >>>> > to be >>>> > >> >>> done >>>> > >> >>> via Gradle, >>>> > >> >>> >>>> but we anyhow need built artifacts that >>>> > don't >>>> > >> >>> require >>>> > >> >>> user >>>> > >> >>> >>>> classpath intervention. >>>> > >> >>> >>>> >>>> > >> >>> >>>> It looks to me like the examples are >>>> > also >>>> > missing >>>> > >> >>> this - they >>>> > >> >>> >>>> have separate configuration e.g. >>>> > >> >>> sparkRunnerPreCommit >>>> > >> >>> but that >>>> > >> >>> >>>> is overspecified compared to a >>>> > free-form >>>> > launching >>>> > >> >>> of >>>> > >> >>> a main() >>>> > >> >>> >>>> program with a runner profile. >>>> > >> >>> >>>> >>>> > >> >>> >>>> On Fri, Apr 6, 2018 at 11:09 AM Lukasz >>>> > Cwik >>>> > >> >>> <lc...@google.com <mailto:lc...@google.com> >>>> > <mailto:lc...@google.com <mailto:lc...@google.com>> >>>> > >> >>> >>>> <mailto:lc...@google.com >>>> > <mailto:lc...@google.com> >>>> > >> >>> <mailto:lc...@google.com <mailto:lc...@google.com>>>> >>>> > >> >>> wrote: >>>> > >> >>> >>>> >>>> > >> >>> >>>> Romain, are you talking about the >>>> > profiles that >>>> > >> >>> exist as >>>> > >> >>> >>>> part of the archetype examples? >>>> > >> >>> >>>> >>>> > >> >>> >>>> If so, then those still exist and >>>> > haven't been >>>> > >> >>> changed. If >>>> > >> >>> >>>> not, can you provide a link to the >>>> > profile in a >>>> > >> >>> pom file to >>>> > >> >>> >>>> be clearer? >>>> > >> >>> >>>> >>>> > >> >>> >>>> On Fri, Apr 6, 2018 at 12:40 PM >>>> > Romain >>>> > >> >>> Manni-Bucau >>>> > >> >>> >>>> <rmannibu...@gmail.com >>>> > <mailto:rmannibu...@gmail.com> >>>> > >> >>> <mailto:rmannibu...@gmail.com >>>> > <mailto:rmannibu...@gmail.com>> <mailto:rmannibu...@gmail.com >>>> > <mailto:rmannibu...@gmail.com> >>>> > >> >>> <mailto:rmannibu...@gmail.com >>>> > <mailto:rmannibu...@gmail.com>>>> >>>> > >> >>> >>>> wrote: >>>> > >> >>> >>>> >>>> > >> >>> >>>> Hi Scott, >>>> > >> >>> >>>> >>>> > >> >>> >>>> is it right that 2 doesn't >>>> > handle the >>>> > >> >>> hierachy anymore >>>> > >> >>> >>>> and that it doesn't handle >>>> > profiles for >>>> > >> >>> runners as it is >>>> > >> >>> >>>> currently with maven? >>>> > >> >>> >>>> >>>> > >> >>> >>>> >>>> > >> >>> >>>> Romain Manni-Bucau >>>> > >> >>> >>>> @rmannibucau >>>> > >> >>> <https://twitter.com/rmannibucau> | Blog >>>> > >> >>> >>>> >>>> > <https://rmannibucau.metawerx.net/> | Old >>>> > >> >>> Blog >>>> > >> >>> >>>> >>>> > <http://rmannibucau.wordpress.com> | Github >>>> > >> >>> >>>> >>>> > <https://github.com/rmannibucau> >>>> > | LinkedIn >>>> > >> >>> >>>> >>>> > <https://www.linkedin.com/in/rmannibucau> | >>>> > >> >>> Book >>>> > >> >>> >>>> >>>> > >> >>> >>>> >>>> > >> >>> >>>> >>>> > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> > >>>> > <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>>> > >> >>> >>>> >>>> > >> >>> >>>> 2018-04-06 18:32 GMT+02:00 >>>> > Scott >>>> > Wegner >>>> > >> >>> >>>> <sweg...@google.com >>>> > <mailto:sweg...@google.com> >>>> > >> >>> <mailto:sweg...@google.com >>>> > <mailto:sweg...@google.com>> >>>> > <mailto:sweg...@google.com <mailto:sweg...@google.com> >>>> > >> >>> >>>> > >> >>> <mailto:sweg...@google.com >>>> > <mailto:sweg...@google.com>>>>: >>>> > >> >>> >>>> >>>> > >> >>> >>>> I wanted to start a thread >>>> > to >>>> > summarize >>>> > >> >>> the current >>>> > >> >>> >>>> state of Gradle migration. >>>> > We've made >>>> > >> >>> lots of good >>>> > >> >>> >>>> progress so far this week. >>>> > Here's the >>>> > >> >>> status from >>>> > >> >>> >>>> what I can tell-- please >>>> > add >>>> > or correct >>>> > >> >>> anything I >>>> > >> >>> >>>> missed: >>>> > >> >>> >>>> >>>> > >> >>> >>>> * Release artifacts can be >>>> > built and >>>> > >> >>> published for >>>> > >> >>> >>>> Snapshot and officlal >>>> > releases [1] >>>> > >> >>> >>>> * Gradle-generated releases >>>> > have been >>>> > >> >>> validated with >>>> > >> >>> >>>> the the Apache Beam >>>> > archetype >>>> > >> >>> generation >>>> > >> >>> quickstart; >>>> > >> >>> >>>> still needs additional >>>> > validation. >>>> > >> >>> >>>> * Generated release pom >>>> > files >>>> > have >>>> > >> >>> correct project >>>> > >> >>> >>>> metadata [2] >>>> > >> >>> >>>> * The python pre-commits >>>> > are now >>>> > >> >>> working >>>> > >> >>> in Gradle >>>> > >> >>> >>>> [3] >>>> > >> >>> >>>> * Ismaël has started a >>>> > collaborative >>>> > >> >>> doc >>>> > >> >>> of Gradle >>>> > >> >>> >>>> tips [4] as we all learn >>>> > the new >>>> > >> >>> system-- >>>> > >> >>> please add >>>> > >> >>> >>>> your own. This will >>>> > eventually feed >>>> > >> >>> into >>>> > >> >>> official >>>> > >> >>> >>>> documentation on the >>>> > website. >>>> > >> >>> >>>> * Łukasz Gajowy is working >>>> > on >>>> > migrating >>>> > >> >>> performance >>>> > >> >>> >>>> testing framework [5] >>>> > >> >>> >>>> * Daniel is working on >>>> > updating >>>> > >> >>> documentation to >>>> > >> >>> >>>> refer to Gradle instead of >>>> > maven >>>> > >> >>> >>>> >>>> > >> >>> >>>> If I missed anything, >>>> > please >>>> > add it to >>>> > >> >>> this thread. >>>> > >> >>> >>>> >>>> > >> >>> >>>> The general roadmap we're >>>> > working >>>> > >> >>> towards >>>> > >> >>> is: >>>> > >> >>> >>>> (a) Publish release >>>> > artifacts >>>> > with >>>> > >> >>> Gradle >>>> > >> >>> (SNAPSHOT >>>> > >> >>> >>>> and signed releases) >>>> > >> >>> >>>> (b) Postcommits migrated to >>>> > Gradle >>>> > >> >>> >>>> (c) Migrate documentation >>>> > from maven to >>>> > >> >>> Gradle >>>> > >> >>> >>>> (d) Migrate perfkit suites >>>> > to use >>>> > >> >>> Gradle >>>> > >> >>> >>>> >>>> > >> >>> >>>> For those of you that are >>>> > hacking: >>>> > >> >>> thanks >>>> > >> >>> for your >>>> > >> >>> >>>> help so far! Progress is >>>> > being roughly >>>> > >> >>> tracked on >>>> > >> >>> >>>> the Kanban [6]; please make >>>> > sure the >>>> > >> >>> issues assigned >>>> > >> >>> >>>> to you are up-to-date. Many >>>> > of the >>>> > >> >>> changes are >>>> > >> >>> >>>> staged on lukecwik's local >>>> > branch [7]; >>>> > >> >>> we'll work on >>>> > >> >>> >>>> merging them back soon. >>>> > >> >>> >>>> >>>> > >> >>> >>>> >>>> > >> >>> >>>> [1] >>>> > >> >>> >>>> >>>> > https://github.com/lukecwik/incubator-beam/pull/7 >>>> > >> >>> >>>> [2] >>>> > >> >>> >>>> >>>> > https://github.com/lukecwik/incubator-beam/pull/3 >>>> > >> >>> >>>> [3] >>>> > >> >>> https://github.com/apache/beam/pull/5032 >>>> > >> >>> >>>> [4] >>>> > >> >>> >>>> >>>> > >> >>> >>>> >>>> > >> >>> >>>> >>>> > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> > >>>> > https://docs.google.com/document/d/1wR56Jef3XIPwj4DFzQKznuGPM3JDfRDVkxzeDlbdVSQ/edit >>>> > >> >>> >>>> [5] >>>> > >> >>> https://github.com/apache/beam/pull/5003 >>>> > >> >>> >>>> [6] >>>> > >> >>> >>>> >>>> > >> >>> >>>> >>>> > >> >>> >>>> > >> >>> >>>> > >>>> > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=242 >>>> > >> >>> >>>> >>>> > >> >>> >>>> [7] >>>> > >> >>> >>>> >>>> > >> >>> >>>> >>>> > https://github.com/lukecwik/incubator-beam/tree/gradle >>>> > >> >>> >>>> -- >>>> > >> >>> >>>> >>>> > >> >>> >>>> >>>> > >> >>> >>>> Got feedback? >>>> > >> >>> http://go/swegner-feedback >>>> > >> >>> >>>> >>>> > >> >>> >>>> >>>> > >> >>> >>>> > >> >> >>>> > > >
