slf4j on the google android platform
Hello all - I did get slf4j-android working after going through the list here by grabbing the source code and patching it myself but I'm wondering if progress has been made on the issues below so that I can adopt a more official release? Thanks in advance, -Darrin
I've run into a couple frustrating issues with slf4j-android that you're no doubt aware of as it seems that some work has occurred here:
1) http://bugzilla.slf4j.org/show_bug.cgi?id=173
Given that I'm dealing with a cross-platform library with lots of existing code the '23 character' android limit is a showstopper for me. I cannot change all the library code to use 'simplename' for example. Granted I see this as really an issue with Android - but still we should be able to handle this in the android port. This means that I cannot just handle it in the android specific portions of the code - the already written libraries have to properly deal with this issue by cropping the name of the logger - so that the library functions don't throw exceptions. This to me means that I need to change the StaticLoggerBinder to instantiate a version of code that knows how to deal with this issue properly even when the client code isn't aware of it. Wendel's solution in the above thread seems a reasonable solution.
2) Availability of android source-code from repo.
Given that this is an for me issue I'd like to put the fix in that wendell suggest... use as much of the useful name as possible and hopefully Android comes around and fixes this limitation someday. I grabbed the codebase from git and I couldn't find references to the android branch. Specifically it seems like wendell's fix is a decent work-around for the android limitation. Unfortunately I cannot easily do this and contribute any branches back to the open source community because I cannot seem to find android code in this branch. Now this said - I did find the slf4j-android code base on the website so I can move forward... but why isn't this in Git??
3) Really just a picky thing... slf4j-android does not appear to be available from any publicly accessible maven repository.
I've resolved this by adding the jar to my project and automatically deploying it to the local repo - but this really isn't a very elegant solution. Any chance the android version is going to be made available anytime soon? I'd rather not package the jar as a build artifact.
On Monday, August 23, 2010 10:51 PM [GMT+1=CET], Darrin Edelman <darrin501@gmail.com> wrote (with possible deletions):
I did get slf4j-android working after going through the list here by grabbing the source code and patching it myself but I'm wondering if progress has been made on the issues below so that I can adopt a more official release? The repository [1] contains a fix which simply truncates names longer than 23 characters at the right-hand side. This fix is considered a temporary solution and it is intended to eventually come up either with the solution proposed in comment #10 [2], or with the following solution (inspired by Eclipse IDE which has a similar function):
tag = a.package.name.longer.than.twentythree.characters.MyClass would be shortened to tag = a.p*.n*.l*.t*.t*.c*.MyClass If tag would still be longer than 23 characters (e.g. long class name, deep hierarchy, or no dots at all), then one could further shorten it to tag = *TrailOfLongClassName Feedback welcome as well as patches. I suggest to continue the discussion via Bugzilla directly on the issue. Cheers, Thorsten [1] http://github.com/twwwt/slf4j [2] http://bugzilla.slf4j.org/show_bug.cgi?id=173#c10
Thanks in advance, -Darrin
I've run into a couple frustrating issues with slf4j-android that you're no doubt aware of as it seems that some work has occurred here:
1) http://bugzilla.slf4j.org/show_bug.cgi?id=173
Given that I'm dealing with a cross-platform library with lots of existing code the '23 character' android limit is a showstopper for me. I cannot change all the library code to use 'simplename' for example. Granted I see this as really an issue with Android - but still we should be able to handle this in the android port. This means that I cannot just handle it in the android specific portions of the code - the already written libraries have to properly deal with this issue by cropping the name of the logger - so that the library functions don't throw exceptions. This to me means that I need to change the StaticLoggerBinder to instantiate a version of code that knows how to deal with this issue properly even when the client code isn't aware of it. Wendel's solution in the above thread seems a reasonable solution.
2) Availability of android source-code from repo.
Given that this is an for me issue I'd like to put the fix in that wendell suggest... use as much of the useful name as possible and hopefully Android comes around and fixes this limitation someday. I grabbed the codebase from git and I couldn't find references to the android branch. Specifically it seems like wendell's fix is a decent work-around for the android limitation. Unfortunately I cannot easily do this and contribute any branches back to the open source community because I cannot seem to find android code in this branch. Now this said - I did find the slf4j-android code base on the website so I can move forward... but why isn't this in Git??
3) Really just a picky thing... slf4j-android does not appear to be available from any publicly accessible maven repository.
I've resolved this by adding the jar to my project and automatically deploying it to the local repo - but this really isn't a very elegant solution. Any chance the android version is going to be made available anytime soon? I'd rather not package the jar as a build artifact.
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
Thorsten - That's a nice solution - sounds perfect. What of the other two points below : 2. Where is this sourcecode? Am I missing this in Git somehow? 3. Are there plans to get slf4j-android into a maven repo? Thanks, -Darrin I didn't see this in the android code base - have I missed something? What On Aug 24, 2010, at 4:52 AM, Thorsten Möller wrote:
On Monday, August 23, 2010 10:51 PM [GMT+1=CET], Darrin Edelman <darrin501@gmail.com> wrote (with possible deletions):
I did get slf4j-android working after going through the list here by grabbing the source code and patching it myself but I'm wondering if progress has been made on the issues below so that I can adopt a more official release? The repository [1] contains a fix which simply truncates names longer than 23 characters at the right-hand side. This fix is considered a temporary solution and it is intended to eventually come up either with the solution proposed in comment #10 [2], or with the following solution (inspired by Eclipse IDE which has a similar function):
tag = a.package.name.longer.than.twentythree.characters.MyClass
would be shortened to
tag = a.p*.n*.l*.t*.t*.c*.MyClass
If tag would still be longer than 23 characters (e.g. long class name, deep hierarchy, or no dots at all), then one could further shorten it to
tag = *TrailOfLongClassName
Feedback welcome as well as patches. I suggest to continue the discussion via Bugzilla directly on the issue.
Cheers, Thorsten
[1] http://github.com/twwwt/slf4j [2] http://bugzilla.slf4j.org/show_bug.cgi?id=173#c10
Thanks in advance, -Darrin
I've run into a couple frustrating issues with slf4j-android that you're no doubt aware of as it seems that some work has occurred here:
1) http://bugzilla.slf4j.org/show_bug.cgi?id=173
Given that I'm dealing with a cross-platform library with lots of existing code the '23 character' android limit is a showstopper for me. I cannot change all the library code to use 'simplename' for example. Granted I see this as really an issue with Android - but still we should be able to handle this in the android port. This means that I cannot just handle it in the android specific portions of the code - the already written libraries have to properly deal with this issue by cropping the name of the logger - so that the library functions don't throw exceptions. This to me means that I need to change the StaticLoggerBinder to instantiate a version of code that knows how to deal with this issue properly even when the client code isn't aware of it. Wendel's solution in the above thread seems a reasonable solution.
2) Availability of android source-code from repo.
Given that this is an for me issue I'd like to put the fix in that wendell suggest... use as much of the useful name as possible and hopefully Android comes around and fixes this limitation someday. I grabbed the codebase from git and I couldn't find references to the android branch. Specifically it seems like wendell's fix is a decent work-around for the android limitation. Unfortunately I cannot easily do this and contribute any branches back to the open source community because I cannot seem to find android code in this branch. Now this said - I did find the slf4j-android code base on the website so I can move forward... but why isn't this in Git??
3) Really just a picky thing... slf4j-android does not appear to be available from any publicly accessible maven repository.
I've resolved this by adding the jar to my project and automatically deploying it to the local repo - but this really isn't a very elegant solution. Any chance the android version is going to be made available anytime soon? I'd rather not package the jar as a build artifact.
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
On Tuesday, August 24, 2010 3:05 PM [GMT+1=CET], Darrin Edelman <darrin501@gmail.com> wrote (with possible deletions):
What of the other two points below : 2. Where is this sourcecode? Am I missing this in Git somehow? [1], folder slf4j-android
3. Are there plans to get slf4j-android into a maven repo? Not of high priority. However, since the project is already managed using Maven, it shouldn't be that complicated to check out the code and build and install it in your local repo. Note that I also refuse to upload it unless #173 is fixed. Together with this we intend to upgrade the code basis to SLF4J 1.6.1 as well.
@Ceki: What would be required in order to publish the artifacts to Maven central - I never did this. Cheers, Thorsten [1] http://github.com/twwwt/slf4j
Thanks, -Darrin
I didn't see this in the android code base - have I missed something? What On Aug 24, 2010, at 4:52 AM, Thorsten Möller wrote:
On Monday, August 23, 2010 10:51 PM [GMT+1=CET], Darrin Edelman <darrin501@gmail.com> wrote (with possible deletions):
I did get slf4j-android working after going through the list here by grabbing the source code and patching it myself but I'm wondering if progress has been made on the issues below so that I can adopt a more official release? The repository [1] contains a fix which simply truncates names longer than 23 characters at the right-hand side. This fix is considered a temporary solution and it is intended to eventually come up either with the solution proposed in comment #10 [2], or with the following solution (inspired by Eclipse IDE which has a similar function):
tag = a.package.name.longer.than.twentythree.characters.MyClass
would be shortened to
tag = a.p*.n*.l*.t*.t*.c*.MyClass
If tag would still be longer than 23 characters (e.g. long class name, deep hierarchy, or no dots at all), then one could further shorten it to
tag = *TrailOfLongClassName
Feedback welcome as well as patches. I suggest to continue the discussion via Bugzilla directly on the issue.
Cheers, Thorsten
[1] http://github.com/twwwt/slf4j [2] http://bugzilla.slf4j.org/show_bug.cgi?id=173#c10
Thanks in advance, -Darrin
I've run into a couple frustrating issues with slf4j-android that you're no doubt aware of as it seems that some work has occurred here:
1) http://bugzilla.slf4j.org/show_bug.cgi?id=173
Given that I'm dealing with a cross-platform library with lots of existing code the '23 character' android limit is a showstopper for me. I cannot change all the library code to use 'simplename' for example. Granted I see this as really an issue with Android - but still we should be able to handle this in the android port. This means that I cannot just handle it in the android specific portions of the code - the already written libraries have to properly deal with this issue by cropping the name of the logger - so that the library functions don't throw exceptions. This to me means that I need to change the StaticLoggerBinder to instantiate a version of code that knows how to deal with this issue properly even when the client code isn't aware of it. Wendel's solution in the above thread seems a reasonable solution.
2) Availability of android source-code from repo.
Given that this is an for me issue I'd like to put the fix in that wendell suggest... use as much of the useful name as possible and hopefully Android comes around and fixes this limitation someday. I grabbed the codebase from git and I couldn't find references to the android branch. Specifically it seems like wendell's fix is a decent work-around for the android limitation. Unfortunately I cannot easily do this and contribute any branches back to the open source community because I cannot seem to find android code in this branch. Now this said - I did find the slf4j-android code base on the website so I can move forward... but why isn't this in Git??
3) Really just a picky thing... slf4j-android does not appear to be available from any publicly accessible maven repository.
I've resolved this by adding the jar to my project and automatically deploying it to the local repo - but this really isn't a very elegant solution. Any chance the android version is going to be made available anytime soon? I'd rather not package the jar as a build artifact.
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
Thank you - Comments below for those who follow... Anyway - I'm back up and going on the official version - thanks much for your help!! -Darrin On Aug 24, 2010, at 8:43 AM, Thorsten Möller wrote:
On Tuesday, August 24, 2010 3:05 PM [GMT+1=CET], Darrin Edelman <darrin501@gmail.com> wrote (with possible deletions):
What of the other two points below : 2. Where is this sourcecode? Am I missing this in Git somehow? [1], folder slf4j-android
Yes - I was able to git this with: Also - I had to make a change to the pom.xml because for whatever reason my android sdk had a different structure: --- a/slf4j-android/pom.xml +++ b/slf4j-android/pom.xml @@ -83,7 +83,7 @@ <artifactId>android</artifactId> <version>1.5</version> <scope>system</scope> - <systemPath>${env.ANDROID_HOME}/platforms/android-1.5/android.jar</systemPath> + <systemPath>${env.ANDROID_HOME}/platforms/android-3/android.jar</systemPath> </dependency> </dependencies> FYI - I believe you can now use a publicly available android jar instead of including the jar within git using something like this: <dependency> <groupId>com.google.android</groupId> <artifactId>android</artifactId> <version>1.5_r4</version> <scope>system</scope> </dependency> Note that this would require a change to the imports from 'android.utils.log' to 'com.google.android.utils.log' which is how it should be...
3. Are there plans to get slf4j-android into a maven repo? Not of high priority. However, since the project is already managed using Maven, it shouldn't be that complicated to check out the code and build and install it in your local repo. Note that I also refuse to upload it unless #173 is fixed. Together with this we intend to upgrade the code basis to SLF4J 1.6.1 as well.
True - but the main issue here is that I don't want members of my team to have to go through this process (understand and download slf4j-android, build, install) in order to build our application - also it makes it a bit more painful for continuous integration. Making it available to the community means that it'll be that much easier to use slf4j as the logger of choice for an android app (for those who are using maven with android anyway). That said - what I'm doing as a workaround to make builds work for my team and our CI server until this happens is what you did above for the android.jar (which also wasn't originally available). I'm putting it the jar into source code control under my project's lib directory and added it as a 'system' maven dependency: <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-android</artifactId> <version>1.5.8</version> <scope>system</scope> <systemPath>${basedir}/lib/slf4j-android-1.5.8.jar</systemPath> </dependency> When you have it publicly available I can remove this from my repo and reference the officially available jar.
@Ceki: What would be required in order to publish the artifacts to Maven central - I never did this.
Cheers, Thorsten
[1] http://github.com/twwwt/slf4j
Thanks, -Darrin
I didn't see this in the android code base - have I missed something? What On Aug 24, 2010, at 4:52 AM, Thorsten Möller wrote:
On Monday, August 23, 2010 10:51 PM [GMT+1=CET], Darrin Edelman <darrin501@gmail.com> wrote (with possible deletions):
I did get slf4j-android working after going through the list here by grabbing the source code and patching it myself but I'm wondering if progress has been made on the issues below so that I can adopt a more official release? The repository [1] contains a fix which simply truncates names longer than 23 characters at the right-hand side. This fix is considered a temporary solution and it is intended to eventually come up either with the solution proposed in comment #10 [2], or with the following solution (inspired by Eclipse IDE which has a similar function):
tag = a.package.name.longer.than.twentythree.characters.MyClass
would be shortened to
tag = a.p*.n*.l*.t*.t*.c*.MyClass
If tag would still be longer than 23 characters (e.g. long class name, deep hierarchy, or no dots at all), then one could further shorten it to
tag = *TrailOfLongClassName
Feedback welcome as well as patches. I suggest to continue the discussion via Bugzilla directly on the issue.
Cheers, Thorsten
[1] http://github.com/twwwt/slf4j [2] http://bugzilla.slf4j.org/show_bug.cgi?id=173#c10
Thanks in advance, -Darrin
I've run into a couple frustrating issues with slf4j-android that you're no doubt aware of as it seems that some work has occurred here:
1) http://bugzilla.slf4j.org/show_bug.cgi?id=173
Given that I'm dealing with a cross-platform library with lots of existing code the '23 character' android limit is a showstopper for me. I cannot change all the library code to use 'simplename' for example. Granted I see this as really an issue with Android - but still we should be able to handle this in the android port. This means that I cannot just handle it in the android specific portions of the code - the already written libraries have to properly deal with this issue by cropping the name of the logger - so that the library functions don't throw exceptions. This to me means that I need to change the StaticLoggerBinder to instantiate a version of code that knows how to deal with this issue properly even when the client code isn't aware of it. Wendel's solution in the above thread seems a reasonable solution.
2) Availability of android source-code from repo.
Given that this is an for me issue I'd like to put the fix in that wendell suggest... use as much of the useful name as possible and hopefully Android comes around and fixes this limitation someday. I grabbed the codebase from git and I couldn't find references to the android branch. Specifically it seems like wendell's fix is a decent work-around for the android limitation. Unfortunately I cannot easily do this and contribute any branches back to the open source community because I cannot seem to find android code in this branch. Now this said - I did find the slf4j-android code base on the website so I can move forward... but why isn't this in Git??
3) Really just a picky thing... slf4j-android does not appear to be available from any publicly accessible maven repository.
I've resolved this by adding the jar to my project and automatically deploying it to the local repo - but this really isn't a very elegant solution. Any chance the android version is going to be made available anytime soon? I'd rather not package the jar as a build artifact.
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
On 24/08/2010 3:43 PM, Thorsten Möller wrote:
@Ceki: What would be required in order to publish the artifacts to Maven central - I never did this.
The simplest way to publish the slf4j-android artifacts on the maven central repo would be for you to point me to a location where these are available. All files placed in your local repository when you build and install the org.slf4j:slf4j-android artifact are required (not just the slf4j-android.jar file). Zipping them and sending these files in an email is also OK. Once I get my hand on the files, I can publish them on the central repo. BTW, is the generated jar file, namely slf4j-android.jar, really a jar file loadable on a regular JVM? My apologies if it's a stupid question. -- Ceki
Ceki - That's not a stupid question. It is a 'regular jar' and is assembled in the usual way (no special maven plugins used that would call anything other than javac) however you'd not be able to use it in an executable without a provided 'android.jar'. This likely means this will never be used in a 'regular java app' but rather only on the android platform. That said this is really no different than the other platforms that you support in that sense since they too are dependent upon other logging systems being in place on the target platform. As with any other jar all I did to add it to my android project was to install it into the repo (local repo) and then to include it as a dependency in my pom file. So what you'll want to put out there are the generated ".jar", "source.jar" and generated poms. -Darrin On Aug 24, 2010, at 4:33 PM, Ceki Gülcü wrote:
On 24/08/2010 3:43 PM, Thorsten Möller wrote:
@Ceki: What would be required in order to publish the artifacts to Maven central - I never did this.
The simplest way to publish the slf4j-android artifacts on the maven central repo would be for you to point me to a location where these are available. All files placed in your local repository when you build and install the org.slf4j:slf4j-android artifact are required (not just the slf4j-android.jar file). Zipping them and sending these files in an email is also OK. Once I get my hand on the files, I can publish them on the central repo.
BTW, is the generated jar file, namely slf4j-android.jar, really a jar file loadable on a regular JVM? My apologies if it's a stupid question.
-- Ceki _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
Darrin, Thank you for your reply. I thought that the android JVM ran a different byte code called dalvik. If I understand correctly, slf4j-android.jar would be converted to Dalvik byte code at a later stage... On 25/08/2010 2:21 PM, Darrin Edelman wrote:
Ceki -
That's not a stupid question. It is a 'regular jar' and is assembled in the usual way (no special maven plugins used that would call anything other than javac) however you'd not be able to use it in an executable without a provided 'android.jar'. This likely means this will never be used in a 'regular java app' but rather only on the android platform. That said this is really no different than the other platforms that you support in that sense since they too are dependent upon other logging systems being in place on the target platform. As with any other jar all I did to add it to my android project was to install it into the repo (local repo) and then to include it as a dependency in my pom file.
So what you'll want to put out there are the generated ".jar", "source.jar" and generated poms.
-Darrin
On Aug 24, 2010, at 4:33 PM, Ceki Gülcü wrote:
On 24/08/2010 3:43 PM, Thorsten Möller wrote:
@Ceki: What would be required in order to publish the artifacts to Maven central - I never did this.
The simplest way to publish the slf4j-android artifacts on the maven central repo would be for you to point me to a location where these are available. All files placed in your local repository when you build and install the org.slf4j:slf4j-android artifact are required (not just the slf4j-android.jar file). Zipping them and sending these files in an email is also OK. Once I get my hand on the files, I can publish them on the central repo.
BTW, is the generated jar file, namely slf4j-android.jar, really a jar file loadable on a regular JVM? My apologies if it's a stupid question.
-- Ceki _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
On Wednesday, August 25, 2010 6:47 PM [GMT+1=CET], Ceki Gülcü <ceki@qos.ch> wrote (with possible deletions):
Darrin,
Thank you for your reply. I thought that the android JVM ran a different byte code called dalvik. Correct. Dalvik VM has its own bytecode format. One reason is because it is register-based (rather than stack-based).
If I understand correctly, slf4j-android.jar would be converted to Dalvik byte code at a later stage... To be precise, the so called Dexer does this - it transforms standard Java bytecode into dalvik bytecode. When working with Eclipse, it is done by a builder that runs in the background before deploying application packages (apk) to the device. It is also available as a stand-alone tool.
-- Thorsten
On Tuesday, August 24, 2010 11:33 PM [GMT+1=CET], Ceki Gülcü <ceki@qos.ch> wrote (with possible deletions):
@Ceki: What would be required in order to publish the artifacts to Maven central - I never did this.
The simplest way to publish the slf4j-android artifacts on the maven central repo would be for you to point me to a location where these are available.
Now that I have released 1.6.1-RC1, you could also check-out from Git [1], jump to tag 1.6.1-RC1 (ok, next time I use a more specific name) and simply cd slf4j-android mvn install This will create binary and source artifacts in yr local repository, together with the POM. Would this be ok, or should I zip and send it via e-mail. Cheers, Thorsten [1] git://github.com/twwwt/slf4j.git
On 25/08/2010 6:22 PM, Thorsten Möller wrote:
On Tuesday, August 24, 2010 11:33 PM [GMT+1=CET],
Now that I have released 1.6.1-RC1, you could also check-out from Git [1], jump to tag 1.6.1-RC1 (ok, next time I use a more specific name) and simply
cd slf4j-android mvn install
This will create binary and source artifacts in yr local repository, together with the POM.
Would this be ok, or should I zip and send it via e-mail.
I thought I needed to install the Android SDK for the build to succeed. Apparently, the Android SDK is no longer required for the build. Anyway, the central maven repo should synchronize with qos.ch within the next few hours. It make take up to 24. HTH,
Cheers, Thorsten
[1] git://github.com/twwwt/slf4j.git
On Wednesday, August 25, 2010 6:54 PM [GMT+1=CET], Ceki Gülcü <ceki@qos.ch> wrote (with possible deletions):
Now that I have released 1.6.1-RC1, you could also check-out from Git [1], jump to tag 1.6.1-RC1 (ok, next time I use a more specific name) and simply
cd slf4j-android mvn install
This will create binary and source artifacts in yr local repository, together with the POM.
Would this be ok, or should I zip and send it via e-mail.
I thought I needed to install the Android SDK for the build to succeed. Apparently, the Android SDK is no longer required for the build. Thanks to some guys they are available from Maven central. So at least to compile the SDK is no longer necessary - runtime is another story. I have modified the POM to use them.
Anyway, the central maven repo should synchronize with qos.ch within the next few hours. It make take up to 24. Thanks!
-- Thorsten
On Wednesday, August 25, 2010 6:54 PM [GMT+1=CET], Ceki Gülcü <ceki@qos.ch> wrote (with possible deletions):
Now that I have released 1.6.1-RC1, you could also check-out from Git [1], jump to tag 1.6.1-RC1 (ok, next time I use a more specific name) and simply
cd slf4j-android mvn install
This will create binary and source artifacts in yr local repository, together with the POM.
Would this be ok, or should I zip and send it via e-mail.
I thought I needed to install the Android SDK for the build to succeed. Apparently, the Android SDK is no longer required for the build.
Anyway, the central maven repo should synchronize with qos.ch within the next few hours. It make take up to 24.
I just checked whether slf4j-android is now in Maven Central but got a HTTP 403 Forbidden error when accessing http://repo1.maven.org/maven2/org/slf4j/slf4j-android/ -- Thorsten
On 31/08/2010 12:18 PM, Thorsten Möller wrote:
On Wednesday, August 25, 2010 6:54 PM [GMT+1=CET], Ceki Gülcü<ceki@qos.ch> wrote (with possible deletions):
Now that I have released 1.6.1-RC1, you could also check-out from Git [1], jump to tag 1.6.1-RC1 (ok, next time I use a more specific name) and simply
cd slf4j-android mvn install
This will create binary and source artifacts in yr local repository, together with the POM.
Would this be ok, or should I zip and send it via e-mail.
I thought I needed to install the Android SDK for the build to succeed. Apparently, the Android SDK is no longer required for the build.
Anyway, the central maven repo should synchronize with qos.ch within the next few hours. It make take up to 24.
I just checked whether slf4j-android is now in Maven Central but got a HTTP 403 Forbidden error when accessing
I am aware of the issue. I created a jira issue with the maven folks regarding the matter. http://jira.codehaus.org/browse/MAVENUPLOAD-2803 You are welcome to vote to increase its priority.
-- Thorsten
participants (3)
-
Ceki Gülcü -
Darrin Edelman -
Thorsten Möller