[alrubinger]

dan.j.allen wrote:

If we move Container configuration down to Test Class level (or even Test Method level as Andrew have suggested), we will be adding 38 in extra to each Test Class. In my mind, that will render Arquillian more or less useless.

Agreed. We definitely don't want to be starting the container for every test class or method. We want to wrap the container boot life cycle around the suite.

This is another case of opinionated software.   We shouldn't be blocking users from accomplishing what they want to do; we must only default to the 80% case.

What I've suggested is a way to let the user control container lifecycle at a granularity with which they're comfortable.  Here's the use case:

JUnit has every test method within a class use a new instance for a reason; isolation.  And while "start the container once per suite" is a fantastic default, perhaps users want/need more isolation by killing the server state between test methods.  So we should let them.

S,

ALR

[dan.j.allen]

ALRubinger wrote:

dan.j.allen wrote:

If we move Container configuration down to Test Class level (or even Test Method level as Andrew have suggested), we will be adding 38 in extra to each Test Class. In my mind, that will render Arquillian more or less useless.

Agreed. We definitely don't want to be starting the container for every test class or method. We want to wrap the container boot life cycle around the suite.

This is another case of opinionated software.   We shouldn't be blocking users from accomplishing what they want to do; we must only default to the 80% case.

What I've suggested is a way to let the user control container lifecycle at a granularity with which they're comfortable.  Here's the use case:

JUnit has every test method within a class use a new instance for a reason; isolation.  And while "start the container once per suite" is a fantastic default, perhaps users want/need more isolation by killing the server state between test methods.  So we should let them.

I'm on that page with you. I was thinking about the default approach (suggested path) of using the test suite. Naturally, being flexible is essential.

[alrubinger]

Some issues to consider w.r.t packaging the core alongside the containers:

• ClassLoading
  • Hierarchal ClassLoaders dictate that a reference in a parent loader cannot point to something loaded by a child, else you get NCDFE.  To maintain a slim application classpath we have to ship a separate API JAR (required when the test class loads), and then use an appropriate ClassLoader to load up the implementations.  If the API leaks out to internals, we get loading problems (unless you use a flat ClassLoading model).
• Modularity
  • Why ship out support for N containers when a user really only wants 1, plus its dependencies?

I guess I only had two points, but I like using bullets anyway.

S,

ALR

[dan.j.allen]

• Modularity
  • Why ship out support for N containers when a user really only wants 1, plus its dependencies?

I was referring to a hierarchical structure. Something like:

arquillian/
   api/
   impl/
   ...
   containers/
      jboss-as-60-remote
      jboss-as-51-remote
      jboss-as-60-embedded
      glassfish-v3-embedded

Still separate JARs. User selects what they want from the menu of artifacts.

The contrib stuff would be in a whole other repository, so we can give access to a different set of committers than those on the core team. Distributed contribution, so to speak.

[alrubinger]

dan.j.allen wrote:

We could provide support for it (system properties), but say that it's not the recommended approach.

Yeah, I think we'll have to provide some kind of support.  Test configuration has stuff like ports and bind names which aren't necessarily portable between environments.

I think to go down this route we need sysprops under a single parent namespace, with clear documentation in the API of whatever container configuration about what properties are supported.  Then the annotations config each map to some property.  So at least we're documented in some way.

Oh, and some order of precendent.  In jboss-bootstrap the resolution logic is:

Configuration

Environment Variable

System Property

...with lower items getting priority.

S,

ALR

[alrubinger]

dan.j.allen wrote:

• Modularity
  • Why ship out support for N containers when a user really only wants 1, plus its dependencies?

I was referring to a hierarchical structure. Something like:

Sorry for the confusion; I'm with you.  My response was in to German "why not ship the containers in the same JAR as the core".

S,

ALR

[aslak]

arquillian/
   api/
   impl/
   ...
   containers/
      jboss-as-60-remote
      jboss-as-51-remote
      jboss-as-60-embedded
      glassfish-v3-embedded

..old habits die hard..

The reason behind using a flat structure to begin with is just tech depth from the days trying to use the Maven Release plugin on a hierarchical layout.. We're not using it anyway, so really no need to obey to its limitations.