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

2012-10-10 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-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Timed Out'.
For reference only, the following projects are affected by this:
- commons-vfs2-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml]
 -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
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/vfs/core/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2-test/gump_work/build_apache-commons_commons-vfs2-test.html
Work Name: build_apache-commons_commons-vfs2-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 60 mins
Command Line: /opt/maven3/bin/mvn --batch-mode --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
-
Running org.apache.commons.vfs2.FileSystemExceptionTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.vfs2.FileTypeSelectorTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.commons.vfs2.FileIteratorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec
Running org.apache.commons.vfs2.cache.LRUFilesCacheTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.18 sec
Running org.apache.commons.vfs2.cache.NullFilesCacheTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.134 sec
Running org.apache.commons.vfs2.util.DelegatingFileSystemOptionsBuilderTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.117 sec
Running org.apache.commons.vfs2.util.EncryptDecryptTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.621 sec
Running org.apache.commons.vfs2.provider.zip.test.NestedZipTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.71 sec
Running org.apache.commons.vfs2.provider.zip.test.ZipProviderTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.241 sec
Running org.apache.commons.vfs2.provider.jar.test.JarAttributesTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.229 sec
Running org.apache.commons.vfs2.provider.jar.test.JarProviderTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.227 sec
Running org.apache.commons.vfs2.provider.ftp.test.FtpProviderTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 22.771 sec
Running org.apache.commons.vfs2.provider.ftp.test.MultipleConnectionTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.058 sec
Running org.apache.commons.vfs2.provider.test.GenericFileNameTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
Running org.apache.commons.vfs2.provider.test.VirtualProviderTestCase
Tests run: 75, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.372 sec
Running org.apache.commons.vfs2.provider.test.FileObjectSortTestCase
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec
Running org.apache.commons.vfs2.provider.url.test.UrlHttpProviderTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.308 sec
Running org.apache.commons.vfs2.provider.url.test.UrlProviderTestCase
Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.427 sec
Running org.apache.commons.vfs2.provider.url.test.UrlProviderHttpTestCase
created threads still running:
#1: system  Keep-Alive-Timerdaemon  class 
sun.net.www.http.KeepAliveCache

Tests run: 73, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.018 sec
Running org.apache.commons.vfs2.provider.http.test.GetContentInfoFunctionalTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.193 sec
Running org.apache.commons.vfs2.provider.http.test.HttpFilesCacheTestCase
Tests run: 1,

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

2012-10-10 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-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 128 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-scxml-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 23 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -Dsimplelog.defaultlog=info 
--settings 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1
[INFO] SimpleSCXMLListener - /s2
[INFO] SimpleSCXMLListener - transition (event = s2.1.done, cond = null, from = 
/s2, to = /s3)
[INFO] SimpleSCXMLListener - /s3
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.275 sec
Running org.apache.commons.scxml.issues.Issue64Test
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: somedata
[INFO] SCXMLSemantics - null: *somedata
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:30:21
 and digester match "scxml/datamodel/misplaced"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:36:19
 and digester match "scxml/state/onentry/foo"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:37:22
 and digester match "scxml/state/onentry/bar"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:41:21
 and digester match "scxml/state/transition/datamodel"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:42:41
 and digester match "scxml/state/transition/datamodel/data"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:49:14
 and digester match "scxml/baz"
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: null
[WARN] SimpleErrorReporter - EXPRESSION_ERROR (eval(''*' + dummy'):null): 
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.065 sec

Results :

Failed tests: 
  testCustomActionCallbacks(org.apache.commons.scxml.model.CustomActionTest)

Tests run: 229, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO

[GUMP@vmgump]: Project commons-jelly-tags-sql (in module commons-jelly) failed

2012-10-10 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-jelly-tags-sql has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 56 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-sql :  Commons Jelly


Full details are available at:

http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/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-jelly-tags-sql-10102012.jar] identifier set 
to project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property 
maven.jar.commons-jexl.
 -DEBUG- (Apache Gump generated) Apache Maven Properties in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/project.xml
 -DEBUG- Maven project properties in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/project.properties
 -INFO- Project Reports in: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/test-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/test-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-sql/gump_work/build_commons-jelly_commons-jelly-tags-sql.html
Work Name: build_commons-jelly_commons-jelly-tags-sql (Type: Build)
Work ended in a state of : Failed
Elapsed: 6 secs
Command Line: maven --offline jar 
[Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/sql]
-
 __  __
|  \/  |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \  ~ intelligent projects ~
|_|  |_\__,_|\_/\___|_||_|  v. 1.0.2

