Re: [graph] Doubts on DFS algorithm implementation

[Thomas Neidhart]

On Thu, Mar 1, 2012 at 8:34 AM, Marco Speranza wrote:

>
> > In the old BFS implementation, the discoverEdge method in the visitor
> > was even called for nodes that have been already visited, which is not
> > the case anymore. From my understanding the new behavior is correct, or
> > am I missing something?
>
> I don't think so. in the old algo there was a check to avoid to call
> already visited nodes.
>

ah you are right.

There is a bug in the new BFS, in that a vertex is marked visited although
it has not been discovered yet. This should be changed.

But I would like to discuss the visitor behavior in general, as I was
working on a SCC algorithm (Kosaraju), and found it quite difficult to
implement the recursive traversal using the visitor.

Thomas

Re: [graph] Doubts on DFS algorithm implementation

[Simone Tripodi]

Hi +,

I can report the same test failure:

Failed tests:
findMaxFlowAndVerify(org.apache.commons.graph.flow.EdmondsKarpTestCase):
expected:<3> but was:<5>

I just applied trivial modifications without altering the algorithms
behavior, I am sure the fix is under our eyes :)

Thanks all, have a nice day!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 8:59 AM, Thomas Neidhart
 wrote:
> On Thu, Mar 1, 2012 at 8:34 AM, Marco Speranza 
> wrote:
>
>>
>> > In the old BFS implementation, the discoverEdge method in the visitor
>> > was even called for nodes that have been already visited, which is not
>> > the case anymore. From my understanding the new behavior is correct, or
>> > am I missing something?
>>
>> I don't think so. in the old algo there was a check to avoid to call
>> already visited nodes.
>>
>
> ah you are right.
>
> There is a bug in the new BFS, in that a vertex is marked visited although
> it has not been discovered yet. This should be changed.
>
> But I would like to discuss the visitor behavior in general, as I was
> working on a SCC algorithm (Kosaraju), and found it quite difficult to
> implement the recursive traversal using the visitor.
>
> Thomas

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

Re: [graph] Doubts on DFS algorithm implementation

[Marco Speranza]

> But I would like to discuss the visitor behavior in general, as I was
> working on a SCC algorithm (Kosaraju), and found it quite difficult to
> implement the recursive traversal using the visitor.

yep, yesterday night I was trying to implementing Kosaraju algo and I found the 
same difficulties.

IMHO the problem is that the DFS is a recursive algo, in our implementation we 
are trying to implement it in a iterative way. 
The result of course is the same but the internal steps are different and this 
for Kosaraju algo can be a problem.

Some days ago I opened in Jira the issue SANDBOX-353 I think that we can put 
there our doubts on the implementation.

hav a nice day 

--
Marco Speranza 

Flickr: http://www.flickr.com/photos/marcosperanza79/
Google Code: http://code.google.com/u/marco.speranza79/




Il giorno 01/mar/2012, alle ore 08:59, Thomas Neidhart ha scritto:

> On Thu, Mar 1, 2012 at 8:34 AM, Marco Speranza 
> wrote:
> 
>> 
>>> In the old BFS implementation, the discoverEdge method in the visitor
>>> was even called for nodes that have been already visited, which is not
>>> the case anymore. From my understanding the new behavior is correct, or
>>> am I missing something?
>> 
>> I don't think so. in the old algo there was a check to avoid to call
>> already visited nodes.
>> 
> 
> ah you are right.
> 
> There is a bug in the new BFS, in that a vertex is marked visited although
> it has not been discovered yet. This should be changed.
> 
> But I would like to discuss the visitor behavior in general, as I was
> working on a SCC algorithm (Kosaraju), and found it quite difficult to
> implement the recursive traversal using the visitor.
> 
> Thomas


-
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 Math - Default Maven 2 Build Definition (Java 1.5)

[Continuum@vmbuild]

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

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Thu 1 Mar 2012 12:21:37 +
  Finished at: Thu 1 Mar 2012 12:29:34 +
  Total time: 7m 57s
  Build Trigger: Schedule
  Build Number: 725
  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_US, platform encoding: UTF-8
  OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: 
"unix"


SCM Changes:

