@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" <[email protected]> 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é <[email protected]> > 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 >> > <[email protected] <mailto:[email protected]>> 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 <[email protected] >> > <mailto:[email protected]>>: >> > > 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 >> > <[email protected] <mailto:[email protected]>> >> > > 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 >> > <[email protected] <mailto:[email protected]>>: >> > >> > 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é >> > <[email protected] <mailto:[email protected]>>: >> > >> >> 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é >> > <[email protected] <mailto:[email protected]> >> > >> >>> <mailto:[email protected] <mailto:[email protected]>>> 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 >> > <[email protected] <mailto:[email protected]> >> > >> >>> <mailto:[email protected] <mailto:[email protected]>>>: >> > >> >>> >> 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 >> > >> >>> <[email protected] <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>>> >> > >> >>> >> 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 >> > >> >>> <[email protected] <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>>>: >> > >> >>> >> > >> >>> >>>> 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 >> > >> >>> >>>> <[email protected] >> > <mailto:[email protected]> <mailto:[email protected] >> > <mailto:[email protected]>> >> > >> >>> <mailto:[email protected] >> > <mailto:[email protected]> <mailto:[email protected] >> > <mailto:[email protected]>>>> >> > >> >>> 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" >> > <[email protected] <mailto:[email protected]> >> > >> >>> <mailto:[email protected] <mailto:[email protected]>> >> > >> >>> >>>> <mailto:[email protected] >> > <mailto:[email protected]> <mailto:[email protected] >> > <mailto:[email protected]>>>> 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 >> > >> >>> <[email protected] <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>> >> > >> >>> >>>> <mailto:[email protected] >> > <mailto:[email protected]> >> > >> >>> <mailto:[email protected] <mailto:[email protected]>>>> >> > >> >>> 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 >> > >> >>> >>>> <[email protected] >> > <mailto:[email protected]> >> > >> >>> <mailto:[email protected] >> > <mailto:[email protected]>> <mailto:[email protected] >> > <mailto:[email protected]> >> > >> >>> <mailto:[email protected] >> > <mailto:[email protected]>>>> >> > >> >>> >>>> 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 >> > >> >>> >>>> <[email protected] >> > <mailto:[email protected]> >> > >> >>> <mailto:[email protected] <mailto:[email protected]>> >> > <mailto:[email protected] <mailto:[email protected]> >> > >> >>> >> > >> >>> <mailto:[email protected] <mailto:[email protected] >> >>>>: >> > >> >>> >>>> >> > >> >>> >>>> 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/1wR56Jef3XIPwj4DFzQKznuGPM3JDf >> RDVkxzeDlbdVSQ/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 >> > >> >>> >>>> >> > >> >>> >>>> >> > >> >>> >> > >> >> >> > >> >
