Hi, I have an issue building the mamacpp project using Visual Studio 2010 and 2012. The configuration is in Win32 Debug and Release. In both cases I compile commonc, commoncpp, mamac and then mamacpp.

Debian/Ubuntu try to follow recent JVMs. OpenMAMA wiki suggests JDK 1.6 and above. The next stable releases of Debian and Ubuntu (end of 2014/early 2015) may have OpenJDK 1.8, the previous OpenMAMA re

SCons also doesn't seem to understand DESTDIR. prefix is only half the story. When building a package, the tools set DESTDIR to have the "install" file-set deployed to some temporary tree. E.g. with a

The SCons build is not setting SONAME for the shared libs (this was set correctly with the autotools build), e.g. $ objdump -p ./objdir/mama/c_cpp/src/c/.libs/libmama.so |grep SONAME doesn't give any

I notice bits of the autotools build system are still present in 2.3.x. Are they still supported in any sense? Are there new source files or build tasks that are described in SCons but not in the 2.2.

Some of the source files in the repository and the release tarball have the executable bit set. This is a quick way to see them: find . -type f -perm /111 | grep -v ^...git Can you please correct this

The 2.3.0 source download includes some things that should not be present, in particular, files matching these patterns: ._* .DS_Store Also, the previous source release had the ".git" tree in it by mi

For OpenMAMA 2.3.0 with QPID, should the package depend on libqpidclient2-dev or also libqpidmessaging2-dev ? http://packages.debian.org/libqpidclient2-dev http://packages.debian.org/libqpidmessaging2

Hi all, I have OpenMAMA 2.3.0 Java Publisher along with Qpid proton 0.5 which keeps crashing when publishing for a mamalistenc client. I haven't had that before with other bridges. When I run it for s

- Retrieval of vector value from another message (field) was broken due to incorrect call to qpidmsgPayload_getVectorFoo() instead of field version in the ADD_VECTOR_FIELD_VALUE_TO_MESSAGE macro. Sign

Avis core dumps under the existing payload unit tests due to lacking NULL and invalid argument checks - Fix these so it runs cleanly (still fails aspects but that's preferable to coring). Signed-off-b

Repurposed the QPid subject construction code and utilised it within Avis to make it compatible. It does seem like this would serve a better purpose as common code between all middleware that want to

Most of this work was conducted before QPID was fully implemented, but this might be useful to make Avis a viable alternative (or as a second reference bridge for testing purposes). Primary changes :-

Morning all, Just a quick note, I've had to do a force push on the next branch to resolve an issue with the last change (Avis refactoring fixes). Hopefully it shouldn't cause any issues for people, an

Afternoon all, Just a quick fix to tidy up a few small issues I noticed with the scan-build tool I implemented in SCons. Basically, because of the way SCons sets up the environment, it wasn't passing

Changes to set default target to dist Updated clean to also clean down the MamdaLock Signed-off-by: Phil Preston <philippreston@...> --- mamda/java/build.xml | 4 ++-- 1 file changed, 2 insertions(+),

XCode 5.1 update includes LLVM/CLang 5.1 (CLang 3.4) which now fires a number of build errors. struct FieldUpdateTradeId struct FieldUpdateOrigTradeId each are declared twice in MamdaTradeListener cla

XCode 5.1 update includes LLVM 5.1 (CLang 3.4) which now fires a number of build errors. Number of files dealing with partid on multi participant feeds do not dereference the pointer to the last dot c

Also please note that there are unittests available for the fieldcache

Afternoon all, I'm starting to plan a merge for the feature-osx branch into next. From the testing I've performed it all looks fine, and I know Phil and a number of others have been working with it on