Arquillian as Container Controller for Build Systems

[aslak]

During the hackergarten at Devoxx I sat down with Hans Dockter (mr gradle) and discussed how / what Arquillian and Gradle could do together. The conclusion was basically that the Gradle team does not have the resources to maintain Container integrations. Container integrations are not their main focus and they are already lagging behind(e.g. missing jetty 8 support). Tho it is very much in the domain of Arquillian.

We started some simple demo code here:

https://github.com/aslakknutsen/arquillian-gradle-plugin

The original design doc from Gradle on this feature can be found here:

https://github.com/gradle/gradle/blob/master/design-docs/deploying-applications-for-testing.md

At the same time Galder was hacking on the same feature for SBT(http://www.scala-sbt.org/) and planning to implement the same for leiningen (http://leiningen.org/).

We currently have a start of the same features for Maven with the Arquillian Maven Plugin.

As we get a picture of what is required / different from the different build systems we should probably extract this into some common arquillian-container-controller library that can be reused. It would basically handle:

- Classloading

- Resolving based on Build Systems Resolver

- Interact with Container API from arquillian.org

[dan.j.allen]

Absolutely. This is a great opportunity for Arquillian and the numerous build systems. Also, don't forget about Forge. That project is in the same process.

We've discussed having a more generic container controller for Arquillian 2.0. We could start prototyping what the API is going to look like while putting together this library and then bolt it onto Arquillian 2.0.

The open questions that I see at this point is, do we want to settle on "container" as the general abstraction for what is being controller, or is there a more general term. If there is a more general term (such as runtime), then Container may be a specialization of that thing. One exercise is to write down all the possible things we forsee needing to be controlled and then work from there. That doesn't mean we have to implement them all know...just room for growth.

The other thing to think about is having a more standardized registry of information about the containers. First and foremost, every adapter should have a GUID (ideally a simple one that a human can actually remember). We should also have standard foundation configuration property names, so that we don't get a dozen different ways to write "port" or "address". Configuration properties is one of the the things I think Cargo did really well.

As for the name of the module, I was thinking about something like "autopilot". Though the terms "medium" and "airwave" also came to mind, both being something through which signals pass (aluding to them being adapters rather than containers themselves).

[dan.j.allen]

To take a page from the Selenium playbook, building on their definition of "Selenium automates browsers", we could say that:

"Arquillian (Autopilot / Airwave / xxx) automates containers"

(of course, "containers" might be replaced with "runtime engines" or other).

[dan.j.allen]

Examples of containers / runtimes engines:

• Application server (or Servlet container) - provides a runtime and services for software components
• Database engine - provides a runtime for exchanging information with permanent storage (SQL or NoSQL)
• Mobile phone emulator - provides a runtime for running native applications
• Command shell (e.g., Forge) - provides a runtime for executing commands
• Virtual machine or cloud (IaaS or PaaS) - provides a runtime for hosting any number of other runtimes
• ...

[aslak]

One thing I've been considering for 2.0 is a nested 'container' structure.

e.g.

• VM Host (Server)
  • VM Guest (Server)
    • Mail (Service)
    • DB (Service)
    • AppServer Domain (DeployableService)
      • AppServer (DeployableService)
        • Application (DeployableService)
    • StandaloneApplication (DeployableService)
  • Mail (Service)
  • ..

The different levels could have a AutoDiscover feature. e.g. a VM Host could auto discover Guests. Support for a Service / AppServer could auto discover itself within a Server. A ppServer Domain could auto discover controlled AppServers.

The Application level DeployableService is intended to cover the case where 'something' is running in a AppServer has it's own Deployment chain, e.g. a Process Engine running on the AS could deploy Process Definitions.

(note, names are just for illustration)

[galder.zamarreno]

Dan Allen wrote:

Examples of containers / runtimes engines:

• Application server (or Servlet container) - provides a runtime and services for software components
• Database engine - provides a runtime for exchanging information with permanent storage (SQL or NoSQL)
• Mobile phone emulator - provides a runtime for running native applications
• Command shell (e.g., Forge) - provides a runtime for executing commands

^ You'd include SBT and Leiningen here too

[galder.zamarreno]

Why do you want a nested structure here? And what's the point of this discoverability thing?

The reason I say this is cos as Dan said, there's a combo of airwarve/autopilot/.. things here here. To give you an example, I want to run tests against Escalante (embedded AS7 - app server), within SBT (scala build tool - command shell). For Immutant guys, they want Immutant (embedded AS7 preferably), within Leinigen (clojure build tool - command shell). For EE people, you could have guys using Embedded AS7 with Maven (one shot build tool), or Gradle (one shot build tool), or Forge (interactive command shell? - not sure if you can deploy from Forge already)...

[aslak]

Galder Zamarreño wrote:

Why do you want a nested structure here? And what's the point of this discoverability thing?

The nested structure is not directly tied to 'use Arquillian as a Controller tool', but rather as a comment to Dans question about what examples of 'runtimes' that I see Arquillian controlling in the future.

The same Tool could eventually be used to control a VM on a host or a database server as a embedded app server.

The discoverabillity is there to help share configuration/protocols between the different 'levels' to avoid the user configuring him self to death. e.g. a Parent can discover it's children, or a child can discover it self on a Parent. At this point they can share configuration info like IP or piggy back on some of the setup code from the parent.

Examples:

A Managed AS7 could install itself by deploying to the Server. The Managed AS7 Server does not need to know how to transfere it self to a specific server, it just relies on Parent.deploy(me). Default that would be a LocalServer which basically just a file copy, but for a Remote Server it would do a scp.

A Process Engine DeployableContainer could install it self to WebSphere by calling Parent.deploy(me). The Process Engine DeployableContainer no longer needs to know how to start WebSphere that's up to the WebSphere DeployableContainer.

One example of the discoverabillity is the AS7 Domain Arquillian Adaptor. You configure the managementIp of the domain server, the domain server then discovers all groups / standalone servers it controls and registers them as individual Containers. You can now Target a deployment to any deployable target (standalone-server or server-group) on the domain. @Deployment @TargetsContainer("main-server-group") ...