You are working offline so the build will continue, but 
commons-jelly-1.1-SNAPSHOT.jar may be out of date!
build:start:

java:prepare-filesystem:
[mkdir] Created dir: 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes

java:compile:
[echo] Compiling to 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
[javac] Compiling 18 source files to 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/target/classes
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.5
[javac] 
/srv/gump/public/workspace/commons-jelly/jelly-tags/sql/src/java/org/apache/commons/jelly/tags/sql/DataSourceWrapper.java:38:
 error: DataSourceWrapper is not abstract and does not override abstract method 
getParentLogger() in CommonDataSource
[javac] public class DataSourceWrapper implements DataSource {
[javac]^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error
[javac] 1 warning

BUILD FAILED
File.. /home/gump/.maven/cache/maven-java-plugin-1.5/plugin.jelly
Element... ant:javac
Line.. 63
Column 48
Compile failed; see the compiler error output for details.
Total time: 6 seconds
Finished at: Wed Oct 10 09:30:49 UTC 2012

-

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

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

--
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: [math] geometry algorithms

2012-10-10 Thread Gilles Sadowski 
Hello.

> > 
> > I started to work on the proposed new features, namely convex hull and
> > voronoi diagrams but am a bit stuck with the API design.
> > 
> > The current type structure in the geometry package introduced a so
> > called Space with different implementation for 1D, 2D and 3D. To
> > represent a Vector in the respective space, a Vector
> > interface exists, with implementing classes for each Space:
> > 
> >  * Vector1D
> >  * Vector2D
> >  * Vector3D
> > 
> > Unfortunately, the Vector interface does not provide a generic access
> > method to each component, e.g. get(int) to get the ith component of the
> > vector. Each subclass has its own getX(), getY() ... method according to
> > the dimension of the Space. This makes it impossible to implement a
> > generic algorithm using the Space as type parameter.
> 
> Yes, it would be nice to add a generic getter. In fact, we also thought
> about implementing the whole RealVector methods. This has to be thought
> again since now RealVector is an abstract class.
> 

We should be careful not to prevent future flexibility by assuming that a
"Vector" is a Cartesian vector.
I.e. we should not assume that a generic getter "get(int)" will return the
Cartesian coordinates. Maybe that an extended interface would do:
-
public interface Cartesian extends Vector {
   public double getCartesianCoordinate(int i);
}
-

> > 
> > Ok, so I was thinking about separate algorithms for the different
> > spaces. Now when trying to generify a ConvexHull interface using the
> > Space I would have something like this:
> > 
> > public interface ConvexHull {
> > Vector[] generate(Vector[] points);
> > }
> > 
> > e.g. with an implementation of the 2D GrahamScan algorithm:
> > 
> > public class GrahamScan2D implements ConvexHull {
> > 
> >   public Vector[] generate(
> > final Vector[] points) { ... }
> > }
> > 
> > So the Vector types would not be Vector2D, Vector3D but the generic
> > ones. Users would need to explicitly cast to them, as I guess these are
> > more convenient to use.
> 
> I think you are speaking about what we have already encountered in BSP
> trees. For example the 3D Plane implements the toSpace method from the
> Embedding interface as follows:
> 
>   public Vector3D toSpace(final Vector point) {
> final Vector2D p2D = (Vector2D) point;
> return new Vector3D(p2D.getX(), u,
> p2D.getY(), v,
> -originOffset, w);
> }
> 
> So yes, there is an ugly cast somewhere.

I guess that we could drop the cast (with the new interface):
-
  public Vector3D toSpace(final Cartesian point) {
return new Vector3D(point.getCartesianCoordinate(0), u,
point.getCartesianCoordinate(1), v,
-originOffset, w);
  }
-

> 
> > 
> > A better solution would be to ignore the Space for now and define the
> > interface as follows:
> > 
> > public interface ConvexHull> {
> > V[] generate(V[] points);
> > }
> > 
> > which allows me to use Vector2D and so forth directly in the implementation.
> 
> This is interesting.
> 
> > 
> > Package structure:
> > 
> > right now the geometry package is structured as follows:
> > 
> >  * basic interfaces in the base package
> >  * euclidean package split up for the 1D, 2D and 3D cases
> >  * partitioning package
> > 
> > I started creating a hull package, which will contain the outlined
> > ConvexHull interface, and implementations, for the different Spaces,
> > e.g. GrahamScan2D, DivideAndConquer2D, Chan3D
> > 
> > Does this make sense? Or should I stick to the general case and provide
> > only one algorithm for the 2D and 3D respectively?
> 
> No, several algorithms are a good thing. I think all of them have their
> pros and cons so they are suited for different problems (accuracy,
> speed, memory requirement, size of data...) and users can choose the
> best one.

Several algorithms, yes; but if they share anything (in principle) they
should be designed so as to avoid code duplication. [Maybe that the
situation is similar to "SimplexOptimizer", where there are two different
strategies for the simplex update ("NelderMead" and "MultiDirectional").]

> > 
> > Maybe we should also create an algo package which will serve as home for
> > such algorithms?
> 
> This seems too broad a category.

I agree; ultimately almost everything would go in "algo" ;-).
At this point, I don't have a proposal on how to organize those
functionalities.
I'd be wary about creating a mirror of what is under "euclidean" (i.e.
"oned", "twod", etc.); e.g. this would better be avoided:

  euclidean/oned
   /twod
   /threed
  hull/oned
  /twod
  /threed

