# Android Saripaar's last release tag is from 2015 and its Gradle line uses compile

> ragunathjawahar/android-saripaar is an Apache licensed Java rule-based form validation library for Android, annotation-driven and working with stock widgets. Its documentation has not moved with the platform: the install line names a Gradle configuration that no longer exists, the snapshot instructions point at a retired repository host, and the background validation path is a class the framework dropped.

**ragunathjawahar/android-saripaar** — GitHub describes it as UI form validation library for Android. The repository metadata lists Java as its primary language. The metadata lists the Apache-2.0 license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/ragunathjawahar/android-saripaar
- Stars: 3,185 · Forks: 456
- Language: Java
- License: Apache-2.0
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/ragunathjawahar-android-saripaar

## The last push was in December 2020 and the last release tag is from 2015

Two dates in this repository are five years apart, and they describe different things.

The three most recent releases are tagged `android-saripaar-2.0.3`, `android-saripaar-2.0.2`, and `android-saripaar-2.0.0`, dated September 2015, August 2015, and July 2015 respectively.

The last push to the master branch was on 2020-12-03.

So there are five years of commits above the newest tag. Whatever changed in that window is on the branch and not in any published artefact.

Two smaller details in the tag sequence. There is no `v` prefix; the version is carried as a prefix in a tag named after the artefact. And the sequence skips 2.0.1, jumping from 2.0.0 to 2.0.2 two days apart, with 2.0.3 following six weeks later.

The README also carries its own age markers. The copyright range in the license header ends in 2015, and the logo credit under it ends in 2015 as well.

None of that means the code is broken. It means the documentation, the install instructions and the platform APIs it names should all be read as a snapshot rather than as current guidance.

## The documented Gradle line uses a configuration name that no longer exists

There are three dependency snippets in the file, and the Gradle one is the shortest of them.

The Maven form names a group, an artefact, and a version placeholder:

```
<groupId>com.mobsandgeeks</groupId>
<artifactId>android-saripaar</artifactId>
```

The Gradle form is a single configuration line:

```
dependencies {
    compile 'com.mobsandgeeks:android-saripaar:(latest version)'
}
```

The configuration name in that line is `compile`. That was the configuration Gradle itself used before it split dependencies into an API set and an implementation set, and it was removed outright in a later major version. A build using any current Gradle rejects that line rather than ignoring it.

So the most concise install instruction in the file is the one least likely to work, and the Maven form is the one that survives, since it does not name a configuration at all.

The version placeholder is a second problem in the same snippet. It is written as a parenthesised note rather than a real coordinate, so a reader has to substitute a version before the line means anything.

The repository also commits the Gradle wrapper, both the Unix script and the Windows one, alongside a wrapper directory, so a checkout does pin a Gradle version. The documentation simply does not say which one.

## Snapshot instructions point at a retired repository host

The section on snapshots is a build file fragment to paste into a project, and two of its lines name infrastructure that no longer serves artifacts.

```
repositories {
    jcenter()
    maven {
        url "https://oss.sonatype.org/content/repositories/snapshots/"
    }
}
```

The first repository is JCenter, which was a Bintray-hosted repository that went read-only and then shut down. Any build that still resolves dependencies from it will fail on a repository that does not answer.

The second is the legacy Sonatype snapshot path, nested under the old public host rather than the service that replaced it. That is the URL shape from before Sonatype moved its publishing flow behind a signed-in service.

So the only route to a snapshot build points at two endpoints that have both been retired, and the wrapped instruction in all projects is the same wrapper around both.

The publishing side of the repository is a Gradle script for pushing to Maven, which is consistent with a project set up for manual publishing rather than for automated snapshot deployment.

## The asynchronous validation path is an AsyncTask

The library makes a point of not making you think about threading, and it offers two modes for it.

A synchronous call validates and returns the result through the listener callbacks:

```
validator.validate();
```

An asynchronous call takes a boolean and runs the work on a background `AsyncTask` instead.

`AsyncTask` is the mechanism the file names, and that class was the framework's answer to threading before it was deprecated in favour of the concurrency utilities and then removed. A library whose stated selling point is that you do not have to worry about threading is expressing that point through a class the platform no longer ships.

The two validation modes are separate from this and are named in the feature list as BURST and IMMEDIATE. Burst validates on demand, which is what the fourth step of the quick start does. Immediate validates as the user interacts, and it is also one of the two cases in which the `@Order` annotation becomes required, along with the ordered validation calls on a view.

The annotation set itself is small and readable, with not-empty, email, password, confirm-password, and a checkbox rule that takes a custom message.

## Continuous integration is a Travis configuration and nothing else

The repository root has one continuous integration file and it is a Travis configuration.

There is no GitHub Actions workflow directory. So a project whose last push was in 2020 was built on the service that most of the Java open source community moved away from during that same period.

The rest of the root is a conventional Android library layout. There is a `saripaar/` directory for the library and a `saripaar-tests/` directory beside it, so the tests are a second module rather than a folder inside the library. A `config/` directory holds shared build configuration, and `gradle.properties` and `settings.gradle` sit alongside `build.gradle`.

Publishing is handled by a Gradle script dedicated to pushing to Maven, which means the path from a commit to a published artefact involves running a task rather than a pipeline.

