date:20130128

Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges

2013-01-28 Thread Simone Tripodi

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  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 
> 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
>>  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 
>> >>To: Bruno P. Kinoshita 
>> >>Cc: Commons Developers List 
>> >>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
>> >> 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  {
>>  ...
>> Generator  toGenerator(S step);
>>  }
>> 
>>  This way, Range itself does not contain a step, but still maintains
>> >

Re: [ANNOUNCE] Commons Parent 28 released

2013-01-28 Thread Gary Gregory

If I do "mvn -Preporting clean site" with CP 28 I get:

[INFO]
[INFO] <<< jdepend-maven-plugin:2.0-beta-2:generate (report:generate) @
commons-codec <<<
[INFO] configuring report plugin
org.codehaus.mojo:cobertura-maven-plugin:2.5.2
[WARNING] The POM for org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2 is
missing, no dependency information available
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 37.852s
[INFO] Finished at: Mon Jan 28 08:00:13 EST 2013
[INFO] Final Memory: 36M/411M
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
project commons-codec: failed to get report for
org.codehaus.mojo:cobertura-maven-plugin: Plugin
org.codehaus.mojo:cobertura-mave
n-plugin:2.5.2 or one of its dependencies could not be resolved: Failed to
read artifact descriptor for
org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2: Failure to find
org.codehaus.mojo:cobertura-maven-plugin:pom:2.5.2 in http
://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced -> [Help 1]

:(

Gary


On Sun, Jan 27, 2013 at 8:34 AM, sebb  wrote:

> Or just try -Preporting which is where Cobertura was moved.
>
> Sorry, should have done a full compare of the poms before release;
> several changes were omitted from the change list.
>
> On 27 January 2013 13:10, Gary Gregory  wrote:
> > This is a bummer. Most of the components I see do use cobertura. So
> > I'll have to skip 28 and wait for 29.
> >
> > Gary
> >
> > On Jan 27, 2013, at 7:40, sebb  wrote:
> >
> >> On 26 January 2013 16:22, Benedikt Ritter  wrote:
> >>> As far as I know, this is because cobertura was dropped in favor of
> Sonar.
> >>> I guess codec should
> >>> a) define the dependency to cobertura itself
> >>> b) use Sonar, like some of the other components (like math) already do.
> >>
> >> c) Update CP29 so it supports Cobertura as an optional profile. I
> >> think that was mentioned, and then forgotten.
> >>
> >>> Regards,
> >>> Benedikt
> >>>
> >>>
> >>> 2013/1/26 Gary Gregory 
> >>>
>  Arg, with [codec] I get:
> 
>  [INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @
>  commons-codec ---
>  [INFO] Nothing to compile - all classes are up to date
>  [INFO]
>  [INFO] <<< jdepend-maven-plugin:2.0-beta-2:generate (report:generate)
> @
>  commons-codec <<<
>  [INFO] configuring report plugin
>  org.codehaus.mojo:cobertura-maven-plugin:2.5.2
>  [WARNING] The POM for
> org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2 is
>  missing, no dependency information available
>  [INFO]
> 
> 
>  [INFO] BUILD FAILURE
>  [INFO]
> 
> 
>  [INFO] Total time: 20.274s
>  [INFO] Finished at: Sat Jan 26 10:06:11 EST 2013
>  [INFO] Final Memory: 32M/345M
>  [INFO]
> 
> 
>  [ERROR] Failed to execute goal
>  org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
>  project commons-codec: failed to get report for
>  org.codehaus.mojo:cobertura-maven-plugin: Plugin
>  org.codehaus.mojo:cobertura-mave
>  n-plugin:2.5.2 or one of its dependencies could not be resolved:
> Failed to
>  read artifact descriptor for
>  org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2: Failure to find
>  org.codehaus.mojo:cobertura-maven-plugin:pom:2.5.2 in http
>  ://repo.maven.apache.org/maven2 was cached in the local repository,
>  resolution will not be reattempted until the update interval of
> central has
>  elapsed or updates are forced -> [Help 1]
>  [ERROR]
> 
>  Gary
> 
> 
>  On Sat, Jan 26, 2013 at 4:53 AM, sebb  wrote:
> 
> > Commons Parent 28 has been released.
> >
> > Release notes:
> 
> https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-28/RELEASE-NOTES.txt
> >
> > Components are recommended to upgrade when convenient, but this is
> not
> > compulsory.
> >
> > If upgrading causes any breaking changes, please report ASAP so a new
> > release can be prepared.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
>  --
>  E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>  JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>  Spring Bat

[GUMP@vmgump]: Project commons-proxy (in module apache-commons) failed

2013-01-28 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-proxy has an issue affecting its community integration.
This issue affects 2 projects.
The current state of this project is 'Failed', with reason 'Build Timed Out'.
For reference only, the following projects are affected by this:
- commons-proxy :  Java library for dynamic proxying
- commons-proxy-test :  Apache Commons


Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-proxy-*[0-9T].jar] identifier set to project 
name
 -INFO- Optional dependency ws-axis failed with reason build timed out
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build timed out
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy/gump_work/build_apache-commons_commons-proxy.html
Work Name: build_apache-commons_commons-proxy (Type: Build)
Work ended in a state of : Failed
Elapsed: 60 mins
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
[INFO] Scanning for projects...
[INFO] 
[INFO] Building Commons Proxy
[INFO]task-segment: [package]
[INFO] 
Downloading: 
http://localhost:8192/maven2/cglib/cglib-nodep/2.1_3/cglib-nodep-2.1_3.pom
-

To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy/atom.xml

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 20130125180006, vmgump.apache.org:vmgump:20130125180006
Gump E-mail Identifier (unique within run) #54.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ANNOUNCE] Commons Parent 28 released

2013-01-28 Thread Benedikt Ritter

Hey Gary,

I had a short look at the parent and it seems to be okay... I'll try to
build codec after work when I'm at home. Until then, you could try mvn
clean install -U to force update of releases (and snapshots). Maybe -X
gives us some more information, whats wrong...

