Upload Project to Maven Repository

[rockstarartist]

Please create a project repository in Maven to allow maven-android-plugin users to develop their applications with the maven dependency management tool.

More Information on how to do this can be found here:

http://maven.apache.org/repository/index.html

Thank you.

[developernotes]

Hi rockstarartist,

You can install the SQLCipher into your local maven repository. The maven-android-plugin supports resolving the native libraries as well. More information can be found here:

http://code.google.com/p/maven-android-plugin/wiki/NativeLibsAsDependencies

[jeffdcamp]

This would still be nice to have in a community REPO (such as Maven's Central Repo). Right now, in order to use sqlcipher in a shared project, we have to put the sqlcipher jar and so files into our own Nexus Repo. Then we can add our dependencies into our pom.xml file.

While we got it to work for us, it can be much more difficult for others to setup their own shared repo.

In a nut shell, it would be nice to just add sqlcipher dependencies (to a Maven Android project), change some imports, add the loadLibs, add the password parameter, DONE.

[developernotes]

Hi jeffdcamp,

We can certainly look into uploading SQLCipher for Android to a public maven repository in the future. Thanks for your feedback!

[Thorbear]

Has this issue been looked any more into? Like jeffdcamp noted above, it would be very nice to have this in Maven's Central Repository for shared projects.

[developernotes]

Hi Thorbear,

At this time we have not focused on providing access to SQLCipher for Android via maven.

[jeffdcamp]

I wonder if this should become more of a priority because:

1. The Android build system is changing to use Maven Repositories and Gradle (http://tools.android.com/tech-docs/new-build-system) (Gradle will depend on libraries from the Maven Central Repository)
2. There are a LOT of Maven Android projects that could use this now.

[developernotes]

Hi jeffdcamp,

The update to the Android build system is interesting. Currently they don't support the NDK, which appears on their radar, but would be a requirement for this project. Certainly something to keep an eye on. Thanks!

[svenjacobs]

Is this still being looked at?

I think development of projects using SQLCipher would be greatly simplified if SQLCipher would be available in official Maven repository. At the moment this is a lot of manual work.

[developernotes]

Hello svenjacobs,

At this time we haven't modified the build/integration process. There is a fair amount of work involved in the main build process as this project is NDK based, however I can understand the desire for maven integration. That said, we are open to pull requests should you be interested in approaching it before we do.

[commonsguy]

Your build process is a trifle unusual for an Android project. Trying to wrangle it into something that is Maven-aware is probably not going to be fun.

Instead, you can create a separate Android library project that can be published as an AAR, that contains just the compiled binaries and assets. I have set up a proof of concept project for this. I am happy to explain more about how it works, how you can alter it to fit your needs (e.g., Maven group and artifact names), etc.

Then, your overall release process would involve copying over the new binaries into your equivalent of this project, and running a gradle command to publish the AAR, to go along with how you release the .ZIP file today. You would also need to document how others can consume this AAR, plus make decisions on where you want to publish it (Maven Central? your own artifact repo? somewhere else?).

We can discuss this further here, in issues on the GitHub repo for the proof of concept, on sqlcipher-users, by private email, etc.

[developernotes]

Your build process is a trifle unusual for an Android project. Trying to wrangle it into something that is Maven-aware is probably not going to be fun.

Yes, the realities of the native interop layer. ;-)

Instead, you can create a separate Android library project that can be published as an AAR, that contains just the compiled binaries and assets. I have set up a proof of concept project for this. I am happy to explain more about how it works, how you can alter it to fit your needs (e.g., Maven group and artifact names), etc.

Thank you for providing a template to base this off of. We've generally preferred to provide the binary package from a single canonical source so there isn't confusion about where to get them, however a maven repository maybe the preferred route for simplicity going forward. In general, while I don't feel integrating SQLCipher for Android is difficult at this point, adding a line to a pom.xml or gradle file is certainly easier. We will take a look at implementing this. Thanks!

[commonsguy]

It's not even so much a matter of being easier as it is Google telling people to stop using JARs (let alone bare NDK .so's). So far, they have only been telling people that on the adt-dev Google Group and in various StackOverflow answers, but they will be continuing to espouse this position throughout 2014 and beyond. Their expectation is that everything will run through artifacts, particularly once Eclipse defers to Gradle for builds. Hence, I would expect a steady increase in the demand for SQLCipher for Android to be available as an artifact, not only for ease, but because Google is telling developers to expect dependencies to be artifacts.

[developernotes]

Thanks Mark, that is also good to know as it will help from our planning perspective.

[albinpoignot]

Come here just to make a "+1". Currently using Gradle, I know that native libs is not usable with it. However, I just would like to give you another point of view for your sentence :

In general, while I don't feel integrating SQLCipher for Android is difficult at this point, adding a line to a pom.xml or gradle file is certainly easier.

I am OK with you about the simplicity of adding a JAR to a project. I am working for a company and so your library will be shared among many developers. Having to bundle the jar and other stuff is not efficient (including binary content inside a repo, having developpers to be aware of the dependencies, ...). As you know, pom.xml and build.gradle files are here to centralize the dependencies of a project so team members will easily know what is included in the project AND a new dev can easily comes working on the project. What I want to say is that your project is a "particular case" in libraries inclusion and some people may not use it because of that (even if it's a really great solution).