ShrinkWrap Resolver 3.0.0-alpha-2 Released

Since we wrote this post we didn't laze around. Check our latest announcement.

The Arquillian team is proud to announce the 3.0.0-alpha-2 release of the ShrinkWrap Resolver component!

You probably know the cases when you have to build a project before running another one or before running tests to use a created archive. Maven Importer provided by ShrinkWrap Resolver can partially help you with it – it compiles the classes and collects dependencies from the pom.xml file. However, you cannot use Maven plugins, profiles or some variables as it doesn’t do the real Maven build – it just tries to simulate it. You can definitely imagine a situation that you don’t have any Maven binary installed in your local repository or that you need different Maven version for one specific build. That’s why ShrinkWrap Resolver introduces a new feature: Embedded Maven.

Embedded Maven

Embedded Maven provides you a possibility to invoke a Maven build for a selected project directly from your Java code. Internally, it uses maven-invoker and mainly the classes Invoker and InvocationRequest, which basically offers the functionality of running Maven builds directly from the Java code.
So now there can arise some questions: Why should I use Embedded Maven? What are the benefits?
There are bunch of functions added to make the usage more user friendly. The most significant additional functions are:

  • downloading and using Maven binaries that the user desires
  • uncluttered API (you can write code that runs either trivial or complex builds in one single line)
  • additional methods & functions (eg. ignoring build failures or making the build output quiet)
  • Java class representing a built project
  • easy way of getting a ShrinkWrap Archive created by the build, so you can further enrich it if needed
  • automatic functions such as skipping tests and formatting a build output
  • possibility to use one’s Invoker and InvocationRequest instances
  • and more …

How can I use it?

Your starting point is a class EmbeddedMaven which offers you three methods. At this point you have to decide which approach of setting Maven build options you want to follow.

1) ShrinkWrap Resolver API

Recommended
You can use ShrinkWrap Resolver API that offers additional features in more comfortable but slightly limited way. This approach is linked with these two methods:

EmbeddedMaven.forProject(File pomFile)
EmbeddedMaven.forProject(String pomFile)
where you have to specify a POM file of a project you want to build.

Why it is limited? Contrary to second approach or to the pure maven-invoker:

  • you cannot set neither output handler nor error handler because it is already set by ShrinkWrap Resolver. On the other hand, it has three positive effects:
    I) the output is automatically formatted (with a prefix -> to make the output visibly separated)
    II) after the completion, the build output is accessible using method BuiltProject#getMavenLog
    III) you can easily suppress the build output using method ConfigurationStage#setQuiet
  • you cannot set a project you want to build by setting base directory and a file name separately.
  • there are no methods for setting Maven home and binaries, because it is set by ShrinkWrap Resolver itself.

2) Using your own Maven Invoker

With the second approach, you can use your own Invoker and InvocationRequest instances. If you use it, then it is expected that all settings are done by yourself so no automatic features are provided by ShrinkWrap Resolver. This approach is linked with the method:

EmbeddedMaven.withMavenInvokerSet(InvocationRequest request, Invoker invoker)

Why it is less comfortable? You can see the differences in these two test cases that does completely the same thing but using different approaches: first approach second approach
These are the disadvantages:

  • methods such as setGoals and setProfiles accept only a list of string.
  • you have to set the property skipTests for each InvocationRequest if you don’t want to run the tests.
  • you don’t have an access to the Maven build output after the build completion
  • the build output is not automatically formatted and it cannot be easily suppressed
  • the methods for setting Maven home or binaries are accessible in Invoker object, but it is advised not to use them as the Maven home is used by ShrinkWrap Resolver

Downloading Maven binaries

In case when there is no Maven binaries installed on the machine or when another Maven version is needed for some specific build, you can ask ShrinkWrap Resolver to download the specific version from the Apache web pages and use it. For this purpose there is a method:

EmbeddedMaven.forProject("path/to/pom.xml").useMaven3Version(String version)

where the desired version is expected (eg: useMaven3Version("3.3.9")). This version is downloaded from Apache web pages and the downloaded zip is cached in a directory $HOME/.arquillian/resolver/maven/ to not download it over and over again. Zip file is extracted in
${project.directory}/target/resolver-maven/${generated_UUID}
and the path to the extracted binaries is set as Maven home applicable for the build.