Changed: erans @ Thu 1 Mar 2012 12:19:30 +
Comment: Removed files not to be included in CM 3.0.
Files changed:
  /commons/proper/math/trunk/pom.xml ( 1295533 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/PivotingQRDecomposition.java
 ( 1295533 )
  
/commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRDecompositionTest.java
 ( 1295533 )
  
/commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRSolverTest.java
 ( 1295533 )
  
/commons/proper/math/trunk/src/test/java/org/apache/commons/math3/optimization/BatteryNISTTest.java
 ( 1295533 )


Dependencies Changes:

No dependencies changed



Build Definition:

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


Test Summary:

Tests: 3504
Failures: 0
Errors: 0
Success Rate: 100
Total time: 364.19492





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

Re: [continuum] BUILD FAILURE: Apache Commons - Commons Math - Default Maven 2 Build Definition (Java 1.5)

[sebb]

This failure is due to the trunk version being set to 3.0, without the
SNAPSHOT suffix.

Trunk should not be left in non-SNAPSHOT state for any longer than is necessary
[Unless you use the release plugin, it's not necessary at all]

On 1 March 2012 12:29, Continuum@vmbuild  wrote:
> Online report : 
> http://vmbuild.apache.org/continuum/buildResult.action?buildId=19541&projectId=97
>
> Build statistics:
>  State: Failed
>  Previous State: Ok
>  Started at: Thu 1 Mar 2012 12:21:37 +
>  Finished at: Thu 1 Mar 2012 12:29:34 +
>  Total time: 7m 57s
>  Build Trigger: Schedule
>  Build Number: 725
>  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_US, platform encoding: UTF-8
>          OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: 
> "unix"
>
> 
> SCM Changes:
> 
> Changed: erans @ Thu 1 Mar 2012 12:19:30 +
> Comment: Removed files not to be included in CM 3.0.
> Files changed:
>  /commons/proper/math/trunk/pom.xml ( 1295533 )
>  /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/PivotingQRDecomposition.java
>  ( 1295533 )
>  /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRDecompositionTest.java
>  ( 1295533 )
>  /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRSolverTest.java
>  ( 1295533 )
>  /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/optimization/BatteryNISTTest.java
>  ( 1295533 )
>
> 
> Dependencies Changes:
> 
> No dependencies changed
>
>
> 
> Build Definition:
> 
> POM filename: pom.xml
> Goals: clean deploy
> Arguments: --batch-mode -Pjava-1.5
> Build Fresh: false
> Always Build: false
> Default Build Definition: true
> Schedule: COMMONS_SCHEDULE
> Profile Name: Maven 2.2.1
> Description: Default Maven 2 Build Definition (Java 1.5)
>
> 
> Test Summary:
> 
> Tests: 3504
> Failures: 0
> Errors: 0
> Success Rate: 100
> Total time: 364.19492
>
>
>
>
>
> -
> 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: r1295533 - in /commons/proper/math/trunk: ./ src/main/java/org/apache/commons/math3/linear/ src/test/java/org/apache/commons/math3/linear/ src/test/java/org/apache/commons/math3/optimi

[sebb]

On 1 March 2012 12:19,   wrote:
> Author: erans
> Date: Thu Mar  1 12:19:30 2012
> New Revision: 1295533
>
> URL: http://svn.apache.org/viewvc?rev=1295533&view=rev
> Log:
> Removed files not to be included in CM 3.0.
>
> Removed:
>    
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/PivotingQRDecomposition.java
>    
> commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRDecompositionTest.java
>    
> commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRSolverTest.java
>    
> commons/proper/math/trunk/src/test/java/org/apache/commons/math3/optimization/BatteryNISTTest.java
> Modified:
>    commons/proper/math/trunk/pom.xml
>
> Modified: commons/proper/math/trunk/pom.xml
> URL: 
> http://svn.apache.org/viewvc/commons/proper/math/trunk/pom.xml?rev=1295533&r1=1295532&r2=1295533&view=diff
> ==
> --- commons/proper/math/trunk/pom.xml (original)
> +++ commons/proper/math/trunk/pom.xml Thu Mar  1 12:19:30 2012
> @@ -24,7 +24,7 @@
>   4.0.0
>   org.apache.commons
>   commons-math3
> -  3.0-SNAPSHOT
> +  3.0

-1

Don't change trunk to a non-SNAPSHOT version.

>   Commons Math
>
>   2003
>
>

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

Re: [continuum] BUILD FAILURE: Apache Commons - Commons Math - Default Maven 2 Build Definition (Java 1.5)

[Gilles Sadowski]

On Thu, Mar 01, 2012 at 12:29:45PM +, Continuum@vmbuild wrote:
> Online report : 
> http://vmbuild.apache.org/continuum/buildResult.action?buildId=19541&projectId=97
> 
> Build statistics:
>   State: Failed
>   Previous State: Ok
>   Started at: Thu 1 Mar 2012 12:21:37 +
>   Finished at: Thu 1 Mar 2012 12:29:34 +
>   Total time: 7m 57s
>   Build Trigger: Schedule
>   Build Number: 725
>   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_US, platform encoding: UTF-8
>   OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: 
> "unix"
> 
> 
> SCM Changes:
> 
> Changed: erans @ Thu 1 Mar 2012 12:19:30 +
> Comment: Removed files not to be included in CM 3.0.
> Files changed:
>   /commons/proper/math/trunk/pom.xml ( 1295533 )
>   
> /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/PivotingQRDecomposition.java
>  ( 1295533 )
>   
> /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRDecompositionTest.java
>  ( 1295533 )
>   
> /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRSolverTest.java
>  ( 1295533 )
>   
> /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/optimization/BatteryNISTTest.java
>  ( 1295533 )
> 

The problem is here:
---CUT---
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar: 
/home/continuum/continuum-base/data/working-directory/97/target/commons-math3-3.0.jar
[INFO] [install:install {execution: default-install}]
[INFO] Installing 
/home/continuum/continuum-base/data/working-directory/97/target/commons-math3-3.0.jar
 to 
/home/continuum/.m2/repository/org/apache/commons/commons-math3/3.0/commons-math3-3.0.jar
[INFO] [deploy:deploy {execution: default-deploy}]
Uploading: 
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/commons/commons-math3/3.0/commons-math3-3.0.jar
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error deploying artifact: Authorization failed: Access denied to:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/commons/commons-math3/3.0/commons-math3-3.0.jar
---CUT---

I guess that it's caused by my having set the version to 3.0.  Does that
mean that the actual release version number in "pom.xml" cannot be
committed?


Gilles

> [...]

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

Re: [continuum] BUILD FAILURE: Apache Commons - Commons Math - Default Maven 2 Build Definition (Java 1.5)

[sebb]

On 1 March 2012 12:55, Gilles Sadowski  wrote:
> On Thu, Mar 01, 2012 at 12:29:45PM +, Continuum@vmbuild wrote:
>> Online report : 
>> http://vmbuild.apache.org/continuum/buildResult.action?buildId=19541&projectId=97
>>
>> Build statistics:
>>   State: Failed
>>   Previous State: Ok
>>   Started at: Thu 1 Mar 2012 12:21:37 +
>>   Finished at: Thu 1 Mar 2012 12:29:34 +
>>   Total time: 7m 57s
>>   Build Trigger: Schedule
>>   Build Number: 725
>>   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_US, platform encoding: UTF-8
>>           OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: 
>> "unix"
>>
>> 
>> SCM Changes:
>> 
>> Changed: erans @ Thu 1 Mar 2012 12:19:30 +
>> Comment: Removed files not to be included in CM 3.0.
>> Files changed:
>>   /commons/proper/math/trunk/pom.xml ( 1295533 )
>>   
>> /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/PivotingQRDecomposition.java
>>  ( 1295533 )
>>   
>> /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRDecompositionTest.java
>>  ( 1295533 )
>>   
>> /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRSolverTest.java
>>  ( 1295533 )
>>   
>> /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/optimization/BatteryNISTTest.java
>>  ( 1295533 )
>>
>
> The problem is here:
> ---CUT---
> [INFO] [jar:jar {execution: default-jar}]
> [INFO] Building jar: 
> /home/continuum/continuum-base/data/working-directory/97/target/commons-math3-3.0.jar
> [INFO] [install:install {execution: default-install}]
> [INFO] Installing 
> /home/continuum/continuum-base/data/working-directory/97/target/commons-math3-3.0.jar
>  to 
> /home/continuum/.m2/repository/org/apache/commons/commons-math3/3.0/commons-math3-3.0.jar
> [INFO] [deploy:deploy {execution: default-deploy}]
> Uploading: 
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/commons/commons-math3/3.0/commons-math3-3.0.jar
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error deploying artifact: Authorization failed: Access denied to:
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/commons/commons-math3/3.0/commons-math3-3.0.jar
> ---CUT---
>
> I guess that it's caused by my having set the version to 3.0.

Which please revert ASAP.

> Does that mean that the actual release version number in "pom.xml" cannot be 
> committed?

AIUI Continuum is not able to upload to the release repo (just as well really).

>
> Gilles
>
>> [...]
>
> -
> 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: r1295533 - in /commons/proper/math/trunk: ./ src/main/java/org/apache/commons/math3/linear/ src/test/java/org/apache/commons/math3/linear/ src/test/java/org/apache/commons/math3/optimi

[Gilles Sadowski]

On Thu, Mar 01, 2012 at 12:49:56PM +, sebb wrote:
> On 1 March 2012 12:19,   wrote:
> > Author: erans
> > Date: Thu Mar  1 12:19:30 2012
> > New Revision: 1295533
> >
> > URL: http://svn.apache.org/viewvc?rev=1295533&view=rev
> > Log:
> > Removed files not to be included in CM 3.0.
> >
> > Removed:
> >    
> > commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/PivotingQRDecomposition.java
> >    
> > commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRDecompositionTest.java
> >    
> > commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRSolverTest.java
> >    
> > commons/proper/math/trunk/src/test/java/org/apache/commons/math3/optimization/BatteryNISTTest.java
> > Modified:
> >    commons/proper/math/trunk/pom.xml
> >
> > Modified: commons/proper/math/trunk/pom.xml
> > URL: 
> > http://svn.apache.org/viewvc/commons/proper/math/trunk/pom.xml?rev=1295533&r1=1295532&r2=1295533&view=diff
> > ==
> > --- commons/proper/math/trunk/pom.xml (original)
> > +++ commons/proper/math/trunk/pom.xml Thu Mar  1 12:19:30 2012
> > @@ -24,7 +24,7 @@
> >   4.0.0
> >   org.apache.commons
> >   commons-math3
> > -  3.0-SNAPSHOT
> > +  3.0
> 
> -1
> 
> Don't change trunk to a non-SNAPSHOT version.

Another important remark that should probably have stood out in the
"UsingNexus" document. [Incidently, shouldn't this document be named
"ReleasePreparation" or something?]


Gilles

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

Re: [Math] Still problems with maven and gpg

[Gilles Sadowski]

On Thu, Mar 01, 2012 at 02:46:33AM +, sebb wrote:
> On 29 February 2012 23:04, Gilles Sadowski  
> wrote:
> > Hi.
> >
> > Trying the following command (from the wiki "UsingNexus" page):
> >
> >  $ mvn release:prepare -DdryRun=true
> >
> > Getting to the signing step:
> > ---CUT---
> > You need a passphrase to unlock the secret key for
> > user: "Gilles Sadowski (ASF code signing) "
> > 4096-bit RSA key, ID 1E22D5B8, created 2012-02-28
> >
> > Enter passphrase: [INFO] gpg: gpg-agent is not available in this session
> >
> > You need a passphrase to unlock the secret key for
> > user: "Gilles Sadowski (ASF code signing) "
> > 4096-bit RSA key, ID 1E22D5B8, created 2012-02-28
> >
> > Enter passphrase: [INFO] gpg: Invalid passphrase; please try again ...
> >
> > You need a passphrase to unlock the secret key for
> > user: "Gilles Sadowski (ASF code signing) "
> > 4096-bit RSA key, ID 1E22D5B8, created 2012-02-28
> >
> > Enter passphrase: [INFO] gpg: gpg-agent is not available in this session
> > [and again...]
> > ---CUT---
> >
> > When I try with this command:
> >
> >  $ mvn -DdryRun=true -Dgpg.keyname=er...@apache.org \
> >    -Darguments="-Dgpg.keyname=er...@apache.org" \
> >    -Prelease release:prepare
> 
> Dunno who wrote that, but it surely should not be necessary to provide
> the keyname twice?
> One of the parameters must surely be redundant, or the release plugin
> is even worse than I thought ...

In the document, it is presented as the alternative to

 $ mvn release:prepare -DdryRun=true

which behaves exactly the same (i.e. does not work here as indicated above
and below, in a way depending on the presence or not of "-Prelease").

> 
> > It gets stuck[1] after printing
> > ---CUT---
> > INFO] [INFO] Building zip:
> > /home/eran/devel/SVN/commons-math/trunk/target/commons-math3-3.0-SNAPSHOT-bin.zip
> > [INFO] [INFO]
> > [INFO] [INFO] --- maven-site-plugin:3.0:attach-descriptor 
> > (attach-descriptor) @ commons-math3 ---
> > [INFO] [INFO]
> > [INFO] [INFO] --- maven-gpg-plugin:1.4:sign (sign-artifacts) @ 
> > commons-math3 ---
> > ---CUT---
> 
> Have you managed to get the following working?
> 
> $ mvn package gpg:sign -DskipTests
> 
> Put the gpg.keyname in settings.xml.
> If you have more than one, put them in profiles.

Yes, that works. [With the  in a profile named "release".]
It prompts for the pass phrase and finishes successfully.

> Until you can sign locally, there's no point trying to use maven
> release - if you really want to use that.
> I find it better to use the manual method described here:
> http://wiki.apache.org/commons/UsingNexus#Create_the_SVN_tags_.28Manual_method.29
> 
> Much easier to understand, and no need to revert trunk when the
> release tag fails.

IMHO, all the more reasons to further clean up the document, leaving there
only what is confirmed to work. I think that, as a mini-howto, it should not
contain more than the strict minimum, i.e. the necessary and sufficient
steps to get to the goal of producing the release. Any alternative step (or
system-specific command) should preferrably be moved to a footnote (or a
dedicated wiki page) in order not to disturb from the main flow.



Regards,
Gilles

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

[SANDBOX][BeanUtils2] Improve implemenation of equals() on AccessibleObjectDescriptor

[Benedikt Ritter]

Hi,

I just ran the eclipse FindBugs plugin with default configuration on 
BeanUtils2 and it pointed me to equals() in 
AccessibleObjectRegistry.AccessibleObjectDescriptor, reporting that the 
cast in line 535


AccessibleObjectDescriptor other = (AccessibleObjectDescriptor) obj;

is not checked for null.
Now I'd like to implement equals() like it is shown in Effective Java. 
Are there any arguments against changing the implementation that way?


Regards,
Benedikt

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

[Math] New warnings from "FindBugs"

[Gilles Sadowski]

Hi.

The version upgrade of the FindBugs plugin led to new discoveries some of
which are potentially serious bugs:

* org.apache.commons.math3.ode.nonstiff.GraggBulirschStoerIntegrator: Was
  method "setStepsizeControl" (note the spelling) intended to override
  "setStepSizeControl" defined in the parent class?

* org.apache.commons.math3.linear.SymmLQ: Yet another problem with a
  probably unnecessary "Serializable"...

* org.apache.commons.math3.genetics.Chromosome: At line 31 (and 43, where
  FindBugs warns about strict floating point comparison), is the value
  intended to be the most negative one, instead of "Double.MIN_VALUE" (which
  is positive)?

* org.apache.commons.math3.random.EmpiricalDistribution (lines 213, 221,
  242, 246) and  org.apache.commons.math3.random.ValueServer (line 270):
  From "FindBugs":
   Dm: Reliance on default encoding (DM_DEFAULT_ENCODING)

   Found a call to a method which will perform a byte to String (or String to
   byte) conversion, and will assume that the default platform encoding is
   suitable. This will cause the application behaviour to vary between
   platforms. Use an alternative API and specify a charset name or Charset
   object explicitly. 


I think that the last one could be fixed later (unless someone knows how to
solve it). But for the others, please have look ASAP.


Thanks,
Gilles

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

Re: [Math] New warnings from "FindBugs"

[Gilles Sadowski]

Hello.

> 
> The version upgrade of the FindBugs plugin led to new discoveries some of
> which are potentially serious bugs:
> 
> * org.apache.commons.math3.ode.nonstiff.GraggBulirschStoerIntegrator: Was
>   method "setStepsizeControl" (note the spelling) intended to override
>   "setStepSizeControl" defined in the parent class?
> 
> * org.apache.commons.math3.linear.SymmLQ: Yet another problem with a
>   probably unnecessary "Serializable"...
> 
> * org.apache.commons.math3.genetics.Chromosome: At line 31 (and 43, where
>   FindBugs warns about strict floating point comparison), is the value
>   intended to be the most negative one, instead of "Double.MIN_VALUE" (which
>   is positive)?

I took care of that one.

> 
> * org.apache.commons.math3.random.EmpiricalDistribution (lines 213, 221,
>   242, 246) and  org.apache.commons.math3.random.ValueServer (line 270):
>   From "FindBugs":
>Dm: Reliance on default encoding (DM_DEFAULT_ENCODING)
> 
>Found a call to a method which will perform a byte to String (or String to
>byte) conversion, and will assume that the default platform encoding is
>suitable. This will cause the application behaviour to vary between
>platforms. Use an alternative API and specify a charset name or Charset
>object explicitly. 
> 
> 
> I think that the last one could be fixed later (unless someone knows how to
> solve it). But for the others, please have look ASAP.
> 

Gilles

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

Re: [SANDBOX][BeanUtils2] Improve implemenation of equals() on AccessibleObjectDescriptor

[Simone Tripodi]

AccessibleObjectRegistry.AccessibleObjectDescriptor is used internally
only, users don't even know that it exist and it is used only as a key
for the AccessibleObject index.
Does it make sense checking other types, nulls, assignability from
super/subclasses, ... etc?

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 3:09 PM, Benedikt Ritter
 wrote:
> Hi,
>
> I just ran the eclipse FindBugs plugin with default configuration on
> BeanUtils2 and it pointed me to equals() in
> AccessibleObjectRegistry.AccessibleObjectDescriptor, reporting that the cast
> in line 535
>
> AccessibleObjectDescriptor other = (AccessibleObjectDescriptor) obj;
>
> is not checked for null.
> Now I'd like to implement equals() like it is shown in Effective Java. Are
> there any arguments against changing the implementation that way?
>
> Regards,
> Benedikt
>
> -
> 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: r1295533 - in /commons/proper/math/trunk: ./ src/main/java/org/apache/commons/math3/linear/ src/test/java/org/apache/commons/math3/linear/ src/test/java/org/apache/commons/math3/optimi

[sebb]

On 1 March 2012 13:12, Gilles Sadowski  wrote:
> On Thu, Mar 01, 2012 at 12:49:56PM +, sebb wrote:
>> On 1 March 2012 12:19,   wrote:
>> > Author: erans
>> > Date: Thu Mar  1 12:19:30 2012
>> > New Revision: 1295533
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1295533&view=rev
>> > Log:
>> > Removed files not to be included in CM 3.0.
>> >
>> > Removed:
>> >    
>> > commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/PivotingQRDecomposition.java
>> >    
>> > commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRDecompositionTest.java
>> >    
>> > commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRSolverTest.java
>> >    
>> > commons/proper/math/trunk/src/test/java/org/apache/commons/math3/optimization/BatteryNISTTest.java
>> > Modified:
>> >    commons/proper/math/trunk/pom.xml
>> >
>> > Modified: commons/proper/math/trunk/pom.xml
>> > URL: 
>> > http://svn.apache.org/viewvc/commons/proper/math/trunk/pom.xml?rev=1295533&r1=1295532&r2=1295533&view=diff
>> > ==
>> > --- commons/proper/math/trunk/pom.xml (original)
>> > +++ commons/proper/math/trunk/pom.xml Thu Mar  1 12:19:30 2012
>> > @@ -24,7 +24,7 @@
>> >   4.0.0
>> >   org.apache.commons
>> >   commons-math3
>> > -  3.0-SNAPSHOT
>> > +  3.0
>>
>> -1
>>
>> Don't change trunk to a non-SNAPSHOT version.
>
> Another important remark that should probably have stood out in the
> "UsingNexus" document.

Not directly relevant; if you use the methods suggested in the doc it
won't happen.

>  [Incidently, shouldn't this document be named "ReleasePreparation" or 
> something?]

It was originally mainly about Nexus, but has grown.

Needs re-organising into smaller chunks.

>
> Gilles
>
> -
> 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: [SANDBOX][BeanUtils2] Improve implemenation of equals() on AccessibleObjectDescriptor

[Benedikt Ritter]

The only thing we have to add is

if ( !( obj instanceof AccessibleObjectDescriptor ) )
{
return false;
}

That will make AccessibleObjectDescritpor.equals() obey to the general 
contract of equals (which states, that x.equals(null) has to return 
false) and it will fix the FindBugs issue, which will have to be fixed 
anyway, if BeanUtils2 leaves Sandbox and gets released someday (at least 
I hope that FindBugs understands, that null instanceof WhatEver returns 
false).
I see no reason to write less robust code, just because it is internal 
to the library and saves us a few lines.


Am 01.03.2012 15:49, schrieb Simone Tripodi:

AccessibleObjectRegistry.AccessibleObjectDescriptor is used internally
only, users don't even know that it exist and it is used only as a key
for the AccessibleObject index.
Does it make sense checking other types, nulls, assignability from
super/subclasses, ... etc?

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 3:09 PM, Benedikt Ritter
  wrote:

Hi,

I just ran the eclipse FindBugs plugin with default configuration on
BeanUtils2 and it pointed me to equals() in
AccessibleObjectRegistry.AccessibleObjectDescriptor, reporting that the cast
in line 535

AccessibleObjectDescriptor other = (AccessibleObjectDescriptor) obj;

is not checked for null.
Now I'd like to implement equals() like it is shown in Effective Java. Are
there any arguments against changing the implementation that way?

Regards,
Benedikt

-
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

Re: [Math] Still problems with maven and gpg

[sebb]

On 1 March 2012 14:01, Gilles Sadowski  wrote:
> On Thu, Mar 01, 2012 at 02:46:33AM +, sebb wrote:
>> On 29 February 2012 23:04, Gilles Sadowski  
>> wrote:
>> > Hi.
>> >
>> > Trying the following command (from the wiki "UsingNexus" page):
>> >
>> >  $ mvn release:prepare -DdryRun=true
>> >
>> > Getting to the signing step:
>> > ---CUT---
>> > You need a passphrase to unlock the secret key for
>> > user: "Gilles Sadowski (ASF code signing) "
>> > 4096-bit RSA key, ID 1E22D5B8, created 2012-02-28
>> >
>> > Enter passphrase: [INFO] gpg: gpg-agent is not available in this session
>> >
>> > You need a passphrase to unlock the secret key for
>> > user: "Gilles Sadowski (ASF code signing) "
>> > 4096-bit RSA key, ID 1E22D5B8, created 2012-02-28
>> >
>> > Enter passphrase: [INFO] gpg: Invalid passphrase; please try again ...
>> >
>> > You need a passphrase to unlock the secret key for
>> > user: "Gilles Sadowski (ASF code signing) "
>> > 4096-bit RSA key, ID 1E22D5B8, created 2012-02-28
>> >
>> > Enter passphrase: [INFO] gpg: gpg-agent is not available in this session
>> > [and again...]
>> > ---CUT---
>> >
>> > When I try with this command:
>> >
>> >  $ mvn -DdryRun=true -Dgpg.keyname=er...@apache.org \
>> >    -Darguments="-Dgpg.keyname=er...@apache.org" \
>> >    -Prelease release:prepare
>>
>> Dunno who wrote that, but it surely should not be necessary to provide
>> the keyname twice?
>> One of the parameters must surely be redundant, or the release plugin
>> is even worse than I thought ...
>
> In the document, it is presented as the alternative to
>
>  $ mvn release:prepare -DdryRun=true
>
> which behaves exactly the same (i.e. does not work here as indicated above
> and below, in a way depending on the presence or not of "-Prelease").

What does <> mean?

If you have only put the gpg.keyname in the release profile, the
setting won't be available unless the profile is activated.
I've no idea whether the release plugin activates the release profile
if dryRun is true.

Properties have to be in profiles, but you can create a profile that
is active by default for any properties you want always to be defined.

>>
>> > It gets stuck[1] after printing
>> > ---CUT---
>> > INFO] [INFO] Building zip:
>> > /home/eran/devel/SVN/commons-math/trunk/target/commons-math3-3.0-SNAPSHOT-bin.zip
>> > [INFO] [INFO]
>> > [INFO] [INFO] --- maven-site-plugin:3.0:attach-descriptor 
>> > (attach-descriptor) @ commons-math3 ---
>> > [INFO] [INFO]
>> > [INFO] [INFO] --- maven-gpg-plugin:1.4:sign (sign-artifacts) @ 
>> > commons-math3 ---
>> > ---CUT---
>>
>> Have you managed to get the following working?
>>
>> $ mvn package gpg:sign -DskipTests
>>
>> Put the gpg.keyname in settings.xml.
>> If you have more than one, put them in profiles.
>
> Yes, that works. [With the  in a profile named "release".]
> It prompts for the pass phrase and finishes successfully.

That's a bit odd, because I don't think the release profile will be activated.

However, I suppose if you only have one key it might pick that.

>> Until you can sign locally, there's no point trying to use maven
>> release - if you really want to use that.
>> I find it better to use the manual method described here:
>> http://wiki.apache.org/commons/UsingNexus#Create_the_SVN_tags_.28Manual_method.29
>>
>> Much easier to understand, and no need to revert trunk when the
>> release tag fails.
>
> IMHO, all the more reasons to further clean up the document, leaving there
> only what is confirmed to work. I think that, as a mini-howto, it should not
> contain more than the strict minimum, i.e. the necessary and sufficient
> steps to get to the goal of producing the release. Any alternative step (or
> system-specific command) should preferrably be moved to a footnote (or a
> dedicated wiki page) in order not to disturb from the main flow.
>

Yes of course.

>
> Regards,
> Gilles
>
> -
> 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: r1295533 - in /commons/proper/math/trunk: ./ src/main/java/org/apache/commons/math3/linear/ src/test/java/org/apache/commons/math3/linear/ src/test/java/org/apache/commons/math3/optimi

[Gilles Sadowski]

On Thu, Mar 01, 2012 at 02:58:58PM +, sebb wrote:
> On 1 March 2012 13:12, Gilles Sadowski  wrote:
> > On Thu, Mar 01, 2012 at 12:49:56PM +, sebb wrote:
> >> On 1 March 2012 12:19,   wrote:
> >> > Author: erans
> >> > Date: Thu Mar  1 12:19:30 2012
> >> > New Revision: 1295533
> >> >
> >> > URL: http://svn.apache.org/viewvc?rev=1295533&view=rev
> >> > Log:
> >> > Removed files not to be included in CM 3.0.
> >> >
> >> > Removed:
> >> >    
> >> > commons/proper/math/trunk/src/main/java/org/apache/commons/math3/linear/PivotingQRDecomposition.java
> >> >    
> >> > commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRDecompositionTest.java
> >> >    
> >> > commons/proper/math/trunk/src/test/java/org/apache/commons/math3/linear/PivotingQRSolverTest.java
> >> >    
> >> > commons/proper/math/trunk/src/test/java/org/apache/commons/math3/optimization/BatteryNISTTest.java
> >> > Modified:
> >> >    commons/proper/math/trunk/pom.xml
> >> >
> >> > Modified: commons/proper/math/trunk/pom.xml
> >> > URL: 
> >> > http://svn.apache.org/viewvc/commons/proper/math/trunk/pom.xml?rev=1295533&r1=1295532&r2=1295533&view=diff
> >> > ==
> >> > --- commons/proper/math/trunk/pom.xml (original)
> >> > +++ commons/proper/math/trunk/pom.xml Thu Mar  1 12:19:30 2012
> >> > @@ -24,7 +24,7 @@
> >> >   4.0.0
> >> >   org.apache.commons
> >> >   commons-math3
> >> > -  3.0-SNAPSHOT
> >> > +  3.0
> >>
> >> -1
> >>
> >> Don't change trunk to a non-SNAPSHOT version.
> >
> > Another important remark that should probably have stood out in the
> > "UsingNexus" document.
> 
> Not directly relevant;

My view is that it is quite relevant if you don't want people to make that
mistake (again).  Reading the document:
---CUT---
[...]
Or using Maven:

mvn versions:set -DnewVersion=3.1 -DgenerateBackupPoms=false
[...]
---CUT---

it can only help to stress that 

"At this point you should be careful to not commit the changes made to the
POM file (because the trunk should always build a snapshot version)."

This is the sort of things that becomes obvious when you know it, but might
not be so for someone who tries that for the first time.

> if you use the methods suggested in the doc it
> won't happen.

What I see is that many things did not happen as they should...

Anything that will make that document clearer and fail-safe should not be so
lightly dismissed.

> >  [Incidently, shouldn't this document be named "ReleasePreparation" or 
> > something?]
> 
> It was originally mainly about Nexus, but has grown.
> 
> Needs re-organising into smaller chunks.

