SLF4J on the Google Android Platform

[tm-2]

Dear all,

we are happy to announce that we have finished developing a new logger
binding for SLF4J so that it can be directly used on the Google Android
Platform. This new binding (implementation of org.slf4j.Logger)
basically maps all log requests to corresponding logging methods calls
that are provided on the Android platform. The implementation is quite
slim. In fact, that Jar which bundles both the API part and the
implementation is less than 30kB in size (note that both need to be
bundled in one file because of the way Andoid processes JARs into APKs).

The following lines are rather addressed to the SLF4J maintainers.
We have not yet published the project because we would like to
contribute it to the SLF4J community, under the same license terms. What
do you think?

Best,
Thorsten

--
Thorsten Möller
University of Basel
Department of Computer Science
Database and Information Systems Group
Bernoullistrasse 16, 4056 Basel, Switzerland
http://informatik.unibas.ch 


_______________________________________________
user mailing list
[hidden email]
http://www.slf4j.org/mailman/listinfo/user

[Ceki Gulcu]

Hello Thorsten,

Sounds great. The easiest approach to integrate your contributions would be to
fork slf4j on github and let us know when you are done so that we can study the
results.

To fork SLF4J, create a user id on github and then go to
http://github.com/ceki/slf4j and click on fork. You should then locally clone
your fork and publish the results into the forked version.

Holler if you need help,

Cheers,

Thorsten Möller wrote:

> Dear all,
>
> we are happy to announce that we have finished developing a new logger
> binding for SLF4J so that it can be directly used on the Google Android
> Platform. This new binding (implementation of org.slf4j.Logger)
> basically maps all log requests to corresponding logging methods calls
> that are provided on the Android platform. The implementation is quite
> slim. In fact, that Jar which bundles both the API part and the
> implementation is less than 30kB in size (note that both need to be
> bundled in one file because of the way Andoid processes JARs into APKs).
>
> The following lines are rather addressed to the SLF4J maintainers.
> We have not yet published the project because we would like to
> contribute it to the SLF4J community, under the same license terms. What
> do you think?
>
> Best,
> Thorsten
>

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
_______________________________________________
user mailing list
[hidden email]
http://www.slf4j.org/mailman/listinfo/user

[tm-2]

On Thursday, October 22, 2009 4:46 PM [GMT+1=CET],
Ceki Gulcu <[hidden email]> wrote (with possible deletions):

> Sounds great. The easiest approach to integrate your contributions
> would be to fork slf4j on github and let us know when you are done so
> that we can study the results.
Ok, I'll try. Good chance to start working with Git ;-)

> To fork SLF4J, create a user id on github and then go to
> http://github.com/ceki/slf4j and click on fork. You should then
> locally clone your fork and publish the results into the forked
> version.
I can already tell you that I needed to merge the SLf4J-API project and
the new binding implementation into one (Maven) project. The reason is
rather complicated to explain. In short, it is due to the fact that
SLF4J API removes the dummy impl.* classes during the build from the
target Jar, which is not compatible with the Android Dexer. If Git
supports something like symbolic links for files and directories it
could be "cleanly" integrated, otherwise, the code of the API part needs
to be duplicated. Do you know if Git supports symbolic links, or
something equivalent to svn:externals?

-- Thorsten


_______________________________________________
user mailing list
[hidden email]
http://www.slf4j.org/mailman/listinfo/user

[Ceki Gulcu]

I think git supports Unix symbolic links but not all operating systems support
sym links which makes sym-link in git pointless. I am not aware of a git
equivalent for svn:externals.

However, you could modify the build file for the slf4j-android* module so that
it copies the source files it needs from the slf4j-api module. This is pretty
easy to do with an Ant target which you can then add to the Maven build life
cycle.  By the way, initial versions of SLF4J where each binding also contained
the contents of slf4j-api used to work exactly this way.

* feel free to suggest a better name.


Thorsten Möller wrote:

> On Thursday, October 22, 2009 4:46 PM [GMT+1=CET],
> Ceki Gulcu <[hidden email]> wrote (with possible deletions):
>
>> Sounds great. The easiest approach to integrate your contributions
>> would be to fork slf4j on github and let us know when you are done so
>> that we can study the results.
> Ok, I'll try. Good chance to start working with Git ;-)
>
>> To fork SLF4J, create a user id on github and then go to
>> http://github.com/ceki/slf4j and click on fork. You should then
>> locally clone your fork and publish the results into the forked
>> version.
> I can already tell you that I needed to merge the SLf4J-API project and
> the new binding implementation into one (Maven) project. The reason is
> rather complicated to explain. In short, it is due to the fact that
> SLF4J API removes the dummy impl.* classes during the build from the
> target Jar, which is not compatible with the Android Dexer. If Git
> supports something like symbolic links for files and directories it
> could be "cleanly" integrated, otherwise, the code of the API part needs
> to be duplicated. Do you know if Git supports symbolic links, or
> something equivalent to svn:externals?
>
> -- Thorsten
>

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
_______________________________________________
user mailing list
[hidden email]
http://www.slf4j.org/mailman/listinfo/user