Benedikt


2013/1/28 Gary Gregory 

> If I do "mvn -Preporting clean site" with CP 28 I get:
>
> [INFO]
> [INFO] <<< jdepend-maven-plugin:2.0-beta-2:generate (report:generate) @
> commons-codec <<<
> [INFO] configuring report plugin
> org.codehaus.mojo:cobertura-maven-plugin:2.5.2
> [WARNING] The POM for org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2 is
> missing, no dependency information available
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 37.852s
> [INFO] Finished at: Mon Jan 28 08:00:13 EST 2013
> [INFO] Final Memory: 36M/411M
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> project commons-codec: failed to get report for
> org.codehaus.mojo:cobertura-maven-plugin: Plugin
> org.codehaus.mojo:cobertura-mave
> n-plugin:2.5.2 or one of its dependencies could not be resolved: Failed to
> read artifact descriptor for
> org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2: Failure to find
> org.codehaus.mojo:cobertura-maven-plugin:pom:2.5.2 in http
> ://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of central has
> elapsed or updates are forced -> [Help 1]
>
> :(
>
> Gary
>
>
> On Sun, Jan 27, 2013 at 8:34 AM, sebb  wrote:
>
> > Or just try -Preporting which is where Cobertura was moved.
> >
> > Sorry, should have done a full compare of the poms before release;
> > several changes were omitted from the change list.
> >
> > On 27 January 2013 13:10, Gary Gregory  wrote:
> > > This is a bummer. Most of the components I see do use cobertura. So
> > > I'll have to skip 28 and wait for 29.
> > >
> > > Gary
> > >
> > > On Jan 27, 2013, at 7:40, sebb  wrote:
> > >
> > >> On 26 January 2013 16:22, Benedikt Ritter 
> wrote:
> > >>> As far as I know, this is because cobertura was dropped in favor of
> > Sonar.
> > >>> I guess codec should
> > >>> a) define the dependency to cobertura itself
> > >>> b) use Sonar, like some of the other components (like math) already
> do.
> > >>
> > >> c) Update CP29 so it supports Cobertura as an optional profile. I
> > >> think that was mentioned, and then forgotten.
> > >>
> > >>> Regards,
> > >>> Benedikt
> > >>>
> > >>>
> > >>> 2013/1/26 Gary Gregory 
> > >>>
> >  Arg, with [codec] I get:
> > 
> >  [INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @
> >  commons-codec ---
> >  [INFO] Nothing to compile - all classes are up to date
> >  [INFO]
> >  [INFO] <<< jdepend-maven-plugin:2.0-beta-2:generate
> (report:generate)
> > @
> >  commons-codec <<<
> >  [INFO] configuring report plugin
> >  org.codehaus.mojo:cobertura-maven-plugin:2.5.2
> >  [WARNING] The POM for
> > org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2 is
> >  missing, no dependency information available
> >  [INFO]
> > 
> > 
> >  [INFO] BUILD FAILURE
> >  [INFO]
> > 
> > 
> >  [INFO] Total time: 20.274s
> >  [INFO] Finished at: Sat Jan 26 10:06:11 EST 2013
> >  [INFO] Final Memory: 32M/345M
> >  [INFO]
> > 
> > 
> >  [ERROR] Failed to execute goal
> >  org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site)
> on
> >  project commons-codec: failed to get report for
> >  org.codehaus.mojo:cobertura-maven-plugin: Plugin
> >  org.codehaus.mojo:cobertura-mave
> >  n-plugin:2.5.2 or one of its dependencies could not be resolved:
> > Failed to
> >  read artifact descriptor for
> >  org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2: Failure to find
> >  org.codehaus.mojo:cobertura-maven-plugin:pom:2.5.2 in http
> >  ://repo.maven.apache.org/maven2 was cached in the local repository,
> >  resolution will not be reattempted until the update interval of
> > central has
> >  elapsed or updates are forced -> [Help 1]
> >  [ERROR]
> > 
> >  Gary
> > 
> > 
> >  On Sat, Jan 26, 2013 at 4:53 AM, sebb  wrote:
> > 
> > > Commons Parent 28 has been released.
> > >
> > > Release notes:
> > 
> >
> https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-28/RELEASE-NOTES.txt
> > >
> > > Components are recommended to upgrade when convenien

Re: [ANNOUNCE] Commons Parent 28 released

2013-01-28 Thread Benedikt Ritter

Sorry, in your case it should be mvn -Preporting clean site -U

Benedikt


2013/1/28 Benedikt Ritter 

