Thanks again for the suggestion. As for the rest of your response: the main reason I was asking is that I have not upgraded my UIMA to 2.4.2 or even 2.6.0 because there is no release of uimacpp for those versions. If I understand your response correctly, it seems that even though uimacpp is versioned at 2.4.0 it should work just as well is with uimaj-as 2.6.0?
Of course, at least one feature request would be to keep the dependencies up to date, for example, the dependency on APR < 1.5. While the change of the build-script isn't that hard, it does make it harder to have newcomers to uimacpp adopt it. Another feature request: make it possible to load annotators from shared libraries without having to change the LD_LIBRARY_PATH: e.g., make it possible to specify a full / relative path in the annotator descriptors instead of just a library name. Where should I report these feature requests? Thanks again! Egbert On Tuesday, July 22, 2014 05:04:36 PM Eddie Epstein wrote: > Good to hear the build worked. UIMACPP implements only a core subset of > UIMA functionality, basically the CAS API and the ability to create > primitive and aggregate analysis engines. There are also two alternative > methods to integrate native code wrapped with uimapp with a uimaj pipeline: > a JNI interface and a JMS service interface. I am not aware of any changes > to the CAS API or to UIMA-AS that stop uimacpp from working, nor of any new > feature requests for uimacpp. > > Regards, > Eddie > > On Tue, Jul 22, 2014 at 3:38 PM, Egbert van der Wal <[email protected]> > > wrote: > > This helps indeed. A weird hack, but at least the configure script > > completes > > and the build succeeds. Thanks a lot! > > > > I noticed there haven't been any commits to the uimacpp repository in > > 2012. It > > is indeed the case that there is noone actively working on it or has > > development been moved to a different repository? > > > > I have also been able to run the precompiled binaries, but that of course > > references the non-system libraries bundled with the package and since my > > annotators are also linking against the system ICU library, this will > > probably > > result in conflicts. > > > > Kind regards, > > > > Egbert > > > > Op dinsdag 22 juli 2014 09:30:41 schreef Eddie Epstein: > > > Looking at a build on RHEL, jni.h was resolved with: > > > --with-jdk="/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/include > > > -I/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/include/linux" > > > which follows the instructions in README.4src > > > > > > I had built ICU [and all other dependencies] and installed it in a > > > > private > > > > > directory by configuring with --prefix command. Changing uimacpp's > > > configure to use icu-config looks interesting. > > > > > > Hope this helps, > > > Eddie > > > > > > > > > > > > > > > On Tue, Jul 22, 2014 at 2:51 AM, Egbert van der Wal <[email protected]> > > > > > > wrote: > > > > Hi, > > > > > > > > I've been trying to add an annotator in C++ to an Annotation Engine in > > > > Java. > > > > However, building UIMA-CPP is not a trivial task, so it seems. > > > > > > > > So far, I've identified dependencies on ActiveMQ-CPP, APR, a Java JRE, > > > > Xerces > > > > and ICU. Maybe there's more key dependencies but those do not appear > > > > to be > > > > > > a > > > > problem on Ubuntu. > > > > > > > > libxerces was easy to fix as a compatible version is in the Ubuntu > > > > repository. > > > > > > > > APR is harder: Ubuntu 14.04 ships with 1.5.x while the configure > > > > script > > > > checks > > > > for 1.2, 1.3 or 1.4. Hacking the configure-script to also accept 1.5.x > > > > works > > > > but I didn't get to compiling yet so I don't know about the > > > > API-differences > > > > and if this will work. > > > > > > > > ActiveMQ-CPP is not in the Ubuntu repository. I had to locate and > > > > built > > > > this > > > > myself, but this actually didn't prove to be so hard. > > > > > > > > ICU is harder. The configure script wants a --with-icu path, but then > > > > assumes > > > > other facts. In Ubuntu, icu-config is located in /usr/bin while the > > > > header > > > > > > filers are located in /usr/include/x86-64-linux-gnu/unicode/. The > > > > configure- > > > > script seems to have problems to recognize this difference. I would've
