Darn... I forgot that 'system' scope assumes the jar will be provided on the target platform which in the case of slf4j of course it is note. So I've added a maven snippet that will auto-install the jar included in source code control so you can use maven without manual steps for the build in this case...
-Darrin > > On Aug 24, 2010, at 10:16 AM, Darrin Edelman wrote: > >> 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 <[email protected]> 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> >> > > Yeah - this won't work here... two modifications needed: > > 1. remove the 'system' scope and 'systemPath' from the dependency above - > that dependency should now look like this: > > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>slf4j-android</artifactId> > <version>1.5.8</version> > </dependency> > > 2. add the maven-install-plugin to the 'plugins' section: > > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-install-plugin</artifactId> > <executions> > <execution> > <id>install-slf4j-android-jar</id> > <phase>validate</phase> > <configuration> > <file>${basedir}/lib/slf4j-android-1.5.8.jar</file> > <repositoryLayout>default</repositoryLayout> > <groupId>org.slf4j</groupId> > <artifactId>slf4j-android</artifactId> > <version>1.5.8</version> > <packaging>jar</packaging> > <generatePom>true</generatePom> > </configuration> > <goals> > <goal>install-file</goal> > </goals> > </execution> > </executions> > </plugin> > > I needed to run 'mvn clean package' and reload eclipse before it was happy > (needs to do the initial install). > >> 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 <[email protected]> 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 >>>>>> [email protected] >>>>>> http://qos.ch/mailman/listinfo/slf4j-dev >>>>> >>>>> _______________________________________________ >>>>> slf4j-dev mailing list >>>>> [email protected] >>>>> http://qos.ch/mailman/listinfo/slf4j-dev >>>> >>>> _______________________________________________ >>>> slf4j-dev mailing list >>>> [email protected] >>>> http://qos.ch/mailman/listinfo/slf4j-dev >>> >>> _______________________________________________ >>> slf4j-dev mailing list >>> [email protected] >>> http://qos.ch/mailman/listinfo/slf4j-dev >> > _______________________________________________ slf4j-dev mailing list [email protected] http://qos.ch/mailman/listinfo/slf4j-dev