> Hey Gary,
>
> I had a short look at the parent and it seems to be okay... I'll try to
> build codec after work when I'm at home. Until then, you could try mvn
> clean install -U to force update of releases (and snapshots). Maybe -X
> gives us some more information, whats wrong...
>
> Benedikt
>
>
> 2013/1/28 Gary Gregory 
>
>> If I do "mvn -Preporting clean site" with CP 28 I get:
>>
>> [INFO]
>> [INFO] <<< jdepend-maven-plugin:2.0-beta-2:generate (report:generate) @
>> commons-codec <<<
>> [INFO] configuring report plugin
>> org.codehaus.mojo:cobertura-maven-plugin:2.5.2
>> [WARNING] The POM for org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2
>> is
>> missing, no dependency information available
>> [INFO]
>> 
>> [INFO] BUILD FAILURE
>> [INFO]
>> 
>> [INFO] Total time: 37.852s
>> [INFO] Finished at: Mon Jan 28 08:00:13 EST 2013
>> [INFO] Final Memory: 36M/411M
>> [INFO]
>> 
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
>> project commons-codec: failed to get report for
>> org.codehaus.mojo:cobertura-maven-plugin: Plugin
>> org.codehaus.mojo:cobertura-mave
>> n-plugin:2.5.2 or one of its dependencies could not be resolved: Failed to
>> read artifact descriptor for
>> org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2: Failure to find
>> org.codehaus.mojo:cobertura-maven-plugin:pom:2.5.2 in http
>> ://repo.maven.apache.org/maven2 was cached in the local repository,
>> resolution will not be reattempted until the update interval of central
>> has
>> elapsed or updates are forced -> [Help 1]
>>
>> :(
>>
>> Gary
>>
>>
>> On Sun, Jan 27, 2013 at 8:34 AM, sebb  wrote:
>>
>> > Or just try -Preporting which is where Cobertura was moved.
>> >
>> > Sorry, should have done a full compare of the poms before release;
>> > several changes were omitted from the change list.
>> >
>> > On 27 January 2013 13:10, Gary Gregory  wrote:
>> > > This is a bummer. Most of the components I see do use cobertura. So
>> > > I'll have to skip 28 and wait for 29.
>> > >
>> > > Gary
>> > >
>> > > On Jan 27, 2013, at 7:40, sebb  wrote:
>> > >
>> > >> On 26 January 2013 16:22, Benedikt Ritter 
>> wrote:
>> > >>> As far as I know, this is because cobertura was dropped in favor of
>> > Sonar.
>> > >>> I guess codec should
>> > >>> a) define the dependency to cobertura itself
>> > >>> b) use Sonar, like some of the other components (like math) already
>> do.
>> > >>
>> > >> c) Update CP29 so it supports Cobertura as an optional profile. I
>> > >> think that was mentioned, and then forgotten.
>> > >>
>> > >>> Regards,
>> > >>> Benedikt
>> > >>>
>> > >>>
>> > >>> 2013/1/26 Gary Gregory 
>> > >>>
>> >  Arg, with [codec] I get:
>> > 
>> >  [INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @
>> >  commons-codec ---
>> >  [INFO] Nothing to compile - all classes are up to date
>> >  [INFO]
>> >  [INFO] <<< jdepend-maven-plugin:2.0-beta-2:generate
>> (report:generate)
>> > @
>> >  commons-codec <<<
>> >  [INFO] configuring report plugin
>> >  org.codehaus.mojo:cobertura-maven-plugin:2.5.2
>> >  [WARNING] The POM for
>> > org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2 is
>> >  missing, no dependency information available
>> >  [INFO]
>> > 
>> > 
>> >  [INFO] BUILD FAILURE
>> >  [INFO]
>> > 
>> > 
>> >  [INFO] Total time: 20.274s
>> >  [INFO] Finished at: Sat Jan 26 10:06:11 EST 2013
>> >  [INFO] Final Memory: 32M/345M
>> >  [INFO]
>> > 
>> > 
>> >  [ERROR] Failed to execute goal
>> >  org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site)
>> on
>> >  project commons-codec: failed to get report for
>> >  org.codehaus.mojo:cobertura-maven-plugin: Plugin
>> >  org.codehaus.mojo:cobertura-mave
>> >  n-plugin:2.5.2 or one of its dependencies could not be resolved:
>> > Failed to
>> >  read artifact descriptor for
>> >  org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2: Failure to find
>> >  org.codehaus.mojo:cobertura-maven-plugin:pom:2.5.2 in http
>> >  ://repo.maven.apache.org/maven2 was cached in the local
>> repository,
>> >  resolution will not be reattempted until the update interval of
>> > central has
>> >  elapsed or updates are forced -> [Help 1]
>> >  [ERROR]
>> > 
>> >  Gary
>> > 
>> > 
>> >  On Sat, Jan 26, 2013 at 4:53 AM, sebb  wrote:
>> > 
>> > > Commons Par

Re: [ANNOUNCE] Commons Parent 28 released

2013-01-28 Thread Gary Gregory

On Mon, Jan 28, 2013 at 8:21 AM, Benedikt Ritter wrote:

> Sorry, in your case it should be mvn -Preporting clean site -U
>

OK, that worked.

Thank you!

Gary