+1


Gilles

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

Re: [Math] Still problems with maven and gpg

[Gilles Sadowski]

On Thu, Mar 01, 2012 at 03:09:41PM +, sebb wrote:
> On 1 March 2012 14:01, Gilles Sadowski  wrote:
> > On Thu, Mar 01, 2012 at 02:46:33AM +, sebb wrote:
> >> On 29 February 2012 23:04, Gilles Sadowski  
> >> wrote:
> >> > Hi.
> >> >
> >> > Trying the following command (from the wiki "UsingNexus" page):
> >> >
> >> >  $ mvn release:prepare -DdryRun=true
> >> >
> >> > Getting to the signing step:
> >> > ---CUT---
> >> > You need a passphrase to unlock the secret key for
> >> > user: "Gilles Sadowski (ASF code signing) "
> >> > 4096-bit RSA key, ID 1E22D5B8, created 2012-02-28
> >> >
> >> > Enter passphrase: [INFO] gpg: gpg-agent is not available in this session
> >> >
> >> > You need a passphrase to unlock the secret key for
> >> > user: "Gilles Sadowski (ASF code signing) "
> >> > 4096-bit RSA key, ID 1E22D5B8, created 2012-02-28
> >> >
> >> > Enter passphrase: [INFO] gpg: Invalid passphrase; please try again ...
> >> >
> >> > You need a passphrase to unlock the secret key for
> >> > user: "Gilles Sadowski (ASF code signing) "
> >> > 4096-bit RSA key, ID 1E22D5B8, created 2012-02-28
> >> >
> >> > Enter passphrase: [INFO] gpg: gpg-agent is not available in this session
> >> > [and again...]
> >> > ---CUT---
> >> >
> >> > When I try with this command:
> >> >
> >> >  $ mvn -DdryRun=true -Dgpg.keyname=er...@apache.org \
> >> >    -Darguments="-Dgpg.keyname=er...@apache.org" \
> >> >    -Prelease release:prepare
> >>
> >> Dunno who wrote that, but it surely should not be necessary to provide
> >> the keyname twice?
> >> One of the parameters must surely be redundant, or the release plugin
> >> is even worse than I thought ...
> >
> > In the document, it is presented as the alternative to
> >
> >  $ mvn release:prepare -DdryRun=true
> >
> > which behaves exactly the same (i.e. does not work here as indicated above
> > and below, in a way depending on the presence or not of "-Prelease").
> 
> What does <> mean?

It means what I described in the previous message (and is still quoted
here):
with "-Prelease" it picks the key name and asks for the passphrase and loops
infinitely saying that the passphrase is wrong (cf. quote above). If I
didn't specify "-Prelease", it is stuck indefinitely (cf. quote below).

> If you have only put the gpg.keyname in the release profile, the
> setting won't be available unless the profile is activated.
> I've no idea whether the release plugin activates the release profile
> if dryRun is true.

I have created a "release" profile in my own "settings.xml".

> Properties have to be in profiles, but you can create a profile that
> is active by default for any properties you want always to be defined.

I don't know how to do that. Before trying to prepare that release I didn't
have a "settings.xml" file. What is in there was copied from the document
"UsingNexus".
But it seems that is not sufficient to make a release, hence the document is
not suitable for a release process newbie like me.

> >>
> >> > It gets stuck[1] after printing
> >> > ---CUT---
> >> > INFO] [INFO] Building zip:
> >> > /home/eran/devel/SVN/commons-math/trunk/target/commons-math3-3.0-SNAPSHOT-bin.zip
> >> > [INFO] [INFO]
> >> > [INFO] [INFO] --- maven-site-plugin:3.0:attach-descriptor 
> >> > (attach-descriptor) @ commons-math3 ---
> >> > [INFO] [INFO]
> >> > [INFO] [INFO] --- maven-gpg-plugin:1.4:sign (sign-artifacts) @ 
> >> > commons-math3 ---
> >> > ---CUT---
> >>
> >> Have you managed to get the following working?
> >>
> >> $ mvn package gpg:sign -DskipTests
> >>
> >> Put the gpg.keyname in settings.xml.
> >> If you have more than one, put them in profiles.
> >
> > Yes, that works. [With the  in a profile named "release".]
> > It prompts for the pass phrase and finishes successfully.
> 
> That's a bit odd, because I don't think the release profile will be activated.

It works because I've deduced that everytime I need the key, I must add
"-Prelease" on command line.
If there is another way, one cannot deduce it from the snippets in
"UsingNexus".

> 
> However, I suppose if you only have one key it might pick that.

No, it doesn't.

> [...]


Gilles

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

Re: [Math] New warnings from "FindBugs"

[Sébastien Brisard]

Hi Gilles,

>
> * org.apache.commons.math3.linear.SymmLQ: Yet another problem with a
>  probably unnecessary "Serializable"...
>
In fact, it comes from a nested class which extends EventObject, so it
must be (unfortunately) serializable. I'll look into it.
Sébastien


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

Re: [SANDBOX][BeanUtils2] Improve implemenation of equals() on AccessibleObjectDescriptor

[Simone Tripodi]

> if ( !( obj instanceof AccessibleObjectDescriptor ) )
> {
>    return false;
> }

what is the sense? having a situation where AccessibleObjectDescriptor
is compared to a different type object is something that can simply
*never* happen!
AccessibleObjectDescriptor is a *private static* class of the
AccessibleObjectRegistry - so even the other BeanUtils2 classes know
that it is living under the same umbrella - which visibility scope is
limited to the beanutils2 package.

> That will make AccessibleObjectDescritpor.equals() obey to the general
> contract of equals (which states, that x.equals(null) has to return false)

again, explain why it should be useful under the known circumstances.

> and it will fix the FindBugs issue, which will have to be fixed anyway,

FindBugs violations can be suppressed, and fortunately this is one of
the rare occasions we can do it.

> if BeanUtils2 leaves Sandbox and gets released someday (at least I hope that
> FindBugs understands, that null instanceof WhatEver returns false).

If you want to apply all the best practice you should check every aspect:

+---+
if ( this == obj )
{
return true;
}
if ( obj == null )
{
return false;
}
if ( getClass() != obj.getClass() ) // or manage in
whatever is your preferred way
{
return false;
}
+---+

the first check is missing and it is something that would increase the
performance, so I intend to commit it.

> I see no reason to write less robust code, just because it is internal to
> the library and saves us a few lines.

And I see no reason why you intend applying rules without using a
minimum spirit of criticism. If you analyze the context in which that
class participate, instead of reading the code and se what should/what
not shall has to be done, you can see that cases you intend to cover
*can never happen*.

And just to make it clear: I am not a moron which matter is just of
saving lines of code, it is a metter of using stuff when they are
required - and NOT using them if they are not needed.

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 4:07 PM, Benedikt Ritter
 wrote:
> The only thing we have to add is
>
> if ( !( obj instanceof AccessibleObjectDescriptor ) )
> {
>    return false;
> }
>
> That will make AccessibleObjectDescritpor.equals() obey to the general
> contract of equals (which states, that x.equals(null) has to return false)
> and it will fix the FindBugs issue, which will have to be fixed anyway, if
> BeanUtils2 leaves Sandbox and gets released someday (at least I hope that
> FindBugs understands, that null instanceof WhatEver returns false).
> I see no reason to write less robust code, just because it is internal to
> the library and saves us a few lines.
>
> Am 01.03.2012 15:49, schrieb Simone Tripodi:
>
>> AccessibleObjectRegistry.AccessibleObjectDescriptor is used internally
>> only, users don't even know that it exist and it is used only as a key
>> for the AccessibleObject index.
>> Does it make sense checking other types, nulls, assignability from
>> super/subclasses, ... etc?
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Thu, Mar 1, 2012 at 3:09 PM, Benedikt Ritter
>>   wrote:
>>>
>>> Hi,
>>>
>>> I just ran the eclipse FindBugs plugin with default configuration on
>>> BeanUtils2 and it pointed me to equals() in
>>> AccessibleObjectRegistry.AccessibleObjectDescriptor, reporting that the
>>> cast
>>> in line 535
>>>
>>> AccessibleObjectDescriptor other = (AccessibleObjectDescriptor) obj;
>>>
>>> is not checked for null.
>>> Now I'd like to implement equals() like it is shown in Effective Java.
>>> Are
>>> there any arguments against changing the implementation that way?
>>>
>>> Regards,
>>> Benedikt
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [chain] release roadmap

[Elijah Zupancic]

FYI, I am also updating the examples in the /apps folder.

-Elijah

On Mon, Feb 27, 2012 at 12:01 PM, Simone Tripodi
 wrote:
> Hi Elijah,
>
> no needs to learn docbook, the docbook page you see on svn repo is a
> donation from an old book. Deployed documentation is generated from
> /src/site/xdoc sources, the format is an html-alike [1] markup. Just
> run ``mvn site && open target/site/index.html` to see the produced
> documentation.
> HTH!
> -Simo
>
> [1] http://maven.apache.org/doxia/references/xdoc-format.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Mon, Feb 27, 2012 at 7:32 PM, Elijah Zupancic  wrote:
>> Hi Simo,
>>
>> Here is my comment from the ticket: "My plan is to take this on. I'm
>> just very busy at work right now, so I've been trying to learn docbook
>> format on the bus on my way to and from work. If you want to take on
>> breaking chain into separate modules, that would be much appreciated."
>>
>> -Elijah
>>
>> On Mon, Feb 27, 2012 at 8:58 AM, Simone Tripodi
>>  wrote:
>>>
>>> Hi all guys!
>>>
>>> thanks to Elijah Zupancich's contributions, we now have a fresh new
>>> [chain] on trunk that uses generics. I can have (limited) spare time
>>> to dedicate to [chain] and I would like to put energies on it in order
>>> to have it released ASAP.
>>>
>>> This is my roadmap to have [chain] released in a short time:
>>>
>>>  * CHAIN-65
>>>  * CHAIN-66
>>>  * CHAIN-55
>>>
>>> since some other issues are really old and never fixed, I'd tend to
>>> keep them open and move to release 2.1
>>>
>>> groupId:artifactId:version will be updated to
>>> org.apache.common:commons-chain2:2.0
>>>
>>> Does anyone have objections/suggestions/... ?
>>> TIA, all the best!
>>> -Simo
>>>
>>> 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
>>>
>>
>> -
>> 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

Re: [chain] release roadmap

[Simone Tripodi]

Hi Elijah,

this is something needed indeed, thanks *a lot*!!!

I don't know if you checked out updates, I switched to multi-module
project structure, looks like it is complete and I just have to add
the /apps in the modules list.

Thanks for the hard work, all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 5:33 PM, Elijah Zupancic  wrote:
> FYI, I am also updating the examples in the /apps folder.
>
> -Elijah
>
> On Mon, Feb 27, 2012 at 12:01 PM, Simone Tripodi
>  wrote:
>> Hi Elijah,
>>
>> no needs to learn docbook, the docbook page you see on svn repo is a
>> donation from an old book. Deployed documentation is generated from
>> /src/site/xdoc sources, the format is an html-alike [1] markup. Just
>> run ``mvn site && open target/site/index.html` to see the produced
>> documentation.
>> HTH!
>> -Simo
>>
>> [1] http://maven.apache.org/doxia/references/xdoc-format.html
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Feb 27, 2012 at 7:32 PM, Elijah Zupancic  
>> wrote:
>>> Hi Simo,
>>>
>>> Here is my comment from the ticket: "My plan is to take this on. I'm
>>> just very busy at work right now, so I've been trying to learn docbook
>>> format on the bus on my way to and from work. If you want to take on
>>> breaking chain into separate modules, that would be much appreciated."
>>>
>>> -Elijah
>>>
>>> On Mon, Feb 27, 2012 at 8:58 AM, Simone Tripodi
>>>  wrote:

 Hi all guys!

 thanks to Elijah Zupancich's contributions, we now have a fresh new
 [chain] on trunk that uses generics. I can have (limited) spare time
 to dedicate to [chain] and I would like to put energies on it in order
 to have it released ASAP.

 This is my roadmap to have [chain] released in a short time:

  * CHAIN-65
  * CHAIN-66
  * CHAIN-55

 since some other issues are really old and never fixed, I'd tend to
 keep them open and move to release 2.1

 groupId:artifactId:version will be updated to
 org.apache.common:commons-chain2:2.0

 Does anyone have objections/suggestions/... ?
 TIA, all the best!
 -Simo

 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

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

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

Re: [SANDBOX][BeanUtils2] Improve implemenation of equals() on AccessibleObjectDescriptor

[Benedikt Ritter]

Hi Simo,

I don't know, why are reacting that harshly. I think that questioning 
why an internal class does not have to obey to the general contract of 
equals() is not a sign of lacking "spirit of criticism".
I think adding that check or suppressing a FindBugs complain are both 
equally valid (although the first one IMHO is less obscure). Even though 
you're right, when saying that ATM that can never happen.


Regards,
Benedikt

PS: if you are going for performance you could store the hash code in a 
private filed after the first computation and return the computed value 
on subsequent invocations.


Am 01.03.2012 17:11, schrieb Simone Tripodi:

if ( !( obj instanceof AccessibleObjectDescriptor ) )
{
return false;
}


what is the sense? having a situation where AccessibleObjectDescriptor
is compared to a different type object is something that can simply
*never* happen!
AccessibleObjectDescriptor is a *private static* class of the
AccessibleObjectRegistry - so even the other BeanUtils2 classes know
that it is living under the same umbrella - which visibility scope is
limited to the beanutils2 package.


That will make AccessibleObjectDescritpor.equals() obey to the general
contract of equals (which states, that x.equals(null) has to return false)


again, explain why it should be useful under the known circumstances.


and it will fix the FindBugs issue, which will have to be fixed anyway,


FindBugs violations can be suppressed, and fortunately this is one of
the rare occasions we can do it.


if BeanUtils2 leaves Sandbox and gets released someday (at least I hope that
FindBugs understands, that null instanceof WhatEver returns false).


If you want to apply all the best practice you should check every aspect:

+---+
 if ( this == obj )
 {
 return true;
 }
 if ( obj == null )
 {
 return false;
 }
 if ( getClass() != obj.getClass() ) // or manage in
whatever is your preferred way
 {
 return false;
 }
+---+

the first check is missing and it is something that would increase the
performance, so I intend to commit it.


I see no reason to write less robust code, just because it is internal to
the library and saves us a few lines.


And I see no reason why you intend applying rules without using a
minimum spirit of criticism. If you analyze the context in which that
class participate, instead of reading the code and se what should/what
not shall has to be done, you can see that cases you intend to cover
*can never happen*.

And just to make it clear: I am not a moron which matter is just of
saving lines of code, it is a metter of using stuff when they are
required - and NOT using them if they are not needed.

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 4:07 PM, Benedikt Ritter
  wrote:

The only thing we have to add is

if ( !( obj instanceof AccessibleObjectDescriptor ) )
{
return false;
}

That will make AccessibleObjectDescritpor.equals() obey to the general
contract of equals (which states, that x.equals(null) has to return false)
and it will fix the FindBugs issue, which will have to be fixed anyway, if
BeanUtils2 leaves Sandbox and gets released someday (at least I hope that
FindBugs understands, that null instanceof WhatEver returns false).
I see no reason to write less robust code, just because it is internal to
the library and saves us a few lines.

Am 01.03.2012 15:49, schrieb Simone Tripodi:


AccessibleObjectRegistry.AccessibleObjectDescriptor is used internally
only, users don't even know that it exist and it is used only as a key
for the AccessibleObject index.
Does it make sense checking other types, nulls, assignability from
super/subclasses, ... etc?

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 3:09 PM, Benedikt Ritter
wrote:


Hi,

I just ran the eclipse FindBugs plugin with default configuration on
BeanUtils2 and it pointed me to equals() in
AccessibleObjectRegistry.AccessibleObjectDescriptor, reporting that the
cast
in line 535

AccessibleObjectDescriptor other = (AccessibleObjectDescriptor) obj;

is not checked for null.
Now I'd like to implement equals() like it is shown in Effective Java.
Are
there any arguments against changing the implementation that way?

Regards,
Benedikt

-
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: [Math] New warnings from "FindBugs"

[Gilles Sadowski]

Hi.

> 
> >
> > * org.apache.commons.math3.linear.SymmLQ: Yet another problem with a
> >  probably unnecessary "Serializable"...
> >
> In fact, it comes from a nested class which extends EventObject, so it
> must be (unfortunately) serializable. I'll look into it.

Then, it seems that you can define it as "static", and it will make FindBugs
happy, I think. [The problem is that it is a "plain" inner class, in a
non-serializable class.]


Regards,
Gilles

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

Re: [graph] Doubts on DFS algorithm implementation

[Thomas Neidhart]

