Page History

...

How do I configure SLF4J?

To configure SLF$J SLF4J in Gradle project:

1. Add a log4j-test.properties under the directory of the java test.

2. Add the following snippets into your build.gradle file.

   
   

   Code Block
   test { systemProperty "log4j.configuration", "log4j-test.properties" } dependencies { shadow library.java.slf4j_api shadow library.java.slf4j_log4j12log4j14 // or shadow library.java.slf4j_jdk14jdk12 }

   Note: as of Beam 2.53.0, Beam does not support slf4j 2.x. Make sure your slf4j dependencies are of version 1.x

3. The second dependency shadow library.java.slf4j_log4j12log4j14 is not necessary if another library already provides this dependency.

4. Check the dependency included in the dependency tree, execute:
   

   Code Block
   ./gradlew dependencies.

   
   

5. Check If you encounter an error message like the following.
   

   Panel
   borderStyle dashed
   SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation

   
   

   1. If so, it means there is no SLF4J.Add  library.java.slf4j_log4j12 or library.java.slf4j_jdk14 in the  build.gradle file.

To configure SLF4J in Maven project

1. Configure the dependency in pom.xml:

   Code Block

   <properties> <slf4j.version>1.7.30</slf4j.version> </properties> <dependencies> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>${slf4j.version}</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-jdk14</artifactId> <version>${slf4j.version}</version> <!-- When loaded at runtime this will wire up slf4j to the JUL backend --> <scope>runtime</scope> </dependency> <dependencies>

   
   

How to format code automatically and avoid spotless errors?

...

How to run a single test?

...

• Example command (run from beam root):

  Code Block
  ./gradlew :examples:java:test --tests org.apache.beam.examples.subprocess.ExampleEchoPipelineTest --info

  
  

• To break that line down a bit:

  • ./gradlew
    • the Gradle wrapper that runs your code. It lives in the beam root, so wherever you run your command from, this path needs to point there.
  • :examples:java:test 
    • Everything before the last colon is the path from the project root to the root of the subproject the test is in (this directory will contain a build.gradle file)
    • The last word after the colon will always be test because it isn't a directory name, but the name of the Gradle task you're asking the wrapper to perform
  • --tests 
    • this is the option that lets you declare which specific test(s) (or test suite(s)) to run, typically using their path(s) from the src/test/java folder of the subproject
  • --info (optional)
    • sets the log level to info
• For more information see the documentation below on:
  • Gradle CLI
  • Java test filtering

How to run Java Dataflow Hello World pipeline with compiled Dataflow Java worker.

...

A workaround that did the trick. Since many things were tried in the process and no clear way to reproduce the error, this might not be the correct or best step. Update steps if you find a shorter or cleaner way to do the trick.

1. Refresh tradle gradle project in IntelliJ.

2. Close Intellij.

3. Clean build project from the console. Execute>
   
   

   Code Block
   ./gradlew clean cleanTest build -x testWebsite -x :rat -x test

   
   

4. Open IntelliJ.

Build errors due to inconsistent Gradle cache

Sometimes build fails even for the main (master) branch either using IntelliJ or command line. If it worked before but now consistently failing, most likely this is due to inconsistent Gradle cache. It could happen when switching branches back and forth. Run the build Gradle command line with "--rerun-tasks" would do the trick.

What command should I run locally before creating a pull request?

...