[tm-2]

On Thursday, October 22, 2009 5:53 PM [GMT+1=CET],
Ceki Gulcu <[hidden email]> wrote (with possible deletions):

> I think git supports Unix symbolic links but not all operating
> systems support sym links which makes sym-link in git pointless. I am
> not aware of a git equivalent for svn:externals.
>
> However, you could modify the build file for the slf4j-android*
I gave it this name already :-)

> module so that it copies the source files it needs from the slf4j-api
> module. This is pretty easy to do with an Ant target which you can
> then add to the Maven build life cycle.  By the way, initial versions
> of SLF4J where each binding also contained the contents of slf4j-api
> used to work exactly this way.
Would be a solution. Let me check that.

The initial version is now pushed to my fork:
http://github.com/twwwt/slf4j/tree/master/slf4j-android/

Note that you need to install the Android SDK and set an environment
variable ANDROID_SDK_HOME in order to build it.


Enjoy!
Thorsten


_______________________________________________
user mailing list
[hidden email]
http://www.slf4j.org/mailman/listinfo/user

[Ceki Gulcu]

Thorsten Möller wrote:
> On Thursday, October 22, 2009 5:53 PM [GMT+1=CET],
> Ceki Gulcu <[hidden email]> wrote (with possible deletions):
>
>> I think git supports Unix symbolic links but not all operating
>> systems support sym links which makes sym-link in git pointless. I am
>> not aware of a git equivalent for svn:externals.
>>
>> However, you could modify the build file for the slf4j-android*
> I gave it this name already :-)

Great minds think alike.

>> module so that it copies the source files it needs from the slf4j-api
>> module. This is pretty easy to do with an Ant target which you can
>> then add to the Maven build life cycle.  By the way, initial versions
>> of SLF4J where each binding also contained the contents of slf4j-api
>> used to work exactly this way.
> Would be a solution. Let me check that.
>
> The initial version is now pushed to my fork:
> http://github.com/twwwt/slf4j/tree/master/slf4j-android/
>
> Note that you need to install the Android SDK and set an environment
> variable ANDROID_SDK_HOME in order to build it.

Why on earth isn't it possible to fetch android jar from the central Maven repo
or any other repo? Isn't Android licensed under Apache?

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
_______________________________________________
user mailing list
[hidden email]
http://www.slf4j.org/mailman/listinfo/user

[tm-2]

On Thursday, October 22, 2009 7:32 PM [GMT+1=CET],
Ceki Gulcu <[hidden email]> wrote (with possible deletions):

>>> module so that it copies the source files it needs from the
>>> slf4j-api module. This is pretty easy to do with an Ant target
>>> which you can then add to the Maven build life cycle.  By the way,
>>> initial versions of SLF4J where each binding also contained the
>>> contents of slf4j-api used to work exactly this way.
>> Would be a solution. Let me check that.
Another question on your proposal: how did you support working with IDEs
(such as Eclipse) at that time? I can only imagine that one has to build
the project using Maven first (which copies the API files to the binding
project) and afterwards imports the project into Eclipse. The question
then is how-to consistently deal with updates in the original API
project and also how-to deal with a clean build.

I still prefer referencing required slf4j-api classes from
slf4j-android. After one day of working with Git I learned that it has
the notion of remotes, submodules, and I also read something about
support of file system symlinks. However, I'm still on the way to get
the complete picture to see if it is possible.


>> Note that you need to install the Android SDK and set an environment
>> variable ANDROID_SDK_HOME in order to build it.
>
> Why on earth isn't it possible to fetch android jar from the central
> Maven repo or any other repo? Isn't Android licensed under Apache?
Probably because Google guys don't care much about Maven... Joking
apart, other options would be to install android.jar to the local Maven
repos, or to use toolchains [1]. Unfortunately, all of them require some
initial setup of the environment; the latter is even not officially
released yet.

-- Thorsten



[1] http://maven.apache.org/guides/mini/guide-using-toolchains.html



_______________________________________________
user mailing list
[hidden email]
http://www.slf4j.org/mailman/listinfo/user

[Ceki Gulcu]

Thorsten Möller wrote:

> On Thursday, October 22, 2009 7:32 PM [GMT+1=CET],
> Ceki Gulcu <[hidden email]> wrote (with possible deletions):
>
>>>> module so that it copies the source files it needs from the
>>>> slf4j-api module. This is pretty easy to do with an Ant target
>>>> which you can then add to the Maven build life cycle.  By the way,
>>>> initial versions of SLF4J where each binding also contained the
>>>> contents of slf4j-api used to work exactly this way.
>>> Would be a solution. Let me check that.
> Another question on your proposal: how did you support working with IDEs
> (such as Eclipse) at that time? I can only imagine that one has to build
> the project using Maven first (which copies the API files to the binding
> project) and afterwards imports the project into Eclipse. The question
> then is how-to consistently deal with updates in the original API
> project and also how-to deal with a clean build.
>
> I still prefer referencing required slf4j-api classes from
> slf4j-android. After one day of working with Git I learned that it has
> the notion of remotes, submodules, and I also read something about
> support of file system symlinks. However, I'm still on the way to get
> the complete picture to see if it is possible.

You would wire the copying of slf4j-api sources into slf4j-android on each
build. For example, by tying the copy operation to the "generate-sources" phase
of the maven life cycle. There is an example of such a procedure in
slf4j/integration/pom.xml. A bunch of tests defined in an Ant script are run
during the packaging phase of the integration module. These tests define a bunch
of different class paths in the Ant script which is much harder to do with Maven.

See also http://maven.apache.org/plugins/maven-antrun-plugin/

You could also trigger the copying manually (after defining a Ant script to do
so as above).

>>> Note that you need to install the Android SDK and set an environment
>>> variable ANDROID_SDK_HOME in order to build it.
>> Why on earth isn't it possible to fetch android jar from the central
>> Maven repo or any other repo? Isn't Android licensed under Apache?

> Probably because Google guys don't care much about Maven... Joking
> apart, other options would be to install android.jar to the local Maven
> repos, or to use toolchains [1]. Unfortunately, all of them require some
> initial setup of the environment; the latter is even not officially
> released yet.

Adding a manual installation step would be a regression compared to the current
build. However, we could imagine that while optional for an anonymous build,
building for a release would require slf4j-android to be build and packaged
inside SLF4J. (Here I am assuming slf4j-android is shipping with SLF4J proper.)

Alternatively, you could host slf4j-android elsewhere or host it at slf4j.org
but as a separate project(sub-project). Whenever you are ready to make a release
you would just copy the contents of slf4j-android project into http://slf4j.org 
without any intervention on my part. I would obviously prefer the latter approach.

> -- Thorsten

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
_______________________________________________
user mailing list
[hidden email]
http://www.slf4j.org/mailman/listinfo/user

[tm-2]

On Friday, October 23, 2009 3:17 PM [GMT+1=CET],
Ceki Gulcu <[hidden email]> wrote (with possible deletions):

>>>> Note that you need to install the Android SDK and set an
>>>> environment variable ANDROID_SDK_HOME in order to build it.
>>> Why on earth isn't it possible to fetch android jar from the central
>>> Maven repo or any other repo? Isn't Android licensed under Apache?
>
>> Probably because Google guys don't care much about Maven... Joking
>> apart, other options would be to install android.jar to the local
>> Maven repos, or to use toolchains [1]. Unfortunately, all of them
>> require some initial setup of the environment; the latter is even
>> not officially released yet.
>
> Adding a manual installation step would be a regression compared to
> the current
> build.

I fully agree.


> However, we could imagine that while optional for an anonymous
> build,
> building for a release would require slf4j-android to be build and
> packaged
> inside SLF4J. (Here I am assuming slf4j-android is shipping with
> SLF4J proper.)
This solution would be neat. However, there is yet another issue that
currently prevents it, which is the fact that slf4j-android can not
inherit from the SLF4J root POM. The reason is that android.jar contains
a tailored JUnit version (basically without the SWING GUI because SWING
does not exist on the android platform) which needs to be used. In order
to inherit from the root pom it would be required not to inherit the
JUnit dependency. Unfortunately, there is no possibility in Maven to
exclude a dependency inherited from a parent project.


> Alternatively, you could host slf4j-android elsewhere or host it at
> slf4j.org
> but as a separate project(sub-project).
I would prefer the latter, i.e., host it as a kind of sub project at
slf4j.org to have everything in one place.


> Whenever you are ready to
> make a release
> you would just copy the contents of slf4j-android project into
> http://slf4j.org
> without any intervention on my part. I would obviously prefer the
> latter approach.
That would be also my preference. The current version would then be
created from SLF 1.5.8 and I would prefer to keep the version numbers in
sync.

The question to me now is how-to proceed. What do you need next to get
it online.

Best,
Thorsten


_______________________________________________
user mailing list
[hidden email]
http://www.slf4j.org/mailman/listinfo/user