On 03/01/2012 09:10 AM, Simone Tripodi wrote:
> Hi +,
> 
> I can report the same test failure:
> 
> Failed tests:
> findMaxFlowAndVerify(org.apache.commons.graph.flow.EdmondsKarpTestCase):
> expected:<3> but was:<5>
> 
> I just applied trivial modifications without altering the algorithms
> behavior, I am sure the fix is under our eyes :)

ok. It is fixed now.

The problem was basically, that once a vertex was pushed onto the stack,
it was immediately marked as visited. In case you have a custom visitor
that would instruct you to not visit the tail node for some reason, the
algorithm would never reach that vertex anymore as it thinks the vertex
was already visited.

Thomas

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

Re: [graph] Doubts on DFS algorithm implementation

[Marco Speranza]

Hi Thomas,

I run the test and it seems that the BSF explore twice the same edge. 



Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.025 sec <<< 
FAILURE!

Results :

Tests in error: 
  verifyBreadthFirstSearch(org.apache.commons.graph.visit.VisitTestCase): Edge 
x <-> y() is already present in the Graph

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



I think that we have to add also a list of the visited edges to avoid that. 

Do you agree with me?

Ciao

--
Marco Speranza 
Google Code: http://code.google.com/u/marco.speranza79/

Il giorno 01/mar/2012, alle ore 18:45, Thomas Neidhart ha scritto:

> On 03/01/2012 09:10 AM, Simone Tripodi wrote:
>> Hi +,
>> 
>> I can report the same test failure:
>> 
>> Failed tests:
>> findMaxFlowAndVerify(org.apache.commons.graph.flow.EdmondsKarpTestCase):
>> expected:<3> but was:<5>
>> 
>> I just applied trivial modifications without altering the algorithms
>> behavior, I am sure the fix is under our eyes :)
> 
> ok. It is fixed now.
> 
> The problem was basically, that once a vertex was pushed onto the stack,
> it was immediately marked as visited. In case you have a custom visitor
> that would instruct you to not visit the tail node for some reason, the
> algorithm would never reach that vertex anymore as it thinks the vertex
> was already visited.
> 
> 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: [graph] Doubts on DFS algorithm implementation

[Thomas Neidhart]

On 03/01/2012 07:06 PM, Marco Speranza wrote:
> Hi Thomas,
> 
> I run the test and it seems that the BSF explore twice the same edge. 
> 
> 
> 
> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.025 sec <<< 
> FAILURE!
> 
> Results :
> 
> Tests in error: 
>   verifyBreadthFirstSearch(org.apache.commons.graph.visit.VisitTestCase): 
> Edge x <-> y() is already present in the Graph
> 
> Tests run: 109, Failures: 0, Errors: 1, Skipped: 0
> 
> 
> 
> I think that we have to add also a list of the visited edges to avoid that. 
> 
> Do you agree with me?

yes, sorry, I was too fast committing. Added an extra check to prevent
discovering multiple edges that lead to the same (already visited) vertex.

Thomas

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

Re: [graph] Doubts on DFS algorithm implementation

[Marco Speranza]

Ok great! now works 
thanks you!

--
Marco Speranza 
Google Code: http://code.google.com/u/marco.speranza79/

Il giorno 01/mar/2012, alle ore 19:32, Thomas Neidhart ha scritto:

> On 03/01/2012 07:06 PM, Marco Speranza wrote:
>> Hi Thomas,
>> 
>> I run the test and it seems that the BSF explore twice the same edge. 
>> 
>> 
>> 
>> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.025 sec 
>> <<< FAILURE!
>> 
>> Results :
>> 
>> Tests in error: 
>>  verifyBreadthFirstSearch(org.apache.commons.graph.visit.VisitTestCase): 
>> Edge x <-> y() is already present in the Graph
>> 
>> Tests run: 109, Failures: 0, Errors: 1, Skipped: 0
>> 
>> 
>> 
>> I think that we have to add also a list of the visited edges to avoid that. 
>> 
>> Do you agree with me?
> 
> yes, sorry, I was too fast committing. Added an extra check to prevent
> discovering multiple edges that lead to the same (already visited) vertex.
> 
> 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

[continuum] BUILD FAILURE: Apache Commons - Commons Sanselan - Default Maven 2 Build Definition (Java 1.5)

[Continuum@vmbuild]

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

Build statistics:
  State: Failed
  Previous Build: No previous build.
  Started at: Thu 1 Mar 2012 19:10:22 +
  Finished at: Thu 1 Mar 2012 19:11:00 +
  Total time: 37s
  Build Trigger: Forced
  Build Number: 0
  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_US, platform encoding: UTF-8
  OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: 
"unix"


SCM Changes:

No files changed


Dependencies Changes:

No dependencies changed



Build Definition:

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


Test Summary:

Tests: 0
Failures: 0
Errors: 0
Total time: 0.0





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

Re: Karma for Continuum on vmbuild

[Dennis Lundberg]

On 2012-02-29 22:25, sebb wrote:
> On 29 February 2012 21:14, Dennis Lundberg  wrote:
>> Hi
>>
>> Can someone please grant me karma @ http://vmbuild.apache.org/continuum
>> I'd like to add some missing modules.
>>
>> My account in Continuum is "dennisl" which is backed by my ASF e-mail
>> address.
> 
> Try now.

Thanks Sebb, work's fine now.

> 
>> --
>> Dennis Lundberg
>>
>> -
>> 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
> 


-- 
Dennis Lundberg

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

Re: Maven bugs when building Sanselan

[Dennis Lundberg]

On 2012-03-01 06:23, Damjan Jovanovic wrote:
> On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg  wrote:
>> On 2012-02-29 19:00, Damjan Jovanovic wrote:
>>> Hi
>>>
>>> As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am
>>> having showstopper problems with Maven.
>>>
>>> The first problem, now fixed, was that "mvn assembly:assembly" failed
>>> due to the Maven Assembly plugin failing to add a non-ASCII filename
>>> to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515),
>>> because Plexus Archiver had a bug that wrongly assumed number of chars
>>> = number of bytes, an assumption that quickly fails on UTF-8 locales
>>> (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to
>>> Plexus Archiver, they quickly included that patch in the next release,
>>> and Maven Assembly then made a 2.3 release which unknowingly pulled in
>>> that new release of Plexus Archiver. So by increasing the needed
>>> version of Maven Assembly to 2.3, I got that working now :). I see
>>> someone recently patched the Commons parent POM with the same version
>>> change - even better.
>>>
>>> The second is that "mvn site" fails because Clirr can't compare some
>>> inner classes properly, and the Maven Clirr plugin doesn't properly
>>> count and delete classes that can't be compared, leading to
>>> ArrayIndexOutOfBoundsException
>>> (http://jira.codehaus.org/browse/MCLIRR-36 and probably
>>> http://jira.codehaus.org/browse/MCLIRR-25 and
>>> http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a
>>> working patch to that bug, but there's been no response yet and the
>>> project seems dead :(.
>>
>> I'll take a look at the patch and see if I can push for a release of the
>> Clirr plugin.
>>
> 
> Great, thank you!
>
> Damjan

Hi

I had some trouble building Sanselan locally with Java 5, so I added
Sanselan to our Continuum CI server. The first build gives the same
result as I got locally, which is a compilation failure. The full report
is here:

http://vmbuild.apache.org/continuum/buildResult.action?buildId=19556&projectId=251

The error message is:

[ERROR] BUILD FAILURE
[INFO]

[INFO] Compilation failure
/home/continuum/continuum-base/data/working-directory/251/src/main/java/org/apache/commons/sanselan/formats/jpeg/iptc/IptcParser.java:[56,37]
cannot find symbol
symbol  : method copyOfRange(byte[],int,int)
location: class java.util.Arrays

That seems to be a Java 6 method. Someone should have a look at that.

I'll continue chasing Clirr-bugs using Java 6 for the time being.


-- 
Dennis Lundberg

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

Re: svn commit: r1295694 - /commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/visit/DefaultVisitAlgorithmsSelector.java

[Simone Tripodi]

YEAH congrats and thank you! :)
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 6:39 PM,   wrote:
> Author: tn
> Date: Thu Mar  1 17:39:59 2012
> New Revision: 1295694
>
> URL: http://svn.apache.org/viewvc?rev=1295694&view=rev
> Log:
> fixed unified graph search algorithm in case of non-default visitor 
> implementations
>
> Modified:
>    
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/visit/DefaultVisitAlgorithmsSelector.java
>
> Modified: 
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/visit/DefaultVisitAlgorithmsSelector.java
> URL: 
> http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/visit/DefaultVisitAlgorithmsSelector.java?rev=1295694&r1=1295693&r2=1295694&view=diff
> ==
> --- 
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/visit/DefaultVisitAlgorithmsSelector.java
>  (original)
> +++ 
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/visit/DefaultVisitAlgorithmsSelector.java
>  Thu Mar  1 17:39:59 2012
> @@ -138,6 +138,13 @@ final class DefaultVisitAlgorithmsSelect
>                 }
>             }
>
> +            // only mark the current vertex as visited, if the
> +            // edge leading to should be expanded
> +            if ( !skipVertex )
> +            {
> +                visitedVertices.add( v );
> +            }
> +
>             if ( !skipVertex && handler.discoverVertex( v ) )
>             {
>                 Iterator connected = ( graph instanceof DirectedGraph ) ?
> @@ -150,7 +157,6 @@ final class DefaultVisitAlgorithmsSelect
>                     if ( !visitedVertices.contains( w ) )
>                     {
>                         vertexList.addLast( new VertexPair( w, v ) );
> -                        visitedVertices.add( w );
>                     }
>                 }
>             }
>
>

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

Re: Maven bugs when building Sanselan

[Gary Gregory]

On Thu, Mar 1, 2012 at 2:25 PM, Dennis Lundberg  wrote:

