Gradle

In my previous article I published information about publishing JAR/AAR library to the Maven Central Repository. A few steps of that process were automated, but a few of them were still manual. I mean closing and release process which had to be done by manual clicking on the Sonatype website. Fortunately, it’s possible to automate it. In order to do that, I used gradle-nexus-staging-plugin developed by Codearte. Thanks to this plugin I could get rid of the remaining manual steps left in the release process. ...

Introduction As a Java/JVM/Android developers we rely on the work of other people through frameworks and libraries. Many of them are open-source. Most of the developers are consumers of such projects. What if we would like to create our own library and distribute it to other developers? We can always create it and share a *.jar or *.aar file with others. Drawback of such solution is the fact that source of distribution may not be trusted. We also have problems with versioning. Consumers of the library have to constantly download and update their files. It’s much better to publish our library to Maven Central Repository and allow others to easily and seamlessly add it as an external dependency to pom.xml file (in case of Maven) or build.gradle file (in case of Gradle). In such case, dependency is managed by the appropriate build system and distributed via trusted source. This may be not easy for the first time that’s why I decided to collect information related to this topic in a single article. Let’s see how to do this. ...

I recently wrote a new library called NeuroSky Android SDK. It’s used for writing Android apps using signals of the brain waves received from the NeuroSky MindWave Mobile headsets. Probably I’ll write a separate article about it because it’s quite interesting topic. This library uses ThinkGear library, which is distributed by the NeuroSky as a *.jar file, so I couldn’t use it as a Gradle or Maven dependency in my project and I had to put this *.jar file into the lib directory and link it in the build.gradle file. Moreover, I wanted to create a library, which can be added to the project as a single Gradle dependency without messing around with additional *.jar files or custom configuration. Due to this fact, I decided to create a fat *.aar file and deploy it to the Maven Central repository. For those who are not familar with Android, *.aar is an Android version or *.jar file, which can be used as library in the project. I didn’t want to reinvent the wheel, so I searched for the different solutions. Unfortunatey, a few of them didn’t work, but luckilly I’ve found what I wanted. It’s fat AAR Gradle Plugin developed by Mobbeel company. ...

During development process, we often write unit and integration tests. While unit tests verify corectness of the small pieces of code, integration tests verify software as a whole project and sometimes can treat it as a black box where concrete results are expected. During development of the REST API, we can write integration tests for such API with REST Assured. Integration tests are usually slower, because they need to start the server and sometimes do other stuff. That’s why it’s good to separate their execution from regular unit tests. On the CI server we can even have separate job for them. ...

I recently wrote a simple java app with Dagger 2 as a DI container and Gradle as a build system. I wanted to generate unit test coverage report for this app, so I used Jacoco. In my build.gradle file I configured JaCoCo as follows: plugins { id 'jacoco' } jacocoTestReport { reports { xml.enabled = true html.enabled = true } } Now, I could type: ./gradlew test jacocoTestReport Report was generated in build/reports/jacoco/ directory. I noticed that report includes Java code generated by Dagger during the compilation. I didn’t want to include it in the report because it doesn’t really make any sense to write unit tests for generated code. ...