Arquillian Blog

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.Alpha5 release of the Arquillian Algeron Extension component!

Arquillian Pact has been rebranded to Arquillian Algeron. This is an extension for writing contract-driven tests.

Currently we are providing you seamless integration with well known Pact framework but more integrations will come in next releases.

What’s new

Arquillian Pact has been rebranded to Arquillian Algeron

Now Arquillian Pact is under the umbrella of Consumer Driven Contract project called Arquillian Algeron.

This rebranding has influenced the structure of Arquillian Pact. To migrate from Arquillian Pact to Arquillian Algeron Pact, you need will have to:

• Artifact Id has changed from arquillian-pact-consumer-core and arquillian-pact-provider-core to arquillian-algeron-pact-consumer-core and arquillian-algeron-pact-provider-core.
• Contract loaders has been renamed and relocated to a common place, so instead of @PactFolder now it is @ContractsFolder. In general all loaders annotations has been renamed by replacing the Pact element to Contracts.
• Pact publisher is not configured anymore in pact-consumer extension but in algeron-consumer. You can read about it at Consumer Publisher section
• Pact Loader has been renamed to Contracts Retriever.
• Base package is not org.arquillian.pact anymore but org.arquillian.algeron.pact – this might be relevant if you have already started exploring SPIs.

Allow user to define states like Cucumber expressions

You can pass as state expressions following Cucumber approach, so for example you can pass next state in consumer:

public PactFragment createFragment(PactDslWithProvider builder) {
  builder.given("I have 36 cukes in my belly")
         ...
}

And you can get it on provider side using:

@State("I have (\\d+) cukes in my belly")
public void stateMethod(int numberOfCukes) {
  this.numberOfCukes = numberOfCukes;
}

You can read more about this feature at Pact States section

AssertJ integration

A custom assertj assertion has been created so asserting contracts using Target in provider side could be done in a readable way instead of calling a method.

@ArquillianResource
URL webapp;

@ArquillianResource
Target target;

@Test
public void should_provide_valid_answers() {
  assertThat(target).withUrl(webapp).satisfiesContract();
}

You can read more about this feature at AssertJ Integration section

Retrieving/Loading contracts can be configured using annotations and in arquillian.xml

Consumer can publish contracts when the contract is generated. Its configuration parameters are set in arquillian.xml. But on the provider side, contracts used for verification were configured using annotations.

To make things more standard, now retrievers can be configured using annotations or as publishers in arquillian.xml too. For example:

<extension qualifier="algeron-provider">
  <property name="retrieverConfiguration">
          provider: folder
          contractsFolder: <folder where contracts are stored>
    </property>
</extension>

You can read more about this feature at Retrievers as Configuration section

Integration between Pact Provider and Arquillian Reporter

Now if you have Arquillian Recorder dependency on your classpath and you set @VerificationReports to use recorder as reporting format, the result of the verification of the provider is reported in Arquillian Recorder too.

You can read more about this feature at Arquillian Recorder Reporter integration

PactVerification value is not mandatory

When you want to write a consumer test you need to specify that the method tests a consumer contract by using @PactVerification annotation and setting which provider you are verifying. In case of using @Pact annotation on the class level, this information can be redundant (the value of the annotation). For example you can do:

@RunWith(Arquillian.class)
@Pact(provider="test_provider", consumer="test_consumer")
public class ClientGatewayTest {

  @Test
  @PactVerification
  public void should_return_message() throws IOException {
    assertThat(clientGateway.getMessage(), is("{\"responsetest\": true, \"name\": \"harry\"}"));
  }
}

Notice that now you don’t need to set the provider in @PactVerification annotation since it is retrieved from class level.

Bug fixing

Test does not fail when contract is not verified

If multiple interactions are validated in provider side within same test, Arquillian takes only in consideration the first interaction result as final test result. To fix this a new Arquillian Core has been released (1.1.12). We encourage all users to use Arquillian Core 1.1.12 as the minimum version to avoid this problem. Notice that this also applies to previous versions of Arquillian Pact/Algeron.

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

Published artifacts org.arquillian.algeron

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

Release notes and resolved issues 6

Enhancement

• #58 Make PactVerification value not mandatory
• #55 Create integration between Pact Provider and Arquillian Reporter
• #53 Allow Pact Loader to be specified in configuration file as well
• #48 PACT AssertJ integration
• #47 PACT Allow user to define tests like Cucumber expressions

Bug

• #52 Test does not fail when contract is not verified

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

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

The Arquillian team is proud to announce the 2.2.5 release of the ShrinkWrap Resolver component!

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

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-api-gradle-embedded-archive jar javadoc pom
• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-api-maven jar javadoc pom
• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-depchain pom
• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-gradle-depchain pom
• org.jboss.shrinkwrap.resolver » shrinkwrap-resolver-impl-gradle-embedded-archive 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-spi jar javadoc pom

Release notes and resolved issues 4

Component Upgrade

• SHRINKRES-260 - Upgrade Shrinkwrap to 1.2.6

Bug

• SHRINKRES-259 - Shrinkwrap resolver generates invalid Zips
• SHRINKRES-261 - When multiple settings.xml are merged, then only one default profile is taken
• SHRINKRES-262 - Rename tests that don't contain TestCase in their name, so they are executed

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

The Arquillian team is proud to announce the 1.1.6.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

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 3

Other

• #60 Handle Relativized Path in HTML Exporter
• #58 Update default xml template to make table more readable.

Enhancement

• #28 Put validation of configuration properties outside loop

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

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

The Arquillian team is proud to announce the 2.0.0.Beta4 release of the Arquillian Container Weld Root POM 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

Published artifacts org.jboss.arquillian.container

• org.jboss.arquillian.container » arquillian-weld-embedded jar javadoc pom

Release notes and resolved issues 2

Enhancement

• ARQ-2023 - Use relaxed default constructor configuration in Arquillian Weld embedded adapter for SE environment

Bug

• ARQ-2048 - Excluded elements in beans.xml by the Weld Arquillian plugin is an all check instead of an any

Thanks to the following list of contributors: Bartosz Majsak, Tomas Remes, Antonin Stefanutti, Matej Novotny

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)

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();

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

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

• SHRINKRES-256 - Add Maven BOM to SWR shrinkwrap-resolver-bom
• SHRINKRES-257 - Implement EmbeddedMaven

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