I think we should have multiple repos, but I don’t believe we would ever want them to be fine grained. As I said earlier, The Flume Appender hasn’t changed much in a couple of years and the changes made to it are more likely to be due to changes in Flume than in Log4j. I imagine the same could be said for all the appenders that interact with external datastores. So I would prefer to see all the no-sql stuff outside of the main build in its own repo and on it’s own release cycle. The same is probably true to filters. That is why I created the log4j-plugins project. Then those could be released on their own cycle, separate from Log4j. Also, the jsp tag library is in the same boat, but I’m not sure where a good home for that would be since those aren’t plugins and I don’t think of them as tools.
I would really like to make it so that core has as few optional dependencies as possible. I don’t think I’d ever want the bridge modules to move out of the main build. Ralph > On May 7, 2017, at 9:24 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > On May 7, 2017 9:02 AM, "Remko Popma" <remko.po...@gmail.com> wrote: > > Ralph, thanks for the transparency! > > I'm okay with that unless another tool gives a large advantage. I really > like Gradle's incremental build feature but I can live without it. However, > moving half the project into separate repos feels too much like working > around the limitations of the build tool. > > If the slow release problem can be solved by using a better release plugin > or something, then there is no urgent reason to move away from Maven. > Otherwise we should considering all options, including other build tools. > > Is that fair? > > > Ok with me. I am not s fan of going with many repos. > > Gary > > > > On Sat, May 6, 2017 at 2:50 PM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> I have to be honest. Since I am on the Maven PMC - although I haven’t >> committed anything in years - I still have a preference for using it over >> other tools. >> >> Ralph >> >>> On May 5, 2017, at 10:07 PM, Remko Popma <remko.po...@gmail.com> wrote: >>> >>> Gradle would enable you to skip the clean, so only the necessary classes >> are compiled before the tests are run. Much faster. You'll love it. >>> >>> Agreed that RM's job should be #1 priority. >>> >>> >>> (Shameless plug) Every java main() method deserves http://picocli.info >>> >>>> On May 6, 2017, at 13:40, Gary Gregory <garydgreg...@gmail.com> wrote: >>>> >>>> For normal development I run Eclipse. >>>> >>>> I run mvn clean install before I commit anything non-trivial. >>>> >>>> So whether I do that in last step in Maven or Gradle is the same to me. >>>> >>>> The RM's job should be #1 consideration IMO. >>>> >>>> Gary >>>> >>>>> On Fri, May 5, 2017 at 9:32 PM, Remko Popma <remko.po...@gmail.com> >> wrote: >>>>> >>>>> The gitflow plugin looks promising. It seems to address the problem of >> the >>>>> tests being run twice head-on >>>>> <https://www.atlassian.com/blog/software-teams/maven-git- >>>>> flow-plugin-for-better-releases> >>>>> : >>>>> >>>>>> >>>>>> - Only builds your project once in the finish goal. e.g. if you do >>>>>> release-start and release-finish together, your tests only run once >>>>>> >>>>>> >>>>> It also seems to open up possibilities for streamlining our release >>>>> procedures: since all changes are made on a branch and not on master, > a >>>>> rollback becomes very easy (just delete a branch). Would this allow us >> to >>>>> eliminate the first step in our release procedure? >>>>> >>>>> I assume we currently have `mvn clean install` as a first step >>>>> <https://wiki.apache.org/logging/Log4j2ReleaseGuide> to detect >> problems in >>>>> advance. If a rollback is easy we can just try to optimistically >> build the >>>>> release. It would be great we can reduce 3 test runs to 1. >>>>> >>>>> I'm still interested in Gradle's incremental compilation for normal >> log4j >>>>> development but no rush here. >>>>> >>>>> >>>>> >>>>> >>>>>> On Sat, May 6, 2017 at 4:42 AM, Matt Sicker <boa...@gmail.com> wrote: >>>>>> >>>>>> Yeah, it seems a bit easier to try experimenting with different Maven >>>>>> plugins first before going all in on Gradle or something else. >>>>>> >>>>>>> On 5 May 2017 at 13:26, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >>>>>>> >>>>>>> We could try using the maven gitflow plugin instead of the release >>>>>> plugin. >>>>>>> >>>>>>> Ralph >>>>>>> >>>>>>>> On May 5, 2017, at 11:22 AM, Gary Gregory <garydgreg...@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Is it possible to do mvn test and then the rest with -DskipTests? >>>>>>>> >>>>>>>> G >>>>>>>> >>>>>>>> On May 5, 2017 11:11 AM, "Ralph Goers" <ralph.go...@dslextreme.com> >>>>>>> wrote: >>>>>>>> >>>>>>>>> Probably both. >>>>>>>>> >>>>>>>>> Ralph >>>>>>>>> >>>>>>>>>> On May 5, 2017, at 10:13 AM, Matt Sicker <boa...@gmail.com> >> wrote: >>>>>>>>>> >>>>>>>>>> It seems like it. I'm not sure if it's in release:prepare or >>>>>>>>>> release:perform. >>>>>>>>>> >>>>>>>>>> On 5 May 2017 at 12:12, Gary Gregory <garydgreg...@gmail.com> >>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Are the tests run 3 times from within the same mvn call? >>>>>>>>>>> >>>>>>>>>>> Gary >>>>>>>>>>> >>>>>>>>>>> On May 5, 2017 5:54 AM, "Remko Popma" <remko.po...@gmail.com> >>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> I don't oppose breaking things up into modules, but I'm not > sure >>>>>> that >>>>>>>>> we >>>>>>>>>>>> want to move modules into separate repos: I've seen this in >>>>>> practice >>>>>>> at >>>>>>>>>>>> work and I worry we'll end up with a very complicated build. >>>>>>>>>>>> >>>>>>>>>>>> Are we open to the idea of using a different build tool that >>>>>> supports >>>>>>>>>>>> incremental builds and lets us fix one of the root causes of > the >>>>>> slow >>>>>>>>>>> build >>>>>>>>>>>> where we need to run the tests three times to do a release? >>>>>>>>>>>> >>>>>>>>>>>> I'm willing to put in the time to investigate and prototype a >>>>>> Gradle >>>>>>>>>>> build >>>>>>>>>>>> but I don't want to waste my time if we know upfront we want to >>>>>> stick >>>>>>>>>>> with >>>>>>>>>>>> Maven. >>>>>>>>>>>> >>>>>>>>>>>> Remko >>>>>>>>>>>> >>>>>>>>>>>> (Shameless plug) Every java main() method deserves >>>>>>> http://picocli.info >>>>>>>>>>>> >>>>>>>>>>>>> On May 5, 2017, at 21:11, Mikael Ståldal < >>>>>> mikael.stal...@magine.com >>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> ...but the main reason for breaking up into modules is not >> build >>>>>>>>> speed. >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, May 5, 2017 at 9:40 AM, Mikael Ståldal < >>>>>>>>>>>> mikael.stal...@magine.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I think we should continue to break up things into modules, >> but >>>>>>> keep >>>>>>>>>>>> them >>>>>>>>>>>>>> in the same repo. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, May 5, 2017 at 2:16 AM, Remko Popma < >>>>>>> remko.po...@gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why don't we focus on making the build faster instead of > this >>>>>>> module >>>>>>>>>>> & >>>>>>>>>>>>>>> repo break-up? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We know this breakup is adding all kinds of complexity but > we >>>>>> are >>>>>>>>>>> only >>>>>>>>>>>>>>> *hoping* (not sure) that it will make the build faster. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The way I've heard Ralph and Matt describe it, the build >>>>>> currently >>>>>>>>>>>>>>> requires the most time consuming part (running the tests) to >>>>> be >>>>>>>>>>>> repeated >>>>>>>>>>>>>>> three times! Wouldn't that be the first thing to look at? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is this a Maven issue? Can it be fixed? Are we open to >>>>>> considering >>>>>>>>>>>>>>> alternatives like Gradle? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm concerned we're focusing on the wrong problem. We can >>>>> break >>>>>> up >>>>>>>>>>> the >>>>>>>>>>>>>>> modules later for the right reasons (dependencies etc). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Remko >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (Shameless plug) Every java main() method deserves >>>>>>>>>>> http://picocli.info >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On May 5, 2017, at 1:58, Ralph Goers < >>>>>> ralph.go...@dslextreme.com >>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Because the build takes forever. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ralph >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On May 4, 2017, at 9:00 AM, Mikael Ståldal < >>>>>>>>>>>> mikael.stal...@magine.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am not sure it is worth the effort to keep things in >>>>>> different >>>>>>>>>>>> repos >>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>> this point. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I can see a point in keeping the Scala stuff in its own >> repo >>>>>>> since >>>>>>>>>>> it >>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>> Java 8 and scala compiler for building. The same goes for >>>>>>>>>>>> log4j-kotlin >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> any other language bindings we might want to do. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> But for logging-log4j-tools, why? It has no other build >>>>>>>>>>> requirements >>>>>>>>>>>>>>> than >>>>>>>>>>>>>>>>> the main repo. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Thu, May 4, 2017 at 5:55 PM, Gary Gregory < >>>>>>>>>>>> garydgreg...@gmail.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Thu, May 4, 2017 at 8:08 AM, Matt Sicker < >>>>>>> boa...@gmail.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I think we should really get the other git repos > released >>>>>>> before >>>>>>>>>>> we >>>>>>>>>>>>>>> make >>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>> 2.9 release. The thing holding that back, in my opinion, >>>>> is >>>>>>>>>>>> figuring >>>>>>>>>>>>>>> out >>>>>>>>>>>>>>>>>>> how to manage the website and documentation for all > these >>>>>>>>>>> separate >>>>>>>>>>>>>>>>>> modules >>>>>>>>>>>>>>>>>>> that aren't even in the same Maven project anymore. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Which makes it harder to work with... :-( >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Gary >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 4 May 2017 at 09:44, Mikael Ståldal < >>>>>>>>>>> mikael.stal...@magine.com >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I have extracted the SocketServer stuff from log4j-core >>>>> to >>>>>>> new >>>>>>>>>>>>>>>>>>> log4j-server >>>>>>>>>>>>>>>>>>>> module: >>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/LOG4J2-1851 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> That module is in the new logging-log4j-tools repo. >>>>>> However, >>>>>>>>>>> that >>>>>>>>>>>>>>> repo >>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>> not ready for making a release. Is anyone going to do >>>>> that >>>>>>>>>>> before >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> 2.9 >>>>>>>>>>>>>>>>>>>> release, or should we move the log4j-server module back >>>>> to >>>>>>> the >>>>>>>>>>>> main >>>>>>>>>>>>>>>>>> repo >>>>>>>>>>>>>>>>>>>> for the time being? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> [image: MagineTV] >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> *Mikael Ståldal* >>>>>>>>>>>>>>>>>>>> Senior software developer >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> *Magine TV* >>>>>>>>>>>>>>>>>>>> mikael.stal...@magine.com >>>>>>>>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | >>>>>>>>>>> www.magine.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Privileged and/or Confidential Information may be >>>>> contained >>>>>>> in >>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>> message. If you are not the addressee indicated in this >>>>>>> message >>>>>>>>>>>>>>>>>>>> (or responsible for delivery of the message to such a >>>>>>> person), >>>>>>>>>>> you >>>>>>>>>>>>>>> may >>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>> copy or deliver this message to anyone. In such case, >>>>>>>>>>>>>>>>>>>> you should destroy this message and kindly notify the >>>>>> sender >>>>>>> by >>>>>>>>>>>>>>> reply >>>>>>>>>>>>>>>>>>>> email. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_ >>>>>>>>>>>>>>>>>> tl?ie=UTF8&camp=1789&creative= >>>>> 9325&creativeASIN=1617290459& >>>>>>>>>>>>>>>>>> linkCode=as2&tag=garygregory-20&linkId= >>>>> cadb800f39946ec62ea2b >>>>>>>>>>>>>>> 1af9fe6a2b8> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t= >>>>> garygregory-20&l= >>>>>>>>>>>>>>> am2&o=1&a= >>>>>>>>>>>>>>>>>> 1617290459> >>>>>>>>>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_ >>>>>>>>>>>>>>>>>> tl?ie=UTF8&camp=1789&creative= >>>>> 9325&creativeASIN=1935182021& >>>>>>>>>>>>>>>>>> linkCode=as2&tag=garygregory-20&linkId= >>>>> 31ecd1f6b6d1eaf8886ac >>>>>>>>>>>>>>> 902a24de418%22 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t= >>>>> garygregory-20&l= >>>>>>>>>>>>>>> am2&o=1&a= >>>>>>>>>>>>>>>>>> 1935182021> >>>>>>>>>>>>>>>>>> Spring Batch in Action >>>>>>>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_ >>>>>>>>>>>>>>>>>> tl?ie=UTF8&camp=1789&creative= >>>>> 9325&creativeASIN=1935182951& >>>>>>>>>>>>>>>>>> linkCode=%7B%7BlinkCode%7D%7D& >>>>> tag=garygregory-20&linkId=%7B% >>>>>>>>>>>>>>>>>> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> >>>>>>>>>>>>>>>>>> <http:////ir-na.amazon-adsystem.com/e/ir?t= >>>>> garygregory-20&l= >>>>>>>>>>>>>>> am2&o=1&a= >>>>>>>>>>>>>>>>>> 1935182951> >>>>>>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> [image: MagineTV] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *Mikael Ståldal* >>>>>>>>>>>>>>>>> Senior software developer >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> *Magine TV* >>>>>>>>>>>>>>>>> mikael.stal...@magine.com >>>>>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | >>>>>>> www.magine.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Privileged and/or Confidential Information may be > contained >>>>> in >>>>>>>>> this >>>>>>>>>>>>>>>>> message. If you are not the addressee indicated in this >>>>>> message >>>>>>>>>>>>>>>>> (or responsible for delivery of the message to such a >>>>> person), >>>>>>> you >>>>>>>>>>>> may >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>> copy or deliver this message to anyone. In such case, >>>>>>>>>>>>>>>>> you should destroy this message and kindly notify the >> sender >>>>>> by >>>>>>>>>>> reply >>>>>>>>>>>>>>>>> email. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> [image: MagineTV] >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Mikael Ståldal* >>>>>>>>>>>>>> Senior software developer >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Magine TV* >>>>>>>>>>>>>> mikael.stal...@magine.com >>>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | >>>>> www.magine.com >>>>>>>>>>>>>> >>>>>>>>>>>>>> Privileged and/or Confidential Information may be contained > in >>>>>> this >>>>>>>>>>>>>> message. If you are not the addressee indicated in this >> message >>>>>>>>>>>>>> (or responsible for delivery of the message to such a > person), >>>>>> you >>>>>>>>> may >>>>>>>>>>>> not >>>>>>>>>>>>>> copy or deliver this message to anyone. In such case, >>>>>>>>>>>>>> you should destroy this message and kindly notify the sender >> by >>>>>>> reply >>>>>>>>>>>>>> email. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> [image: MagineTV] >>>>>>>>>>>>> >>>>>>>>>>>>> *Mikael Ståldal* >>>>>>>>>>>>> Senior software developer >>>>>>>>>>>>> >>>>>>>>>>>>> *Magine TV* >>>>>>>>>>>>> mikael.stal...@magine.com >>>>>>>>>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | >>>>> www.magine.com >>>>>>>>>>>>> >>>>>>>>>>>>> Privileged and/or Confidential Information may be contained in >>>>>> this >>>>>>>>>>>>> message. If you are not the addressee indicated in this > message >>>>>>>>>>>>> (or responsible for delivery of the message to such a person), >>>>> you >>>>>>> may >>>>>>>>>>>> not >>>>>>>>>>>>> copy or deliver this message to anyone. In such case, >>>>>>>>>>>>> you should destroy this message and kindly notify the sender > by >>>>>>> reply >>>>>>>>>>>>> email. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matt Sicker <boa...@gmail.com> >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>> Java Persistence with Hibernate, Second Edition >>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_ >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459& >> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> >>>> >>>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= >> 1617290459> >>>> JUnit in Action, Second Edition >>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_ >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021& >> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22 >>> >>>> >>>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= >> 1935182021> >>>> Spring Batch in Action >>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_ >> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951& >> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B% >> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> >>>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a= >> 1935182951> >>>> Blog: http://garygregory.wordpress.com >>>> Home: http://garygregory.com/ >>>> Tweet! http://twitter.com/GaryGregory >>> >> >> >>
