JBossDeveloper

No problem - will do. Once I am ready I'll let you know.

I've changed the code to utilize java.beans.XMLEncoder since it seemed appropriate. I produces something like that:



org.jboss.aop.pointcut.ast.ParseException


6640507307072022813



Now, do we really want a single XML file for all previous releases or you can live with one file for a release ? I think that creating a single file for all releases will complicate the tool without any real advantages. Well, there are some advantages - the fact that we need to validate against j2se 1.4 and 1.5 will double the number of produced files so if we have a single file repository we'll only have two files. Please, advise.

Sorry, an entry in the database looks like this:



org.jboss.aop.pointcut.ast.ParseException


6640507307072022813

Ouch. The board strips the XML tags :(

Use the 'code' button. :)

 <object class="org.jboss.tools.ClassVersionInfo">
 <void property="name">
 <string>org.jboss.aop.pointcut.ast.ParseException</string>
 </void>
 <void property="serialVersion">
 <long>6640507307072022813</long>
 </void>
 </object>

If you need to create multiple XML files, then you should do it in a subdirectory of /etc - perhaps /etc/compatibility-db or something.

I've just committed the changes to the SerialVersionUID tool to generate XML files.

The following SVUID database files were added to the CVS repository:

U etc/svuid-db/svuid-14.1.3.0.GA.xml
U etc/svuid-db/svuid-14.1.4.0.GA.xml
U etc/svuid-db/svuid-50.1.3.0.GA.xml
U etc/svuid-db/svuid-50.1.4.0.GA.xml

Forgot to mention it in the previous post - the database was based on the jars found in jboss-cache-dist-1.4.0.GA.zip and jboss-cache-dist-1.3.0.GA.zip located on sf.net.

I've just commited the test cases for JBossCache 1.3.0 GA and 1.4.0 GA.
Those tests can by executed by using the "compat-tests" target. Both tests fail due to issues with jgroups and some issues with jbosscache classes - see below. Please, advise whether I should mark those failures as expected.

Failed classes when testing against 1.4.0 GA:

org.jboss.cache.marshall.JBCMethodCall
org.jboss.serial.objectmetamodel.DataContainer
org.jgroups.Message
org.jgroups.blocks.DistributedHashtable
org.jgroups.blocks.DistributedLockManager$LockDecree
org.jgroups.blocks.NotificationBus$Info
org.jgroups.blocks.ReplicatedHashtable
org.jgroups.blocks.ReplicatedTree$Node
org.jgroups.blocks.ReplicatedTree$Request
org.jgroups.blocks.VotingAdapter$VoteResult
org.jgroups.demos.Draw$DrawPanel
org.jgroups.demos.MyCanvas
org.jgroups.demos.QuoteClient
org.jgroups.demos.TotalOrder
org.jgroups.demos.wb.SendDialog
org.jgroups.protocols.ENCRYPT$EncryptHeader
org.jgroups.protocols.FD_PROB$FdHeader
org.jgroups.protocols.FD_SIMPLE$FdHeader
org.jgroups.protocols.JMS$JMSAddress
org.jgroups.protocols.PerfEntry
org.jgroups.protocols.SMACK$SmackHeader
org.jgroups.protocols.TOTAL$Header
org.jgroups.protocols.TunnelHeader
org.jgroups.protocols.VIEW_SYNC$ViewSyncHeader
org.jgroups.protocols.pbcast.JoinRsp
org.jgroups.protocols.pbcast.STATE_TRANSFER$StateHeader
org.jgroups.util.List
org.jgroups.util.TimedWriter$Timeout

Failed classes when testing against 1.3.0 GA:

org.jboss.cache.OptimisticTreeNode
org.jboss.cache.optimistic.DefaultDataVersion
org.jboss.cache.optimistic.FqnComparator
org.jgroups.ChannelException
org.jgroups.MergeView
org.jgroups.Message
org.jgroups.View
org.jgroups.ViewId
org.jgroups.blocks.DistributedHashtable
org.jgroups.blocks.DistributedLockManager$LockDecree
org.jgroups.blocks.NotificationBus$Info
org.jgroups.blocks.ReplicatedHashtable
org.jgroups.blocks.ReplicatedTree$Node
org.jgroups.blocks.ReplicatedTree$Request
org.jgroups.blocks.RequestCorrelator$Header
org.jgroups.blocks.VotingAdapter$VoteResult
org.jgroups.debug.Debugger
org.jgroups.demos.Draw$DrawPanel
org.jgroups.demos.MyCanvas
org.jgroups.demos.QuoteClient
org.jgroups.demos.Topology
org.jgroups.demos.TotalOrder
org.jgroups.demos.applets.DrawApplet
org.jgroups.demos.wb.GraphPanel
org.jgroups.demos.wb.SendDialog
org.jgroups.demos.wb.Whiteboard
org.jgroups.protocols.ENCRYPT$EncryptHeader
org.jgroups.protocols.ExampleHeader
org.jgroups.protocols.FC$FcHeader
org.jgroups.protocols.FD$FdHeader
org.jgroups.protocols.FD_PROB$FdHeader
org.jgroups.protocols.FD_SIMPLE$FdHeader
org.jgroups.protocols.FD_SOCK$FdHeader
org.jgroups.protocols.FLOW_CONTROL$FCInfo
org.jgroups.protocols.HTOTAL$HTotalHeader
org.jgroups.protocols.JMS$JMSAddress
org.jgroups.protocols.PerfHeader
org.jgroups.protocols.SMACK$SmackHeader
org.jgroups.protocols.StateTransferRequest
org.jgroups.protocols.TOTAL$Header
org.jgroups.protocols.TOTAL_OLD$TotalHeader
org.jgroups.protocols.TransportedVectorTime
org.jgroups.protocols.TunnelHeader
org.jgroups.protocols.UNICAST$UnicastHeader
org.jgroups.protocols.WanPipeAddress
org.jgroups.protocols.pbcast.Digest
org.jgroups.protocols.pbcast.GMS$GmsHeader
org.jgroups.protocols.pbcast.JoinRsp
org.jgroups.protocols.pbcast.NakAckHeader
org.jgroups.protocols.pbcast.STABLE$StableHeader
org.jgroups.protocols.pbcast.STATE_TRANSFER$StateHeader
org.jgroups.stack.IpAddress
org.jgroups.util.List
org.jgroups.util.TimedWriter$Timeout

I've just merged org.jboss.tools.SerialVersionUID and org.jboss.cache.compat.SerialVersionUIDUnitTestCase into HEAD.
From an earlier comment on this discussion I understand that testing 2.x.x
against 1.x.x doesn't make sense except in some rare cases. So I haven't merged the xml database file - please, let me know if you want me to add them to HEAD.

Are the failures above on HEAD? There is no point comparing HEAD (2.x.x) against 1.x.x classes as you mentioned.

No - the failures above are produced by comparing Branch_JBossCache_1_4_0 to 1.4.0 GA and 1.3.0 GA. I, do understand that 2.x.x is incompatible with 1.x.x as already discussed earlier on this thread.

Most of the JGroups exceptions are meaningless, because JGroups doesn't use Java serialization anyways. I know that some JGroups exceptions *might* get serialized when used with method calls, but I don't see any of them in the output.
Manik ?