Running a Specific Test

Does anyone know the Maven way to run a specific unit test with Beam? I've tried: mvn -Dtest=org.apache.beam.sdk.transforms.RegexTest -DfailIfNoTests=false -Dgroups="org.apache.beam.sdk.testing.NeedsRunner" -pl org.apache.beam:beam-sdks-java-core test The test still doesn't run. Does anyone know

Re: Running a Specific Test

P.S You can also do this from the main directory (without cd-ing into the direct-runner): "mvn test -Dtest=RegexTest -DdependenciesToScan=org.apache.beam:beam-sdks-java-core -pl runners/direct-java" On Thu, Dec 29, 2016 at 8:50 PM Stas Levin wrote: > Once you "cd" into

Re: Running a Specific Test

Hi Jesse Mvn test -Dtest=RegexTest Should work Don't forget the test goal. And no need to provide the fqcn. Regards JB⁣​ On Dec 29, 2016, 18:55, at 18:55, Jesse Anderson wrote: >Does anyone know the Maven way to run a specific unit test with Beam? >I've >tried: >mvn

Re: Running a Specific Test

Once you "cd" into "runners/direct-java" you can use: "mvn test -Dtest=RegexTest -DdependenciesToScan=org.apache.beam:beam-sdks-java-core" -Stas On Thu, Dec 29, 2016 at 8:27 PM Jesse Anderson wrote: > I tried that one already. It gives a no tests run error. If you

Re: Running a Specific Test

I believe you raise a good point :) On Thu, Dec 29, 2016 at 9:00 PM Dan Halperin wrote: > I suspect -- but may be wrong -- that the command line Stas gives will use > the *installed* version of beam-sdks-java-core. If you are iterating on a > @NeedsRunner test in

Re: [DISCUSS] Graduation to a top-level project

A quick update: the Apache Infra process, tracked in INFRA-13177 [1], should now be complete. As far as I see, everything should be operational -- please reply back if you encounter something unexpected. The announcement is still planned for the second week in January. Davor [1]

Re: Running a Specific Test

If you'd like early eyes on the blog post, let us know. Happy to review! One thing worth noting: we've tried to structure Beam so that the pain is mostly limited to the core. Many modules have module-specific unit tests that use DirectRunner directly. The module simply has a test dependency on

Re: PCollection to PCollection Conversion

I agree MapElements isn't hard to use. I think there is a demand for this built-in conversion. My thought on the formatter is that, worst case, we could do runtime type checking. It would be ugly and not as performant, but it should work. As we've said, we'd point them to MapElements for better

Re: Build failed in Jenkins: beam_PostCommit_Java_RunnableOnService_Spark #574

Manual build by me in release testing -- I entered the wrong tag. Please ignore. On Thu, Dec 29, 2016 at 2:30 PM, Apache Jenkins Server < jenk...@builds.apache.org> wrote: > See RunnableOnService_Spark/574/> > >

Re: PCollection to PCollection Conversion

I like that idea, with the caveat that we should probably come up with a better name. Perhaps "ToString.elements()" and ToString.Elements or something? Calling one the "default" and using "create" for it seems moderately non-future proof. On Thu, Dec 29, 2016 at 3:17 PM Dan Halperin

Re: PCollection to PCollection Conversion

On Thu, Dec 29, 2016 at 1:36 PM, Jesse Anderson wrote: > I prefer JB's take. I think there should be three overloaded methods on the > class. I like Vikas' name ToString. The methods for a simple conversion > should be: > > ToString.strings() - Outputs the .toString() of

Re: PCollection to PCollection Conversion

On Thu, Dec 29, 2016 at 2:10 PM, Jesse Anderson wrote: > I agree MapElements isn't hard to use. I think there is a demand for this > built-in conversion. > > My thought on the formatter is that, worst case, we could do runtime type > checking. It would be ugly and not as

Re: PCollection to PCollection Conversion

+1 to Dan's point that MapElements.via is not that hard to use and going too far down this path leads to significant complexity. Pipelines should generally prefer to deal with structured data as much as possible. As has been discussed on this thread, though, sometimes it is necessary to convert

Re: [VOTE] Release 0.4.0, release candidate #1

* mvn verify passes with and without network enabled * mvn apache-ret:check passes * mvn verify passes with -Prelease * release signature properly signed by JB (using the KEYS file as the keyring) * No binary files [one false positive empty file in ./runners/core-java/src/test/java/.placeholder we

Re: PCollection to PCollection Conversion

Sounds good to me too. @vikas can you start modifying the PR's code: Clean up the PR to be more future-proof for now? Aka make `ToString` itself not a PTransform, but instead ToString.create() returns ToString.Default which is a private class implementing what ToString is now (PTransform

Re: PCollection to PCollection Conversion

Dan's proposal to move forward with a simple (future-proofed) version of the ToString transform and Javadoc, and add specific features via follow-up PRs. On Thu, Dec 29, 2016 at 3:53 PM Jesse Anderson wrote: > @Ben which idea do you like? > > On Thu, Dec 29, 2016 at 3:20

Re: PCollection to PCollection Conversion

@Ben which idea do you like? On Thu, Dec 29, 2016 at 3:20 PM Ben Chambers wrote: > I like that idea, with the caveat that we should probably come up with a > better name. Perhaps "ToString.elements()" and ToString.Elements or > something? Calling one the "default"