Ideally, common (non-dimension-specific) algorithms would go under "hull"
and dimension-specific implementations (if needed or useful) would go under
the corresponding sub-packages of "euclidean".


Best regards,
Gilles

Re: [VOTE] Apache Commons as Sponsor for BeanShell in Incubator

2012-10-10 Thread Gary Gregory 
+1

On Tue, Oct 9, 2012 at 9:12 AM, Simone Tripodi wrote:

> Hi all,
>
> (following up the discussion from private@)
>
> I prepared the BeanShell[1] proposal to be submitted to the ASF
> incubator and, as already discussed time ago with interested people
> and the original author, we agreed Commons should be the best place
> for BeanShell where living.
>
> So, I'm here to call for a vote for Commons PMC be the BeanShell
> Sponsor, please cast your votes
>
> [ ] +1
> [ ] +/- 0
> [ ] -1, because...
>
> We already collected ten +1 votes from following PMCs:
>
>  * Simone Tripodi
>  * Sebb
>  * Oliver Heger
>  * Phil Steitz
>  * Christian Grobmeier
>  * Ralph Goers
>  * Luc Maisonobe
>  * Rony G. Flatscher
>  * Jörg Schaible
>  * Thomas Neidhart
>
> PMCs that already expressed their vote don't need to express it again.
>
> This vote is open for at least 72hours and will close on ~October 12th
> at 01:00pm GMT
>
> Many thanks in advance, have a nice day!
> Simo
>
> [1] http://wiki.apache.org/incubator/BeanShellProposal
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> -
> 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 Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Apache Commons as Sponsor for BeanShell in Incubator

2012-10-10 Thread James Carman 
+1

On Wed, Oct 10, 2012 at 1:33 PM, Gary Gregory  wrote:
> +1
>
> On Tue, Oct 9, 2012 at 9:12 AM, Simone Tripodi 
> wrote:
>
>> Hi all,
>>
>> (following up the discussion from private@)
>>
>> I prepared the BeanShell[1] proposal to be submitted to the ASF
>> incubator and, as already discussed time ago with interested people
>> and the original author, we agreed Commons should be the best place
>> for BeanShell where living.
>>
>> So, I'm here to call for a vote for Commons PMC be the BeanShell
>> Sponsor, please cast your votes
>>
>> [ ] +1
>> [ ] +/- 0
>> [ ] -1, because...
>>
>> We already collected ten +1 votes from following PMCs:
>>
>>  * Simone Tripodi
>>  * Sebb
>>  * Oliver Heger
>>  * Phil Steitz
>>  * Christian Grobmeier
>>  * Ralph Goers
>>  * Luc Maisonobe
>>  * Rony G. Flatscher
>>  * Jörg Schaible
>>  * Thomas Neidhart
>>
>> PMCs that already expressed their vote don't need to express it again.
>>
>> This vote is open for at least 72hours and will close on ~October 12th
>> at 01:00pm GMT
>>
>> Many thanks in advance, have a nice day!
>> Simo
>>
>> [1] http://wiki.apache.org/incubator/BeanShellProposal
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>> -
>> 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 Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

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

Re: [VOTE] Apache Commons as Sponsor for BeanShell in Incubator

2012-10-10 Thread Thomas Vandahl 
On 09.10.12 15:12, Simone Tripodi wrote:
> So, I'm here to call for a vote for Commons PMC be the BeanShell
> Sponsor, please cast your votes
> 
> [X] +1

Bye, Thomas


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

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

