On Mon, Jan 28, 2013 at 10:18 AM, Bruno P. Kinoshita <ki...@apache.org>wrote:
> Hi Matt
>
> > As for the modularization, I went ahead and did this in the trunk. On
> >the overall I think Bruno's work is proceeding in a good direction, so I
> >agree that it should be merged back to trunk when ready.
>
> Thanks! I'll sync the repos here at office in the next hours. Regarding
> the other refactorings.
>
> >- LoopingGenerator's wrapping constructor should only accept other looping
> >generators; otherwise, the objects will do things users probably don't
> >expect.
>
> +1 it makes sense indeed
>
I've actually realized now that it should not be necessary for the
generator wrapped by one of these to implement
whatever-the-name-of-the-abstract-class is. I am now thinking
PredicatedGenerator with a Behavior enum { TEST_BEFORE, TEST_AFTER }.
Matt
>
> >- LoopingGenerator should be renamed to something that relates to its
> >"stoppable" quality. StoppableGenerator? InterruptibleGenerator?
>
> I first named it StoppableGenerator, then changed to LoopGenerator since
> it was being used in classes that reproduced while, dowhile, until, etc.
>
> StoppableGenerator makes it very clear the "stoppable" behaviour of the
> generators, but I'm okay with any name. My main concern was having the
> stop() method in the Generator interface :)
>
> >- Several of the generator implementations, e.g. UntilGenerate, don't seem
> >to behave consistently with their description.
>
> I'll take a look on the generators again, but I remember it took me some
> time to get used to the Until, DoWhile, UntilGenerate and other generators.
>
> >- I still feel Range should be decoupled from Generator. I think it would
> >be better to join a Range<T> with a UnaryFunction<T, T> to create the step
> >needed to go from Range to Generator. This would be more flexible than a
> >simple addition-based step anyway.
>
> +1 sounds great Matt. IIUC, this way if I wanted something like a
> PrimeNumberGenerator, I could pass a PrimeNumberFunction. FWIW, there is a
> Range in the lambda project too, probably it is worth taking a look on
> their API too.
>
> Thanks!
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>
> >________________________________
> > From: Matt Benson <gudnabr...@gmail.com>
> >To: Simone Tripodi <simonetrip...@apache.org>
> >Cc: Commons Developers List <dev@commons.apache.org>
> >Sent: Monday, January 28, 2013 2:00 PM
> >Subject: Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges
> >
> >Hi Simo,
> > As for the modularization, I went ahead and did this in the trunk. On
> >the overall I think Bruno's work is proceeding in a good direction, so I
> >agree that it should be merged back to trunk when ready. I have some more
> >refactorings i am interested to try out on this, or another, branch.
> These
> >are all, of course, my opinion:
> >
> >- LoopingGenerator's wrapping constructor should only accept other looping
> >generators; otherwise, the objects will do things users probably don't
> >expect.
> >- LoopingGenerator should be renamed to something that relates to its
> >"stoppable" quality. StoppableGenerator? InterruptibleGenerator?
> >- Several of the generator implementations, e.g. UntilGenerate, don't seem
> >to behave consistently with their description.
> >- I still feel Range should be decoupled from Generator. I think it would
> >be better to join a Range<T> with a UnaryFunction<T, T> to create the step
> >needed to go from Range to Generator. This would be more flexible than a
> >simple addition-based step anyway.
> >
> >Does anyone object to any of these changes?
> >
> >Matt
> >
> >
> >On Mon, Jan 28, 2013 at 2:46 AM, Simone Tripodi <simonetrip...@apache.org
> >wrote:
> >
> >> Hi Matt,
> >>
> >> I had a quick look at your branch and I honestly think it is a very
> >> good work, maybe we could insert even more modules granularization,
> >> but IMHO it worths to merge it in the main branch.
> >> Do you see any blocker?
> >>
> >> Best and thanks!
> >> -Simo
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://simonetripodi.livejournal.com/
> >> http://twitter.com/simonetripodi
> >> http://www.99soft.org/
> >>
> >>
> >> On Sun, Jan 27, 2013 at 6:39 PM, Matt Benson <gudnabr...@gmail.com>
> wrote:
> >> > All: I have merged Bruno's work to
> >> >
> >>
> https://svn.apache.org/repos/asf/commons/proper/functor/branches/FUNCTOR-14-mmbased
> >> > on functor's multi-module reorg.
> >> >
> >> > Matt
> >> >
> >> >
> >> > On Wed, Sep 19, 2012 at 2:12 AM, Simone Tripodi <
> >> simonetrip...@apache.org>wrote:
> >> >
> >> >> Olá Bruno,
> >> >>
> >> >> excellent work, congrats!! I will have a look tonight (my local TZ)
> >> >> I'll try to let you know ASAP!
> >> >>
> >> >> thanks, all the best!
> >> >> -Simo
> >> >>
> >> >> http://people.apache.org/~simonetripodi/
> >> >> http://simonetripodi.livejournal.com/
> >> >> http://twitter.com/simonetripodi
> >> >> http://www.99soft.org/
> >> >>
> >> >>
> >> >> On Wed, Sep 19, 2012 at 4:12 AM, Bruno P. Kinoshita
> >> >> <brunodepau...@yahoo.com.br> wrote:
> >> >> > Hi all,
> >> >> >
> >> >> > me again bringing a new implementation idea for the Generators API
> >> >> >
> >> >> > in [functor], and looking forward to some thoughts on this :-)
> >> >> >
> >> >> > There is a separate branch for this issue [1], and here's what has
> >> been
> >> >> done.
> >> >> >
> >> >> > - Split Generator interface into Generator interface and
> LoopGenerator
> >> >> > (abstract class). IMO, this will help in modularization (see this
> >> >> discussion [2])
> >> >> > in the Generators API, as the stop() method and the wrapped
> >> generators,
> >> >> > for instance, had been added because of the generators created for
> >> >> handling
> >> >> > execution flow control (e.g.: GenerateWhile, UntilGenerate, etc).
> >> >> >
> >> >> > - Moved LoopGenerator and its implementations under the newly
> created
> >> >> > org.apache.commons.functor.generator.loop package.
> >> >> >
> >> >> > - Moved IntegerRange and LongRange from
> >> >> org.apache.commons.functor.generator.util to
> >> >> > the newly created org.apache.commons.functor.generator.range
> package.
> >> >> >
> >> >> > - Created a Range API, with a Range interface, a Ranges helper
> >> interface
> >> >> and
> >> >> > some implementations (including existing IntegerRange and
> LongRange,
> >> and
> >> >> new
> >> >> > ones like DoubleRange, FloatRange and CharacterRange).
> >> >> >
> >> >> > - Added steps different than 1 to Ranges (not the generator
> interface,
> >> >> as this
> >> >> > is related only to ranges).
> >> >> >
> >> >> > - The Ranges implemented are all Generators too, what is very
> >> >> convenient, as you
> >> >> > can use Ranges to both define intervals and/or execute a procedure
> for
> >> >> each of its
> >> >> > elements.
> >> >> >
> >> >> > I've wrote a sample code using the existing Generators API [3] and
> >> wrote
> >> >> the
> >> >> > same code for the new Generators API [4]. The API is compatible,
> but
> >> as
> >> >> some
> >> >> > packages changed, you have to update existing code (but as
> [functor]
> >> >> hasn't been
> >> >> > released yet, it shouldn't be a problem I believe :-). Both codes
> >> >> produce the
> >> >> > same output too (0 1 2 3 4 5 6 7 8 9 ).
> >> >> >
> >> >> > And here's an example [5] of creating Ranges and using them as
> >> >> Generators. More
> >> >> > examples can be found in the tests for the Generator and the Range
> >> API's.
> >> >> >
> >> >> > I've updated the examples page and added tests. I've also updated
> the
> >> >> parent
> >> >> > pom to 26, but as this is not related to the FUNCTOR-14 issue, we
> can
> >> >> drop this
> >> >> >
> >> >> > part when merging the code.
> >> >> >
> >> >> > I'll merge the changes to trunk if everybody thinks this new
> >> >> implementation is
> >> >> > better than the current one.
> >> >> >
> >> >> > A side note: PHP recently got generators too [6], and an
> interesting
> >> >> thing that I noticed in
> >> >> > their Wiki was the discussion about callback functions. After
> reading
> >> the
> >> >> > discussion, for me it looks like [functor] generators API is more
> >> >> similar to
> >> >> > callback handler. Differently than the Python and PHP
> implementations
> >> >> with the
> >> >> > yield statement.
> >> >> >
> >> >> > Thank you in advance!
> >> >> >
> >> >> > [1]
> >> >>
> >>
> https://svn.apache.org/repos/asf/commons/proper/functor/branches/generators-FUNCTOR-14
> >> >> > [2] http://markmail.org/message/nymsk7l64aj4csxi
> >> >> > [3] https://gist.github.com/3747204
> >> >> > [4] https://gist.github.com/3747207
> >> >> > [5] https://gist.github.com/3747224
> >> >> > [5] https://wiki.php.net/rfc/generators
> >> >> >
> >> >> > Bruno P. Kinoshita
> >> >> > http://kinoshita.eti.br
> >> >> > http://tupilabs.com
> >> >> >
> >> >> >>________________________________
> >> >> >> From: Matt Benson <gudnabr...@gmail.com>
> >> >> >>To: Bruno P. Kinoshita <brunodepau...@yahoo.com.br>
> >> >> >>Cc: Commons Developers List <dev@commons.apache.org>
> >> >> >>Sent: Wednesday, 6 June 2012 9:56 AM
> >> >> >>Subject: Re: [functor] Patch for FUNCTOR-14, new Generators and
> Ranges
> >> >> >>
> >> >> >>On Tue, Jun 5, 2012 at 11:48 PM, Bruno P. Kinoshita
> >> >> >><brunodepau...@yahoo.com.br> wrote:
> >> >> >>> Hi Matt,
> >> >> >>>
> >> >> >>>
> >> >> >>>> Would there be a type of Range that could not be turned into a
> >> >> >>>> Generator given a compatible Step parameter? If not, we could
> >> define:
> >> >> >>>>
> >> >> >>>> interface Range<T, S> {
> >> >> >>>> ...
> >> >> >>>> Generator<T> toGenerator(S step);
> >> >> >>>> }
> >> >> >>>>
> >> >> >>>> This way, Range itself does not contain a step, but still
> maintains
> >> >> >>>> control over how a step is used to create a generator.
> >> >> >>>
> >> >> >>> I can't think of any type that could not be turned into a
> generator
> >> >> given
> >> >> >>> the step parameter. But if a range has no step, I think we would
> >> have
> >> >> to
> >> >> >>> remove the isEmpty(), contains(), containsAll() methods from
> range
> >> >> >>> implementations, as using steps higher than 1, we need to use the
> >> step
> >> >> value
> >> >> >>> to check if a range is empty or contains a certain element (e.g.:
> >> >> integer
> >> >> >>> range (1, 2], step 3, check if contains(2) or isEmpty()).
> >> >> >>>
> >> >> >>
> >> >> >>My thought was that by decoupling a Range from a step, you use only
> >> >> >>the bound types/values to determine inclusion of a given value.
> If a
> >> >> >>Generator is created from (1, 2] with step 3, then that Generator
> will
> >> >> >>only return 1, but that doesn't reflect on the Range, IMO.
> >> >> >>
> >> >> >>Matt
> >> >> >>
> >> >> >>>
> >> >> >>>> Either way, I like the notion that a Range is its own type that
> >> just
> >> >> >>>> *happens* to either provide access to, or an implementation of,
> >> >> >>>> Generator.
> >> >> >>>
> >> >> >>> +1, let it provide access or be an implementation of Generator.
> In
> >> >> case we
> >> >> >>> do the latter case, I believe isEmpty(), contains() and other
> >> methods
> >> >> using
> >> >> >>> the step value would be doable.
> >> >> >>>
> >> >> >>> Regards,
> >> >> >>>
> >> >> >>>
> >> >> >>> Bruno P. Kinoshita
> >> >> >>> http://www.kinoshita.eti.br
> >> >> >>> http://www.tupilabs.com
> >> >> >>>
> >> >> >>> On 06/05/2012 11:52 PM, Matt Benson wrote:
> >> >> >>>>
> >> >> >>>> Hi, Bruno. Likewise, answers inline:
> >> >> >>>>
> >> >> >>>> On Tue, Jun 5, 2012 at 9:32 PM, Bruno P. Kinoshita
> >> >> >>>> <brunodepau...@yahoo.com.br> wrote:
> >> >> >>>>>
> >> >> >>>>> Hi Matt!
> >> >> >>>>>
> >> >> >>>>> Thanks for your response! Answers added inline.
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>> 1. Why are a Range's type and step-type potentially different
> >> >> >>>>>> (different type variables, etc.)?
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> When I started writing this patch, the range's type and
> step-type
> >> >> were
> >> >> >>>>> the
> >> >> >>>>> same (i.e. the interface had only one generics type,<T>), but
> >> then I
> >> >> >>>>> created the CharacterRange and it didn't work because its range
> >> type
> >> >> is
> >> >> >>>>> Character and its step-type is Integer (same would happen for a
> >> >> >>>>> DateRange).
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> I see; good point.
> >> >> >>>>
> >> >> >>>>>
> >> >> >>>>> What do you think? Maybe with some generics magic or with a
> >> different
> >> >> >>>>> approach we could remove the step-type? (I would be +1 for
> this)
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>> 2. Why, if it is a Generator's responsibility to generate
> items
> >> >> >>>>>> subsequent to the lower endpoint, is the step part of the
> range
> >> at
> >> >> >>>>>> all? Based on [1], which definition of "range" are we
> attempting
> >> to
> >> >> >>>>>> represent?
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> In google guava and java-yield a range is a generator, as it
> was
> >> in
> >> >> >>>>> [functor] too (this patch removes the old IntegerRange, a
> >> generator
> >> >> of
> >> >> >>>>> Integers).
> >> >> >>>>>
> >> >> >>>>> [functor] has generators that don't require steps
> (GenerateWhile,
> >> >> >>>>> WhileGenerate, UntilGenerate, etc). I think random generators
> >> >> wouldn't
> >> >> >>>>> use
> >> >> >>>>> steps too (e.g.: RandomIntegerGenerator,
> USPhoneNumberGenerator,
> >> >> >>>>> UUIDGenerator, PrimeNumberGenerator).
> >> >> >>>>>
> >> >> >>>>> The initial idea of the Range interface, was to have similar
> >> >> behavior as
> >> >> >>>>> commons-lang's Range [1], plus being able to define steps and
> have
> >> >> the
> >> >> >>>>> actual process (the yield) being executed by an external
> agent, a
> >> >> >>>>> generator.
> >> >> >>>>> In the end, I think the of the Range in my patch would be more
> >> like
> >> >> an
> >> >> >>>>> Interval [2]?.
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>> The current code seems to implement definition 2 and
> >> >> >>>>>> *part* of definition 3, deferring the rest to a corresponding
> >> >> >>>>>> Generator.
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> I couldn't have said it better :-)
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>>> Settling the question of whether [functor]'s Range is a
> >> >> >>>>>> "2-range" or also a "3-range" would seem to dictate our
> action:
> >> do
> >> >> we
> >> >> >>>>>> move the step to the generator, or do we make Range calculate
> >> each
> >> >> >>>>>> item (in which case would it be simpler for Range to implement
> >> >> >>>>>> Generator)?
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> After reading your considerations, I now think that it would be
> >> >> better to
> >> >> >>>>> maintain the current approach (Range implements a Generator)
> and
> >> try
> >> >> to
> >> >> >>>>> implement generators for double, float and character using the
> >> actual
> >> >> >>>>> interfaces and try to use steps. What do you think?
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Would there be a type of Range that could not be turned into a
> >> >> >>>> Generator given a compatible Step parameter? If not, we could
> >> define:
> >> >> >>>>
> >> >> >>>> interface Range<T, S> {
> >> >> >>>> ...
> >> >> >>>> Generator<T> toGenerator(S step);
> >> >> >>>> }
> >> >> >>>>
> >> >> >>>> This way, Range itself does not contain a step, but still
> maintains
> >> >> >>>> control over how a step is used to create a generator.
> >> >> >>>>
> >> >> >>>>>
> >> >> >>>>> Do you think we should keep the naming standard
> >> >> IntegerRange/LongRange,
> >> >> >>>>> or
> >> >> >>>>> change them to IntegerGenerator/LongGenerator?
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Either way, I like the notion that a Range is its own type that
> >> just
> >> >> >>>> *happens* to either provide access to, or an implementation of,
> >> >> >>>> Generator.
> >> >> >>>>
> >> >> >>>> br,
> >> >> >>>> Matt
> >> >> >>>>
> >> >> >>>>>
> >> >> >>>>> Thank you for reviewing my patch and for the interesting
> >> questions!
> >> >> I'm
> >> >> >>>>> no
> >> >> >>>>> FP expert either, feel free to suggest different ideas, no hard
> >> >> feelings
> >> >> >>>>> :)
> >> >> >>>>>
> >> >> >>>>> [1]
> >> >> >>>>>
> >> >> >>>>>
> >> >>
> >>
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/Range.java?view=markup
> >> >> >>>>> [2] http://en.wikipedia.org/wiki/Interval_(mathematics)
> >> >> >>>>>
> >> >> >>>>> Bruno P. Kinoshita
> >> >> >>>>> http://www.kinoshita.eti.br
> >> >> >>>>> http://www.tupilabs.com
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> On 06/05/2012 12:08 PM, Matt Benson wrote:
> >> >> >>>>>>
> >> >> >>>>>>
> >> >> >>>>>> Hi, Bruno!
> >> >> >>>>>>
> >> >> >>>>>> I have some questions:
> >> >> >>>>>>
> >> >> >>>>>> 1. Why are a Range's type and step-type potentially different
> >> >> >>>>>> (different type variables, etc.)?
> >> >> >>>>>> 2. Why, if it is a Generator's responsibility to generate
> items
> >> >> >>>>>> subsequent to the lower endpoint, is the step part of the
> range
> >> at
> >> >> >>>>>> all? Based on [1], which definition of "range" are we
> >> attempting to
> >> >> >>>>>> represent? The current code seems to implement definition 2
> and
> >> >> >>>>>> *part* of definition 3, deferring the rest to a corresponding
> >> >> >>>>>> Generator. Settling the question of whether [functor]'s Range
> >> is a
> >> >> >>>>>> "2-range" or also a "3-range" would seem to dictate our
> action:
> >> do
> >> >> we
> >> >> >>>>>> move the step to the generator, or do we make Range calculate
> >> each
> >> >> >>>>>> item (in which case would it be simpler for Range to implement
> >> >> >>>>>> Generator)?
> >> >> >>>>>>
> >> >> >>>>>> I am by no means an FP or any other type of expert, so feel
> free
> >> to
> >> >> >>>>>> show me why I'm wrong on a given point!
> >> >> >>>>>>
> >> >> >>>>>> br,
> >> >> >>>>>> Matt
> >> >> >>>>>>
> >> >> >>>>>> [1] http://en.wikipedia.org/wiki/Range_(computer_science)
> >> >> >>>>>>
> >> >> >>>>>> On Mon, Jun 4, 2012 at 11:59 PM, Bruno P. Kinoshita
> >> >> >>>>>> <brunodepau...@yahoo.com.br> wrote:
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>> Hi all,
> >> >> >>>>>>>
> >> >> >>>>>>> I've finished a patch for FUNCTOR-14, regarding the
> Generators
> >> API
> >> >> in
> >> >> >>>>>>> [functor]. I'd like to hear what others think about what was
> >> done
> >> >> >>>>>>> before
> >> >> >>>>>>> attaching the patch to JIRA:
> >> >> >>>>>>>
> >> >> >>>>>>> - Didn't change the Generator interface. Although I
> commented in
> >> >> the
> >> >> >>>>>>> issue about removing the stop() and isStopped() methods and
> >> moving
> >> >> to a
> >> >> >>>>>>> different interface, it would require a major refactoring, as
> >> many
> >> >> >>>>>>> other
> >> >> >>>>>>> generators are built upon this idea.
> >> >> >>>>>>>
> >> >> >>>>>>> - Created IntegerGenerator, LongGenerator, FloatGenerator,
> >> >> >>>>>>> DoubleGenerator and CharacterGenerator. Didn't implement a
> >> >> >>>>>>> DateGenerator as
> >> >> >>>>>>> it would require more time and a discussion on how to use
> days,
> >> >> months,
> >> >> >>>>>>> years, days of week, etc.
> >> >> >>>>>>>
> >> >> >>>>>>> - Introduced Ranges, with the following initial ranges:
> >> >> IntegerRange,
> >> >> >>>>>>> LongRange, FloatRange, DoubleRange and CharacterRange. This
> API
> >> is
> >> >> >>>>>>> quite
> >> >> >>>>>>> similar to other existing APIs, with the difference that you
> can
> >> >> >>>>>>> specify the
> >> >> >>>>>>> step (like ranges in Matlab)
> >> >> >>>>>>>
> >> >> >>>>>>> - The generators that use numbers (there are many other
> >> generators,
> >> >> >>>>>>> like
> >> >> >>>>>>> GenerateWhile, GenerateUntil, etc) use ranges to create the
> >> >> series. The
> >> >> >>>>>>> objects are created only when the generator is executed,
> >> calling a
> >> >> >>>>>>> procedure. Like in python, but instead of retrieving the
> value
> >> >> with a
> >> >> >>>>>>> 'yield' statement, we give a procedure to be executed using
> the
> >> >> value
> >> >> >>>>>>> created.
> >> >> >>>>>>>
> >> >> >>>>>>> - Included tests to cover the changes.
> >> >> >>>>>>>
> >> >> >>>>>>> - Updated web site examples.
> >> >> >>>>>>>
> >> >> >>>>>>> All the tests passed, no checkstyle/pmd/findbugs errors. The
> >> >> character
> >> >> >>>>>>> range/generator is a very simple, and there are some
> operations
> >> >> with
> >> >> >>>>>>> double/float in the ranges and generators. I keep my code
> >> mirrored
> >> >> in
> >> >> >>>>>>> github
> >> >> >>>>>>> too, in case someone prefers reading it there
> >> >> >>>>>>> https://github.com/kinow/functor.
> >> >> >>>>>>>
> >> >> >>>>>>> Let me know what you think about it :-)
> >> >> >>>>>>>
> >> >> >>>>>>> Thank you in advance!
> >> >> >>>>>>>
> >> >> >>>>>>> Bruno P. Kinoshita
> >> >> >>>>>>> http://kinoshita.eti.br
> >> >> >>>>>>> http://tupilabs.com
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>>>> 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
> >> >> >>>>
> >> >> >>>
> >> >> >>
> >> >>
> >>---------------------------------------------------------------------
> >> >> >>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
> >> >>
> >> >>
> >>
> >
> >
> >
>
