If a script or plugin was provided to make changing the implementation easy I think that would be better. That can be made as simple. I think shipping optional components is generally a bad practice. It would be like shipping all the wagon/aether implementations to let people pick. Not really scalable and I don't think users really care that much and with event spies users are responsible for adding the components.
On Dec 1, 2012, at 2:22 PM, Jason van Zyl <[email protected]> wrote: > > On Dec 1, 2012, at 2:17 PM, Olivier Lamy <[email protected]> wrote: > >> 2012/12/1 Jason van Zyl <[email protected]>: >>> On Dec 1, 2012, at 1:44 PM, Olivier Lamy <[email protected]> wrote: >>> >>>>> >>>>> I don't think that's particularly easy and additionally opens us up to >>>>> having to specifically support any SLF4J implementation which I don't >>>>> think is wise. >>>>> >>>> if documented that's not really complicated. >>>> >>> >>> So the process would be: >>> >> Did you check build distrib link I provide or git branch ? >>> - downloads the new implementation >> no. implementations are already here in separate directories. >>> - change the configuration >> no, default configuration files for 3 impl are here. >>> - use a command line parameter >> only configure MAVEN_OPTS envvar (not having to repeat that for each >> maven invocation) >> >> and modify it if you want to try an other. >> > > I don't think we should avoid the discussion of picking an implementation by > shipping them all. > > I'm not in favour of shipping all the implementations. > >> >>> >>>> this could be nice for ci servers to get logs easily. >>> >>> A single good implementation would also work. >>> >>>> We already have eventspy to intercept build informations so why not >>>> having something else for logs. >>> >>> The mechanism for the event spy is just putting an extension on the >>> classpath. If you wanted to leverage the existing mechanism you can just >>> put the JARs in the ${MAVEN_HOME}/lib/ext directory along with making your >>> configuration available, but you're going to have to remove the other SLF4J >>> implementation or you're going to get the duplicate binding exception. Not >>> a huge deal. >>> >>> So you can already add a new implementation of SLF4J right now using the >>> mechanism that exists without anything additional. No modification of the >>> classwords configuration or a command line parameters which gives it parity >>> with the event spy if that's what you're looking for. >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder & CTO, Sonatype >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> --------------------------------------------------------- >>> >>> A man enjoys his work when he understands the whole and when he >>> is responsible for the quality of the whole >>> >>> -- Christopher Alexander, A Pattern Language >>> >>> >>> >>> >>> >> >> >> >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > happiness is like a butterfly: the more you chase it, the more it will > elude you, but if you turn your attention to other things, it will come > and sit softly on your shoulder ... > > -- Thoreau > > > > > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon
