On Wed, Sep 21, 2011 at 10:34, Aslak Knutsen <span dir="ltr">&lt;<a href="mailto:aslak@4fs.no">aslak@4fs.no</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br></div>
Usecase for Only Container Extension is where Arquillian work as a<br>
pure common integration layer between the different Containers, write<br>
once deploy run anywhere. A Example here is Arquillian Maven, JBoss<br>
Forge, JBoss Tools. Possible other use cases would be some<br>
provisioning / deployment tool.<br></blockquote><div><br></div><div>Exactly, we want to only have to solve this problem once, esp in the case of build builds (maven, gradle) and forge. JBoss Tools could offer this support, though users needs are satisfied pretty well in the Eclipse ecosystem already, so that&#39;s less of a concern. More that it could be if the motivation is there.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
The current brand focus up til today has been on &quot;Testing with<br>
Containers&quot; and that Arquillian is one thing. But reality is<br>
Arquillian is becoming the umbrella project that &quot;JBoss Testing Lab&quot;<br>
was suppose to be, and we&#39;re slowly moving outside the boundries of<br>
the Testing realm with efforts like Arquillian Maven and Forge / Tools<br>
integration. This is also why i&#39;ve started to talk about Arquillian as<br>
a Platform.<br></blockquote><div><br></div><div>+1 This ties into the suggestion I had a while back that it could be used for procurement. Though I think we do want to keep the scope at least within developer and devops tooling...at least as far as we explain it on the project site &amp; docs. By all means, prototype in any which direction.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
I would say, let&#39;s stick with one strong brand around this and point<br>
out the different angles, instead of multiple smaller obscure brands<br>
that happen to work together in random locations. It simplifies docs,<br>
promotion, recognition, inter operability, consistency.<br></blockquote><div><br></div><div>+1</div><div><br></div><div>Back to the topic of the thread, I&#39;m looking for an agreement from the forge team to impl the container control &amp; deployment using Arquillian Containers, enhancing it as needed. After all, we don&#39;t want to be stuck having to maintain two sets of adapters.</div>

<div><br></div><div>-Dan</div><div><br></div></div>-- <br><div>Dan Allen</div>Principal Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><div><a href="http://www.google.com/profiles/dan.j.allen#about" target="_blank">http://www.google.com/profiles/dan.j.allen#about</a><br>

<a href="http://mojavelinux.com" target="_blank">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br></div><br>