date:20120301

On Thu, Mar 1, 2012 at 8:34 AM, Marco Speranza marcospera...@apache.orgwrote:


  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

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
thomas.neidh...@gmail.com wrote:
 On Thu, Mar 1, 2012 at 8:34 AM, Marco Speranza 
 marcospera...@apache.orgwrote:


  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

 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 marco.speranz...@gmail.com

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 
 marcospera...@apache.orgwrote:
 
 
 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)

2012-03-01 Thread Continuum@vmbuild

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=19541projectId=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)

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 contin...@apache.org wrote:
 Online report : 
 http://vmbuild.apache.org/continuum/buildResult.action?buildId=19541projectId=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

On 1 March 2012 12:19,  er...@apache.org wrote:
 Author: erans
 Date: Thu Mar  1 12:19:30 2012
 New Revision: 1295533

 URL: http://svn.apache.org/viewvc?rev=1295533view=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=1295533r1=1295532r2=1295533view=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 @@
   modelVersion4.0.0/modelVersion
   groupIdorg.apache.commons/groupId
   artifactIdcommons-math3/artifactId
 -  version3.0-SNAPSHOT/version
 +  version3.0/version

-1

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

   nameCommons Math/name

   inceptionYear2003/inceptionYear



-
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

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

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
b...@systemoutprintln.de 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

On 1 March 2012 13:12, Gilles Sadowski gil...@harfang.homelinux.org wrote:
 On Thu, Mar 01, 2012 at 12:49:56PM +, sebb wrote:
 On 1 March 2012 12:19,  er...@apache.org wrote:
  Author: erans
  Date: Thu Mar  1 12:19:30 2012
  New Revision: 1295533
 
  URL: http://svn.apache.org/viewvc?rev=1295533view=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=1295533r1=1295532r2=1295533view=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 @@
    modelVersion4.0.0/modelVersion
    groupIdorg.apache.commons/groupId
    artifactIdcommons-math3/artifactId
  -  version3.0-SNAPSHOT/version
  +  version3.0/version

 -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

2012-03-01 Thread 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
b...@systemoutprintln.de  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

On 1 March 2012 14:01, Gilles Sadowski gil...@harfang.homelinux.org wrote:
 On Thu, Mar 01, 2012 at 02:46:33AM +, sebb wrote:
 On 29 February 2012 23:04, Gilles Sadowski gil...@harfang.homelinux.org 
 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) er...@apache.org
  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) er...@apache.org
  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) er...@apache.org
  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 in a way depending on the presence or not of -Prelease 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 gpg.keyname 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

On Thu, Mar 01, 2012 at 02:58:58PM +, sebb wrote:
 On 1 March 2012 13:12, Gilles Sadowski gil...@harfang.homelinux.org wrote:
  On Thu, Mar 01, 2012 at 12:49:56PM +, sebb wrote:
  On 1 March 2012 12:19,  er...@apache.org wrote:
   Author: erans
   Date: Thu Mar  1 12:19:30 2012
   New Revision: 1295533
  
   URL: http://svn.apache.org/viewvc?rev=1295533view=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=1295533r1=1295532r2=1295533view=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 @@
     modelVersion4.0.0/modelVersion
     groupIdorg.apache.commons/groupId
     artifactIdcommons-math3/artifactId
   -  version3.0-SNAPSHOT/version
   +  version3.0/version
 
  -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

On Thu, Mar 01, 2012 at 03:09:41PM +, sebb wrote:
 On 1 March 2012 14:01, Gilles Sadowski gil...@harfang.homelinux.org wrote:
  On Thu, Mar 01, 2012 at 02:46:33AM +, sebb wrote:
  On 29 February 2012 23:04, Gilles Sadowski gil...@harfang.homelinux.org 
  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) er...@apache.org
   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) er...@apache.org
   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) er...@apache.org
   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 in a way depending on the presence or not of -Prelease 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 gpg.keyname 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

2012-03-01 Thread 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

 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
b...@systemoutprintln.de 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
 b...@systemoutprintln.de  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

2012-03-01 Thread 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
simonetrip...@apache.org 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 eli...@zupancic.name 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
 simonetrip...@apache.org 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

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 eli...@zupancic.name wrote:
 FYI, I am also updating the examples in the /apps folder.

 -Elijah

 On Mon, Feb 27, 2012 at 12:01 PM, Simone Tripodi
 simonetrip...@apache.org 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 eli...@zupancic.name 
 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
 simonetrip...@apache.org 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

2012-03-01 Thread 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
b...@systemoutprintln.de  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
b...@systemoutprintln.dewrote:


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:

Re: [Math] New warnings from FindBugs

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

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

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 marcospera...@apache.org
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

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

Ok great! now works 
thanks you!

--
Marco Speranza marcospera...@apache.org
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)

