Re: [slf4j-dev] svn commit: r1328 - in slf4j/trunk/slf4j-ext/src: main/java/org/slf4j/ext test/java/org/slf4j/dummyExt
Ralph Goers skrev: Yes, I knew that. The issue is I really don't want to us Eclipse as my IDE. It seems silly to load it just to see the warnings. Most, if not all, the ones you mentioned would also be shown in IntelliJ. Running something as a maven report is far more palatable than being forced to use a particular IDE. True, but it requires somehow to have the Eclipse compiler glued into Maven (which I am extraordinarily unfamliar with - we don't use Maven inhouse[1]). I am in no way advocating you should use Eclipse, and if you find a way to get the same information from Maven, then I'd love to hear about it. [1] - We have considered it, but went for putting the libraries we need in CVS instead as Eclipse projects. It turned out for now to be the path of least resistance for us. -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! ___ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
Re: [slf4j-dev] svn commit: r1328 - in slf4j/trunk/slf4j-ext/src: main/java/org/slf4j/ext test/java/org/slf4j/dummyExt
Thorbjoern Ravn Andersen wrote: c...@slf4j.org skrev: Fewer eclipse warnings Would it be a reasonable goal that the code base compile without any Eclipse warnings at all? Reasonable yes, possible no. There are 5 warnings total in the project (all modules). Two in LoggerFactory about accessing StaticLoggerBinder.SINGLETON which is deprecated. LoggerFactory accessing the said deprecated field for backward compatibility reasons. Thus, we can't get rid of or change that particular code. There is another warning in StaticLoggerBinder setting a level variable but never using it. The level variable is set to check for the presence of an older version of log4j. The same check is performed elsewhere and we could actually get rid of it. There are two warnings in EventData about unchecked cast from Object to MapString, Object which I was unable to get rid of. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch ___ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
Re: [slf4j-dev] svn commit: r1328 - in slf4j/trunk/slf4j-ext/src: main/java/org/slf4j/ext test/java/org/slf4j/dummyExt
You can easily make maveninzed project eclipse-ready by launching the mvn eclipse:eclipse command. Once you do that, you just import into Eclipse the various SLF4J modules as eclipse projects. Once you have eclipse and maven installed, and SLF4J checked out, the mvn eclipse:eclipse procedure followed by import should take less than 30 seconds for all SLF4J modules combined, perhaps 60 if you hesitate... Ralph Goers wrote: I'm certainly willing to give it a try. I've been exposed to the Eclipse IDE from time to time as the Maven guys I collaborate with have worked on some good plugins. Despite that I still prefer IntelliJ. But if these are just checkstyle errors then we should configure the Maven build to report them. Ralph -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch ___ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
Re: [slf4j-dev] svn commit: r1328 - in slf4j/trunk/slf4j-ext/src: main/java/org/slf4j/ext test/java/org/slf4j/dummyExt
On Apr 23, 2009, at 9:25 AM, Thorbjoern Ravn Andersen wrote: c...@slf4j.org skrev: Fewer eclipse warnings Would it be a reasonable goal that the code base compile without any Eclipse warnings at all? Unfortunately, I use IntelliJ. Presumably SLF4J could just use the checkstyle plugin and then I could verify it before committing. Setting up checkstyle for a multi module project is a bit tricky, but I've done it for Apache Commons VFS. The trick is to use the pom's parent relative path setting to locate checkstyle.xml, but this doesn't work if you have a project that goes more than 1 level deep. ___ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
Re: [slf4j-dev] svn commit: r1328 - in slf4j/trunk/slf4j-ext/src: main/java/org/slf4j/ext test/java/org/slf4j/dummyExt
Ralph Goers skrev: Unfortunately, I use IntelliJ. Presumably SLF4J could just use the checkstyle plugin and then I could verify it before committing. Setting up checkstyle for a multi module project is a bit tricky, but I've I don't mind a few extra commits. If you can use Eclipse on your platform (it is just a zipfile) and if I document step-by-step how to extract slf4j from subversion and create a Eclipse workspace with that, so you can see the errors, would that be a reasonable approach? The Eclipse compiler locates a lot more than the stock javac. -- Thorbjørn Ravn Andersen ...plus... Tubular Bells! ___ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
