What dependencies are really required for Automaton

[AlexanderZobkov]

In the documentation, it's mentioned that groovy is required to present in classpath. However, Automaton POM file includes quite a list of dependencies (groovy + sl4j + junit + empus-fugit + harmcrest) with runtime scope.

Official Maven documentation states the following for runtime scope:

runtime - this scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.

It means that dependencies with scope runtime are required to be present in runtime classpath for proper functioning of an artifact.

Could you please clarify what is realy needed to use Automaton? Does it really requires junit, harmcrest and empus-fugit to run, for example when using Automaton in JavaAgent mode?

[renatoathaydes]

Hi!

My dependencies declarations can be found in the build.gradle file:

https://github.com/renatoathaydes/Automaton/blob/master/build.gradle

The reason all libraries are marked with scope runtime is that the Gradle's Maven plugin, which I use to build Automaton, does that when creating the pom. Not sure why.

The required dependencies are the following:

• groovy (2.1+)
• slf4j-api (1.7.5)
• junit (4.11)
• hamcrest-library (1.3)

I intentionally removed groovy from the dependencies declared in the pom because adding it causes the Groovy version the user already has to be potentially changed, which can cause havoc. But I hope it's obvious in the README page you must add it.

slf4j-api was only introduced in the latest version to replace JUL. Use an older version if you need to avoid it.

junit and hamcrest-library are necessary because of the support for assertions in Automaton. You may be able to run without them but I do not recommend that.

tempus-fugit should not be part of the dependencies (it should be a test-only dependency of Automaton). I will try to fix for the next version.

slf4j-log4j12 + log4j is mistakenly added to the list of dependencies (I didn't expect runtime Gradle dependencies would be added to the pom, I should've used the same Gradle hack I used to remove groovy). It should be just the logger implementation provided by you at runtime (to make slf4j-api work)...

So, here's the generated pom, marked with comments where it's wrong:

<dependencies>
    <dependency>
      <!-- Should be excluded... and should be <provided> in the Gradle declaration -->
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-log4j12</artifactId>
      <version>1.7.5</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <!-- Should be excluded... and should be <provided> in the Gradle declaration -->
      <groupId>log4j</groupId>
      <artifactId>log4j</artifactId>
      <version>1.2.14</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
      <version>1.7.5</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupId>org.hamcrest</groupId>
      <artifactId>hamcrest-library</artifactId>
      <version>1.3</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <!-- Should be excluded... and should be scope=test in the Gradle declaration -->
      <groupId>com.google.code.tempus-fugit</groupId>
      <artifactId>tempus-fugit</artifactId>
      <version>1.1</version>
      <scope>runtime</scope>
    </dependency>
  </dependencies>

Thank you for raising the problem, I will fix this ASAP and make a new minor release soon (few days max).

[renatoathaydes]

By the way, if you don't want to worry about dependencies at all, try using the all-deps jar, which includes all dependencies in it.

[renatoathaydes]

Fixed in https://github.com/renatoathaydes/Automaton/commit/2d347d22ea8f11c3608cd05ebcd8d656ac8b810a

[renatoathaydes]

Version 1.3.2-beta released with a improved pom. I generated this with the old Gradle maven plugin, which creates a proper pom... but unfortunately, the pom.xml is not being correctly enriched with the extra metadata needed for publication on Maven Central, so I might have to use the maven-publish plugin again and try to workaround the problem in some other way...

[renatoathaydes]

Here's the new pom in Maven Central.

I used the old maven Gradle plugin which actually generates a proper pom, unlike maven-publish which makes a mess of a pom.

It was a lot of trouble to get a good pom that Maven Central accepts AND publish with Bintray (which uses maven-publish in the tutorials, unfortunately)... but finally it's working now...