2012-10-10 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-exec-test has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-exec-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/exec/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html
Work Name: build_apache-commons_commons-exec-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 24 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/exec]
M2_HOME: /opt/maven2
-
Running org.apache.commons.exec.util.StringUtilTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running org.apache.commons.exec.util.MapUtilTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.exec.DefaultExecutorTest
FOO..
gdal_translate
HDF5:"/home/kk/grass/data/4404.he5"://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif
FOO..
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.023 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.027 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.025 ms
Process completed in 2003 millis; below is its output
Process timed out and was killed by watchdog.
org.apache.commons.exec.ExecuteException: Process exited with an error: 143 
(Exit value: 143)
Process completed in 2003 millis; below is its output
Process timed out and was killed.
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
Executing [sh, -c, src/test/scripts/invoker.sh]
invoker.sh -- going to start daemon process
invoker.sh --  daemon process was started
cd: 21: can't cd to ../../../target
Process completed in 8035 millis; above is its output
Processes terminated: 6 killed: 0 Multiplier: 1 MaxRetries: 180 Elapsed (avg 
ms): 1004
Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.753 sec <<< 
FAILURE!

Results :

Failed tests: 
  testExec_60(org.apache.commons.exec.DefaultExecutorTest)

Tests run: 95, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/exec/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 23 seconds
[INFO] Finished at: Wed Oct 10 20:16:04 UTC 2012
[INFO] Final Memory: 28M/69M
[INFO] 
-

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

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

--
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: [math] geometry algorithms

2012-10-10 Thread Thomas Neidhart 
On 10/10/2012 02:09 PM, Gilles Sadowski wrote:
> Hello.
>

Hi Luc, Gilles,

>>> I started to work on the proposed new features, namely convex hull and
>>> voronoi diagrams but am a bit stuck with the API design.
>>>
>>> The current type structure in the geometry package introduced a so
>>> called Space with different implementation for 1D, 2D and 3D. To
>>> represent a Vector in the respective space, a Vector
>>> interface exists, with implementing classes for each Space:
>>>
>>>  * Vector1D
>>>  * Vector2D
>>>  * Vector3D
>>>
>>> Unfortunately, the Vector interface does not provide a generic access
>>> method to each component, e.g. get(int) to get the ith component of the
>>> vector. Each subclass has its own getX(), getY() ... method according to
>>> the dimension of the Space. This makes it impossible to implement a
>>> generic algorithm using the Space as type parameter.
>>
>> Yes, it would be nice to add a generic getter. In fact, we also thought
>> about implementing the whole RealVector methods. This has to be thought
>> again since now RealVector is an abstract class.
>>
> 
> We should be careful not to prevent future flexibility by assuming that a
> "Vector" is a Cartesian vector.
> I.e. we should not assume that a generic getter "get(int)" will return the
> Cartesian coordinates. Maybe that an extended interface would do:
> -
> public interface Cartesian extends Vector {
>public double getCartesianCoordinate(int i);
> }
> -
> 

hmm, I am split on this. It sounds right but may also introduce an
additional layer that is not necessary at all.

>>>
>>> Ok, so I was thinking about separate algorithms for the different
>>> spaces. Now when trying to generify a ConvexHull interface using the
>>> Space I would have something like this:
>>>
>>> public interface ConvexHull {
>>> Vector[] generate(Vector[] points);
>>> }
>>>
>>> e.g. with an implementation of the 2D GrahamScan algorithm:
>>>
>>> public class GrahamScan2D implements ConvexHull {
>>>
>>>   public Vector[] generate(
>>> final Vector[] points) { ... }
>>> }
>>>
>>> So the Vector types would not be Vector2D, Vector3D but the generic
>>> ones. Users would need to explicitly cast to them, as I guess these are
>>> more convenient to use.
>>
>> I think you are speaking about what we have already encountered in BSP
>> trees. For example the 3D Plane implements the toSpace method from the
>> Embedding interface as follows:
>>
>>   public Vector3D toSpace(final Vector point) {
>> final Vector2D p2D = (Vector2D) point;
>> return new Vector3D(p2D.getX(), u,
>> p2D.getY(), v,
>> -originOffset, w);
>> }
>>
>> So yes, there is an ugly cast somewhere.
> 
> I guess that we could drop the cast (with the new interface):
> -
>   public Vector3D toSpace(final Cartesian point) {
> return new Vector3D(point.getCartesianCoordinate(0), u,
> point.getCartesianCoordinate(1), v,
> -originOffset, w);
>   }
> -
> 
>>
>>>
>>> A better solution would be to ignore the Space for now and define the
>>> interface as follows:
>>>
>>> public interface ConvexHull> {
>>> V[] generate(V[] points);
>>> }
>>>
>>> which allows me to use Vector2D and so forth directly in the implementation.
>>
>> This is interesting.
>>
>>>
>>> Package structure:
>>>
>>> right now the geometry package is structured as follows:
>>>
>>>  * basic interfaces in the base package
>>>  * euclidean package split up for the 1D, 2D and 3D cases
>>>  * partitioning package
>>>
>>> I started creating a hull package, which will contain the outlined
>>> ConvexHull interface, and implementations, for the different Spaces,
>>> e.g. GrahamScan2D, DivideAndConquer2D, Chan3D
>>>
>>> Does this make sense? Or should I stick to the general case and provide
>>> only one algorithm for the 2D and 3D respectively?
>>
>> No, several algorithms are a good thing. I think all of them have their
>> pros and cons so they are suited for different problems (accuracy,
>> speed, memory requirement, size of data...) and users can choose the
>> best one.

