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.
On 09/20/2011 02:18 PM, Dan Allen wrote:
On Tue, Sep 20, 2011 at 14:14, Max Rydahl Andersen
<max.andersen(a)redhat.com <mailto:firstname.lastname@example.org>> wrote:
On Sep 20, 2011, at 05:18, Dan Allen wrote:
> On Mon, Sep 19, 2011 at 16:23, Paul Bakker
<paul.bakker.nl(a)gmail.com <mailto:email@example.com>> wrote:
> I think we're talking about two different things here
> 1) Deploying to AS7 using Shrinkwrap/Arquillian instead of file
> 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?
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597