2012-03-01 Thread Continuum@vmbuild

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=19556projectId=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

On 2012-02-29 22:25, sebb wrote:
 On 29 February 2012 21:14, Dennis Lundberg denn...@apache.org 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

On 2012-03-01 06:23, Damjan Jovanovic wrote:
On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg denn...@apache.org 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

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=19556projectId=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

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,  t...@apache.org wrote:
 Author: tn
 Date: Thu Mar  1 17:39:59 2012
 New Revision: 1295694

 URL: http://svn.apache.org/viewvc?rev=1295694view=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=1295694r1=1295693r2=1295694view=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 ) )
             {
                 IteratorV connected = ( graph instanceof DirectedGraph ) ?
 @@ -150,7 +157,6 @@ final class DefaultVisitAlgorithmsSelect
                     if ( !visitedVertices.contains( w ) )
                     {
                         vertexList.addLast( new VertexPairV( 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

2012-03-01 Thread Gary Gregory

On Thu, Mar 1, 2012 at 2:25 PM, Dennis Lundberg denn...@apache.org wrote:

 On 2012-03-01 06:23, Damjan Jovanovic wrote:
  On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg denn...@apache.org
 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=19556projectId=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://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Maven bugs when building Sanselan

2012-03-01 Thread Gary Gregory

On Thu, Mar 1, 2012 at 2:25 PM, Dennis Lundberg denn...@apache.org wrote:

 On 2012-03-01 06:23, Damjan Jovanovic wrote:
  On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg denn...@apache.org
 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=19556projectId=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://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [graph] Doubts on DFS algorithm implementation

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 marcospera...@apache.org wrote:
 Ok great! now works
 thanks you!

 --
 Marco Speranza marcospera...@apache.org
 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

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
b...@systemoutprintln.de 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
 b...@systemoutprintln.de  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
 b...@systemoutprintln.de    wrote:


 Hi,

 I just

Re: Maven bugs when building Sanselan

2012-03-01 Thread Damjan Jovanovic

On Thu, Mar 1, 2012 at 9:25 PM, Dennis Lundberg denn...@apache.org wrote:
On 2012-03-01 06:23, Damjan Jovanovic wrote:
On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg denn...@apache.org 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.

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

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

The error message is:

[ERROR] BUILD FAILURE
[INFO]

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

On 2012-03-01 20:45, Gary Gregory wrote:
On Thu, Mar 1, 2012 at 2:25 PM, Dennis Lundberg denn...@apache.org wrote:

On 2012-03-01 06:23, Damjan Jovanovic wrote:
On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg denn...@apache.org
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.

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

http://vmbuild.apache.org/continuum/buildResult.action?buildId=19556projectId=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

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:

SetV applyingKosarajuSharir( V source );
SetSetV 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

2012-03-01 Thread Gary Gregory

On Thu, Mar 1, 2012 at 3:18 PM, Dennis Lundberg denn...@apache.org wrote:

On 2012-03-01 20:45, Gary Gregory wrote:
On Thu, Mar 1, 2012 at 2:25 PM, Dennis Lundberg denn...@apache.org
wrote:

On 2012-03-01 06:23, Damjan Jovanovic wrote:
On Wed, Feb 29, 2012 at 9:45 PM, Dennis Lundberg denn...@apache.org
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.

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

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

The error message is:

[ERROR] BUILD FAILURE
[INFO]

[INFO] Compilation failure

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! :)

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://goog_1249600977http://bit.ly/ECvg0
Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] New warnings from FindBugs

2012-03-01 Thread 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/

: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,  t...@apache.org wrote:
 Author: tn
 Date: Thu Mar  1 20:27:55 2012
 New Revision: 1295773

 URL: http://svn.apache.org/viewvc?rev=1295773view=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=1295773r1=1295772r2=1295773view=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 SetV applyingKosarajuSharir( V source )
 +    public SetV 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 
 KosarajuSharirVisitHandlerV, E, G( source ) );
 +        final SetV visitedVertices = new HashSetV();
 +        final ListV expandedVertexList = getExpandedVertexList( source, 
 visitedVertices );
 +        final DirectedGraphV, E reverted = new RevertedGraphV, E( graph 
 );
 +
 +        // remove the last element from the expanded vertices list
 +        final V v = expandedVertexList.remove( expandedVertexList.size() - 1 
 );
 +        final SetV sccSet = new HashSetV();
 +        searchRecursive( reverted, v, sccSet, visitedVertices, false );
 +        return sccSet;
 +    }
 +
 +    /**
 +     * {@inheritDoc}
 +     */
 +    public SetSetV applyingKosarajuSharir()
 +    {
 +        final SetV visitedVertices = new HashSetV();
 +        final ListV expandedVertexList = getExpandedVertexList( null, 
 visitedVertices );
 +        final DirectedGraphV, E reverted = new RevertedGraphV, E( graph 
 );

 -        DirectedGraphV, E reverted = new RevertedGraphV, E( graph );
 +        final SetSetV sccs = new HashSetSetV();

 -        // 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 SetV sccSet = new HashSetV();
 +            searchRecursive( reverted, v, sccSet, visitedVertices, false );
 +
 +            // remove all strongly connected components from the expanded 
 list
 +            expandedVertexList.removeAll( sccSet );
 +            sccs.add( sccSet );
 +        }
 +
 +        return sccs;
 +    }
 +
 +    private ListV getExpandedVertexList( final V source, final SetV 
 visitedVertices )
 +    {
 +        final int size = (source != null) ? 13 : graph.getOrder();
 +        final SetV vertices = new HashSetV( 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 ArrayListV expandedVertexList = new ArrayListV();

 -        return null;
 +        int idx = 0;
 +        while ( ! vertices.isEmpty() )
 +        {
 +            // get the next vertex that has not yet been added to the 
 expanded list
 +            final

[configuration] Replace DatabaseConfiguration with version from branch?

2012-03-01 Thread 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

great work :-)

--
Marco Speranza marcospera...@apache.org
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:
 
SetV applyingKosarajuSharir( V source );
SetSetV 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

2012-03-01 Thread 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
b...@systemoutprintln.de  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
b...@systemoutprintln.dewrote:


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?

Re: Maven bugs when building Sanselan

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

2012-03-01 Thread 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

Ciao Marco,

+DirectedMutableWeightedGraphBaseLabeledVertex,
BaseLabeledWeightedEdgeInteger, Integer graph =
+newDirectedMutableWeightedGraph( new
AbstractGraphConnectionBaseLabeledVertex,
BaseLabeledWeightedEdgeInteger()
+{
+@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,  marcospera...@apache.org wrote:
 Author: marcosperanza
 Date: Thu Mar  1 21:51:40 2012
 New Revision: 1295924

 URL: http://svn.apache.org/viewvc?rev=1295924view=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=1295924r1=1295923r2=1295924view=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 @@
   /properties
   body
   release version=0.1 date=201?-??-?? description=First release.
 +    action dev=marcosperanza type=fix issue=SANDBOX-392
 +      Add test for Kosaraju Sharir Algorithm
 +    /action
     action dev=tn type=fix issue=SANDBOX-353
       Provide a Kosaraju-Sharir's algorithm implementation
     /action

 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=1295924r1=1295923r2=1295924view=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 SetV 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 SetV visitedVertices = new HashSetV();
         final ListV expandedVertexList = getExpandedVertexList( source, 
 visitedVertices );
         final DirectedGraphV, E reverted = new RevertedGraphV, E( 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=1295924r1=1295923r2=1295924view=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

Re: [Math] New warnings from FindBugs

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

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)

2012-03-01 Thread Continuum@vmbuild

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=19566projectId=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

Hi.

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

Reading this
---CUT---
server
  idstagingSite/id
  usernamerepouser/username
  !-- other optional elements:
 passwordmy_login_password/password
 privateKey/path/to/identity/privateKey (default is ~/.ssh/id_dsa)
 passphrasemy_key_passphrase/passphrase
  --
/server
---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

 item name=Javadoc (3.0 release) href=apidocs/index.html/
 item name=Javadoc (2.2 release)
   href=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

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

2012-03-01 Thread 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?

2012-03-01 Thread 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

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

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

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

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:

Re: Maven bugs when building Sanselan

2012-03-01 Thread Damjan Jovanovic

On Thu, Mar 1, 2012 at 11:37 PM, Dennis Lundberg denn...@apache.org 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

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 misplaced 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 foo 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 bar 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 datamodel 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 data 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 baz 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]

Re: [Math] New warnings from FindBugs

2012-03-01 Thread 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

2012-03-01 Thread 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 simonetrip...@apache.orgwrote:

 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 eli...@zupancic.name
 wrote:
  FYI, I am also updating the examples in the /apps folder.
 
  -Elijah
 
  On Mon, Feb 27, 2012 at 12:01 PM, Simone Tripodi
  simonetrip...@apache.org 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 eli...@zupancic.name
 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
  simonetrip...@apache.org 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

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

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

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 ja...@carmanconsulting.com 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?

2012-03-01 Thread 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 simonetrip...@apache.org 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 jwcar...@gmail.com 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?

2012-03-01 Thread James Carman

Yeah, I would say something like this:

public interface GraphV extends Serializable,E extends Serializable
{
...
}

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

On Fri, Mar 2, 2012 at 2:47 AM, Simone Tripodi simonetrip...@apache.org 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 ja...@carmanconsulting.com 
 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