There are three more methods for setting Maven binaries that should be used for the build.

EmbeddedMaven.forProject("path/to/pom.xml").useDistribution(URL mavenDist, boolean useCache)

where you need to specify a URL the distribution should be downloaded from. You should also specify if the cache directory should be used. If useCache is false, then the zip file is downloaded into ${project.directory}/target/resolver-maven/downloaded.

Next method

EmbeddedMaven.forProject("path/to/pom.xml").useInstallation(File mavenHome)

uses Maven installation located on the given path.

Last method:

EmbeddedMaven.forProject("path/to/pom.xml").useDefaultDistribution()

basically does nothing. It just says that the default Maven installation that is on your PATH should be used. It is same as you wouldn’t use any of these methods.

Explanation of additional features:

Skipping tests
Using ShrinkWrap Resolver API approach, there is no need to set the skipTests property if you don’t want to run any test as it is set automatically. If you still want to run tests, then you can use method: ConfigurationStage#skipTests

Ignoring failures
If the Maven build fails, then an IllegalStateException is thrown by default. If you use method BuildStage#ignoreFailure, then failures of the Maven build is ignored and a BuiltProject instance with a non-zero value stored in mavenBuildExitCode variable is returned.

BuiltProject

BuiltProject is a Java class that represents a built project. An instance of this class is returned by the method build() when the Maven build is completed. The most useful method is probably:

builtProject.getDefaultBuiltArchive()

that returns an archive with a default name that was created by the Maven build. As a “default archive name” is understood:

  • either combination of artifactId + version + packaging suffix (eg.
  • or a finalName set in <build> section of project’s POM file + packaging suffix

if no archive with a corresponding name is found, then null is returned. null is also returned for the projects with packaging=pom as it is usually a parent project with a set of modules. To get all modules that are specified use the method:

builtProject.getModules()

which returns list of BuiltProject instances. If you know the name (string within an element <module> in the parent’s POM file) of a module you are interested in, you can use:

builtProject.getModule(String moduleName)

There are several other useful methods provided by this Java class. For more information see BuiltProject

Examples

First example is just packaging a project and getting the default archive out of it:

EmbeddedMaven.forProject("some/pom.xml").setGoals("package").build().getDefaultBuiltArchive();

Then let’s say that we want to build some project using goals clean and package and with activated profile production:
BuiltProject builtProject = EmbeddedMaven.forProject("path/to/pom.xml")
.setGoals("clean", "package")
.setProfiles("production")
.build();

Then you can get the default archive:

 Archive archive = builtProject.getDefaultBuiltArchive();

or all Java archives, that are contained in the build directory:

 List javaArchives = builtProject.getArchives(JavaArchive.class);


Let’s say that we want to use Maven 3.1.0 for building a project with a goal install and property wildfly=true. We also don’t want to display the build output and we want to ignore all possible build failures:

EmbeddedMaven.forProject("path/to/pom.xml")
.useMaven3Version("3.1.0")
.setGoals("install")
.addProperty("wildfly", "true")
.setQuiet()
.ignoreFailure()
.build();

Some additional examples can be found in integration tests here and here.

What is ShrinkWrap Resolver?

The ShrinkWrap Resolvers project provides a Java API to obtain artifacts from a repository system. This is handy to include third party libraries available in any Maven repository in your test archive. ShrinkWrap Resolvers additionally allow you to reuse all the configuration you've already specified in the Maven build file, making packaging of an application archive much easier job.

Release details

Component ShrinkWrap Resolver
Version 3.0.0-alpha-2 view tag
Release date 2016-11-30
Released by Matous Jobanek
Compiled against
  • JUnit – 4.12

Published artifacts org.jboss.shrinkwrap.resolver

  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-bom pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-api jar javadoc pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-spi jar javadoc pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-depchain pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-api-maven jar javadoc pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-impl-maven jar javadoc pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-api-maven-archive jar javadoc pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-spi-maven jar javadoc pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-spi-maven-archive jar javadoc pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-impl-maven-archive jar javadoc pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-api-maven-embedded jar javadoc pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-impl-maven-embedded jar javadoc pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-api-gradle-embedded-archive jar javadoc pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-gradle-depchain pom
  • org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-impl-gradle-embedded-archive jar javadoc pom

Release notes and resolved issues 5

Feature Request
Bug
  • SHRINKRES-238 - Maven resolver always throws at with(out)Transitivity
  • SHRINKRES-239 - maven version incompatibility? Caused by: java.lang.AbstractMethodError \tat org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:899)
  • SHRINKRES-241 - Wrong maven-aether-provider dependency for some reason