>
> Benedikt
>
>
> 2013/1/28 Benedikt Ritter 
>
> > Hey Gary,
> >
> > I had a short look at the parent and it seems to be okay... I'll try to
> > build codec after work when I'm at home. Until then, you could try mvn
> > clean install -U to force update of releases (and snapshots). Maybe -X
> > gives us some more information, whats wrong...
> >
> > Benedikt
> >
> >
> > 2013/1/28 Gary Gregory 
> >
> >> If I do "mvn -Preporting clean site" with CP 28 I get:
> >>
> >> [INFO]
> >> [INFO] <<< jdepend-maven-plugin:2.0-beta-2:generate (report:generate) @
> >> commons-codec <<<
> >> [INFO] configuring report plugin
> >> org.codehaus.mojo:cobertura-maven-plugin:2.5.2
> >> [WARNING] The POM for org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2
> >> is
> >> missing, no dependency information available
> >> [INFO]
> >> 
> >> [INFO] BUILD FAILURE
> >> [INFO]
> >> 
> >> [INFO] Total time: 37.852s
> >> [INFO] Finished at: Mon Jan 28 08:00:13 EST 2013
> >> [INFO] Final Memory: 36M/411M
> >> [INFO]
> >> 
> >> [ERROR] Failed to execute goal
> >> org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
> >> project commons-codec: failed to get report for
> >> org.codehaus.mojo:cobertura-maven-plugin: Plugin
> >> org.codehaus.mojo:cobertura-mave
> >> n-plugin:2.5.2 or one of its dependencies could not be resolved: Failed
> to
> >> read artifact descriptor for
> >> org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2: Failure to find
> >> org.codehaus.mojo:cobertura-maven-plugin:pom:2.5.2 in http
> >> ://repo.maven.apache.org/maven2 was cached in the local repository,
> >> resolution will not be reattempted until the update interval of central
> >> has
> >> elapsed or updates are forced -> [Help 1]
> >>
> >> :(
> >>
> >> Gary
> >>
> >>
> >> On Sun, Jan 27, 2013 at 8:34 AM, sebb  wrote:
> >>
> >> > Or just try -Preporting which is where Cobertura was moved.
> >> >
> >> > Sorry, should have done a full compare of the poms before release;
> >> > several changes were omitted from the change list.
> >> >
> >> > On 27 January 2013 13:10, Gary Gregory 
> wrote:
> >> > > This is a bummer. Most of the components I see do use cobertura. So
> >> > > I'll have to skip 28 and wait for 29.
> >> > >
> >> > > Gary
> >> > >
> >> > > On Jan 27, 2013, at 7:40, sebb  wrote:
> >> > >
> >> > >> On 26 January 2013 16:22, Benedikt Ritter 
> >> wrote:
> >> > >>> As far as I know, this is because cobertura was dropped in favor
> of
> >> > Sonar.
> >> > >>> I guess codec should
> >> > >>> a) define the dependency to cobertura itself
> >> > >>> b) use Sonar, like some of the other components (like math)
> already
> >> do.
> >> > >>
> >> > >> c) Update CP29 so it supports Cobertura as an optional profile. I
> >> > >> think that was mentioned, and then forgotten.
> >> > >>
> >> > >>> Regards,
> >> > >>> Benedikt
> >> > >>>
> >> > >>>
> >> > >>> 2013/1/26 Gary Gregory 
> >> > >>>
> >> >  Arg, with [codec] I get:
> >> > 
> >> >  [INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @
> >> >  commons-codec ---
> >> >  [INFO] Nothing to compile - all classes are up to date
> >> >  [INFO]
> >> >  [INFO] <<< jdepend-maven-plugin:2.0-beta-2:generate
> >> (report:generate)
> >> > @
> >> >  commons-codec <<<
> >> >  [INFO] configuring report plugin
> >> >  org.codehaus.mojo:cobertura-maven-plugin:2.5.2
> >> >  [WARNING] The POM for
> >> > org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2 is
> >> >  missing, no dependency information available
> >> >  [INFO]
> >> > 
> >> >
> 
> >> >  [INFO] BUILD FAILURE
> >> >  [INFO]
> >> > 
> >> >
> 
> >> >  [INFO] Total time: 20.274s
> >> >  [INFO] Finished at: Sat Jan 26 10:06:11 EST 2013
> >> >  [INFO] Final Memory: 32M/345M
> >> >  [INFO]
> >> > 
> >> >
> 
> >> >  [ERROR] Failed to execute goal
> >> >  org.apache.maven.plugins:maven-site-plugin:3.1:site
> (default-site)
> >> on
> >> >  project commons-codec: failed to get report for
> >> >  org.codehaus.mojo:cobertura-maven-plugin: Plugin
> >> >  org.codehaus.mojo:cobertura-mave
> >> >  n-plugin:2.5.2 or one of its dependencies could not be resolved:
> >> > Failed to
> >> >  read artifact descriptor for
> >> >  org.codehaus.mojo:cobertura-maven-plugin:jar:2.5.2: Failure to
> find
> >> >  org.codehaus.mojo:cobertura-maven-plugin:pom:2.5.2 in http
> >>

Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges

2013-01-28 Thread Matt Benson

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 with a UnaryFunction 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 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  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
> >>  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

Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges

2013-01-28 Thread Bruno P. Kinoshita

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

>- 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 with a UnaryFunction 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 
>To: Simone Tripodi  
>Cc: Commons Developers List  
>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 with a UnaryFunction 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 
>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  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
>> >>  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
>>

[logging] commons logging 1.1.2 release?

2013-01-28 Thread radai

Hi.

Is there any sort of estimate release date for 1.1.2?
the reason im asking is this issue
https://issues.apache.org/jira/browse/LOGGING-119 which is affecting
jenkins (https://issues.jenkins-ci.org/browse/JENKINS-15846) is now marked
as fixed for 1.1.2, but given that 1.1.1 was released november 2007 and i
couldnt find a release plan anywhere i'm not sure when it'll be available

Thank you for your time,
   Radai.

Re: [logging] commons logging 1.1.2 release?

2013-01-28 Thread Thomas Neidhart

On 01/28/2013 07:02 PM, radai wrote:
> Hi.
> 
> Is there any sort of estimate release date for 1.1.2?
> the reason im asking is this issue
> https://issues.apache.org/jira/browse/LOGGING-119 which is affecting
> jenkins (https://issues.jenkins-ci.org/browse/JENKINS-15846) is now marked
> as fixed for 1.1.2, but given that 1.1.1 was released november 2007 and i
> couldnt find a release plan anywhere i'm not sure when it'll be available

Hi Radai,

yes, we are working on a release in the near future (coming weeks).
If it will be accepted I can not tell yet, but there are definitely
plans for it.

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges

2013-01-28 Thread Matt Benson

On Mon, Jan 28, 2013 at 10:18 AM, Bruno P. Kinoshita 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 with a UnaryFunction 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 
> >To: Simone Tripodi 
> >Cc: Commons Developers List 
> >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 with a UnaryFunction 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  >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 
> 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
> >> >>  wrote:
> >> >> > Hi all,
> >> >> >
> >> >> > me again bringing a new implementation

Re: [logging] commons logging 1.1.2 release?

2013-01-28 Thread Benedikt Ritter



Am 28.01.2013 um 19:08 schrieb Thomas Neidhart :

> On 01/28/2013 07:02 PM, radai wrote:
>> Hi.
>> 
>> Is there any sort of estimate release date for 1.1.2?
>> the reason im asking is this issue
>> https://issues.apache.org/jira/browse/LOGGING-119 which is affecting
>> jenkins (https://issues.jenkins-ci.org/browse/JENKINS-15846) is now marked
>> as fixed for 1.1.2, but given that 1.1.1 was released november 2007 and i
>> couldnt find a release plan anywhere i'm not sure when it'll be available
> 
> Hi Radai,
> 
> yes, we are working on a release in the near future (coming weeks).
> If it will be accepted I can not tell yet, but there are definitely
> plans for it.

Hi Thomas,

are you talking about the new version in trunk which is binary incompartible?
Radai's mail sounds like people would like to see a bug fix release that is 
binary compartible.
Maybe we can prepare that in a separate branch?

Regards,
Benedikt

> 
> Thomas
> 
> -
> 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

Re: [logging] commons logging 1.1.2 release?

2013-01-28 Thread Thomas Neidhart

On 01/28/2013 09:21 PM, Benedikt Ritter wrote:
> 
> 
> Am 28.01.2013 um 19:08 schrieb Thomas Neidhart :
> 
>> On 01/28/2013 07:02 PM, radai wrote:
>>> Hi.
>>>
>>> Is there any sort of estimate release date for 1.1.2?
>>> the reason im asking is this issue
>>> https://issues.apache.org/jira/browse/LOGGING-119 which is affecting
>>> jenkins (https://issues.jenkins-ci.org/browse/JENKINS-15846) is now marked
>>> as fixed for 1.1.2, but given that 1.1.1 was released november 2007 and i
>>> couldnt find a release plan anywhere i'm not sure when it'll be available
>>
>> Hi Radai,
>>
>> yes, we are working on a release in the near future (coming weeks).
>> If it will be accepted I can not tell yet, but there are definitely
>> plans for it.
> 
> Hi Thomas,
> 
> are you talking about the new version in trunk which is binary incompartible?
> Radai's mail sounds like people would like to see a bug fix release that is 
> binary compartible.
> Maybe we can prepare that in a separate branch?

Hi Benedikt,

why do you think it is not binary compatible?
Clirr does not report any error wrt version 1.1.1 and none of the
implemented changes hint to any non-compatibility.

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges

2013-01-28 Thread Benedikt Ritter



Am 28.01.2013 um 21:12 schrieb Matt Benson :

> On Mon, Jan 28, 2013 at 10:18 AM, Bruno P. Kinoshita 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 :)

Hi,

without knowing the code base in detail I would not recommend calling it an 
InterruptibleGenerator, because this could cause confusion with java's thread 
interruption features.

Benedikt

>> 
>>> - 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 with a UnaryFunction 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 
>>> To: Simone Tripodi 
>>> Cc: Commons Developers List 
>>> 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 with a UnaryFunction 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 >> 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 
>> 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
>

Re: [logging] commons logging 1.1.2 release?

2013-01-28 Thread Benedikt Ritter


Am 28.01.2013 um 21:28 schrieb Thomas Neidhart :

> On 01/28/2013 09:21 PM, Benedikt Ritter wrote:
>> 
>> 
>> Am 28.01.2013 um 19:08 schrieb Thomas Neidhart :
>> 
>>> On 01/28/2013 07:02 PM, radai wrote:
 Hi.
 
 Is there any sort of estimate release date for 1.1.2?
 the reason im asking is this issue
 https://issues.apache.org/jira/browse/LOGGING-119 which is affecting
 jenkins (https://issues.jenkins-ci.org/browse/JENKINS-15846) is now marked
 as fixed for 1.1.2, but given that 1.1.1 was released november 2007 and i
 couldnt find a release plan anywhere i'm not sure when it'll be available
>>> 
>>> Hi Radai,
>>> 
>>> yes, we are working on a release in the near future (coming weeks).
>>> If it will be accepted I can not tell yet, but there are definitely
>>> plans for it.
>> 
>> Hi Thomas,
>> 
>> are you talking about the new version in trunk which is binary incompartible?
>> Radai's mail sounds like people would like to see a bug fix release that is 
>> binary compartible.
>> Maybe we can prepare that in a separate branch?
> 
> Hi Benedikt,
> 
> why do you think it is not binary compatible?
> Clirr does not report any error wrt version 1.1.1 and none of the
> implemented changes hint to any non-compatibility.

Hi Thomas,

Sorry, I got your mail on the other thread wrong. Thought binary incompartible 
changes have already been made in trunk.

Benedikt

> 
> Thomas
> 
> -
> 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

Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges

2013-01-28 Thread Matt Benson

Hello, Benedikt!  I had the same concern about "Interruptible", TBH.
Thanks for weighing in.  As I mentioned earlier, I am thinking of
PredicatedGenerator at this point.

Matt


On Mon, Jan 28, 2013 at 2:30 PM, Benedikt Ritter wrote:

>
>
> Am 28.01.2013 um 21:12 schrieb Matt Benson :
>
> > On Mon, Jan 28, 2013 at 10:18 AM, Bruno P. Kinoshita  >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 :)
>
> Hi,
>
> without knowing the code base in detail I would not recommend calling it
> an InterruptibleGenerator, because this could cause confusion with java's
> thread interruption features.
>
> Benedikt
>
> >>
> >>> - 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 with a UnaryFunction 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 
> >>> To: Simone Tripodi 
> >>> Cc: Commons Developers List 
> >>> 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 with a UnaryFunction 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 Bens

Re: [configuration] Design discussion

2013-01-28 Thread Oliver Heger

(From time to time I am going to post an update about the progress I 
have made so that everybody who is interested can comment.)


Just finished reworking MultiFileConfiguration to use the new builder 
approach. There is now a MultiFileConfigurationBuilder class offering 
pretty much the same functionality plus that it can deal with arbitrary 
file-based configurations.


The class now also works well together with CombinedConfigurationBuilder 
in the same way the old integration was with 
DefaultConfigurationBuilder, i.e. a DynamicCombinedConfiguration is used 
to ensure that a new CombinedConfiguration is constructed every time the 
file pattern changes.


@Ralph: Maybe, as the original author, you find the time to have a short 
look to verify that no features were lost?


CombinedConfigurationBuilder should now provide the same functionality 
as DefaultConfigurationBuilder. With slight exceptions it can process 
the same configuration definition files. So I plan to remove 
DefaultConfigurationBuilder shortly.


Oliver

Am 05.01.2013 16:48, schrieb Oliver Heger:

Hi Jörg,

Am 04.01.2013 17:47, schrieb Jörg Schaible:

Hi Oliver,

Oliver Heger wrote:


Hi,

recently I have worked on code regarding the creation of Configuration
objects and reloading support. I have created two Jira tickets [1, 2]
with a description of the problems I see in the current design.

The code in SVN (mainly in the new builder package) should be sufficient
to get a good impression about the direction I would like to go. It is
far more than a pure proof of concept.

However, following this road means some significant changes in the
design and in the way client code uses our classes. Therefore, I would
really appreciate feedback from other committers also interested in this
component.

My main question is: Can we replace the reloading mechanisms available
in 1.x by an approach based on builders as currently implemented in
trunk (e.g. classes
o.a.c.c.builder.ReloadingFileBasedConfigurationBuilder,
o.a.c.c.reloading.ReloadingController)? If the answer is 'yes', we could
go forward and significantly simplify most of the file-based
configuration implementations.

Thanks
Oliver

[1] https://issues.apache.org/jira/browse/CONFIGURATION-519
[2] https://issues.apache.org/jira/browse/CONFIGURATION-520


simply go-on with these changes. IMHO it looks good and since
separation of
concern leads here to significant code simplification, it's for the
best of
us devs and also for our users in the long term. Especially since the new
approach brings also improved functionality.


Thanks for your feedback. Will do!

Oliver



Cheers,
Jörg


-
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

[continuum] BUILD FAILURE: Apache Commons - Commons Configuration - Group (shared) Maven 2 Build Definition (Java 1.5)

2013-01-28 Thread Continuum@vmbuild

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=25957&projectId=72

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Mon 28 Jan 2013 21:20:07 +
  Finished at: Mon 28 Jan 2013 21:22:11 +
  Total time: 2m 4s
  Build Trigger: Schedule
  Build Number: 252
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_30"
  Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
  Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)

  Builder version :
  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
  Java version: 1.6.0_30
  Java home: /usr/lib/jvm/jdk1.6.0_30/jre
  Default locale: en_AU, platform encoding: UTF-8
  OS name: "linux" version: "2.6.32-41-server" arch: "amd64" Family: 
"unix"


SCM Changes:

Changed: oheger @ Mon 28 Jan 2013 20:58:46 +
Comment: Added reloading support for the integration of 
MultiFileConfigurationBuilder with CombinedConfigurationBuilder.
Files changed:
  
/commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/builder/combined/MultiFileConfigurationBuilderProvider.java
 ( 1439624 )
  
/commons/proper/configuration/trunk/src/test/java/org/apache/commons/configuration/builder/combined/TestCombinedConfigurationBuilder.java
 ( 1439624 )
  
/commons/proper/configuration/trunk/src/test/resources/testCCMultiTenentReloading.xml
 ( 1439624 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean deploy   
Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 2.2.1
Description: Group (shared) Maven 2 Build Definition (Java 1.5)


Test Summary:

Tests: 2058
Failures: 2
Errors: 0
Success Rate: 99
Total time: 82.54899


Test Failures:


TestCombinedConfigurationBuilderVFS
testMultiTenentConfigurationReloading :
  java.lang.AssertionError
  java.lang.AssertionError: No change detected
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.commons.configuration.builder.combined.TestCombinedConfigurationBuilder.testMultiTenentConfigurationReloading(TestCombinedConfigurationBuilder.java:1133)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.mave

Re: [configuration] Design discussion

2013-01-28 Thread Ralph Goers

Sure - But as I've worked with CombinedConfiguration I became less enthralled 
with it.  The problem I had with the DynamicCombinedConfiguration was that 
every CombinedConfiguration has to have its own copy of all the configurations. 
Attempting to share a configuration led to all kinds of corruption when the 
file was updated and the tree was modified.  I really wanted to do the same 
thing with CompositeConfiguration but since it didn't officially support XML 
and doesn't have a builder I didn't get around to it.

Ultimately, I would prefer that there only be one ConfigurationBuilder and that 
its end result be a Configuration, not a CombinedConfiguration.  Underneath 
that there could, of course, be various flavors of builders but ideally the 
user wouldn't need to be bothered with them.

Ralph

On Jan 28, 2013, at 1:10 PM, Oliver Heger wrote:

> (From time to time I am going to post an update about the progress I have 
> made so that everybody who is interested can comment.)
> 
> Just finished reworking MultiFileConfiguration to use the new builder 
> approach. There is now a MultiFileConfigurationBuilder class offering pretty 
> much the same functionality plus that it can deal with arbitrary file-based 
> configurations.
> 
> The class now also works well together with CombinedConfigurationBuilder in 
> the same way the old integration was with DefaultConfigurationBuilder, i.e. a 
> DynamicCombinedConfiguration is used to ensure that a new 
> CombinedConfiguration is constructed every time the file pattern changes.
> 
> @Ralph: Maybe, as the original author, you find the time to have a short look 
> to verify that no features were lost?
> 
> CombinedConfigurationBuilder should now provide the same functionality as 
> DefaultConfigurationBuilder. With slight exceptions it can process the same 
> configuration definition files. So I plan to remove 
> DefaultConfigurationBuilder shortly.
> 
> Oliver
> 
> Am 05.01.2013 16:48, schrieb Oliver Heger:
>> Hi Jörg,
>> 
>> Am 04.01.2013 17:47, schrieb Jörg Schaible:
>>> Hi Oliver,
>>> 
>>> Oliver Heger wrote:
>>> 
 Hi,

 recently I have worked on code regarding the creation of Configuration
 objects and reloading support. I have created two Jira tickets [1, 2]
 with a description of the problems I see in the current design.

 The code in SVN (mainly in the new builder package) should be sufficient
 to get a good impression about the direction I would like to go. It is
 far more than a pure proof of concept.

 However, following this road means some significant changes in the
 design and in the way client code uses our classes. Therefore, I would
 really appreciate feedback from other committers also interested in this
 component.

 My main question is: Can we replace the reloading mechanisms available
 in 1.x by an approach based on builders as currently implemented in
 trunk (e.g. classes
 o.a.c.c.builder.ReloadingFileBasedConfigurationBuilder,
 o.a.c.c.reloading.ReloadingController)? If the answer is 'yes', we could
 go forward and significantly simplify most of the file-based
 configuration implementations.

 Thanks
 Oliver

 [1] https://issues.apache.org/jira/browse/CONFIGURATION-519
 [2] https://issues.apache.org/jira/browse/CONFIGURATION-520
>>> 
>>> simply go-on with these changes. IMHO it looks good and since
>>> separation of
>>> concern leads here to significant code simplification, it's for the
>>> best of
>>> us devs and also for our users in the long term. Especially since the new
>>> approach brings also improved functionality.
>> 
>> Thanks for your feedback. Will do!
>> 
>> Oliver
>> 
>>> 
>>> Cheers,
>>> Jörg
>>> 
>>> 
>>> -
>>> 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

[functor] Remove TODO comment from CollectionTransformer

2013-01-28 Thread Bruno P. Kinoshita

Hi all, 

The CollectionTransformer in [functor] has the following TODO: 

   TODO revisit this class... it could stand a more-descriptive name.  Also, 
it's a little
   hard to say whether, for an instance constructed without a specific target 
collection,
   #evaluate() should return a new ArrayList for each call, or continue adding 
to
   a single ArrayList instance (the current behavior).
   Perhaps this is more a documentation issue than anything.

>  it could stand a more-descriptive name. 

I'm okay with the name. What this class does is, for a given generator, it 
fills a collection with the generated elements and returns this collection. 
Maybe GenetorToCollection? Any thoughts?

> Also, it's a little
   hard to say whether, for an instance constructed without a specific target 
collection,
   #evaluate() should return a new ArrayList for each call, or continue adding 
to
   a single ArrayList instance (the current behavior).

It used an ArrayList in teh past, but now it uses generics. I believe this part 
of the comment can be ignored. This TODO was mentioned in the last release vote 
too http://markmail.org/message/ythw55yad5lrvqrj

Thanks in advance

[1] 
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

Re: [functor] Remove TODO comment from CollectionTransformer

2013-01-28 Thread Bruno P. Kinoshita

Ops, turns out I had already started a thread [1] about this TODO here in the 
mailing list. Quoting other names that I had thought: 

"GeneratorToCollectionTransformer (...) Listify, Eagerlize and Lazy List 
Builder."

Sorry,

[1] http://markmail.org/thread/l552rd6xrr2afcvl

Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


- Original Message -
> From: Bruno P. Kinoshita 
> To: Commons List 
> Cc: 
> Sent: Monday, January 28, 2013 11:22 PM
> Subject: [functor] Remove TODO comment from CollectionTransformer
> 
> Hi all, 
> 
> The CollectionTransformer in [functor] has the following TODO: 
> 
>    TODO revisit this class... it could stand a more-descriptive name.  Also, 
> it's a little
>    hard to say whether, for an instance constructed without a specific target 
> collection,
>    #evaluate() should return a new ArrayList for each call, or continue 
> adding 
> to
>    a single ArrayList instance (the current behavior).
>    Perhaps this is more a documentation issue than anything.
> 
>>   it could stand a more-descriptive name. 
> 
> I'm okay with the name. What this class does is, for a given generator, it 
> fills a collection with the generated elements and returns this collection. 
> Maybe GenetorToCollection? Any thoughts?
> 
>>  Also, it's a little
>    hard to say whether, for an instance constructed without a specific target 
> collection,
>    #evaluate() should return a new ArrayList for each call, or continue 
> adding 
> to
>    a single ArrayList instance (the current behavior).
> 
> It used an ArrayList in teh past, but now it uses generics. I believe this 
> part 
> of the comment can be ignored. This TODO was mentioned in the last release 
> vote 
> too http://markmail.org/message/ythw55yad5lrvqrj
> 
> Thanks in advance
> 
> [1] 
> 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

Re: svn commit: r1439683 - in /commons/proper/functor/branches/FUNCTOR-14-mm/core/src: main/java/org/apache/commons/functor/core/algorithm/ main/java/org/apache/commons/functor/generator/ main/java/or

2013-01-28 Thread Matt Benson

Hmm, I'm struggling with the package name.  oacf.generator.flow?  I wonder
if we should just merge this package back into oacf.generator.

Matt


On Mon, Jan 28, 2013 at 8:15 PM, Matt Benson  wrote:

> I think so, yes.  :)  Knew there was something I forgot!
>
> Matt
>
>
> On Mon, Jan 28, 2013 at 7:23 PM, Bruno P. Kinoshita <
> brunodepau...@yahoo.com.br> wrote:
>
>> Thanks Matt! The name is more intuitive now. What about the package name?
>> Should we rename it as well?
>>
>> Cheers,
>>
>> Bruno P. Kinoshita
>> http://kinoshita.eti.br
>> http://tupilabs.com
>>
>>
>> - Original Message -
>> > From: "mben...@apache.org" 
>> > To: comm...@commons.apache.org
>> > Cc:
>> > Sent: Monday, January 28, 2013 8:49 PM
>> > Subject: svn commit: r1439683 - in
>> /commons/proper/functor/branches/FUNCTOR-14-mm/core/src:
>> main/java/org/apache/commons/functor/core/algorithm/
>> main/java/org/apache/commons/functor/generator/
>> main/java/org/apache/commons/functor/generator/loop/ main/java/org/a...
>> >
>> > Author: mbenson
>> > Date: Mon Jan 28 22:49:36 2013
>> > New Revision: 1439683
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1439683&view=rev
>> > Log:
>> > refactor LoopGenerator to PredicatedGenerator
>> >
>> > Added:
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/generator/loop/PredicatedGenerator.java
>> >   - copied, changed from r1439123,
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/generator/loop/LoopGenerator.java
>> > Removed:
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/generator/loop/LoopGenerator.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/test/java/org/apache/commons/functor/generator/loop/TestLoopGenerator.java
>> > Modified:
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/core/algorithm/IndexOfInGenerator.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/generator/BaseGenerator.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/generator/loop/GenerateUntil.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/generator/loop/GenerateWhile.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/generator/loop/IteratorToGeneratorAdapter.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/generator/loop/TransformedGenerator.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/generator/loop/UntilGenerate.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/generator/loop/WhileGenerate.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/generator/range/CharacterRange.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/generator/range/NumericRange.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/test/java/org/apache/commons/functor/TestAlgorithms.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/test/java/org/apache/commons/functor/example/lines/Lines.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/test/java/org/apache/commons/functor/generator/loop/TestGenerateUntil.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/test/java/org/apache/commons/functor/generator/loop/TestGenerateWhile.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/test/java/org/apache/commons/functor/generator/loop/TestTransformedGenerator.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/test/java/org/apache/commons/functor/generator/loop/TestUntilGenerate.java
>> >
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/test/java/org/apache/commons/functor/generator/loop/TestWhileGenerate.java
>> >
>> > Modified:
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/core/algorithm/IndexOfInGenerator.java
>> > URL:
>> >
>> http://svn.apache.org/viewvc/commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/core/algorithm/IndexOfInGenerator.java?rev=1439683&r1=1439682&r2=1439683&view=diff
>> >
>> ==
>> > ---
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/functor/core/algorithm/IndexOfInGenerator.java
>> > (original)
>> > +++
>> >
>> commons/proper/functor/branches/FUNCTOR-14-mm/core/src/main/java/org/apache/commons/func

[GUMP@vmgump]: Project commons-vfs2 (in module apache-commons) failed

2013-01-28 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-vfs2 has an issue affecting its community integration.
This issue affects 5 projects.
The current state of this project is 'Failed', with reason 'Build Timed Out'.
For reference only, the following projects are affected by this:
- commons-configuration :  Apache Commons
- commons-configuration-test :  Apache Commons
- commons-vfs2 :  Apache Commons
- commons-vfs2-sandbox :  Apache Commons
- commons-vfs2-test :  Apache Commons


Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-vfs2-*[0-9T].jar] identifier set to project 
name
 -INFO- Optional dependency commons-net failed with reason build timed out
 -INFO- Optional dependency commons-compress failed with reason build timed out
 -INFO- Optional dependency mina prerequisite failed with reason build timed out
 -INFO- Optional dependency doxia-site-renderer failed with reason build timed 
out
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml
 -INFO- Failed with reason build timed out
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/vfs/pom.xml
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2/gump_work/build_apache-commons_commons-vfs2.html
Work Name: build_apache-commons_commons-vfs2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 60 mins
Command Line: /opt/maven3/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/vfs]
M2_HOME: /opt/maven3
-
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
org.apache.commons:commons-vfs2-project:pom:2.1-SNAPSHOT
[WARNING] 'parent.relativePath' points at 
org.apache.commons:commons-proper-aggregator instead of 
org.apache.commons:commons-parent, please verify your project structure @ line 
22, column 11
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten 
the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects.
[WARNING] 
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] Commons VFS
[INFO] Commons VFS Core
[INFO] Commons VFS Examples
[INFO] Commons VFS Distribution
[INFO] 
[INFO] 
[INFO] Building Commons VFS 2.1-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (javadoc.resources) @ 
commons-vfs2-project ---
Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-interpolation/1.1/plexus-interpolation-1.1.jar
-