One more root entry is not build-related: a logo image file, which matches the logo credit in the README.

## The ProGuard rules keep an annotation the guide never explains

There is a short section on shrinking, with two rules to add to a project's ProGuard configuration file.

```
-keep class com.mobsandgeeks.saripaar.** {*;}
-keep @com.mobsandgeeks.saripaar.annotation.ValidateUsing class * {*;}
```

The first keeps the library's classes from being removed or renamed, which is the ordinary requirement for a library that reflects over its own types.

The second keeps any class annotated with an annotation called `ValidateUsing`, in the library's annotation package.

That annotation does not appear anywhere else in the file. The quick start shows four annotation types on widgets, the required-order annotation is named, and the feature list mentions custom annotations and an extensible rule set. `ValidateUsing` is named once, in a ProGuard rule, and never explained.

So either the annotation is part of the public surface and the guide omits it, or it is an internal marker that the keep rule preserves defensively. A reader adding the rules will not know which, and the difference matters if they are trying to use it.

The rules are also the only place the library's own package name is written out in full, which is how a reader can confirm that the namespace is not the repository's owner.

## The Maven group is com.mobsandgeeks while the repository lives under another owner

The coordinates and the repository do not share a name, and the file does not comment on it.

The Maven group is `com.mobsandgeeks`, the artefact is `android-saripaar`, and the license header credits Mobs and Geeks with a copyright range from 2012 to 2015. The ProGuard rules use the same namespace.

The repository is under a different owner entirely, and the links in the reference section point at paths under that owner with the library source nested inside a directory named for the library.

So the package namespace, the copyright holder, and the repository owner are three different names for one project. That is normal enough for a project that changed hands, and it matters in one concrete place: a build that resolves the artefact by coordinates will get the code from that namespace, not from the repository name.

The reference links are unusually specific for a README. Rather than linking to documentation pages, the definitions point at the annotation directory, at the single source file that holds both the validator and the listener interface, and at the separate repository holding the country-specific extension annotations.

## A superlative claim, a list of users, and a wiki as the manual

Three parts of the file are worth reading as period pieces.

The opening says the library is simple, feature-rich, and rule-based, and then states that it is the simplest UI validation library available for Android. That is an assertion rather than a measurement, and it is the kind of claim that dates a file.

The reasons given for choosing it are mostly architectural rather than comparative. It is built on a validation framework from Apache Commons, it validates declaratively with annotations, it allows custom annotations, it works with stock Android widgets with no custom view dependencies, and it isolates the rules from the views. It also says it is compatible with other annotation-based libraries, naming ButterKnife, AndroidAnnotations, and RoboGuice, all three of which are annotation-injection libraries rather than validation libraries.

Then there is a list of apps using it, twelve of them across three columns, with an invitation to send a Play Store URL to be added to it.

The manual is elsewhere. The file says to visit the wiki for a complete guide, and the only other reading material is a short video about how version 2 evolved from version 1.

## Conclusion

Android Saripaar suits someone who wants declarative form validation on stock Android widgets with no custom views, and the annotation model and the two validation modes are still a coherent design. Read the documentation with its age in mind, because the last push to the branch was on 2020-12-03 and the most recent release tag is from September 2015. That date decides the practical questions: the documented Gradle configuration name has not been valid for several major Gradle versions, the snapshot repository it points at has been retired, and the asynchronous path is built on a class the Android framework dropped. If you are starting something new on a current Android toolchain, check whether a maintained alternative exists before committing to this one.

## FAQ

### What is Android Saripaar and how is it used?

It is an Apache licensed Java form validation library for Android, rule-based and annotation-driven, working with stock Android widgets and no custom view dependencies. You annotate the fields, create a Validator, implement a ValidationListener, and call validate, with the result delivered through the listener callbacks. It supports two modes, BURST and IMMEDIATE.

### How do I add Android Saripaar to a Gradle build?

The documented line is dependencies { compile 'com.mobsandgeeks:android-saripaar:(latest version)' }. The configuration name in that line predates the split between API and implementation dependencies and has since been removed from Gradle, so a current build needs a different configuration. The Maven form in the file uses no configuration name at all.

### Is Android Saripaar still maintained?

The last push to the master branch was on 2020-12-03. The most recent release tag, android-saripaar-2.0.3, is dated 2015-09-18, and the ones before it are from July and August 2015. Five years of commits sit above the newest published tag.

### What are BURST and IMMEDIATE modes in Android Saripaar?

Two validation modes. Burst validates when you ask it to, through the validate call. Immediate validates as the user interacts with the fields. The required-order annotation is needed only for the ordered validation calls on a view, or when using IMMEDIATE mode.

### Where are country-specific validation annotations for Android Saripaar?

In a separate project called Saripaar X, which the file describes as being in its early stages and needing contributors. The README points at that repository rather than shipping the extensions itself, and its own reference links point at the annotation directory and at the source file holding the validator and the listener interface.

## Sources

- [Official README](https://github.com/ragunathjawahar/android-saripaar#readme)
- [Project repository](https://github.com/ragunathjawahar/android-saripaar)
- [Release notes](https://github.com/ragunathjawahar/android-saripaar/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ragunathjawahar-android-saripaar