I had some time to work a bit more on the code and experiment with it.

I had added a @SpringWebConfiguration that marks that the beans in annotated test should be injected from WebApplicationContext. So now it's possible to run very simple tests of Spring MVC controllers in the container.

Until now I'd though that it's only possible to enquire the Spring root web context, created by ContextLoaderListener or ContextLoaderServlet, but after some research I have found that by default each DispatcherServlet publishes it's own application context in ServletContext as an attribute. That gives some extra possibilites.

So, my question is, is it possible to inject into Arquillian extension a ServletContext?

I want to start by saying that I'm really excited to see your proposal and I think you are on a great path already to a successful project, if you get accepted for it. We'd be glad to have your participation either way.

To answer your question:

I was thinking, how about introducing a Google Guice support in Arquillian?

I'am gessing the reasons why would You like to have Spring support. Spring provides entire stack for developing applications while Guice is only IOC container, but still I

find Guice as a very friendly framework in terms of usage. It's very lightweight and it gives You entire freedom for various usages from standalone applications to web and enterpise apps.

The only reason we have omitted Guice so far is because we didn't want to get too optimistic. We've been waiting on the Spring extension to take shape for so long, we'd be happy just to say we got that done finally. It's also the bigger audience compared to Guice, so it's definitely the right place to focus first. If you finish up with the Spring extension and want to get "extra credit", by all means, please do explore the Guice extension as well. Trust me, we will give you lots of credit for your extra work (e.g., http://arquillian.org/community/contributors).

I was looking to use Arquillian with my project (maven, jboss 4.2.3, spring 2.5.6) and I was wondering if the current "prototype" already supports this environment and what libs do I have to add to my pom.xml to make it work.

If you can provide me a bit more instructions I can test it in my environment, just apologize me because I know 0 about arquillian

I'm affraid that currently the extension could be used for testing Spring 3.0 and above, due to existing references to AnnotationConfigApplicationContext. Let me see if there will be posibility to add support for previouse versions.

Guys, let me ask You a question, what would be Yours approach for supporting legacy Spring versions? Seperate artefacts maybe?

That's correct Jakub. The way we handle supporting different API versions of services and containers is to version the Maven artifacts. Typically this involves also creating a common module where generic code can go.

A good example is to see the GlassFish container. It uses all the conventions that we've established.

You can have various artifacts for different capabilities - e.g. Spring JavaConfig can get its own artifact.

Or the extension can detect if classes like AnnotationConfigApplicationContext are available at runtime - and if they're not, just fail the test stating that the Spring version used in the test does not support that use case. In fact, it seems to me that being able to target specific Spring versions in the tests makes them more accurate.

Perhaps start a design thread about the best way to handle auto packaging of a bundled service. A bundled service is any service that is not provided by the container (and thus must be bundled, or packaged, in the deployment). Spring and Seam 2 are obvious examples. Another example is Hibernate.