[lincolnthree]

I understand the need to be able to specify your own stack, but this wouldn't limit that, simply provide an alternative for quick/easy setup!

[dan.j.allen]

I think the stack POMs are the best short term solution (i.e., gets it in people's hands in the shortest amount of time). We want to get some sort of off-the-shelf experience. Feel free to hack something together and commit it to the Arquillian sandbox.

[dan.j.allen]

Indeed! And the better the embedded containers are, the better Arquillian is.

If you think about it, all containers should really provide a super fast embedded stack for this very purpose. Embedded GlassFish is actually not as lightweight as it could be. When OpenEJB supports all of EJB 3.1, it shouldn't be hard to create a Jetty+Weld+OpenEJB+OpenJPA combo for blazing fast testing. This fits with my theory that integration testing should be a continuum, starting with a single embedded runtime all the way up to a full remote server. That way, you get the most productivity out of your testing. And it's not just about testing. It's about experimenting, learning, querying, probing, investigating...

What's important is to keep the test portable across the board (though some non-portable tests aren't a crime).

Should I mention now that I figured out how to test JSF on Jetty using the Arquillian JSFUnit integration? I'll be pushing that commit soon enough

[dan.j.allen]

This project is now available in the Arquillian examples project on github.

[dan.j.allen]

Laird Nelson wrote:

One of the neat things we've got going at my company is a (non-Arquillian for the moment) test suite that uses OpenEJB 3.1.3-SNAPSHOT, which does have JPA 2.0 support, and a JUnit parameterized test that cycles through all major JPA providers.

Would you be willing to provide a patch for the pom.xml in jpalab that upgrades the project to JPA 2? Feel free to fork the project and send a pull request. It's fun!

You'd be surprised--or perhaps not!--at how far apart they all are.

I'm not surprised, but that's because I've already been surprised by the differences too many times. One of the things I love about Arquillian is the prospect of "keeping them honest" as CNN would say

The real-world rule of thumb seems to be: test spec adherence with EclipseLink, and test fragility with OpenJPA.  Hibernate seems to just be lenient and easygoing with everything, but sometimes burns you behind your back.

Hibernate, and in some respects JBoss AS, have always aspired to go a little beyond the specs. If you are interested in the bonus behavior, then you are happy about that. If you are interested in portability, then you find that this gets you in trouble

Personally, I prefer the default behavior to be consistent with the spec and to use configuration settings to step outside of the spec.

I would love to see a Maven surefire fork, or perhaps a JUnit @Rule or something like that, that would fork a JVM with this stack for each JPA implementation.  Because each JPA implementation really wants to do bytecode surgery on the JPA entities, doing it like we have it at the moment--in VM, with all enhancements turned off--only lets you do some basic stuff.

You'll be happy to know the Arquillian team has had this exact conversation. The current limitation really stems from Maven rather than Arquillian. Maven doesn't know how to execute the same phase twice...it's lifecycle is fixed. A build tool like Gradle (or if you want to be old skol, Ant) can execute any task any number of times. So testing against each JPA implementation in sequence can be done today using Gradle or Ant. In fact, I have an example of such a setup in my sample Gradle build in the Arquillian showcase.

However, I do recognize that Maven is here to stay and we must have a solution for Maven users as well. So we'll be looking into this idea of a surefire fork or some other way to cycle through executions using different classpaths. Aslak, do we have a JIRA for this one?

Anyhow, to try to make this relevant: OpenEJB in particular is a great little container.  I would love to see an Arquillian feature that ran a test case over various JPA implementations in a row.

+1. In fact, I'll add a build.gradle file to the jpalab to satisfy this requirement in the near term

[dan.j.allen]

Just added a Gradle build to the jpalab. Now you can run all the JPA providers back-to-back in one build.

gradle oEEOpenjpaT oEEHibernateT oEEEclipselinkT

Those are shorthands for the tasks I setup in the pattern openEjbEmbedded%provider%Test. Gradle is just smart like that.

[aslak]

Dan Allen wrote:

However, I do recognize that Maven is here to stay and we must have a solution for Maven users as well. So we'll be looking into this idea of a surefire fork or some other way to cycle through executions using different classpaths. Aslak, do we have a JIRA for this one?

We have spoken about it, but it hasn't materialized into a specific issue yet.

With the help of the upcoming ClassLoader control, multi container support and some hackery with Test Suites, I think it might be possible to make it a Arquillian feature, without having to rely on the build system.