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.
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's less of a concern. More that it could be if the motivation is there.
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.
+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 & docs. By all means, prototype in any which direction.
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.
+1
Back to the topic of the thread, I'm looking for an agreement from the forge team to impl the container control & deployment using Arquillian Containers, enhancing it as needed. After all, we don't want to be stuck having to maintain two sets of adapters.
-Dan