[brian.stansberry]

The tests under tests/compatibility/org/jboss/cache/compatibility sounds fine.

The varia part seems odd. That creates a whole new directory structure just for two classes. How about tests/compatibility/org/jboss/tools instead?

Also, packaging the 2 classes (I assume we're talking about ClassVersionInfo and SerialVersionUID) under org.jboss.tools is a bit strange. I understand the desire to do that -- it's the same classes as the ones under the AS codebase. But actually, it's not the same classes -- it's a copy. It's not going to automatically be developed/maintained along with the AS version.

So, I'd say

1) If it's QA's intent to someday unify this stuff by doing something like putting these classes in the test project where they can be shared by AS and JBC, then leave them in org.jboss.tools. Even if you guys think you might do that someday, go ahead and leave them in org.jboss.tools.

2) Otherwise, they should be packaged in org.jboss.cache.compatibility.

[pavel.tsekov]

SearialVersionUID contains mostly copy/paste code. It is possible and even necessary to make it configurable. And I have taken such approach - i.e. reading certain properties which drive it. So, yes, I think SerialVersionUID can be common class between Jboss AS and JBossCache. Anyway, this can be changed at any time ... So how should I proceed for this particular case .

[ryan.campbell]

Let's go with 1. We really should move the org.jboss.tools classes to the test module, and have jbosscache depend on the test module. But for now, let's just get the test in place.

[manik]

Let's go with 1. We really should move the org.jboss.tools classes to the test module, and have jbosscache depend on the test module. But for now, let's just get the test in place.

+1.

Also, +1 to Brian's comment about a "varia" directory - I'd rather see this under tests/compat as well.

Cheers,
Manik

[pavel.tsekov]

Ok. I'll do it as per your suggestions.
Now, a final question - where should I commit the test ? HEAD, Branch_JBossCache_1_4_0 or somewhere else.

[brian.stansberry]

Both HEAD and Branch_JBossCache_1_4_0. Releases will continue to go out from both branches.

JBC 2.x (HEAD) is API incompatible with 1.x, so there is no reason to test serialVersionUID compatibility with 1.x, other than for our own curiousity about what changed. So maybe we'll ignore the test on HEAD for the first 2.0.0 release. But for subsequent 2.x releases we'll need the test in HEAD.

[manik]

My thoughts exactly

[pavel.tsekov]

I added the news files to the Branch_JBossCache_1_4_0 branch. I also modified the build.xml to include a new target - "compat-tests".

Now I'd like to create a database and add a test for it. Which releases are we going to test against ? Where should we keep the database ?

[manik]

What format would this database be? I presume a txt or xml file? If so, this could reside in cvs, perhaps in the etc/ directory.

As for versions, any a.b.x version of JBC needs to be binary compatible with any a.b.y release. So you could maintain a db of all versions to date, but only enforce the checks according to the rule defined.

[pavel.tsekov]

Manic,

The database is a serialized Map object containing ClassVersionInfo objects inside it. As for the versions - on the download page (http://labs.jboss.com/portal/jbosscache/download) there are a lot of version - do we want to create a database for each of them excluding the 2.0.0 and the BETAs ?

[manik]

I would say yes, we should create a db for each of them.

[pavel.tsekov]

Ok, then. So I'd create a database for each existing release and put it under etc/ in the cvs repository, right ?

[manik]

Yes, but to prevent cluttering /etc, would this be a single binary file containing a serialized Map? Or would you need multiple objects?

[pavel.tsekov]

Well, the Jboss AS has multiple binary files but they track less versions. I can change the tool for the needs of JBossCache to generate a single binary file or multiple XML files or something else... Whatever you wish. Just let me know what you want me to do and I'll do so.

[manik]

Could I be a pain and ask for a single XML file? :-)