Thanks to the following list of contributors: Matous Jobanek, Andrew Lee Rubinger, Michal Matloka, George Gastaldi

Arquillian Algeron Extension 1.0.0.Alpha4 Released

Since we wrote this post we didn't laze around. Check our latest announcement.

The Arquillian team is proud to announce the 1.0.0.Alpha4 release of the Arquillian Algeron Extension component!

Important note: This extension was called Arquillian Pact before version 1.0.0.Alpha5, so you should use this name when pulling dependencies from Maven Central.

Arquillian Pact is an extension for writing contract-driven tests providing you seamless integration with well known Pact framework.

What’s new

@Pact annotation can be used on the class level

You can use @Pact annotation on the class level, so method that defines a pact fragment just need to return PactFragment object. In case of setting this annotation both on the class and method level, the one defined on the method will take precedence.

Pact Publisher properties configuration

You can configure Pact Publisher properties using Java System properties or Environment variables using Arquillian syntax. Any property value can be set using Java system property ${name:defaultValue} or using environment variable ${env.name:defaultValue}. defaulValue will be used if referred property is not defined.

Bug fixing

Using skipDeployment with WildFly Swarm returns a NPE

Skipping deployment for WildFly Swarm was resulting with NPE. This is because our URL provider was conflicting with the one Swarm implements (#44).

Pact Publisher is not called when used with Gradle

Pact Publisher is not called when used with Gradle due to a bug in Gradle. Since Publisher reacts to AfterSuite and this event is not emitted when running in Gradle, we changed it to AfterClass. This has a slight impact on the performance as publishing pacts happens after each test execution instead of being triggered once in a bulk after the whole test suite execution (#43).

What is Arquillian?

Arquillian is open source software that empowers you to test JVM-based applications more effectively. Created to defend the software galaxy from bugs, Arquillian brings your test to the runtime so you can focus on testing your application's behavior rather than managing the runtime. Using Arquillian, you can develop a comprehensive suite of tests from the convenience of your IDE and run them in any IDE, build tool or continuous integration environment.

Release details

Component Arquillian Algeron Extension
Version 1.0.0.Alpha4 view tag
Release date 2016-11-07
Released by Alex Soto
Compiled against

Published artifacts org.arquillian.pact

  • org.arquillian.pact » arquillian-pact-consumer-api jar javadoc pom
  • org.arquillian.pact » arquillian-pact-consumer-core jar javadoc pom
  • org.arquillian.pact » arquillian-pact-consumer-spi jar javadoc pom
  • org.arquillian.pact » arquillian-pact-consumer-git-publisher jar javadoc pom
  • org.arquillian.pact » arquillian-pact-provider-api jar javadoc pom
  • org.arquillian.pact » arquillian-pact-provider-core jar javadoc pom
  • org.arquillian.pact » arquillian-pact-provider-spi jar javadoc pom
  • org.arquillian.pact » arquillian-pact-provider-pact-broker-loader jar javadoc pom
  • org.arquillian.pact » arquillian-pact-provider-maven-loader jar javadoc pom
  • org.arquillian.pact » arquillian-pact-provider-git-loader jar javadoc pom
  • org.arquillian.pact » arquillian-pact-git jar javadoc pom
  • org.arquillian.pact » arquillian-pact-configuration jar javadoc pom

Release notes and resolved issues 4

Bug

Thanks to the following list of contributors: Alex Soto, Bartosz Majsak

Arquillian Tomcat Container 1.0.0.CR8 Released

Since we wrote this post we didn't laze around. Check our latest announcement.

The Arquillian team is proud to announce the 1.0.0.CR8 release of the Arquillian Tomcat Container component!

What is Arquillian?

Arquillian is open source software that empowers you to test JVM-based applications more effectively. Created to defend the software galaxy from bugs, Arquillian brings your test to the runtime so you can focus on testing your application's behavior rather than managing the runtime. Using Arquillian, you can develop a comprehensive suite of tests from the convenience of your IDE and run them in any IDE, build tool or continuous integration environment.

Release details

Component Arquillian Tomcat Container
Modules
Version 1.0.0.CR8 view tag
Release date 2016-11-11
Released by Matous Jobanek
Compiled against

Published artifacts org.jboss.arquillian.container

  • org.jboss.arquillian.container » arquillian-tomcat-common jar javadoc pom
  • org.jboss.arquillian.container » arquillian-tomcat-embedded-common jar javadoc pom
  • org.jboss.arquillian.container » arquillian-tomcat-embedded-6 jar javadoc pom
  • org.jboss.arquillian.container » arquillian-tomcat-embedded-7 jar javadoc pom
  • org.jboss.arquillian.container » arquillian-tomcat-embedded-8 jar javadoc pom
  • org.jboss.arquillian.container » arquillian-tomcat-managed-common jar javadoc pom
  • org.jboss.arquillian.container » arquillian-tomcat-managed-5.5 jar javadoc pom
  • org.jboss.arquillian.container » arquillian-tomcat-managed-6 jar javadoc pom
  • org.jboss.arquillian.container » arquillian-tomcat-managed-7 jar javadoc pom
  • org.jboss.arquillian.container » arquillian-tomcat-managed-8 jar javadoc pom
  • org.jboss.arquillian.container » arquillian-tomcat-remote-common jar javadoc pom
  • org.jboss.arquillian.container » arquillian-tomcat-remote-6 jar javadoc pom
  • org.jboss.arquillian.container » arquillian-tomcat-remote-7 jar javadoc pom

Release notes and resolved issues 10

Component Upgrade
  • ARQ-2055 - Update Tomcat containers to the latest versions
  • ARQ-2057 - Upgrade test dependencies (Arquillian,ShrinkWrap,Weld) to the latest versions
Feature Request
  • ARQ-600 - Improve Tomcat codebase - Managed
  • ARQ-1847 - Support specifying JMX RMI server port
  • ARQ-1855 - Tomcat 6 Embedded container should support deployment of ROOT.war to the default context
Bug
  • ARQ-1814 - TomcatManagedConfiguration validates catalinaBase too soon
  • ARQ-1965 - Tomcat 7 Adapter rely on ContextHome constructor introduced in 7.0.52
  • ARQ-1983 - tomcat-embedded-8 unpackArchive property doesn't have any effect
  • ARQ-2033 - Managed Tomcat fails to launch on Windows during maven test phase
Task
  • ARQ-2056 - Module tomcat-managed-5.5 cannot be tested on JDK 1.8

Thanks to the following list of contributors: Ian Brandt, Bartosz Majsak, Matous Jobanek, Stephen Coy, Aslak Knutsen, Dave Levitt, Tomas Remes, Dimitrij Drus, Brett Meyer

Arquillian Algeron Extension 1.0.0.Alpha3 Released

Since we wrote this post we didn't laze around. Check our latest announcement.

The Arquillian team is proud to announce the 1.0.0.Alpha3 release of the Arquillian Algeron Extension component!

Important note: This extension was called Arquillian Pact before version 1.0.0.Alpha5, so you should use this name when pulling dependencies from Maven Central.

Arquillian Pact is an extension for writing contract-driven tests which provides integration with Pact framework.

What’s new

Skipping the deployment

In case of consumer driven contracts, there are two kinds of tests – consumer tests and provider tests. Usually in your CI environment you want to run provider tests against two different scenarios:

Against a master branch of provider to detect if provider team has already implemented all the functionalities defined in your contracts.

Against (pre)production. If you support deploying consumer independently of a provider, then you need to ensure that if you deploy new consumer with the new contracts to (pre)production everything will be still working and you haven’t introduced any regressions.

In both cases, the test itself is exactly the same. There is only one slight difference in both cases which how you set up your test environments. In the first scenario, you want to deploy the latest provider code. One way of doing it is using Arquillian container control and @Deployment method to create the package, start the container and deploy it. But in the latter case, when you want to run contract test against provider that is already deployed on (pre)production environment, you don’t need to deploy anything nor control the lifecycle of any container. For this reason we provided skipDeployment flag.

skipDeployment default value by default is set to false, which means that the test will behave as it usually does, but when it is set to true, Arquillian is going to ignore anything related to container lifecycle. To use this strategy your test needs to be defined as `@RunAsClient`. You can think of it as a dynamic way of converting an Arquillian container test into Arquillian standalone test.

Let’s see an example:

@RunWith(Arquillian.class)
@Provider("test_provider")
@PactFolder("pacts")
@RunAsClient
public class MyServiceProviderTest {

    @Deployment(testable = false)
    public static WebArchive createDeployment() {
        return ShrinkWrap.create(WebArchive.class).addClass(MyService.class);
    }

    @ArquillianResource
    @Environment("myservice.url")
    URL webapp;

    @ArquillianResource
    Target target;

    @Test
    public void should_provide_valid_answers() {
        target.testInteraction(webapp);
    }

}

Given previous test, if skipDeployment is false, this test will behave like:

  1. Start chosen application server (Wildfly, TomEE, Tomcat, …​)
  2. Package and Deploy MyService
  3. Enrich webapp URL with the one provided by application server. @Environment reference is ignored.
  4. Executes contract test against deployed application.
  5. Undeploy and stop everything.

But if you set skipDeployment to true, lifecycle is slightly different:

  1. Enrich webapp URL with Java system property or environment variable named myservice.url set in @Environment.
    # Executes contract tests against URL provided by @Environment.

There is no additional “behind the scenes” Arquillian magic involved. Notice that with a simple attribute you can enable/disable how Arquillian behaves regarding the deployment lifecycle, and how you can reuse same test (DRY) for different scenarios.

You can read more about this feature in Pact documentation

Provider states with parameters introduced in Version 3 of Pact Spec

You can also use parameters for defining pact states. This feature is introduced in version 3 of pact contract files.

In consumer part you can add states with parameters doing:

Map<String, Object> stateParams = new HashMap<>();
stateParams.put("name", "Alexandra");

return builder
        .given("test state", stateParams)
        .uponReceiving("ConsumerTest test interaction")
        .path("/")
        .method("GET")
        .willRespondWith()
        .status(200)
        .headers(header)
        .body("{\"responsetest\": true, \"name\": \"harry\"}")
        .toFragment();

Notice that you are using given passing state name and parameters.

Then in provider side:

 @State("test state")
public void testStateMethod(Map<String, Object> params) {
    assertThat(params).containsEntry("name", "Alexandra");
}

Pact Publisher mechanism

Arquillian Pact also offers additional ways to of publishing “pact” contract files comparing to what Pact itself is providing. With Pact you usually need to relay on the build tool to publish “pact” files. Pact offers a Maven and Gradle plugin for publishing contracts to Pact Broker, but if you want to use Git repository or sharing contracts through an arbitrary folder, then you’ll need to start hacking the build tool which is not always as easy as it should be :)

In Arquillian Pact we have defined a Pact Publishing SPI so you can implement your own publisher. We currently support three different publishers – Folder, URL[POST method] and Git.

For example to use it with Folder Publisher, arquillian.xml might look like:

<?xml version="1.0"?>
<arquillian xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns="http://jboss.org/schema/arquillian"
            xsi:schemaLocation="http://jboss.org/schema/arquillian
    http://jboss.org/schema/arquillian/arquillian_1_0.xsd">

    <extension qualifier="pact-consumer">
        <property name="pactPublishConfiguration">
            provider: folder
            outputFolder: /mypacts
        </property>
    </extension>

</arquillian>

With this configuration and setting publishContracts to true, Arquillian Pact copies generated contracts to outputFolder.

It is important to note that by default publishContracts configuration attribute is false. This means that when you run any consumer contract test, contracts are not published. publishContracts configuration attribute should be only set to true if and only if you are publishing a new version of a consumer, and this will be done by your CI/CD environment.

You can set outputFolder value using Java system property.

You can read more about this feature in Pact documentation

Bug fixing

GitPactLoader – password field as passphrase bug

GitPactLoader was using password field as passphrase which is totally wrong since passphrase of a private key is not a password. issue-31

GitPactLoader – always using default key

GitPactLoader was always using default key instead of the one in current user home directory.

What is Arquillian?

Arquillian is open source software that empowers you to test JVM-based applications more effectively. Created to defend the software galaxy from bugs, Arquillian brings your test to the runtime so you can focus on testing your application's behavior rather than managing the runtime. Using Arquillian, you can develop a comprehensive suite of tests from the convenience of your IDE and run them in any IDE, build tool or continuous integration environment.

Release details

Component Arquillian Algeron Extension
Version 1.0.0.Alpha3 view tag
Release date 2016-11-03
Released by Bartosz Majsak
Compiled against

Published artifacts org.arquillian.pact

  • org.arquillian.pact » arquillian-pact-consumer-api jar javadoc pom
  • org.arquillian.pact » arquillian-pact-consumer-core jar javadoc pom
  • org.arquillian.pact » arquillian-pact-consumer-spi jar javadoc pom
  • org.arquillian.pact » arquillian-pact-consumer-git-publisher jar javadoc pom
  • org.arquillian.pact » arquillian-pact-provider-api jar javadoc pom
  • org.arquillian.pact » arquillian-pact-provider-core jar javadoc pom
  • org.arquillian.pact » arquillian-pact-provider-spi jar javadoc pom
  • org.arquillian.pact » arquillian-pact-provider-pact-broker-loader jar javadoc pom
  • org.arquillian.pact » arquillian-pact-provider-maven-loader jar javadoc pom
  • org.arquillian.pact » arquillian-pact-provider-git-loader jar javadoc pom
  • org.arquillian.pact » arquillian-pact-git jar javadoc pom
  • org.arquillian.pact » arquillian-pact-configuration jar javadoc pom

Release notes and resolved issues 8

Enhancement
Bug

Thanks to the following list of contributors: Bartosz Majsak, Alex Soto, Eddú Meléndez Gonzales

Arquillian Recorder 1.1.5.Final Released

Since we wrote this post we didn't laze around. Check our latest announcement.

The Arquillian team is proud to announce the 1.1.5.Final release of the Arquillian Recorder component!

What is Arquillian?

Arquillian is open source software that empowers you to test JVM-based applications more effectively. Created to defend the software galaxy from bugs, Arquillian brings your test to the runtime so you can focus on testing your application's behavior rather than managing the runtime. Using Arquillian, you can develop a comprehensive suite of tests from the convenience of your IDE and run them in any IDE, build tool or continuous integration environment.

Release details

Component Arquillian Recorder
Version 1.1.5.Final view tag
Release date 2016-11-02
Released by Bartosz Majsak
Compiled against

Published artifacts org.arquillian.extension

  • org.arquillian.extension » arquillian-recorder-api jar javadoc pom
  • org.arquillian.extension » arquillian-recorder-spi jar javadoc pom
  • org.arquillian.extension » arquillian-recorder-reporter-api jar javadoc pom
  • org.arquillian.extension » arquillian-recorder-reporter-spi jar javadoc pom
  • org.arquillian.extension » arquillian-recorder-reporter-impl jar javadoc pom
  • org.arquillian.extension » arquillian-recorder-screenshooter-api jar javadoc pom
  • org.arquillian.extension » arquillian-recorder-screenshooter-spi jar javadoc pom
  • org.arquillian.extension » arquillian-recorder-screenshooter-impl-base jar javadoc pom
  • org.arquillian.extension » arquillian-recorder-video-api jar javadoc pom
  • org.arquillian.extension » arquillian-recorder-video-spi jar javadoc pom
  • org.arquillian.extension » arquillian-recorder-video-impl-base jar javadoc pom
  • org.arquillian.extension » arquillian-desktop-video-recorder jar javadoc pom

Release notes and resolved issues 2

Enhancement

Thanks to the following list of contributors: Bartosz Majsak, Hemani, Dipak Pawar, Alex Soto