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

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.