indeed, I am particularly interested in output-sensitive algorithms like
Chan's algorithm, but they are more difficult to implement.

> Several algorithms, yes; but if they share anything (in principle) they
> should be designed so as to avoid code duplication. [Maybe that the
> situation is similar to "SimplexOptimizer", where there are two different
> strategies for the simplex update ("NelderMead" and "MultiDirectional").]

>>>
>>> Maybe we should also create an algo package which will serve as home for
>>> such algorithms?
>>
>> This seems too broad a category.
> 
> I agree; ultimately almost everything would go in "algo" ;-).
> At this point, I don't have a proposal on how to organize those
> functionalities.
> I'd be wary about creating a mirror of what is under "euclidean" (i.e.
> "oned", "twod", etc.); e.g. this

Re: [math] geometry algorithms

2012-10-10 Thread Gilles Sadowski 
Hello.

> 
> >>> I started to work on the proposed new features, namely convex hull and
> >>> voronoi diagrams but am a bit stuck with the API design.
> >>>
> >>> The current type structure in the geometry package introduced a so
> >>> called Space with different implementation for 1D, 2D and 3D. To
> >>> represent a Vector in the respective space, a Vector
> >>> interface exists, with implementing classes for each Space:
> >>>
> >>>  * Vector1D
> >>>  * Vector2D
> >>>  * Vector3D
> >>>
> >>> Unfortunately, the Vector interface does not provide a generic access
> >>> method to each component, e.g. get(int) to get the ith component of the
> >>> vector. Each subclass has its own getX(), getY() ... method according to
> >>> the dimension of the Space. This makes it impossible to implement a
> >>> generic algorithm using the Space as type parameter.
> >>
> >> Yes, it would be nice to add a generic getter. In fact, we also thought
> >> about implementing the whole RealVector methods. This has to be thought
> >> again since now RealVector is an abstract class.
> >>
> > 
> > We should be careful not to prevent future flexibility by assuming that a
> > "Vector" is a Cartesian vector.
> > I.e. we should not assume that a generic getter "get(int)" will return the
> > Cartesian coordinates. Maybe that an extended interface would do:
> > -
> > public interface Cartesian extends Vector {
> >public double getCartesianCoordinate(int i);
> > }
> > -
> > 
> 
> hmm, I am split on this. It sounds right but may also introduce an
> additional layer that is not necessary at all.

It's true that we could just add a method to the "Vector" interface:
-
public double getCartesianCoordinate(int i);
-

[But it should not be named "get(int i)" since that would be confusing if we
ever wanted to create a subclass, say of "Vector3D", to represent spherical
coordinates.]

> [...]
> > I'd be wary about creating a mirror of what is under "euclidean" (i.e.
> > "oned", "twod", etc.); e.g. this would better be avoided:
> > 
> >   euclidean/oned
> >/twod
> >/threed
> >   hull/oned
> >   /twod
> >   /threed
> > 
> > Ideally, common (non-dimension-specific) algorithms would go under "hull"
> > and dimension-specific implementations (if needed or useful) would go under
> > the corresponding sub-packages of "euclidean".
> 
> this sound like a good plan, I did not intend to reproduce the
> oned/twod/threed package structure from the euclidean package.
> 
> Otoh, distributing implementations over several packages could also be
> confusing for users (and for developers too). [...]

The idea was to group tools by dimension, like there is now e.g. "Vector3D"
and (tridimensional) "Rotation" in the same "threed" subpackage of
"geometry".


> [...]

Gilles

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