https://github.com/arquillian/arquillian-maven/blob/master/plugin/src/mai... :) On Mon, Sep 19, 2011 at 8:54 PM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com&gt; wrote:

I think we're talking about two different things here 1) Deploying to AS7 using Shrinkwrap/Arquillian instead of file copies. 2) Downloading and setting up the container (the issue Lincoln linked to). But anyway, I agree we should do this. I will pick this up. Paul On Sep 19, 2011, at 10:07 PM, Lincoln Baxter, III wrote:

I see I'm still slightly off, I think I'm about fried for today. Thanks Paul. On Mon, Sep 19, 2011 at 4:49 PM, Lincoln Baxter, III < lincolnbaxter(a)gmail.com&gt; wrote: -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"

On Sep 20, 2011, at 05:18, Dan Allen wrote: 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. /max /max http://about.me/maxandersen

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" ...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 8:23 PM, Andrew Lee Rubinger <alr(a)alrubinger.com&gt; wrote: 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-

I agree with this approach. On Wed, Sep 21, 2011 at 12:37 PM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"