2012/11/11 Jason van Zyl <ja...@tesla.io>: > > On Nov 10, 2012, at 5:36 PM, Olivier Lamy <ol...@apache.org> wrote: > >> Hi, >> As I daily use trunk as mvn version to work, I'm a bit irritate with >> the current transfer listener :-) >> > > Yes, I use Logback to do the same in integrations, but I would prefer not to > pull in one of the larger frameworks simply to resolve the console transfer > listener issue. > >> So I have fixed using log4j2 as slf4j implementation. >> See the stuff here: https://github.com/olamy/maven-3/tree/log4j2 >> It's simply a matter of defining a different layout for transfer >> logging (which is not possible with slf4j-simple AFAIK but maybe I >> miss something) > > I honestly don't think it requires a logging framework, the layout is not the > issue. The console transfer listener is unique in its requirements and can be > dealt with accordingly. I checked in the changes that restore the console > logging to its former glory, keeps the core small still using SLF4J Simple > but allows extension points for integrators if they want to do anything more > sophisticated. For example my Maven variant that uses Logback, or your Maven > variant that uses Log4J. I would really like to try and get away with SLF4J > Simple before resorting to a logging framework.
So if layout is not the issue what is the issue ? Perso I think slf4j-simple is too simple :-) and users want for very long time easily customizing their logging. So adding a more advanced logging framework will help them for customization. And this customization will be simply be changing a configuration file (replacing/adding jars need to much manual steps IMHO for users). And Ralph is committer here so I'm pretty sure (or at least I hope :-)) he will help if we have any issues. What do you mean with "your variant" ? Sorry but I work only on Apache Maven sources so I don't understand this point. > > For the following cases I have done the following: > > 1) Logging to the console: I simply restored the class that was there such > that when logging to the console it uses System.out as it did and the > download progress appears as it did. So users are not able to simply control it as today... > > 2) Logging in batch mode: the batch mode transfer listener uses an SLF4J > logger and the batch mode transfer listener doesn't report download progress > so there is no issue. Download progress would just create a bunch of noise. > The size and the speed at which it is downloaded are logged. > > 3) Logging to a file: same as 2) except it's all diverted to the specified > file. > > 4) I created two protected methods in MavenCli so that integrators can supply > their own console and batch transfer listeners if they wish. Same as previous comment, users will certainly prefer control that with modifying a configuration file > > I think that covers everything and avoids having to bring in Logback or Log4J. Perso I propose a change by pointing you (you means other maven dev folks too) to a branch I made somewhere but you commit code without listening POV from others. If you could wait to hear what other thinks that could be lovely.... > >> >> Thanks >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > We all have problems. How we deal with them is a measure of our worth. > > -- Unknown > > > > > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