> On 2012-03-01 06:23, Damjan Jovanovic wrote:
> > On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg 
> wrote:
> >> On 2012-02-29 19:00, Damjan Jovanovic wrote:
> >>> Hi
> >>>
> >>> As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am
> >>> having showstopper problems with Maven.
> >>>
> >>> The first problem, now fixed, was that "mvn assembly:assembly" failed
> >>> due to the Maven Assembly plugin failing to add a non-ASCII filename
> >>> to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515),
> >>> because Plexus Archiver had a bug that wrongly assumed number of chars
> >>> = number of bytes, an assumption that quickly fails on UTF-8 locales
> >>> (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to
> >>> Plexus Archiver, they quickly included that patch in the next release,
> >>> and Maven Assembly then made a 2.3 release which unknowingly pulled in
> >>> that new release of Plexus Archiver. So by increasing the needed
> >>> version of Maven Assembly to 2.3, I got that working now :). I see
> >>> someone recently patched the Commons parent POM with the same version
> >>> change - even better.
> >>>
> >>> The second is that "mvn site" fails because Clirr can't compare some
> >>> inner classes properly, and the Maven Clirr plugin doesn't properly
> >>> count and delete classes that can't be compared, leading to
> >>> ArrayIndexOutOfBoundsException
> >>> (http://jira.codehaus.org/browse/MCLIRR-36 and probably
> >>> http://jira.codehaus.org/browse/MCLIRR-25 and
> >>> http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a
> >>> working patch to that bug, but there's been no response yet and the
> >>> project seems dead :(.
> >>
> >> I'll take a look at the patch and see if I can push for a release of the
> >> Clirr plugin.
> >>
> >
> > Great, thank you!
> >
> > Damjan
>
> Hi
>
> I had some trouble building Sanselan locally with Java 5, so I added
> Sanselan to our Continuum CI server. The first build gives the same
> result as I got locally, which is a compilation failure. The full report
> is here:
>
>
> http://vmbuild.apache.org/continuum/buildResult.action?buildId=19556&projectId=251
>
> The error message is:
>
> [ERROR] BUILD FAILURE
> [INFO]
> 
> [INFO] Compilation failure
>
> /home/continuum/continuum-base/data/working-directory/251/src/main/java/org/apache/commons/sanselan/formats/jpeg/iptc/IptcParser.java:[56,37]
> cannot find symbol
> symbol  : method copyOfRange(byte[],int,int)
> location: class java.util.Arrays
>
> That seems to be a Java 6 method. Someone should have a look at that.


> I'll continue chasing Clirr-bugs using Java 6 for the time being.
>

Interesting that I just mentioned:

"- Is there anything in Java 6 that would make Imaging better? Is using
Java 5 vs. 6 an impediment?"

!

Why not use Java 6 for this component?

Gary


>
> --
> Dennis Lundberg
>
> -
> 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: Maven bugs when building Sanselan

[Gary Gregory]

On Thu, Mar 1, 2012 at 2:25 PM, Dennis Lundberg  wrote:

> On 2012-03-01 06:23, Damjan Jovanovic wrote:
> > On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg 
> wrote:
> >> On 2012-02-29 19:00, Damjan Jovanovic wrote:
> >>> Hi
> >>>
> >>> As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am
> >>> having showstopper problems with Maven.
> >>>
> >>> The first problem, now fixed, was that "mvn assembly:assembly" failed
> >>> due to the Maven Assembly plugin failing to add a non-ASCII filename
> >>> to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515),
> >>> because Plexus Archiver had a bug that wrongly assumed number of chars
> >>> = number of bytes, an assumption that quickly fails on UTF-8 locales
> >>> (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to
> >>> Plexus Archiver, they quickly included that patch in the next release,
> >>> and Maven Assembly then made a 2.3 release which unknowingly pulled in
> >>> that new release of Plexus Archiver. So by increasing the needed
> >>> version of Maven Assembly to 2.3, I got that working now :). I see
> >>> someone recently patched the Commons parent POM with the same version
> >>> change - even better.
> >>>
> >>> The second is that "mvn site" fails because Clirr can't compare some
> >>> inner classes properly, and the Maven Clirr plugin doesn't properly
> >>> count and delete classes that can't be compared, leading to
> >>> ArrayIndexOutOfBoundsException
> >>> (http://jira.codehaus.org/browse/MCLIRR-36 and probably
> >>> http://jira.codehaus.org/browse/MCLIRR-25 and
> >>> http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a
> >>> working patch to that bug, but there's been no response yet and the
> >>> project seems dead :(.
> >>
> >> I'll take a look at the patch and see if I can push for a release of the
> >> Clirr plugin.
> >>
> >
> > Great, thank you!
> >
> > Damjan
>
> Hi
>
> I had some trouble building Sanselan locally with Java 5, so I added
> Sanselan to our Continuum CI server. The first build gives the same
> result as I got locally, which is a compilation failure. The full report
> is here:
>
>
> http://vmbuild.apache.org/continuum/buildResult.action?buildId=19556&projectId=251
>
> The error message is:
>
> [ERROR] BUILD FAILURE
> [INFO]
> 
> [INFO] Compilation failure
>
> /home/continuum/continuum-base/data/working-directory/251/src/main/java/org/apache/commons/sanselan/formats/jpeg/iptc/IptcParser.java:[56,37]
> cannot find symbol
> symbol  : method copyOfRange(byte[],int,int)
> location: class java.util.Arrays
>
> That seems to be a Java 6 method. Someone should have a look at that.
>
> I'll continue chasing Clirr-bugs using Java 6 for the time being.
>

Why are we "chasing Clirr-bugs" when this is not released?

Gary



>
> --
> Dennis Lundberg
>
> -
> 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: [graph] Doubts on DFS algorithm implementation

[Simone Tripodi]

terrific, indeed!!!
very well done!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 7:38 PM, Marco Speranza  wrote:
> Ok great! now works
> thanks you!
>
> --
> Marco Speranza 
> Google Code: http://code.google.com/u/marco.speranza79/
>
> Il giorno 01/mar/2012, alle ore 19:32, Thomas Neidhart ha scritto:
>
>> On 03/01/2012 07:06 PM, Marco Speranza wrote:
>>> Hi Thomas,
>>>
>>> I run the test and it seems that the BSF explore twice the same edge.
>>>
>>> 
>>>
>>> Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.025 sec 
>>> <<< FAILURE!
>>>
>>> Results :
>>>
>>> Tests in error:
>>>  verifyBreadthFirstSearch(org.apache.commons.graph.visit.VisitTestCase): 
>>> Edge x <-> y() is already present in the Graph
>>>
>>> Tests run: 109, Failures: 0, Errors: 1, Skipped: 0
>>>
>>> 
>>>
>>> I think that we have to add also a list of the visited edges to avoid that.
>>>
>>> Do you agree with me?
>>
>> yes, sorry, I was too fast committing. Added an extra check to prevent
>> discovering multiple edges that lead to the same (already visited) vertex.
>>
>> 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
>

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

Re: [SANDBOX][BeanUtils2] Improve implemenation of equals() on AccessibleObjectDescriptor

[Simone Tripodi]

Hi Bene,

apologize but maybe I expressed myself in the wrong form - I didn't
intend to offend you nor attack at all.
Sorry you got it personally.

My intention was rather spur you on not accepting rules/guides as they
are. I didn't hide you that IMHO you're a very talented guy - at your
age I wasn't able to contribute at your level - but it would be a
shame if you continue using someone's else techniques rather than
making your own.

> PS: if you are going for performance you could store the hash code in a
> private filed after the first computation and return the computed value on
> subsequent invocations.

+1 that would be a very nice addition, glad if you could contribute it.

best and alles gute,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 6:04 PM, Benedikt Ritter
 wrote:
> Hi Simo,
>
> I don't know, why are reacting that harshly. I think that questioning why an
> internal class does not have to obey to the general contract of equals() is
> not a sign of lacking "spirit of criticism".
> I think adding that check or suppressing a FindBugs complain are both
> equally valid (although the first one IMHO is less obscure). Even though
> you're right, when saying that ATM that can never happen.
>
> Regards,
> Benedikt
>

>
> Am 01.03.2012 17:11, schrieb Simone Tripodi:
>
>>> if ( !( obj instanceof AccessibleObjectDescriptor ) )
>>> {
>>>    return false;
>>> }
>>
>>
>> what is the sense? having a situation where AccessibleObjectDescriptor
>> is compared to a different type object is something that can simply
>> *never* happen!
>> AccessibleObjectDescriptor is a *private static* class of the
>> AccessibleObjectRegistry - so even the other BeanUtils2 classes know
>> that it is living under the same umbrella - which visibility scope is
>> limited to the beanutils2 package.
>>
>>> That will make AccessibleObjectDescritpor.equals() obey to the general
>>> contract of equals (which states, that x.equals(null) has to return
>>> false)
>>
>>
>> again, explain why it should be useful under the known circumstances.
>>
>>> and it will fix the FindBugs issue, which will have to be fixed anyway,
>>
>>
>> FindBugs violations can be suppressed, and fortunately this is one of
>> the rare occasions we can do it.
>>
>>> if BeanUtils2 leaves Sandbox and gets released someday (at least I hope
>>> that
>>> FindBugs understands, that null instanceof WhatEver returns false).
>>
>>
>> If you want to apply all the best practice you should check every aspect:
>>
>> +---+
>>             if ( this == obj )
>>             {
>>                 return true;
>>             }
>>             if ( obj == null )
>>             {
>>                 return false;
>>             }
>>             if ( getClass() != obj.getClass() ) // or manage in
>> whatever is your preferred way
>>             {
>>                 return false;
>>             }
>> +---+
>>
>> the first check is missing and it is something that would increase the
>> performance, so I intend to commit it.
>>
>>> I see no reason to write less robust code, just because it is internal to
>>> the library and saves us a few lines.
>>
>>
>> And I see no reason why you intend applying rules without using a
>> minimum spirit of criticism. If you analyze the context in which that
>> class participate, instead of reading the code and se what should/what
>> not shall has to be done, you can see that cases you intend to cover
>> *can never happen*.
>>
>> And just to make it clear: I am not a moron which matter is just of
>> saving lines of code, it is a metter of using stuff when they are
>> required - and NOT using them if they are not needed.
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Thu, Mar 1, 2012 at 4:07 PM, Benedikt Ritter
>>   wrote:
>>>
>>> The only thing we have to add is
>>>
>>> if ( !( obj instanceof AccessibleObjectDescriptor ) )
>>> {
>>>    return false;
>>> }
>>>
>>> That will make AccessibleObjectDescritpor.equals() obey to the general
>>> contract of equals (which states, that x.equals(null) has to return
>>> false)
>>> and it will fix the FindBugs issue, which will have to be fixed anyway,
>>> if
>>> BeanUtils2 leaves Sandbox and gets released someday (at least I hope that
>>> FindBugs understands, that null instanceof WhatEver returns false).
>>> I see no reason to write less robust code, just because it is internal to
>>> the library and saves us a few lines.
>>>
>>> Am 01.03.2012 15:49, schrieb Simone Tripodi:
>>>
 AccessibleObjectRegistry.AccessibleObjectDescriptor is used internally
 only, users don't even know that it exist and it is used only as a key
 for the AccessibleObject index.
 Does it make sense checking other types, nulls, assignability from
 super/subclasses, ... etc?

 http://people.apa

Re: Maven bugs when building Sanselan

[Damjan Jovanovic]

On Thu, Mar 1, 2012 at 9:25 PM, Dennis Lundberg  wrote:
> On 2012-03-01 06:23, Damjan Jovanovic wrote:
>> On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg  wrote:
>>> On 2012-02-29 19:00, Damjan Jovanovic wrote:
 Hi

 As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am
 having showstopper problems with Maven.

 The first problem, now fixed, was that "mvn assembly:assembly" failed
 due to the Maven Assembly plugin failing to add a non-ASCII filename
 to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515),
 because Plexus Archiver had a bug that wrongly assumed number of chars
 = number of bytes, an assumption that quickly fails on UTF-8 locales
 (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to
 Plexus Archiver, they quickly included that patch in the next release,
 and Maven Assembly then made a 2.3 release which unknowingly pulled in
 that new release of Plexus Archiver. So by increasing the needed
 version of Maven Assembly to 2.3, I got that working now :). I see
 someone recently patched the Commons parent POM with the same version
 change - even better.

 The second is that "mvn site" fails because Clirr can't compare some
 inner classes properly, and the Maven Clirr plugin doesn't properly
 count and delete classes that can't be compared, leading to
 ArrayIndexOutOfBoundsException
 (http://jira.codehaus.org/browse/MCLIRR-36 and probably
 http://jira.codehaus.org/browse/MCLIRR-25 and
 http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a
 working patch to that bug, but there's been no response yet and the
 project seems dead :(.
>>>
>>> I'll take a look at the patch and see if I can push for a release of the
>>> Clirr plugin.
>>>
>>
>> Great, thank you!
>>
>> Damjan
>
> Hi
>
> I had some trouble building Sanselan locally with Java 5, so I added
> Sanselan to our Continuum CI server. The first build gives the same
> result as I got locally, which is a compilation failure. The full report
> is here:
>
> http://vmbuild.apache.org/continuum/buildResult.action?buildId=19556&projectId=251
>
> The error message is:
>
> [ERROR] BUILD FAILURE
> [INFO]
> 
> [INFO] Compilation failure
> /home/continuum/continuum-base/data/working-directory/251/src/main/java/org/apache/commons/sanselan/formats/jpeg/iptc/IptcParser.java:[56,37]
> cannot find symbol
> symbol  : method copyOfRange(byte[],int,int)
> location: class java.util.Arrays
>
> That seems to be a Java 6 method. Someone should have a look at that.
>
> I'll continue chasing Clirr-bugs using Java 6 for the time being.
>
>
> --
> Dennis Lundberg

Sorry about that. In commit 1295763 I've added the
animal-sniffer-maven-plugin to the POM, configured it to check for
Java 1.5 compatibility, and taken out the Arrays.copyOfRange().

Damjan

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

Re: Maven bugs when building Sanselan

[Dennis Lundberg]

On 2012-03-01 20:45, Gary Gregory wrote:
> On Thu, Mar 1, 2012 at 2:25 PM, Dennis Lundberg  wrote:
> 
>> On 2012-03-01 06:23, Damjan Jovanovic wrote:
>>> On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg 
>> wrote:
 On 2012-02-29 19:00, Damjan Jovanovic wrote:
> Hi
>
> As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am
> having showstopper problems with Maven.
>
> The first problem, now fixed, was that "mvn assembly:assembly" failed
> due to the Maven Assembly plugin failing to add a non-ASCII filename
> to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515),
> because Plexus Archiver had a bug that wrongly assumed number of chars
> = number of bytes, an assumption that quickly fails on UTF-8 locales
> (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to
> Plexus Archiver, they quickly included that patch in the next release,
> and Maven Assembly then made a 2.3 release which unknowingly pulled in
> that new release of Plexus Archiver. So by increasing the needed
> version of Maven Assembly to 2.3, I got that working now :). I see
> someone recently patched the Commons parent POM with the same version
> change - even better.
>
> The second is that "mvn site" fails because Clirr can't compare some
> inner classes properly, and the Maven Clirr plugin doesn't properly
> count and delete classes that can't be compared, leading to
> ArrayIndexOutOfBoundsException
> (http://jira.codehaus.org/browse/MCLIRR-36 and probably
> http://jira.codehaus.org/browse/MCLIRR-25 and
> http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a
> working patch to that bug, but there's been no response yet and the
> project seems dead :(.

 I'll take a look at the patch and see if I can push for a release of the
 Clirr plugin.

>>>
>>> Great, thank you!
>>>
>>> Damjan
>>
>> Hi
>>
>> I had some trouble building Sanselan locally with Java 5, so I added
>> Sanselan to our Continuum CI server. The first build gives the same
>> result as I got locally, which is a compilation failure. The full report
>> is here:
>>
>>
>> http://vmbuild.apache.org/continuum/buildResult.action?buildId=19556&projectId=251
>>
>> The error message is:
>>
>> [ERROR] BUILD FAILURE
>> [INFO]
>> 
>> [INFO] Compilation failure
>>
>> /home/continuum/continuum-base/data/working-directory/251/src/main/java/org/apache/commons/sanselan/formats/jpeg/iptc/IptcParser.java:[56,37]
>> cannot find symbol
>> symbol  : method copyOfRange(byte[],int,int)
>> location: class java.util.Arrays
>>
>> That seems to be a Java 6 method. Someone should have a look at that.
>>
>> I'll continue chasing Clirr-bugs using Java 6 for the time being.
>>
> 
> Why are we "chasing Clirr-bugs" when this is not released?

I'm trying to fix bugs in Maven Clirr Plugin. The JIRA tickets uses
Commons Sanselan as an example project that shows the bugs in action.
That's what got me building Sanselan.

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


-- 
Dennis Lundberg

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

[graph] Kosaraju's SCC algorithm

[Thomas Neidhart]

Hi,

I have checked in my version of Kosaraju's strongly connected components
algorithm. It is a first version and I would be glad if someone can do a
review.

The implementation is roughly based on

http://algowiki.net/wiki/index.php?title=Kosaraju%27s_algorithm

but the search has been implemented in an iterative manner instead of
the outlined recursive variant (which is stupid anyway in the case of
graphs, as this can quickly lead to StackOverflowExceptions imho).

The interface for SccAlgorithmSelector has been updated, so you can call
the algo in two different ways:

Set applyingKosarajuSharir( V source );
Set> applyingKosarajuSharir();

to either get the Set of SCCs for one vertex, or the Set of Sets of SCCs
for the whole graph.

The unit test has been updated too, and runs through this time (feel
ashamed ;-)

Currently there are two helper methods for the algorithm that reside in
the same DefaultSccAlgorithmSelector class, which may be better
offloaded to an algorithm specific auxiliary class to reduce complexity.

The currently existing KosarajuSharirVisitHandler is not used at the
moment due to the problems described in the other thread wrt the current
visitor implementation, but has been kept at the moment. Maybe in the
future we can use a more generic approach.

Thomas

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

Re: Maven bugs when building Sanselan

[Gary Gregory]

On Thu, Mar 1, 2012 at 3:18 PM, Dennis Lundberg  wrote:

> On 2012-03-01 20:45, Gary Gregory wrote:
> > On Thu, Mar 1, 2012 at 2:25 PM, Dennis Lundberg 
> wrote:
> >
> >> On 2012-03-01 06:23, Damjan Jovanovic wrote:
> >>> On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg 
> >> wrote:
>  On 2012-02-29 19:00, Damjan Jovanovic wrote:
> > Hi
> >
> > As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am
> > having showstopper problems with Maven.
> >
> > The first problem, now fixed, was that "mvn assembly:assembly" failed
> > due to the Maven Assembly plugin failing to add a non-ASCII filename
> > to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515),
> > because Plexus Archiver had a bug that wrongly assumed number of
> chars
> > = number of bytes, an assumption that quickly fails on UTF-8 locales
> > (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to
> > Plexus Archiver, they quickly included that patch in the next
> release,
> > and Maven Assembly then made a 2.3 release which unknowingly pulled
> in
> > that new release of Plexus Archiver. So by increasing the needed
> > version of Maven Assembly to 2.3, I got that working now :). I see
> > someone recently patched the Commons parent POM with the same version
> > change - even better.
> >
> > The second is that "mvn site" fails because Clirr can't compare some
> > inner classes properly, and the Maven Clirr plugin doesn't properly
> > count and delete classes that can't be compared, leading to
> > ArrayIndexOutOfBoundsException
> > (http://jira.codehaus.org/browse/MCLIRR-36 and probably
> > http://jira.codehaus.org/browse/MCLIRR-25 and
> > http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a
> > working patch to that bug, but there's been no response yet and the
> > project seems dead :(.
> 
>  I'll take a look at the patch and see if I can push for a release of
> the
>  Clirr plugin.
> 
> >>>
> >>> Great, thank you!
> >>>
> >>> Damjan
> >>
> >> Hi
> >>
> >> I had some trouble building Sanselan locally with Java 5, so I added
> >> Sanselan to our Continuum CI server. The first build gives the same
> >> result as I got locally, which is a compilation failure. The full report
> >> is here:
> >>
> >>
> >>
> http://vmbuild.apache.org/continuum/buildResult.action?buildId=19556&projectId=251
> >>
> >> The error message is:
> >>
> >> [ERROR] BUILD FAILURE
> >> [INFO]
> >> 
> >> [INFO] Compilation failure
> >>
> >>
> /home/continuum/continuum-base/data/working-directory/251/src/main/java/org/apache/commons/sanselan/formats/jpeg/iptc/IptcParser.java:[56,37]
> >> cannot find symbol
> >> symbol  : method copyOfRange(byte[],int,int)
> >> location: class java.util.Arrays
> >>
> >> That seems to be a Java 6 method. Someone should have a look at that.
> >>
> >> I'll continue chasing Clirr-bugs using Java 6 for the time being.
> >>
> >
> > Why are we "chasing Clirr-bugs" when this is not released?
>
> I'm trying to fix bugs in Maven Clirr Plugin. The JIRA tickets uses
> Commons Sanselan as an example project that shows the bugs in action.
> That's what got me building Sanselan.
>

Ah... I see the light! :)

G

>
> >
> > Gary
> >
> >
> >
> >>
> >> --
> >> Dennis Lundberg
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >
> >
>
>
> --
> Dennis Lundberg
>
> -
> 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: [Math] New warnings from "FindBugs"

[Luc Maisonobe]

Le 01/03/2012 15:16, Gilles Sadowski a écrit :
> Hi.

Hi Gilles,

> 
> The version upgrade of the FindBugs plugin led to new discoveries some of
> which are potentially serious bugs:
> 
> * org.apache.commons.math3.ode.nonstiff.GraggBulirschStoerIntegrator: Was
>   method "setStepsizeControl" (note the spelling) intended to override
>   "setStepSizeControl" defined in the parent class?

No, this is a completely different method. The name and signature
similarity was unfortunate ... I have renamed this method.

Fixed in r1295772.

Sorry for the confusion.

Luc

> 
> * org.apache.commons.math3.linear.SymmLQ: Yet another problem with a
>   probably unnecessary "Serializable"...
> 
> * org.apache.commons.math3.genetics.Chromosome: At line 31 (and 43, where
>   FindBugs warns about strict floating point comparison), is the value
>   intended to be the most negative one, instead of "Double.MIN_VALUE" (which
>   is positive)?
> 
> * org.apache.commons.math3.random.EmpiricalDistribution (lines 213, 221,
>   242, 246) and  org.apache.commons.math3.random.ValueServer (line 270):
>   From "FindBugs":
>Dm: Reliance on default encoding (DM_DEFAULT_ENCODING)
> 
>Found a call to a method which will perform a byte to String (or String to
>byte) conversion, and will assume that the default platform encoding is
>suitable. This will cause the application behaviour to vary between
>platforms. Use an alternative API and specify a charset name or Charset
>object explicitly. 
> 
> 
> I think that the last one could be fixed later (unless someone knows how to
> solve it). But for the others, please have look ASAP.
> 
> 
> Thanks,
> Gilles
> 
> -
> 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: r1295773 - in /commons/sandbox/graph/trunk/src: main/java/org/apache/commons/graph/scc/ test/java/org/apache/commons/graph/scc/

[Simone Tripodi]

:O WOW!

may I can ask you to mark SANDBOX-353 as resolved, please?

Many thanks in advance!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 9:27 PM,   wrote:
> Author: tn
> Date: Thu Mar  1 20:27:55 2012
> New Revision: 1295773
>
> URL: http://svn.apache.org/viewvc?rev=1295773&view=rev
> Log:
> added Kosaraju Sharir algorithm for SCC.
>
> Modified:
>    
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/scc/DefaultSccAlgorithmSelector.java
>    
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/scc/SccAlgorithmSelector.java
>    
> commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/scc/KosarajuSharirTestCase.java
>
> Modified: 
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/scc/DefaultSccAlgorithmSelector.java
> URL: 
> http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/scc/DefaultSccAlgorithmSelector.java?rev=1295773&r1=1295772&r2=1295773&view=diff
> ==
> --- 
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/scc/DefaultSccAlgorithmSelector.java
>  (original)
> +++ 
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/scc/DefaultSccAlgorithmSelector.java
>  Thu Mar  1 20:27:55 2012
> @@ -21,12 +21,14 @@ package org.apache.commons.graph.scc;
>
>  import static java.lang.Math.min;
>  import static org.apache.commons.graph.CommonsGraph.visit;
> -import static org.apache.commons.graph.utils.Assertions.checkNotNull;
> -import static org.apache.commons.graph.utils.Assertions.checkState;
>
> +import java.util.ArrayList;
> +import java.util.Collection;
>  import java.util.HashMap;
>  import java.util.HashSet;
>  import java.util.LinkedHashSet;
> +import java.util.LinkedList;
> +import java.util.List;
>  import java.util.Map;
>  import java.util.Set;
>  import java.util.Stack;
> @@ -58,21 +60,143 @@ public final class DefaultSccAlgorithmSe
>     /**
>      * {@inheritDoc}
>      */
> -    public Set applyingKosarajuSharir( V source )
> +    public Set applyingKosarajuSharir( final V source )
>     {
> -        source = checkNotNull( source, "KosarajuSharir algorithm requires a 
> non-null source vertex" );
> -        checkState( graph.containsVertex( source ), "Vertex %s does not 
> exist in the Graph", source );
> -
> -        visit( graph ).from( source ).applyingDepthFirstSearch( new 
> KosarajuSharirVisitHandler( source ) );
> +        final Set visitedVertices = new HashSet();
> +        final List expandedVertexList = getExpandedVertexList( source, 
> visitedVertices );
> +        final DirectedGraph reverted = new RevertedGraph( graph 
> );
> +
> +        // remove the last element from the expanded vertices list
> +        final V v = expandedVertexList.remove( expandedVertexList.size() - 1 
> );
> +        final Set sccSet = new HashSet();
> +        searchRecursive( reverted, v, sccSet, visitedVertices, false );
> +        return sccSet;
> +    }
> +
> +    /**
> +     * {@inheritDoc}
> +     */
> +    public Set> applyingKosarajuSharir()
> +    {
> +        final Set visitedVertices = new HashSet();
> +        final List expandedVertexList = getExpandedVertexList( null, 
> visitedVertices );
> +        final DirectedGraph reverted = new RevertedGraph( graph 
> );
>
> -        DirectedGraph reverted = new RevertedGraph( graph );
> +        final Set> sccs = new HashSet>();
>
> -        // TODO FILL ME, algorithm is incomplete
> +        while ( expandedVertexList.size() > 0 )
> +        {
> +            // remove the last element from the expanded vertices list
> +            final V v = expandedVertexList.remove( expandedVertexList.size() 
> - 1 );
> +            final Set sccSet = new HashSet();
> +            searchRecursive( reverted, v, sccSet, visitedVertices, false );
> +
> +            // remove all strongly connected components from the expanded 
> list
> +            expandedVertexList.removeAll( sccSet );
> +            sccs.add( sccSet );
> +        }
> +
> +        return sccs;
> +    }
> +
> +    private List getExpandedVertexList( final V source, final Set 
> visitedVertices )
> +    {
> +        final int size = (source != null) ? 13 : graph.getOrder();
> +        final Set vertices = new HashSet( size );
> +
> +        if ( source != null )
> +        {
> +            vertices.add( source );
> +        }
> +        else
> +        {
> +            for ( V vertex : graph.getVertices() )
> +            {
> +                vertices.add( vertex );
> +            }
> +        }
> +
> +        // use an ArrayList so that subList is fast
> +        final ArrayList expandedVertexList = new ArrayList();
>
> -        return null;
> +        int idx = 0;
> +        while ( ! vertices.isEmpty() )
> +        {
> +            // get the next vertex that 

[configuration] Replace DatabaseConfiguration with version from branch?

[Oliver Heger]

Hi,

the version of DatabaseConfiguration in the experimental branch strongly 
differs from the trunk version. It uses a template approach for 
executing JDBC operations thus avoiding the complex JDBC exception 
handling plumbing code.


I prefer this style because IMHO it makes the implementations of the 
operations clearer and more readable. So are there any objections 
against replacing the trunk version?


Oliver

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

Re: [graph] Kosaraju's SCC algorithm

[Marco Speranza]

great work :-)

--
Marco Speranza 
Google Code: http://code.google.com/u/marco.speranza79/

Il giorno 01/mar/2012, alle ore 21:26, Thomas Neidhart ha scritto:

> Hi,
> 
> I have checked in my version of Kosaraju's strongly connected components
> algorithm. It is a first version and I would be glad if someone can do a
> review.
> 
> The implementation is roughly based on
> 
> http://algowiki.net/wiki/index.php?title=Kosaraju%27s_algorithm
> 
> but the search has been implemented in an iterative manner instead of
> the outlined recursive variant (which is stupid anyway in the case of
> graphs, as this can quickly lead to StackOverflowExceptions imho).
> 
> The interface for SccAlgorithmSelector has been updated, so you can call
> the algo in two different ways:
> 
>Set applyingKosarajuSharir( V source );
>Set> applyingKosarajuSharir();
> 
> to either get the Set of SCCs for one vertex, or the Set of Sets of SCCs
> for the whole graph.
> 
> The unit test has been updated too, and runs through this time (feel
> ashamed ;-)
> 
> Currently there are two helper methods for the algorithm that reside in
> the same DefaultSccAlgorithmSelector class, which may be better
> offloaded to an algorithm specific auxiliary class to reduce complexity.
> 
> The currently existing KosarajuSharirVisitHandler is not used at the
> moment due to the problems described in the other thread wrt the current
> visitor implementation, but has been kept at the moment. Maybe in the
> future we can use a more generic approach.
> 
> 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: [SANDBOX][BeanUtils2] Improve implemenation of equals() on AccessibleObjectDescriptor

[Benedikt Ritter]

Am 01.03.2012 20:52, schrieb Simone Tripodi:

Hi Bene,

apologize but maybe I expressed myself in the wrong form - I didn't
intend to offend you nor attack at all.
Sorry you got it personally.


you're right, I got that wrong - sorry (it's a bit ironic, since in my 
last mail I told you not to worry about stuff like that ;). Let's go 
back to business!




My intention was rather spur you on not accepting rules/guides as they
are. I didn't hide you that IMHO you're a very talented guy - at your
age I wasn't able to contribute at your level - but it would be a
shame if you continue using someone's else techniques rather than
making your own.


PS: if you are going for performance you could store the hash code in a
private filed after the first computation and return the computed value on
subsequent invocations.


+1 that would be a very nice addition, glad if you could contribute it.


I'll right a patch tomorrow.
Buona notte! ;)
Benedikt



best and alles gute,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 6:04 PM, Benedikt Ritter
  wrote:

Hi Simo,

I don't know, why are reacting that harshly. I think that questioning why an
internal class does not have to obey to the general contract of equals() is
not a sign of lacking "spirit of criticism".
I think adding that check or suppressing a FindBugs complain are both
equally valid (although the first one IMHO is less obscure). Even though
you're right, when saying that ATM that can never happen.

Regards,
Benedikt





Am 01.03.2012 17:11, schrieb Simone Tripodi:


if ( !( obj instanceof AccessibleObjectDescriptor ) )
{
return false;
}



what is the sense? having a situation where AccessibleObjectDescriptor
is compared to a different type object is something that can simply
*never* happen!
AccessibleObjectDescriptor is a *private static* class of the
AccessibleObjectRegistry - so even the other BeanUtils2 classes know
that it is living under the same umbrella - which visibility scope is
limited to the beanutils2 package.


That will make AccessibleObjectDescritpor.equals() obey to the general
contract of equals (which states, that x.equals(null) has to return
false)



again, explain why it should be useful under the known circumstances.


and it will fix the FindBugs issue, which will have to be fixed anyway,



FindBugs violations can be suppressed, and fortunately this is one of
the rare occasions we can do it.


if BeanUtils2 leaves Sandbox and gets released someday (at least I hope
that
FindBugs understands, that null instanceof WhatEver returns false).



If you want to apply all the best practice you should check every aspect:

+---+
 if ( this == obj )
 {
 return true;
 }
 if ( obj == null )
 {
 return false;
 }
 if ( getClass() != obj.getClass() ) // or manage in
whatever is your preferred way
 {
 return false;
 }
+---+

the first check is missing and it is something that would increase the
performance, so I intend to commit it.


I see no reason to write less robust code, just because it is internal to
the library and saves us a few lines.



And I see no reason why you intend applying rules without using a
minimum spirit of criticism. If you analyze the context in which that
class participate, instead of reading the code and se what should/what
not shall has to be done, you can see that cases you intend to cover
*can never happen*.

And just to make it clear: I am not a moron which matter is just of
saving lines of code, it is a metter of using stuff when they are
required - and NOT using them if they are not needed.

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 4:07 PM, Benedikt Ritter
wrote:


The only thing we have to add is

if ( !( obj instanceof AccessibleObjectDescriptor ) )
{
return false;
}

That will make AccessibleObjectDescritpor.equals() obey to the general
contract of equals (which states, that x.equals(null) has to return
false)
and it will fix the FindBugs issue, which will have to be fixed anyway,
if
BeanUtils2 leaves Sandbox and gets released someday (at least I hope that
FindBugs understands, that null instanceof WhatEver returns false).
I see no reason to write less robust code, just because it is internal to
the library and saves us a few lines.

Am 01.03.2012 15:49, schrieb Simone Tripodi:


AccessibleObjectRegistry.AccessibleObjectDescriptor is used internally
only, users don't even know that it exist and it is used only as a key
for the AccessibleObject index.
Does it make sense checking other types, nulls, assignability from
super/subclasses, ... etc?

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal

Re: Maven bugs when building Sanselan

[Dennis Lundberg]

On 2012-02-29 19:00, Damjan Jovanovic wrote:
> Hi
> 
> As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am
> having showstopper problems with Maven.
> 
> The first problem, now fixed, was that "mvn assembly:assembly" failed
> due to the Maven Assembly plugin failing to add a non-ASCII filename
> to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515),
> because Plexus Archiver had a bug that wrongly assumed number of chars
> = number of bytes, an assumption that quickly fails on UTF-8 locales
> (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to
> Plexus Archiver, they quickly included that patch in the next release,
> and Maven Assembly then made a 2.3 release which unknowingly pulled in
> that new release of Plexus Archiver. So by increasing the needed
> version of Maven Assembly to 2.3, I got that working now :). I see
> someone recently patched the Commons parent POM with the same version
> change - even better.
> 
> The second is that "mvn site" fails because Clirr can't compare some
> inner classes properly, and the Maven Clirr plugin doesn't properly
> count and delete classes that can't be compared, leading to
> ArrayIndexOutOfBoundsException
> (http://jira.codehaus.org/browse/MCLIRR-36 and probably
> http://jira.codehaus.org/browse/MCLIRR-25 and
> http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a
> working patch to that bug, but there's been no response yet and the
> project seems dead :(.

I am unable to reproduce this error using current trunk of Sanselan. Are
you using some local modifications to your pom.xml that specifies which
artifact Clirr should compare against?

All I get is this:

[INFO] Unable to find a previous version of the project in the repository
[INFO] Not generating Clirr report as there is no previous version of
the library to compare against

> Otherwise, what is the procedure for renaming the project to Apache
> Commons Imaging?
> 
> Thank you
> Damjan
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-- 
Dennis Lundberg

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

Re: [graph] Doubts on DFS algorithm implementation

[Claudio Squarcella]

Hi,


Added an extra check to prevent
discovering multiple edges that lead to the same (already visited) vertex.


cool stuff, thanks for turning human words into computer words :)
I spent a couple minutes running the tests on max-flow algos with 
breakpoints and stuff, and apparently they keep avoiding zero-capacity 
links during graph visit. Excellent!


Claudio

--
Claudio Squarcella
PhD student at Roma Tre University
http://www.dia.uniroma3.it/~squarcel
http://squarcella.com/


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

Re: svn commit: r1295924 - in /commons/sandbox/graph/trunk/src: changes/changes.xml main/java/org/apache/commons/graph/scc/DefaultSccAlgorithmSelector.java test/java/org/apache/commons/graph/scc/Kosar

[Simone Tripodi]

Ciao Marco,

+DirectedMutableWeightedGraph, Integer> graph =
+newDirectedMutableWeightedGraph( new
AbstractGraphConnection>()
+{
+@Override
+public void connect()
+{
+}
+
+} );

it would be more readable if you just create the graph instance, in
these cases empty configuration is quiet useless ;)

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Mar 1, 2012 at 10:51 PM,   wrote:
> Author: marcosperanza
> Date: Thu Mar  1 21:51:40 2012
> New Revision: 1295924
>
> URL: http://svn.apache.org/viewvc?rev=1295924&view=rev
> Log:
> [SANDBOX-392] Add test for Kosaraju Sharir Algorithm
>
> Modified:
>    commons/sandbox/graph/trunk/src/changes/changes.xml
>    
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/scc/DefaultSccAlgorithmSelector.java
>    
> commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/scc/KosarajuSharirTestCase.java
>
> Modified: commons/sandbox/graph/trunk/src/changes/changes.xml
> URL: 
> http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/changes/changes.xml?rev=1295924&r1=1295923&r2=1295924&view=diff
> ==
> --- commons/sandbox/graph/trunk/src/changes/changes.xml (original)
> +++ commons/sandbox/graph/trunk/src/changes/changes.xml Thu Mar  1 21:51:40 
> 2012
> @@ -23,6 +23,9 @@
>   
>   
>   
> +    
> +      Add test for Kosaraju Sharir Algorithm
> +    
>     
>       Provide a Kosaraju-Sharir's algorithm implementation
>     
>
> Modified: 
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/scc/DefaultSccAlgorithmSelector.java
> URL: 
> http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/scc/DefaultSccAlgorithmSelector.java?rev=1295924&r1=1295923&r2=1295924&view=diff
> ==
> --- 
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/scc/DefaultSccAlgorithmSelector.java
>  (original)
> +++ 
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/scc/DefaultSccAlgorithmSelector.java
>  Thu Mar  1 21:51:40 2012
> @@ -21,6 +21,8 @@ package org.apache.commons.graph.scc;
>
>  import static java.lang.Math.min;
>  import static org.apache.commons.graph.CommonsGraph.visit;
> +import static org.apache.commons.graph.utils.Assertions.checkState;
> +import static org.apache.commons.graph.utils.Assertions.checkNotNull;
>
>  import java.util.ArrayList;
>  import java.util.Collection;
> @@ -62,6 +64,9 @@ public final class DefaultSccAlgorithmSe
>      */
>     public Set applyingKosarajuSharir( final V source )
>     {
> +        checkNotNull( source, "Kosaraju Sharir algorithm cannot be 
> calculated without expressing the source vertex" );
> +        checkState( graph.containsVertex( source ), "Vertex %s does not 
> exist in the Graph", source );
> +
>         final Set visitedVertices = new HashSet();
>         final List expandedVertexList = getExpandedVertexList( source, 
> visitedVertices );
>         final DirectedGraph reverted = new RevertedGraph( graph );
>
> Modified: 
> commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/scc/KosarajuSharirTestCase.java
> URL: 
> http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/scc/KosarajuSharirTestCase.java?rev=1295924&r1=1295923&r2=1295924&view=diff
> ==
> --- 
> commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/scc/KosarajuSharirTestCase.java
>  (original)
> +++ 
> commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/scc/KosarajuSharirTestCase.java
>  Thu Mar  1 21:51:40 2012
> @@ -21,7 +21,7 @@ package org.apache.commons.graph.scc;
>
>  import static 
> org.apache.commons.graph.CommonsGraph.findStronglyConnectedComponent;
>  import static org.apache.commons.graph.CommonsGraph.newDirectedMutableGraph;
> -
> +import static 
> org.apache.commons.graph.CommonsGraph.newDirectedMutableWeightedGraph;
>  import static org.junit.Assert.assertEquals;
>  import static org.junit.Assert.assertFalse;
>
> @@ -32,7 +32,9 @@ import java.util.Set;
>  import org.apache.commons.graph.builder.AbstractGraphConnection;
>  import org.apache.commons.graph.model.BaseLabeledEdge;
>  import org.apache.commons.graph.model.BaseLabeledVertex;
> +import org.apache.commons.graph.model.BaseLabeledWeightedEdge;
>  import org.apache.commons.graph.model.DirectedMutableGraph;
> +import org.apache.commons.graph.model.DirectedMutableWeightedGraph;
>  import org.junit.Test;
>
>  /**
> @@ -42,8 +44,93 @@ import org.junit.Test;
>  public final class KosarajuSharirTestCase
>  {
>
> +    @Test( expected = NullPointerException.class )
> +    

Re: [Math] New warnings from "FindBugs"

[Gilles Sadowski]

Hello Sébastien.

> > 
> > >
> > > * org.apache.commons.math3.linear.SymmLQ: Yet another problem with a
> > >  probably unnecessary "Serializable"...
> > >
> > In fact, it comes from a nested class which extends EventObject, so it
> > must be (unfortunately) serializable. I'll look into it.
> 
> Then, it seems that you can define it as "static", and it will make FindBugs
> happy, I think. [The problem is that it is a "plain" inner class, in a
> non-serializable class.]
> 

I've performed this change and also had to make the "state" field
"transient" because "State" is not "Serializable" and it cannot be
since "RealLinearOperator" is not "Serializable" and cannot be (IIUC).[1]
[At first sight, all this confirms that we should stay away from
"Serializable". :-}]


Best,
Gilles

[1] This quiets "FindBugs", and since that class is a private inner class,
you'll have the possiblity to handle this in another way for 3.1.

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

Re: [Math] New warnings from "FindBugs"

[Gilles Sadowski]

Hello Luc.

> > 
> > The version upgrade of the FindBugs plugin led to new discoveries some of
> > which are potentially serious bugs:
> > 
> > * org.apache.commons.math3.ode.nonstiff.GraggBulirschStoerIntegrator: Was
> >   method "setStepsizeControl" (note the spelling) intended to override
> >   "setStepSizeControl" defined in the parent class?
> 
> No, this is a completely different method. The name and signature
> similarity was unfortunate ... I have renamed this method.
> 
> Fixed in r1295772.

Thanks.

> [...]

> > * org.apache.commons.math3.random.EmpiricalDistribution (lines 213, 221,
> >   242, 246) and  org.apache.commons.math3.random.ValueServer (line 270):
> >   From "FindBugs":
> >Dm: Reliance on default encoding (DM_DEFAULT_ENCODING)
> > 
> >Found a call to a method which will perform a byte to String (or String 
> > to
> >byte) conversion, and will assume that the default platform encoding is
> >suitable. This will cause the application behaviour to vary between
> >platforms. Use an alternative API and specify a charset name or Charset
> >object explicitly. 
> > 
> > 
> > I think that the last one could be fixed later (unless someone knows how to
> > solve it). [...]

OK to leave those?


Gilles

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

[continuum] BUILD FAILURE: Apache Commons - Apache Commons Digester - Default Maven 2 Build Definition (Java 1.5)

[Continuum@vmbuild]

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

Build statistics:
  State: Failed
  Previous State: Failed
  Started at: Thu 1 Mar 2012 23:22:08 +
  Finished at: Thu 1 Mar 2012 23:23:17 +
  Total time: 1m 9s
  Build Trigger: Schedule
  Build Number: 162
  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_US, platform encoding: UTF-8
  OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: 
"unix"


SCM Changes:

Changed: simonetripodi @ Thu 1 Mar 2012 22:54:46 +
Comment: aggregate javadoc reports
Files changed:
  /commons/proper/digester/trunk/pom.xml ( 1295963 )

Changed: simonetripodi @ Thu 1 Mar 2012 22:56:47 +
Comment: typo
Files changed:
  /commons/proper/digester/trunk/src/changes/changes.xml ( 1295964 )


Dependencies Changes:

No dependencies changed



Build Definition:

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


Test Summary:

Tests: 208
Failures: 0
Errors: 0
Success Rate: 100
Total time: 4.9560003





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

[Math] More missing/confusing infos in "UsingNexus"

[Gilles Sadowski]

Hi.

I'm now trying to figure how to "stage the site". [What does "stage" mean in
this context?]

Reading this
---CUT---

  stagingSite
  repouser
  

---CUT---

I wonder:
 * Should I replace "repouser" with my login?
 * Is the password really optional?
 * Can the password be encrypted?
 * What should be done with the ssh key?

Then, what does "[...]" mean in the next excerpt from the document? I.e.
---CUT---
mvn site:stage-deploy -DstagingDirectory=src/site \
-DstagingSiteURL=scp://[...]/people.apache.org/builds/commons/compress/1.1/RC1
---CUT---

When I issue the command:

 $ mvn site:stage-deploy -DstagingDirectory=src/site 
-DstagingSiteURL=scp://people.apache.org/builds/commons/math/3.0/RC1

I get this:
---CUT---
[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building Commons Math 3.0
[INFO] 
[INFO] 
[INFO] --- maven-site-plugin:3.0:stage-deploy (default-cli) @ commons-math3 ---
[INFO] Using this server ID for stage deploy: people.apache.org
[INFO] Using this base URL for stage deploy: 
scp://people.apache.org/builds/commons/math/3.0/RC1
[INFO] Parent project loaded from repository: 
org.apache.commons:commons-parent:pom:23
Using private key: /home/eran/.ssh/id_rsa

: Password: :
---CUT---

Do I have to give the password interactively? Why is it specified in the
"settings.xml" then? [Moreover it is echoed on the console as I type it.]
It does not make any sense.

What is the purpose of the
 Using private key: /home/eran/.ssh/id_rsa
statement?
Do I in fact need to set up no-password login to my account on
"people.apache.org"?

For when the above is going to work, I noticed that the file
  src/site/site.xml
(in the working copy) contains theses lines

 
 http://commons.apache.org/math/api-2.2/index.html"/>

i.e. the new (3.0) docs links to a local file. Will that be automagically
changed at some point? By which command?
[I also note that I had to change that file manually (to remove the
"snapshot" string). This probably should also be mentioned in the
"ReleaseForNewbies" document...]


Regards,
Gilles

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

[Math] Toward 3.0 release: First deliverables

[Gilles Sadowski]

Hi.

I managed to complete part of the release process:

Tag on SVN:
  https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_0_RC1/

Artefacts on Nexus:
  https://repository.apache.org/content/repositories/orgapachecommons-010/

I'm still stuck with the "staged" web site (cf. other post); but you can
already have a look at the above deliverables. Please let me know of
anything that requires correction.


Regards,
Gilles

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

Re: [Math] Toward 3.0 release: First deliverables

[Bruce A Johnson]

On Mar 1, 2012, at 7:59 PM, Gilles Sadowski wrote:

> Hi.
> 
> I managed to complete part of the release process:
> 
> Tag on SVN:
>  https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_0_RC1/
> 
> Artefacts on Nexus:
>  https://repository.apache.org/content/repositories/orgapachecommons-010/
> 
> I'm still stuck with the "staged" web site (cf. other post); but you can
> already have a look at the above deliverables. Please let me know of
> anything that requires correction.
> 
> 
> Regards,
> Gilles
> 

Release notes at 

https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_0_RC1/

are for Math 2.1,

Bruce

(and keep up the good work, it looks like your almost there)



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

[graph] Why the Vertex and Edge interfaces?

[James Carman]

Sorry if this was double-posted.  I think I accidentally sent it from
my "personal" email account too (which isn't subscribed).

Anyway, shouldn't we just let anything (perhaps restrict it to
Serializables) be a vertex or an edge?

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

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

[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-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 38 runs.
The current state of this project is 'Failed', with reason 'Missing Build 
Outputs'.
For reference only, the following projects are affected by this:
- commons-digester3 :  XML to Java Object Configuration
- commons-digester3-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/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-digester3-*[0-9T].jar] identifier set to 
project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/digester/pom.xml
 -INFO- Failed with reason missing build outputs
 -ERROR- Missing Output: 
/srv/gump/public/workspace/apache-commons/digester/target/commons-digester3-*[0-9T].jar
 -ERROR- See Directory Listing Work for Missing Outputs
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
Work Name: build_apache-commons_commons-digester3 (Type: Build)
Work ended in a state of : Success
Elapsed: 1 min 35 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml 
package 
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-archiver/1.1/plexus-archiver-1.1.pom

Downloading: 
http://localhost:8192/maven2/org/apache/maven/shared/maven-shared-io/1.1/maven-shared-io-1.1.pom

Downloading: 
http://localhost:8192/maven2/org/apache/maven/shared/maven-repository-builder/1.0-alpha-2/maven-repository-builder-1.0-alpha-2.pom

Downloading: 
http://localhost:8192/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.0-alpha-1/maven-common-artifact-filters-1.0-alpha-1.pom

Downloading: 
http://localhost:8192/maven2/org/apache/maven/shared/maven-shared-components/6/maven-shared-components-6.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-archiver/1.1/plexus-archiver-1.1.jar
Downloading: 
http://localhost:8192/maven2/org/apache/maven/shared/maven-shared-io/1.1/maven-shared-io-1.1.jar


Downloading: 
http://localhost:8192/maven2/org/apache/maven/shared/maven-repository-builder/1.0-alpha-2/maven-repository-builder-1.0-alpha-2.jar

[INFO] [assembly:single {execution: default}]
[INFO] Reading assembly descriptor: 
/srv/gump/public/workspace/apache-commons/digester/dist/src/main/assembly/bin.xml
[INFO] Reading assembly descriptor: 
/srv/gump/public/workspace/apache-commons/digester/dist/src/main/assembly/src.xml
[INFO] Building tar : 
/srv/gump/public/workspace/apache-commons/digester/dist/target/commons-digester3-3.3-SNAPSHOT-bin.tar.gz
[INFO] Building zip: 
/srv/gump/public/workspace/apache-commons/digester/dist/target/commons-digester3-3.3-SNAPSHOT-bin.zip
[INFO] Building tar : 
/srv/gump/public/workspace/apache-commons/digester/dist/target/commons-digester3-3.3-SNAPSHOT-src.tar.gz
[INFO] Building zip: 
/srv/gump/public/workspace/apache-commons/digester/dist/target/commons-digester3-3.3-SNAPSHOT-src.zip
[INFO] 
[INFO] 
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Commons Digester ... SUCCESS [10.101s]
[INFO] Apache Commons Digester :: Core ... SUCCESS [30.123s]
[INFO] Apache Commons Digester :: Annotations Processor .. SUCCESS [2.511s]
[INFO] Commons Digester :: Examples .. SUCCESS [0.582s]
[INFO] Apache Commons Digester :: Examples :: Annotations :: Atom  SUCCESS 
[3.209s]
[INFO] Apache Commons Digester :: Examples :: API :: Address Book  SUCCESS 
[1.989s]
[INFO] Apache Commons Digester :: Examples :: API :: Catalog . SUCCESS [1.899s]
[INFO] Apache Commons Digester :: Examples :: API :: DB Insert  SUCCESS [2.098s]
[INFO] Apache Commons Digester :: Examples :: API :: Document Markup  SUCCESS 
[1.628s]
[INFO] Apache Commons Digester :: Examples :: EDSL :: Atom ... SUCCESS [1.881s]
[INFO] Apache Commons Digester :: Examples :: Plugins :: Pipeline  SUCCESS 
[1.494s]
[INFO] Apache Commons Digester :: Exam

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

[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,
 and has been outstanding for 3 runs.
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 23 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
-
FOO..
org.apache.commons.exec.ExecuteException: Process exited with an error: 143 
(Exit value: 143)
Process completed in 2013 millis; below is its output
Process timed out and was killed.
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 8027 millis; above is its output
0: process has terminated: false
1: process has terminated: false
2: process has terminated: false
3: process has terminated: false
4: process has terminated: false
5: process has terminated: false
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
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.022 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.028 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.028 ms
Process completed in 2004 millis; below is its output
Process timed out and was killed by watchdog.
gdal_translate
HDF5:"/home/kk/grass/data/4404.he5"://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif
FOO..
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.79 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 22 seconds
[INFO] Finished at: Fri Mar 02 02:52:25 UTC 2012
[INFO] Final Memory: 25M/65M
[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 1202032012, vmgump.apache.org:vmgump:1202032012
Gump E-mail Identifier (unique within run) #14.

--
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-lang3-test (in module apache-commons) failed

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


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-lang3-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/lang/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/lang/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/lang/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/lang/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-lang3-test/gump_work/build_apache-commons_commons-lang3-test.html
Work Name: build_apache-commons_commons-lang3-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 32 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/lang/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/lang]
M2_HOME: /opt/maven2
-
Running org.apache.commons.lang3.text.translate.LookupTranslatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running org.apache.commons.lang3.text.ExtendedMessageFormatTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.879 sec
Running org.apache.commons.lang3.text.StrSubstitutorTest
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.025 sec
Running org.apache.commons.lang3.text.CompositeFormatTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.lang3.text.StrTokenizerTest
Tests run: 55, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec
Running org.apache.commons.lang3.text.StrBuilderTest
Tests run: 77, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.038 sec
Running org.apache.commons.lang3.text.FormattableUtilsTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Running org.apache.commons.lang3.StringUtilsStartsEndsWithTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Running org.apache.commons.lang3.ArrayUtilsRemoveMultipleTest
Tests run: 55, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec
Running org.apache.commons.lang3.RandomStringUtilsTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.059 sec
Running org.apache.commons.lang3.StringUtilsTest
Tests run: 83, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.26 sec

Results :

Failed tests:   
testReflectionObjectCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)
  
testSimpleReflectionObjectCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)
  
testReflectionByteArrayArray(org.apache.commons.lang3.builder.ToStringBuilderTest)
  
testReflectionCharArrayArray(org.apache.commons.lang3.builder.ToStringBuilderTest)
  testReflectionShortArray(org.apache.commons.lang3.builder.ToStringBuilderTest)
  
testSelfInstanceVarReflectionObjectCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)
  testReflectionIntArray(org.apache.commons.lang3.builder.ToStringBuilderTest)
  testReflectionCharArray(org.apache.commons.lang3.builder.ToStringBuilderTest)
  testObjectCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)

Tests run: 2139, Failures: 9, Errors: 0, Skipped: 4

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

Please refer to 
/srv/gump/public/workspace/apache-commons/lang/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 31 seconds
[INFO] Finished at: Fri Mar 02 03:39:12 UTC 2012
[INFO] Final Memory: 32M/78M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apac

Re: Maven bugs when building Sanselan

[Damjan Jovanovic]

On Thu, Mar 1, 2012 at 11:37 PM, Dennis Lundberg  wrote:
> On 2012-02-29 19:00, Damjan Jovanovic wrote:
>> Hi
>>
>> As we near the 1.0 release of Sanselan / Apache Commons Imaging, I am
>> having showstopper problems with Maven.
>>
>> The first problem, now fixed, was that "mvn assembly:assembly" failed
>> due to the Maven Assembly plugin failing to add a non-ASCII filename
>> to a tar file (https://jira.codehaus.org/browse/MASSEMBLY-515),
>> because Plexus Archiver had a bug that wrongly assumed number of chars
>> = number of bytes, an assumption that quickly fails on UTF-8 locales
>> (http://jira.codehaus.org/browse/PLXCOMP-195). I sent a patch to
>> Plexus Archiver, they quickly included that patch in the next release,
>> and Maven Assembly then made a 2.3 release which unknowingly pulled in
>> that new release of Plexus Archiver. So by increasing the needed
>> version of Maven Assembly to 2.3, I got that working now :). I see
>> someone recently patched the Commons parent POM with the same version
>> change - even better.
>>
>> The second is that "mvn site" fails because Clirr can't compare some
>> inner classes properly, and the Maven Clirr plugin doesn't properly
>> count and delete classes that can't be compared, leading to
>> ArrayIndexOutOfBoundsException
>> (http://jira.codehaus.org/browse/MCLIRR-36 and probably
>> http://jira.codehaus.org/browse/MCLIRR-25 and
>> http://jira.codehaus.org/browse/MCLIRR-37). I made and attached a
>> working patch to that bug, but there's been no response yet and the
>> project seems dead :(.
>
> I am unable to reproduce this error using current trunk of Sanselan. Are
> you using some local modifications to your pom.xml that specifies which
> artifact Clirr should compare against?
>
> All I get is this:
>
> [INFO] Unable to find a previous version of the project in the repository
> [INFO] Not generating Clirr report as there is no previous version of
> the library to compare against
>

Clirr doesn't find the 0.97 release because the groupId and artifactId
for it were different.
It breaks for me because I somehow have Sanselan 0.98 (a version that
was never released) in my ~/.m2 directory.
But there is still a Clirr bug here which will affect future releases
even if it doesn't affect this one.

I will attach the minimum set of Sanselan 0.98 files needed to
reproduce this bug to the bug report.

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

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

[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 19 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: 24 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.202 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.105 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]

Re: [Math] New warnings from "FindBugs"

[Sébastien Brisard]

>
> Hello Sébastien.
>

Hi Gilles,

>> >
>> > >
>> > > * org.apache.commons.math3.linear.SymmLQ: Yet another problem with a
>> > >  probably unnecessary "Serializable"...
>> > >
>> > In fact, it comes from a nested class which extends EventObject, so it
>> > must be (unfortunately) serializable. I'll look into it.
>>
>> Then, it seems that you can define it as "static", and it will make FindBugs
>> happy, I think. [The problem is that it is a "plain" inner class, in a
>> non-serializable class.]
>>
>
> I've performed this change and also had to make the "state" field
> "transient" because "State" is not "Serializable" and it cannot be
> since "RealLinearOperator" is not "Serializable" and cannot be (IIUC).[1]
> [At first sight, all this confirms that we should stay away from
> "Serializable". :-}]
>

I do agree with you on this, although my point of view is far less
enlightened than yours. I know "serializable" is difficult,
problematic and error-prone, so I just keep away from it as a general
rule. I should therefore apologize for having carelessly implemented
serializable in this particular instance.

>
> Best,
> Gilles
>
> [1] This quiets "FindBugs", and since that class is a private inner class,
>    you'll have the possiblity to handle this in another way for 3.1.
>

Actually, I *do* want to handle it differently (I've even set a TODO
tag in the source). In short, I've used references a lot in order to
avoid creating new objects, but this makes event handling a bit
intricate, and I want to refactor that part (keeping the public API
unchanged).

Thanks for your help on this,
Sébastien


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

Re: [chain] release roadmap

[Elijah Zupancic]

Hi Simo,

I saw the changes and they look great! Let's see if I can get you a patch
to get the 2.0 apps examples compiling. They are written to use Java 1.3
and we need to change the pom to support 1.5. I already have some source
changes for them, but I am not done with it.

-Elijah

On Thu, Mar 1, 2012 at 8:37 AM, Simone Tripodi wrote:

> Hi Elijah,
>
> this is something needed indeed, thanks *a lot*!!!
>
> I don't know if you checked out updates, I switched to multi-module
> project structure, looks like it is complete and I just have to add
> the /apps in the modules list.
>
> Thanks for the hard work, all the best!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Thu, Mar 1, 2012 at 5:33 PM, Elijah Zupancic 
> wrote:
> > FYI, I am also updating the examples in the /apps folder.
> >
> > -Elijah
> >
> > On Mon, Feb 27, 2012 at 12:01 PM, Simone Tripodi
> >  wrote:
> >> Hi Elijah,
> >>
> >> no needs to learn docbook, the docbook page you see on svn repo is a
> >> donation from an old book. Deployed documentation is generated from
> >> /src/site/xdoc sources, the format is an html-alike [1] markup. Just
> >> run ``mvn site && open target/site/index.html` to see the produced
> >> documentation.
> >> HTH!
> >> -Simo
> >>
> >> [1] http://maven.apache.org/doxia/references/xdoc-format.html
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://simonetripodi.livejournal.com/
> >> http://twitter.com/simonetripodi
> >> http://www.99soft.org/
> >>
> >>
> >>
> >> On Mon, Feb 27, 2012 at 7:32 PM, Elijah Zupancic 
> wrote:
> >>> Hi Simo,
> >>>
> >>> Here is my comment from the ticket: "My plan is to take this on. I'm
> >>> just very busy at work right now, so I've been trying to learn docbook
> >>> format on the bus on my way to and from work. If you want to take on
> >>> breaking chain into separate modules, that would be much appreciated."
> >>>
> >>> -Elijah
> >>>
> >>> On Mon, Feb 27, 2012 at 8:58 AM, Simone Tripodi
> >>>  wrote:
> 
>  Hi all guys!
> 
>  thanks to Elijah Zupancich's contributions, we now have a fresh new
>  [chain] on trunk that uses generics. I can have (limited) spare time
>  to dedicate to [chain] and I would like to put energies on it in order
>  to have it released ASAP.
> 
>  This is my roadmap to have [chain] released in a short time:
> 
>   * CHAIN-65
>   * CHAIN-66
>   * CHAIN-55
> 
>  since some other issues are really old and never fixed, I'd tend to
>  keep them open and move to release 2.1
> 
>  groupId:artifactId:version will be updated to
>  org.apache.common:commons-chain2:2.0
> 
>  Does anyone have objections/suggestions/... ?
>  TIA, all the best!
>  -Simo
> 
>  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
> 
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

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

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


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-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/configuration/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/configuration/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/configuration/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/gump_work/build_apache-commons_commons-configuration-test.html
Work Name: build_apache-commons_commons-configuration-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 54 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml 
test 
[Working Directory: /srv/gump/public/workspace/apache-commons/configuration]
M2_HOME: /opt/maven2
-
Running org.apache.commons.configuration.TestHierarchicalConfigurationXMLReader
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
Running org.apache.commons.configuration.TestNullCompositeConfiguration
Tests run: 23, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.152 sec
Running org.apache.commons.configuration.interpol.TestConfigurationInterpolator
Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec
Running org.apache.commons.configuration.interpol.TestEnvironmentLookup
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.configuration.interpol.TestExprLookup
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
Running org.apache.commons.configuration.interpol.TestConstantLookup
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec
Running org.apache.commons.configuration.TestPropertiesConfigurationLayout
Tests run: 38, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec
Running org.apache.commons.configuration.TestConfigurationConverter
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.configuration.TestFileConfiguration
Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.681 sec
Running org.apache.commons.configuration.TestPatternSubtreeConfiguration
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec
Running org.apache.commons.configuration.TestPropertyConverter
Tests run: 28, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.043 sec
Running org.apache.commons.configuration.TestConfigurationMap
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.configuration.reloading.TestManagedReloadingStrategy
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running 
org.apache.commons.configuration.reloading.TestVFSFileChangedReloadingStrategy
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.026 sec
Running 
org.apache.commons.configuration.reloading.TestFileChangedReloadingStrategy
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.027 sec

Results :

Failed tests:   
testValidation2(org.apache.commons.configuration.TestVFSConfigurationBuilder): 
The test key was not located

Tests run: 1593, 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/configuration/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 53 seconds
[INFO] Finished at: Fri Mar 02 06:53:44 UTC 2012
[INFO] Final Memo

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

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


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-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/proxy/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -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



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html
Work Name: build_apache-commons_commons-proxy-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 11 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.provider.TestConstantProvider
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
Running org.apache.commons.proxy.exception.TestDelegateProviderException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.invoker.TestChainInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.provider.TestBeanProvider
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec

Results :

Tests in error: 
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)

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

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

Please refer to 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 10 seconds
[INFO] Finished at: Fri Mar 02 06:54:50 UTC 2012
[INFO] Final Memory: 24M/58M
[INFO] 
-

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

RE: [Math] Toward 3.0 release: First deliverables

[Hendriks, D.]

Hi Gilles,

https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_0_RC1/NOTICE.txt

states:

Copyright 2001-2010 The Apache Software Foundation

should this not be updated to:

Copyright 2001-2012 The Apache Software Foundation

Best regards,
Dennis



Van: Gilles Sadowski [gil...@harfang.homelinux.org]
Verzonden: vrijdag 2 maart 2012 1:59
Aan: dev@commons.apache.org
Onderwerp: [Math] Toward 3.0 release: First deliverables

Hi.

I managed to complete part of the release process:

Tag on SVN:
  https://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_3_0_RC1/

Artefacts on Nexus:
  https://repository.apache.org/content/repositories/orgapachecommons-010/

I'm still stuck with the "staged" web site (cf. other post); but you can
already have a look at the above deliverables. Please let me know of
anything that requires correction.


Regards,
Gilles

-
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

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

[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 6 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
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 failed
 -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: 1 min 46 secs
Command Line: /opt/maven2/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/maven2
-
Tests in error: 
  
testDefaultInstance(org.apache.commons.vfs2.test.FileSystemManagerFactoryTestCase):
 Could not create a file system manager of class 
"org.apache.commons.vfs2.impl.StandardFileSystemManager".
  org.apache.commons.vfs2.PatternFileSelectorTest: Could not create a file 
system manager of class 
"org.apache.commons.vfs2.impl.StandardFileSystemManager".
  org.apache.commons.vfs2.FileTypeSelectorTest: Could not create a file system 
manager of class "org.apache.commons.vfs2.impl.StandardFileSystemManager".
  org.apache.commons.vfs2.FileIteratorTest: Could not create a file system 
manager of class "org.apache.commons.vfs2.impl.StandardFileSystemManager".
  
junit.framework.TestSuite@c75e4fc(org.apache.commons.vfs2.test.CacheTestSuite): 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@7e78fc6(org.apache.commons.vfs2.test.CacheTestSuite): 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
testDelegatingBad(org.apache.commons.vfs2.util.DelegatingFileSystemOptionsBuilderTest):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
testConfiguration(org.apache.commons.vfs2.util.DelegatingFileSystemOptionsBuilderTest):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
testDelegatingGood(org.apache.commons.vfs2.util.DelegatingFileSystemOptionsBuilderTest):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@379e8f17(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@39385660(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@44a613f8(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@40589e56(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@6c69d02b(org.apache.commons.vfs2.provider.ftp.test.FtpProviderTestCase$1):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@7c0b6548(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  org.apache.commons.vfs2.provider.test.FileObjectSortTestCase: Could not 
create a file system manager of class 
"org.apache.commons.vfs2.impl.StandardFileSystemManager".
  
junit.framework.TestSuite@50269997(org.apac

Re: [Math] Toward 3.0 release: First deliverables

[Sébastien Brisard]

Hi Gilles,
could we make the following additions to the release notes?
New features
MATH-655: framework for iterative linear solvers. Implementation of
two solvers: conjugate gradient, SYMMLQ.

Changes
MATH-677, MATH-743: several changes to the API in the transform package.


Best regards,
Sébastien


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

Re: [graph] Why the Vertex/Edge Interfaces?

[Simone Tripodi]

Hi James,

while it could be true for Vertex, Edge in some case requires
assumptions, such as the Weight so a marker interface is required.

Do you have a proposal to modify current codebase?
TIA!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Fri, Mar 2, 2012 at 2:41 AM, James Carman  wrote:
> Should we not let anything be an edge or a vertex?
>
> -
> 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: [graph] Why the Vertex and Edge interfaces?

[Simone Tripodi]

Hi James!

the email was posted twice because looks like you posted to old
jakarta address :P

The main reason because these interfaces are there, is that when I
started resurrecting it I just opened my Graph book, I started
defining element according to definitions :P

Some already implemented algorithms require specific informations
about edges - specifically WeightedEdges - so while for Vertex a
complete generalization can still be applied, Edge requires some
assumptions at a certain point.

Claudio is aware also about algorithms where weights are associated to
Vertex - he's preparing his PhD research on graphes - maybe he can
show us a more long-vision roadmap and evaluate benefits on
simplifying the design.

Do you have already a proposal how to modify the actual design?
TIA, all the best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Fri, Mar 2, 2012 at 2:45 AM, James Carman  wrote:
> Sorry if this was double-posted.  I think I accidentally sent it from
> my "personal" email account too (which isn't subscribed).
>
> Anyway, shouldn't we just let anything (perhaps restrict it to
> Serializables) be a vertex or an edge?
>
> -
> 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: [graph] Why the Vertex/Edge Interfaces?

[James Carman]

True, the weighted stuff might require an interface, but you could
have a "regular" graph with arbitrary objects representing its edges
and vertices.

On Fri, Mar 2, 2012 at 2:35 AM, Simone Tripodi  wrote:
> Hi James,
>
> while it could be true for Vertex, Edge in some case requires
> assumptions, such as the Weight so a marker interface is required.
>
> Do you have a proposal to modify current codebase?
> TIA!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Fri, Mar 2, 2012 at 2:41 AM, James Carman  wrote:
>> Should we not let anything be an edge or a vertex?
>>
>> -
>> 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

Re: [graph] Why the Vertex and Edge interfaces?

[James Carman]

Yeah, I would say something like this:

public interface Graph
{
...
}

this is assuming you'd want to enforce the serialization stuff.
Otherwise it'd just be Graph

On Fri, Mar 2, 2012 at 2:47 AM, Simone Tripodi  wrote:
> Hi James!
>
> the email was posted twice because looks like you posted to old
> jakarta address :P
>
> The main reason because these interfaces are there, is that when I
> started resurrecting it I just opened my Graph book, I started
> defining element according to definitions :P
>
> Some already implemented algorithms require specific informations
> about edges - specifically WeightedEdges - so while for Vertex a
> complete generalization can still be applied, Edge requires some
> assumptions at a certain point.
>
> Claudio is aware also about algorithms where weights are associated to
> Vertex - he's preparing his PhD research on graphes - maybe he can
> show us a more long-vision roadmap and evaluate benefits on
> simplifying the design.
>
> Do you have already a proposal how to modify the actual design?
> TIA, all the best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Fri, Mar 2, 2012 at 2:45 AM, James Carman  
> wrote:
>> Sorry if this was double-posted.  I think I accidentally sent it from
>> my "personal" email account too (which isn't subscribed).
>>
>> Anyway, shouldn't we just let anything (perhaps restrict it to
>> Serializables) be a vertex or an edge?
>>
>> -
>> 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

Re: [chain] release roadmap

[Simone Tripodi]

Hi Elijah,

great! :) You can take in consideration to include samples in the
maven reactor, so you can safety inherit the chain2 parent pom and
avoiding repeat stuff, have a look at existing thin pom modules :P

Samples will be anyway excluded from the deployment on Nexus, the
`dist` module contains the needed maven-deploy-plugin settings.

TIA for your effort and time!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Fri, Mar 2, 2012 at 7:52 AM, Elijah Zupancic  wrote:
> Hi Simo,
>
> I saw the changes and they look great! Let's see if I can get you a patch
> to get the 2.0 apps examples compiling. They are written to use Java 1.3
> and we need to change the pom to support 1.5. I already have some source
> changes for them, but I am not done with it.
>
> -Elijah
>
> On Thu, Mar 1, 2012 at 8:37 AM, Simone Tripodi 
> wrote:
>
>> Hi Elijah,
>>
>> this is something needed indeed, thanks *a lot*!!!
>>
>> I don't know if you checked out updates, I switched to multi-module
>> project structure, looks like it is complete and I just have to add
>> the /apps in the modules list.
>>
>> Thanks for the hard work, all the best!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Thu, Mar 1, 2012 at 5:33 PM, Elijah Zupancic 
>> wrote:
>> > FYI, I am also updating the examples in the /apps folder.
>> >
>> > -Elijah
>> >
>> > On Mon, Feb 27, 2012 at 12:01 PM, Simone Tripodi
>> >  wrote:
>> >> Hi Elijah,
>> >>
>> >> no needs to learn docbook, the docbook page you see on svn repo is a
>> >> donation from an old book. Deployed documentation is generated from
>> >> /src/site/xdoc sources, the format is an html-alike [1] markup. Just
>> >> run ``mvn site && open target/site/index.html` to see the produced
>> >> documentation.
>> >> HTH!
>> >> -Simo
>> >>
>> >> [1] http://maven.apache.org/doxia/references/xdoc-format.html
>> >>
>> >> http://people.apache.org/~simonetripodi/
>> >> http://simonetripodi.livejournal.com/
>> >> http://twitter.com/simonetripodi
>> >> http://www.99soft.org/
>> >>
>> >>
>> >>
>> >> On Mon, Feb 27, 2012 at 7:32 PM, Elijah Zupancic 
>> wrote:
>> >>> Hi Simo,
>> >>>
>> >>> Here is my comment from the ticket: "My plan is to take this on. I'm
>> >>> just very busy at work right now, so I've been trying to learn docbook
>> >>> format on the bus on my way to and from work. If you want to take on
>> >>> breaking chain into separate modules, that would be much appreciated."
>> >>>
>> >>> -Elijah
>> >>>
>> >>> On Mon, Feb 27, 2012 at 8:58 AM, Simone Tripodi
>> >>>  wrote:
>> 
>>  Hi all guys!
>> 
>>  thanks to Elijah Zupancich's contributions, we now have a fresh new
>>  [chain] on trunk that uses generics. I can have (limited) spare time
>>  to dedicate to [chain] and I would like to put energies on it in order
>>  to have it released ASAP.
>> 
>>  This is my roadmap to have [chain] released in a short time:
>> 
>>   * CHAIN-65
>>   * CHAIN-66
>>   * CHAIN-55
>> 
>>  since some other issues are really old and never fixed, I'd tend to
>>  keep them open and move to release 2.1
>> 
>>  groupId:artifactId:version will be updated to
>>  org.apache.common:commons-chain2:2.0
>> 
>>  Does anyone have objections/suggestions/... ?
>>  TIA, all the best!
>>  -Simo
>> 
>>  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
>> 
>> >>>
>> >>> -
>> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >>> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>>
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

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