Folks, I' suggest the following: 1.) create single JARs which exactly do what they should. 2.) use the maven-shade-plugin [1] to package 'bundles' containing some fitting jars of your project just for convenience.
LieGrue, strub [1] http://maven.apache.org/plugins/maven-shade-plugin/ --- On Fri, 7/29/11, Ralph Goers <ralph.go...@dslextreme.com> wrote: > From: Ralph Goers <ralph.go...@dslextreme.com> > Subject: Re: [logging] logging vs slf4j > To: "Commons Developers List" <dev@commons.apache.org> > Date: Friday, July 29, 2011, 5:39 PM > Unfortunately, you are in the > minority on this one. Technically, you could just use the > Log4J 2.0 Impl jar, but then you would be coding to a > private API. > > Ralph > > On Jul 29, 2011, at 8:15 AM, Gary Gregory wrote: > > > One thing that is a hassle to me with modularized > projects, even > > slf4j, is that you end up with a bunch of tiny jars. > IOW & IMO: a > > mess. Personally, I want one jar to rule them all. If > I want to switch > > logging implementer or a client wants another impl I > have to fiddle > > with my builds and explain what each jar does. It's a > hassle. > > > > Gary > > > > On Fri, Jul 29, 2011 at 4:33 AM, Torsten Curdt <tcu...@vafer.org> > wrote: > >> At some stage I started to refactor commons > logging into a multi > >> module maven project and got rid of the discovery > part. So you would > >> have the commons-logging-api jar plus exactly one > of the > >> implementation bridges. So you pick the logging > target by putting the > >> correct bridge into your classpath. Similar to > slf4j. > >> > >> Didn't think there is still interest in commons > logging. Not sure I > >> still have the code. I lost interest after yet > another logging > >> discussion :) ...but it shouldn't be hard to > re-create. Not sure there > >> is still enough interest in this. > >> > >>>>> Seems to me you should focus on making > Log4J the impl > >>>>> excellent > >> > >> That sounds like work ;) > >> > >>> Unfortunately, SLF4J and Logback are run under > the BDFL model, not a collaboration as is done at the ASF. > >> > >> Which is one of the reasons I have always been > very reluctant to use it. > >> > >> cheers, > >> Torsten > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > > > > > -- > > Thank you, > > Gary > > > > http://garygregory.wordpress.com/ > > http://garygregory.com/ > > http://people.apache.org/~ggregory/ > > http://twitter.com/GaryGregory > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
