[jboss-dev] How can a project run in both AS 4.2.0 and AS 5.0?

[Adrian]

There's nothing to stop you delivering your tests
into the AS as part of the integration. 

Same as what we do with the joram tests.

Except of course you have your own test framework
(which is something I complained about a while ago)
instead of reusing and extending jboss-test,
so that will be hard.

On Thu, 2007-07-19 at 16:37 +0100, Tim Fox wrote:
> So what you're saying is that a lot (maybe most) of the tests in our 
> test suite are actually integration tests and should go into AS. (The 
> current messaging integration tests in are really crappy)
> 
> And the JBM test suite should only deal with mocks. So we need to mock 
> out usage of JGroups, AOP, the database, commons core etc

In principle, there should be no real difference between using mocks and
picking a single version of those projects to test against.
If the api is stable it should make no difference.

In reverse, there should be a simple cutdown configuration
of JBoss Messaging (no persistence, security, clustering, networking,
etc.) that others can use in their tests as a "Mock JMS".

You've really got two choices of version, both have their advantages
and disadvantages.

1) Choose the same versions as the current stable branch of JBossAS,
at time of writing JBoss-4.2

Advantage: Its easy for you to work out problems with the
integration in that branch

Disadvantage: Its harder to test integration with JBoss-5
or other branches. You have to debug in the JBossAS codebase
instead of your own.

2) Always choose the lastest reasonably stable version of each project

Advantage: You're catching regressions and problems in those projects
early.

Disadvantage(s): You could easily introduce a dependency on a new
feature of those projects that isn't available in the version
chosen by JBoss-4.2. And you're only going to find integration
problems caused by old bugs in the other projects (fixed 
in the lastet versions) when you run the JBossAS integration tests.
But that's really a problem for the other project. :-)

In practice, you probably want to switch between these
strategies depending upon where you are in your development
lifecycle.
i.e. strategy (2 - latest and "greatest") for alphas/betas and strategy
(1 - more stable versions) as you get towards a more stable release
yourself.
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx