I've made changes to add support for Logback on Android. It omits some features, including JMS and Grroovy configuration, but works otherwise (AFAIK). I'm hoping it will eventually make its way into the main line somehow. I've read the page at http://articles.qos.ch/contributing.html, but the convention for a feature like this is unclear. I know at the very least that I need to fork ceki/logback, but then do I add my changes to the fork itself? or a branch of the fork? Thanks.
Hi Tony, Thanks for the heads up. It's hard to say how logback-android changes would be integrated into the my git repository. I would imagine that the changes for running logback on the android platform would be rather pervasive. It follows that logback-android would be packaged as a separate project. This raises the question of pulling changes from my repository into your own. Git is very good in merging changes. I've never had to maintain two closely related but still distinct projects. Are your changes available somewhere? -- Ceki On 07/07/2011 1:11 AM, Tony Trinh wrote:
I've made changes to add support for Logback on Android. It omits some features, including JMS and Grroovy configuration, but works otherwise (AFAIK). I'm hoping it will eventually make its way into the main line somehow.
I've read the page at http://articles.qos.ch/contributing.html, but the convention for a feature like this is unclear. I know at the very least that I need to fork ceki/logback, but then do I add my changes to the fork itself? or a branch of the fork?
Thanks.
Hi Ceki, The changes are not as pervasive as one might expect. There are only a handful of files that are modified. Anything that cannot be supported in Android is omitted from the build (including the features I previously listed). There is no Android-specific code (e.g., calls to the android.os package). The most significant change is the addition 4 small classes to replace the Introspector class (and friends) used in PropertySetter. I had to roll my own since Android doesn't support the necessary packages, and it was pretty straightforward since only a small portion of the class is needed. I'm ready to check in my changes, but I just wasn't sure where to put it: the fork itself or a branch of it? Skimming the other logback forks, I didn't really see a convention (although I did see some branch-of-fork usage). Regarding merging into your git repo... My original vision was to build either a standard JAR or an Android JAR from Maven using a single code repository, and this is possible (from what I can tell) using Maven profiles and possibly some minor refactoring of a few classes. However, if you believe logback-android should be kept as a separate project (like slf4j-android), I can certainly maintain that. Thanks, Tony
participants (2)
-
Ceki Gülcü -
Tony Trinh