Romain, I haven't seen that error. At the very top of your test execution log it gives you the tasks that it is running, for example: 6:41:33 AM: Executing tasks ':beam-sdks-java-core:cleanTest :beam-sdks-java-core:test --tests "org.apache.beam.sdk.coders.AvroCoderTest.testAvroCoderEncoding"'...
What task did it fail for you for? On Tue, Apr 10, 2018 at 9:21 AM Romain Manni-Bucau <[email protected]> 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]>: > > 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]> > > 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]>: > >> > 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]>> 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]>> 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]>> 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]>> > >> > 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]>>: > >> > > >> > 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 > >> > > >> > >