To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2/atom.xml

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 20130125180006, vmgump.apache.org:vmgump:20130125180006
Gump E-mail Identifier (unique within run) #65.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-jexl3 (in module apache-commons) failed

2013-01-28 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-jexl3 has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Timed Out'.
For reference only, the following projects are affected by this:
- commons-jexl3 :  Commons Jexl Package


Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-jexl3/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-jexl3-*[0-9T].jar] identifier set to project 
name
 -INFO- Optional dependency doxia-site-renderer failed with reason build timed 
out
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/jexl/gump_mvn_settings.xml
 -INFO- Failed with reason build timed out
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/jexl/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-jexl3/gump_work/build_apache-commons_commons-jexl3.html
Work Name: build_apache-commons_commons-jexl3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 60 mins
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/jexl/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/jexl]
M2_HOME: /opt/maven2
-
[INFO] Scanning for projects...
[INFO] 
[INFO] Building Commons JEXL3
[INFO]task-segment: [package]
[INFO] 
Downloading: 
http://localhost:8192/maven2/org/codehaus/mojo/javacc-maven-plugin/2.6/javacc-maven-plugin-2.6.pom
-

To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-jexl3/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/apache-commons/commons-jexl3/atom.xml

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 20130125180006, vmgump.apache.org:vmgump:20130125180006
Gump E-mail Identifier (unique within run) #66.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges

Re: [ANNOUNCE] Commons Parent 28 released

[GUMP@vmgump]: Project commons-proxy (in module apache-commons) failed

Re: [ANNOUNCE] Commons Parent 28 released

Re: [ANNOUNCE] Commons Parent 28 released

Re: [ANNOUNCE] Commons Parent 28 released

Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges

Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges

[logging] commons logging 1.1.2 release?

Re: [logging] commons logging 1.1.2 release?

Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges

Re: [logging] commons logging 1.1.2 release?

Re: [logging] commons logging 1.1.2 release?

Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges

Re: [logging] commons logging 1.1.2 release?

Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges

Re: [configuration] Design discussion

[continuum] BUILD FAILURE: Apache Commons - Commons Configuration - Group (shared) Maven 2 Build Definition (Java 1.5)

Re: [configuration] Design discussion

[functor] Remove TODO comment from CollectionTransformer

Re: [functor] Remove TODO comment from CollectionTransformer

Re: svn commit: r1439683 - in /commons/proper/functor/branches/FUNCTOR-14-mm/core/src: main/java/org/apache/commons/functor/core/algorithm/ main/java/org/apache/commons/functor/generator/ main/java/or

[GUMP@vmgump]: Project commons-vfs2 (in module apache-commons) failed

[GUMP@vmgump]: Project commons-jexl3 (in module apache-commons) failed

24 matches

Site Navigation

Mail list logo

Footer information