I understand your point of view, but if we make changes that cause Appenders and Filters to break then we have made huge mistake as it will impact many of our downstream customers. Also, those are components we have said will remain backward compatible. Any change that would break these components would most likely also break components that would be left in core, and if you found yourself having to change those I would hope you would see that as a huge red flag.
Ralph > On May 7, 2017, at 11:16 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > Hi all, > > My 2c and I'll stop: It's not so much that things are stable now, it is > what will happen next. > > I've been in situations where mostly internal code (like our core but not > our API) needs to evolve but is forced to do a delicate dance and > negotiation because downstream components would break due to API changes. > If we have it all in one repo, it is easier to refactor, build, test. That > or the changes do not happen and the API stays BC but does not evolve as > fast. > > Gary > > On Sun, May 7, 2017 at 11:07 AM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> 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=cadb800f39946ec62ea2b1af9fe6a2 >> b8> >>>>>> >>>>>> <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=31ecd1f6b6d1eaf8886ac902a24de4 >> 18%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 >>>>> >>>> >>>> >>>> >> >> >> > > > -- > 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
