On wiring up continuous integration amongst other things about dbus-java HOT 1 CLOSED

This project is active, more or less.
I'm the only maintainer right now.

The original dbus-java was developed by Matthew Johnson around a decade ago and was no longer maintained.

As I needed dbus for one of my private projects and wanted to have a version available in maven central, I forked the original project and cleaned it up, introduced junit and slf4j.
There were also a few pull requests/bug reports/feature request which have been merged.

Currently there are 4 releases (2.7.1 - 2.7.4) with only a few changes and fixes. The version scheme was re-used from the original library which had version 2.7.0.

Version 2.7.5 is also ready to go and will be released soon.

I also started developing version 3.0.0 with some major changes in used datastructures, packages, class naming, and thread handling (that's why it is version 3.0.0, it is no longer a 'drop-in' replacement for old 2.7.x versions). I also fixed the unit tests and added some missing DBus interfaces.

I'm not sure when 3.0.0 will be released. I don't have much time atm and dbus-java has not the highest priority right now (2.7.x is working in most cases).
It's also very difficult to test the whole thread and parallel running stuff to find race-conditions or missing synchronization.

To answer your question about continues integration:
If you want to do the continues integration stuff, it's ok for me.
But as this project is not changed very frequently (only a few commits per month or even per half year), I don't think continues integration will help much (except of providing SNAPSHOT builds now and then).

This will also answer the question about regular releases .. what to release if nothing has changed?

Gradle is another thing:
I don't use it because I don't like it. I have maven and I'm happy with it and will stick with it.
It works for everything I need in this project. Why to re-invent the wheel, if everything is fine just like it is?

from dbus-java.