[forge-dev] arquillian powered forge deployer

[Aslak Knutsen]

On Tue, Sep 20, 2011 at 8:23 PM, Andrew Lee Rubinger <alr at alrubinger.com> wrote:
> Sounds to me like this is something to be broken off from Arquillian
> honestly.  If we draw the bounds of Arquillian to be:
>
> "An adaptor between test lifecycle and backing container lifecycle, with
> additional services support"
>

I would not draw the boundaries here, and specially not test _and_
container. Both Test lifecycle and Container lifecycle are just
different aspects that can be used with Arquillian on their own.

In the current form Arquillian Core is a standalone event bus with
support for Extensions.

Where the current 'Core' Extensions are:

- Test Extension
  Adds support for Test lifecycle events and contexts via the TestRunnerAdaptor

Enrichers are impls of SPIs exposed by this Extension.

- Container Extension
  Adds support for Container events and contexts

DeployabeContainers are impls of SPIs exposed by this Extension.

- Container Test Extension
  Adds a integration layer between Test and Container Extension to map
events between them

TestRunners(remote relaunch) and Protocols are impls of SPIs exposed
by this Extension.


Now you can mix and match, do you want just Test integration, or just
Containers or both to be active when you run.

Usecase for Only Test Extension is where Arquillian work as a pure
common integration layer between the different Test Runners, write
once run in any of them. Arquillian Drone is only tied to Test
Extension SPIs and can be used without any Container / Deployment,
e.g. running against existing deployments. Or Byteman, which has their
own JUnit/TestNG integration atm, but will be rewritten as a pure Test
Extension at some point.

Usecase for Only Container Extension is where Arquillian work as a
pure common integration layer between the different Containers, write
once deploy run anywhere. A Example here is Arquillian Maven, JBoss
Forge, JBoss Tools. Possible other use cases would be some
provisioning / deployment tool.

And of course when you combine Test and Container Extension, you get
what you know to be 'Arquillian' today.

We also have two other sub projects in the testing ralm, but not
directly related to the Containers part, Arquillian Ajocado (type safe
Selenium + Ajax support, integrates via Arquillian Drone) and
Arquillian Rusheye (visual testing by 'comparing screenshot's, not
currently integrated with Arquillian Core)

The current brand focus up til today has been on "Testing with
Containers" and that Arquillian is one thing. But reality is
Arquillian is becoming the umbrella project that "JBoss Testing Lab"
was suppose to be, and we're slowly moving outside the boundries of
the Testing realm with efforts like Arquillian Maven and Forge / Tools
integration. This is also why i've started to talk about Arquillian as
a Platform.


I would say, let's stick with one strong brand around this and point
out the different angles, instead of multiple smaller obscure brands
that happen to work together in random locations. It simplifies docs,
promotion, recognition, inter operability, consistency.


-aslak-



> ...then it sounds like the logic of doing deployment (to be reused by other
> projects) should live outside Arquillian, and be consumed both by these
> other projects and Arquillian itself.
>
> In that case we'd reopen the discussion of a deployment abstraction project
> to be shared by all.
>
> S,
> ALR
>
> On 09/20/2011 02:18 PM, Dan Allen wrote:
>>
>> On Tue, Sep 20, 2011 at 14:14, Max Rydahl Andersen
>> <max.andersen at redhat.com <mailto:max.andersen at redhat.com>> wrote:
>>
>>
>>    On Sep 20, 2011, at 05:18, Dan Allen wrote:
>>
>>     > On Mon, Sep 19, 2011 at 16:23, Paul Bakker
>>    <paul.bakker.nl at gmail.com <mailto:paul.bakker.nl at gmail.com>> wrote:
>>     > I think we're talking about two different things here
>>     > 1) Deploying to AS7 using Shrinkwrap/Arquillian instead of file
>>    copies.
>>     >
>>     > This got me thinking, perhaps the Arquillian managed container
>>    should support both a remote deployment and a local deployment. The
>>    remote deployment is via the deployment APIs of a running server,
>>    whereas the local deployment is a file copy to a deployment
>>    directory. I'm hesitant to introduce another type of container in
>>    Arquillian, so perhaps it's just an aspect of a managed
>>    container...seems to fit best.
>>
>>    File copies definitely shouldn't go away since otherwise you are
>>    dependent on both the server running and the server being accessible
>>    to you for remote management calls.
>>
>>    Not something that is guaranteed in todays world - i.e. openshift
>>    servers or production servers aren't necessarily accessible for
>>    remote operations beyond file copies.
>>
>>
>> Right, which is why I think the Arquillian container adapters should
>> support this deployment method, even if they aren't use for Arquillian
>> tests. Aslak and ALR, got an opinion on where this feature should fit
>> into the existing container organization?
>>
>> -Dan
>> --
>> Dan Allen
>> Principal Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://www.google.com/profiles/dan.j.allen#about
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>>
>