What is the proper Maven POM entries for Couchbase Lite Android EE


I am using NetBeans with Gluon JavaFX to build multi-platform APPS. Currently just trying to re-run the published Couchbase Lite Android EE demo in this environment.

Maven is throwing the following error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.8:purge-local-repository (default-cli) on project gluonapplicationcba1: Failed to refresh project dependencies for: com.gluonapplicationcba1:gluonapplicationcba1:jar:1.0-SNAPSHOT: required artifacts missing:
[ERROR] com.couchbase.lite:couchbase-lite-android-ee:jar:3.0.0
[ERROR] for the artifact:
[ERROR] com.gluonapplicationcba1:gluonapplicationcba1:jar:1.0-SNAPSHOT
[ERROR] from the specified remote repositories:
[ERROR] couchbase (https://mobile.maven.couchbase.com/maven2/dev/, releases=true, snapshots=true),

The relevant POM XML Elements currently set are as follows:

> <dependency>
>  <groupId>com.couchbase.lite</groupId>
>  <artifactId>couchbase-lite-android-ee</artifactId>
>  <version>3.0.0</version>
>  </dependency>
>  <repository>
>  <id>couchbase</id>
>  <url>https://mobile.maven.couchbase.com/maven2/dev/</url>
>  </repository>"

Thanks in advance for your consideration.

Michael Fene’

I’m a little unclear on whether this is for desktop Java or for Android. If the latter, my guess is that this tries to pull a .jar file. CBL-android is a .aar file. I think you need to add this:


The answer is: Yes. Gluon provides the ability to craft cross platform/cross device ; single code base applications/apps based on Java. (akin to Xamarin; but embraces linux as a target (in addition to Android/ios)… Uses Oracle Graalvm to compile java (and other jvm based languages) to native.


I am still quite the noobie when in comes to Java and Java Android.

BTW - Just took receipt of your Programming Android book; and interestingly I already had Enterprise Android in my personal library already.

That said…still a noobie.

Gluonhq has crafted a development environment based on IntelliJ and/or Netbeans to AOT compile java (and other jvm based languages) to native targets including Android, IOS, Linux (my intended targets); as well as WINxx.

But because of my noobie-ness I dont know how to link/deploy an aar library (in this case couch-base-lite-android-ee) into the development environment and tool chain to facilitate deployment to (android) in this case.

The whole point of the Gluon approach is analogous to Xamarin (platform agnostic UI) bound to native components for deployment.

I have read that one can uncompress the aar and (convert/morph it) to behave as a jar library.

Any guidance/leg-up is appreciated.



I am unfamiliar with Gluon but it may not provide a simple answer here. Couchbase Lite functionality is mostly written in C/C++ and compiled to a (non-portable) native binary. Somehow, the “portable” code is going to have to figure out which native binary to use and how to load it.

You are right that you can uncompress an aar. It is just a zipped directory structure. I’m not sure that’s going to help, though…

There is another developer, in these forums, attempting something very similar. If you look around this mobile channel, you should be able to find him. You might benefit from his experience.

… and sincerely hope you enjoy the books! They are both a bit dated, at this point. You might want to have a look at the more recent one that I did with Pierre-Olivier Laurence and Amanda Hinchman-Dominguez: Programming Android with Kotlin.


Thanks for that guidance. I did see the new book; just reticent to add another language to the 10+ already in my head (its like bee’s flying around in one’s head?!)

Presumably those native binaries you are referring to are bound at run-time; and the couchbase logic is detecting android h/w architecture to determine which native binary to bind on the fly. Do I have this correct?



Yes… Sort of like that. The strategy that the Android bindings use is substantially different from the strategy that the JVM bindings use. Have a look at the code in CouchbaseLiteInternal.

Actually figuring out which version of the native binary to use is largely something that the OS takes care of. The naming conventions are different, on different OSs (.so, .dll, lib, etc). Android handles the whole thing. For the JVM platform, we have to unpack the native lib to the file system and then figure out which one to use. The algorithm is not very general, because we can only support OS/ABI combinations for which we’ve built a version of LiteCore.


Thanks again for your communication.

So if I come up with logic that exploits a construct analogous to this:

static {

To Selectively Load the correct native library based on the architecture; that ought to do the trick?



Well… libLiteCore is not in the support directory of the distribution. … and that definitely won’t work for Android.

I think that something along these lines might work… but you are going to need it to be quite a bit more complex than that.

Blake…thanks again for your reply and guidance.