So I figured out what the problem was, and believe that the new code is pretty stable. At least it's functional, anyway! :) I have created a new issue [AMQNET-68] to track this change.
Since this is a fairly significant modification, and includes several new files plus a new project assembly, what is the most practical approach to contributing it? I have coded this new addition against my code base, which has really started to diverge from the main trunk. I have logged several bugs, and contributed patches for them, and they are all included in my codebase. One of the more significant changes is the changing of namespaces [AMQNET-31], and a corresponding change made was changing the name of the assembly files. I changed the assembly names to include 'Apache' at the beginning (e.g., NMS.DLL is now Apache.NMS.DLL, NMS.ActiveMQ.dll is now Apache.NMS.ActiveMQ.dll). This became important to differentiate the Apache assemblies from the TIBCO assembly. The new assembly is named Apache.NMS.TIBCO.DLL. I also removed the vs2005-stomp.vcproj from the solution. This project is only needed by the vs2005-stomp-test.vcproj. To replace it, I added a new file in the vs2005-stomp-test.vcproj that will instantiate the proper ConnectionFactory for all of the STOMP unit tests. The gist is, how would you like the changes? I am using Perforce to track all of my changes, and I can generate a diff against the current trunk, but it will include patches for several other bugs. I also don't know how to show the removal of files. I would like to get these changes out there for others to start playing with. Once I have passed on this batch of changes, I will add another project for the unit test support for this new component. It will be modeled after the STOMP unit tests. Thanks, Jim Gomes Hiram Chirino wrote: > > Wow.. that's awesome! > > On 9/27/07, semog <[EMAIL PROTECTED]> wrote: >> >> FWIW, >> >> I am working on wrapping the Tibco C# client with the NMS APIs. It is >> almost complete. I have all of the interface mappings done, but I have >> having some minor issues with getting Tibco to pick up a message from a >> queue when it is sent back to client. Once it is worked out, I will >> contribute this new implementation to the community. >> >> This implementation will give a third direct provider for NMS: ActiveMQ, >> MSMQ, and now Tibco. I don't know what Tibco's client licensing is, so I >> may not be able to include their client assembly (TIBCO.EMS.DLL). You >> may >> need to acquire it separately. I don't know yet. >> >> I will update more as I make progress. >> >> - Jim > -- View this message in context: http://www.nabble.com/NMS-Provider-for-Tibco-EMS--tf2480565s2354.html#a12949721 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
