[forge-dev] arquillian powered forge deployer
Andrew Lee Rubinger
alr at alrubinger.com
Tue Sep 20 14:23:12 EDT 2011
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 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
>
More information about the forge-dev
mailing list