Merge now and clean up docs later?
On Fri, Apr 12, 2013 at 11:10 AM, Remko Popma <rem...@yahoo.com> wrote: > Most of the work would be rewriting the documentation. For example, the > bit on FastFileAppender and FastRollingFileAppender. (Better names for > these, anyone?) > > I guess the section on those would need to move into the manual page on > Appenders. Not sure what to do with the performance results for those > appenders... Maybe merge with the existing performance page and move that > page into the manual? > I was thinking about refactoring the existing performance page anyway, > just thought I had more time to do it. > > I'm in two minds. I see your point about confusing some users, but on the > other hand I would like to get it out there, get some feedback, and take > the time to do the restructuring and rewriting the docs right. > > Sent from my iPhone > > On 2013/04/13, at 2:42, Gary Gregory <garydgreg...@gmail.com> wrote: > > Since this is new, it would be less confusing to do it now instead of > adding and removing a jar from one beta to the next. IMO that is ;) > > Gary > > On Apr 12, 2013, at 13:32, Remko Popma <rem...@yahoo.com> wrote: > > If we do merge async into core, can we do it after beta 5? I'd like to get > it out there and get people's feedback... > > Sent from my iPhone > > On 2013/04/13, at 2:11, Gary Gregory <garydgreg...@gmail.com> wrote: > > The dependency only kicks in when you run the class. We have the same > issue in Commoms VFS and we do not split out in a bunch of jars, nice and > simple. > > Gary > > On Apr 12, 2013, at 12:38, Scott Deboy <scott.de...@gmail.com> wrote: > > I'd like to avoid what we had with log4j 1.x - the receivers/companions > mess. Whether or something belongs in core or not is a fuzzy judgment call > sometimes. If possible, I would like to see as much as possible included > in a single 'release' (that includes 'receivers/companions' if they ever > are rewritten for log4j2). > > > > > > > On Fri, Apr 12, 2013 at 9:30 AM, Ralph Goers > <ralph.go...@dslextreme.com>wrote: > >> It probably should be done anyway, but the various components would also >> need to check for the presence of the disruptor and log a warning if it >> isn't there (I believe we do this for Jansi and Jackson) as the disruptor >> would have to be an optional dependency. In the async package it can be >> non-optional so this is less important for anyone using Maven. >> >> Ralph >> >> On Apr 12, 2013, at 9:23 AM, Ralph Goers wrote: >> >> Because it has a dependency on the Disruptor, which Remko has said may >> not work on all JDKs >> >> Sent from my iPad >> >> On Apr 12, 2013, at 8:23 AM, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> Why not more log4j-async into the core? >> >> Gary >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second >> Edition<http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> >> >
