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

[Gump]

To whom it may engage...

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

Project commons-vfs2-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 10 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-vfs2-test :  Apache Commons


Full details are available at:

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

That said, some information snippets are provided here.

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



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2-test/gump_work/build_apache-commons_commons-vfs2-test.html
Work Name: build_apache-commons_commons-vfs2-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 mins 1 sec
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/vfs]
M2_HOME: /opt/maven2
-
Tests in error: 
  
testDefaultInstance(org.apache.commons.vfs2.test.FileSystemManagerFactoryTestCase):
 Could not create a file system manager of class 
"org.apache.commons.vfs2.impl.StandardFileSystemManager".
  org.apache.commons.vfs2.PatternFileSelectorTest: Could not create a file 
system manager of class 
"org.apache.commons.vfs2.impl.StandardFileSystemManager".
  org.apache.commons.vfs2.FileTypeSelectorTest: Could not create a file system 
manager of class "org.apache.commons.vfs2.impl.StandardFileSystemManager".
  org.apache.commons.vfs2.FileIteratorTest: Could not create a file system 
manager of class "org.apache.commons.vfs2.impl.StandardFileSystemManager".
  
junit.framework.TestSuite@c75e4fc(org.apache.commons.vfs2.test.CacheTestSuite): 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@7e78fc6(org.apache.commons.vfs2.test.CacheTestSuite): 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
testDelegatingBad(org.apache.commons.vfs2.util.DelegatingFileSystemOptionsBuilderTest):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
testConfiguration(org.apache.commons.vfs2.util.DelegatingFileSystemOptionsBuilderTest):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
testDelegatingGood(org.apache.commons.vfs2.util.DelegatingFileSystemOptionsBuilderTest):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@379e8f17(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@39385660(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@44a613f8(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@40589e56(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@6c69d02b(org.apache.commons.vfs2.provider.ftp.test.FtpProviderTestCase$1):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@50269997(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  org.apache.commons.vfs2.provider.test.FileObjectSortTestCase: Could not 
create a file system manager of class 
"org.apache.commons.vfs2.impl.StandardFileSystemManager".
  
junit.framework.TestSuite@162db19d(org.apac

Re: [chain] Changing from Exception to RuntimeException

[James Carman]

I hate checked exceptions.  +1

On Sat, Mar 3, 2012 at 11:07 PM, Elijah Zupancic  wrote:
> As I've been working on the examples and the documentation for v2 of
> chain, I've noticed that the API for exception handling of Command and
> Chain is clunky.
>
> When executing a command like:
>
>        ProfileContext context = new ProfileContext();
>        Command command = new ProfileCheck();
>
>        try {
>            command.execute(context);
>        }
>        catch (Exception e) {
>            throw new RuntimeException(e);
>        }
>
> The user of chain has to explicitly catch Exception. If the desire was
> to catch the most base error and force the user to deal with it, why
> aren't we using Throwable? Anyways, this design leads to less than
> elegant code and since we will be breaking the API in v2, I would like
> to suggest a different approach.
>
> I suggest that Command and Chain should throw a custom exception class
> called ChainException that inherits from RuntimeException. And in the
> CommandBase, ChainBase we wrap the catch of Exception in this runtime
> exception. Moreover, we would attach to ChainException some optional
> debug information about the Context invoked when the exception was
> encountered. If anyone thinks that this is a good idea, I can whip up
> a patch quickly.
>
> Thanks,
> -Elijah
>
> -
> 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-proxy-test (in module apache-commons) failed

[Gump]

To whom it may engage...

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

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


Full details are available at:

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

That said, some information snippets are provided here.

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



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

Results :

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

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

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

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

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

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

[Gump]

To whom it may engage...

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

Project commons-configuration-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 23 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 47 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.016 sec
Running org.apache.commons.configuration.TestNullCompositeConfiguration
Tests run: 23, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
Running org.apache.commons.configuration.interpol.TestConfigurationInterpolator
Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 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.011 sec
Running org.apache.commons.configuration.interpol.TestConstantLookup
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec
Running org.apache.commons.configuration.TestPropertiesConfigurationLayout
Tests run: 38, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec
Running org.apache.commons.configuration.TestConfigurationConverter
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running org.apache.commons.configuration.TestFileConfiguration
Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.804 sec
Running org.apache.commons.configuration.TestPatternSubtreeConfiguration
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running org.apache.commons.configuration.TestPropertyConverter
Tests run: 28, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec
Running org.apache.commons.configuration.TestConfigurationMap
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running org.apache.commons.configuration.reloading.TestManagedReloadingStrategy
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running 
org.apache.commons.configuration.reloading.TestVFSFileChangedReloadingStrategy
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.013 sec
Running 
org.apache.commons.configuration.reloading.TestFileChangedReloadingStrategy
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.017 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 45 seconds
[INFO] Finished at: Sun Mar 04 06:13:52 UTC 2012
[INFO] Final Memor

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

[Gump]

To whom it may engage...

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

Project commons-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 23 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: 20 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.14 sec
Running org.apache.commons.scxml.issues.Issue64Test
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: somedata
[INFO] SCXMLSemantics - null: *somedata
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:30:21
 and digester match "scxml/datamodel/misplaced"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:36:19
 and digester match "scxml/state/onentry/foo"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:37:22
 and digester match "scxml/state/onentry/bar"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:41:21
 and digester match "scxml/state/transition/datamodel"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:42:41
 and digester match "scxml/state/transition/datamodel/data"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:49:14
 and digester match "scxml/baz"
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: null
[WARN] SimpleErrorReporter - EXPRESSION_ERROR (eval(''*' + dummy'):null): 
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.065 sec

Results :

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

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

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

[chain] Changing from Exception to RuntimeException

[Elijah Zupancic]

As I've been working on the examples and the documentation for v2 of
chain, I've noticed that the API for exception handling of Command and
Chain is clunky.

When executing a command like:

ProfileContext context = new ProfileContext();
Command command = new ProfileCheck();

try {
command.execute(context);
}
catch (Exception e) {
throw new RuntimeException(e);
}

The user of chain has to explicitly catch Exception. If the desire was
to catch the most base error and force the user to deal with it, why
aren't we using Throwable? Anyways, this design leads to less than
elegant code and since we will be breaking the API in v2, I would like
to suggest a different approach.

I suggest that Command and Chain should throw a custom exception class
called ChainException that inherits from RuntimeException. And in the
CommandBase, ChainBase we wrap the catch of Exception in this runtime
exception. Moreover, we would attach to ChainException some optional
debug information about the Context invoked when the exception was
encountered. If anyone thinks that this is a good idea, I can whip up
a patch quickly.

Thanks,
-Elijah

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

Re: [chain] release roadmap

[Elijah Zupancic]

Hi Simo,

I will take a look at the thin pom modules.

Right now, I'm working on editing the cookbook so that it contains
examples that include generics. As part of this, I want to create
another module under apps called cookbook-examples. In side of that
module, I would put the source code used in the cookbook. I'm having
to do this anyways because I need to verify that all of the examples
that I am editing in the cookbook actually work.

Thanks,
-Elijah

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

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

[Gump]

To whom it may engage...

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

Project commons-lang3-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 17 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 20 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 sec
Running org.apache.commons.lang3.text.ExtendedMessageFormatTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.089 sec
Running org.apache.commons.lang3.text.StrSubstitutorTest
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec
Running org.apache.commons.lang3.text.CompositeFormatTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.lang3.text.StrTokenizerTest
Tests run: 55, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.055 sec
Running org.apache.commons.lang3.text.StrBuilderTest
Tests run: 77, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.07 sec
Running org.apache.commons.lang3.text.FormattableUtilsTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
Running org.apache.commons.lang3.StringUtilsStartsEndsWithTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running org.apache.commons.lang3.ArrayUtilsRemoveMultipleTest
Tests run: 55, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.041 sec
Running org.apache.commons.lang3.RandomStringUtilsTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.074 sec
Running org.apache.commons.lang3.StringUtilsTest
Tests run: 83, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.246 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 18 seconds
[INFO] Finished at: Sun Mar 04 03:26:11 UTC 2012
[INFO] Final Memory: 32M/78M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/g

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

[Gump]

To whom it may engage...

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

Project commons-exec-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 7 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 24 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/exec]
M2_HOME: /opt/maven2
-
FOO..
org.apache.commons.exec.ExecuteException: Process exited with an error: 143 
(Exit value: 143)
Process completed in 2012 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
cd: 21: can't cd to ../../../target
invoker.sh --  daemon process was started
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.021 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.026 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.026 ms
Process completed in 2003 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: 72.914 sec <<< 
FAILURE!

Results :

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

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

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

Please refer to 
/srv/gump/public/workspace/apache-commons/exec/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 23 seconds
[INFO] Finished at: Sun Mar 04 02:43:03 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 1104032012, vmgump.apache.org:vmgump:1104032012
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

[VOTE] Release Commons Math 3.0

[Gilles Sadowski]

Hello.

Please review the deliverables for Math 3.0.

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

Site:
  http://people.apache.org/builds/commons/math/3.0/RC2/

Binaries:
  
https://repository.apache.org/content/repositories/orgapachecommons-050/org/apache/commons/commons-math3/3.0/

[ ] +1 Release it.
[ ] +0 Go ahead; I don't care.
[ ] -1 No, do not release it because ...

This vote will close in 72 hours (02:30 GMT 07/03/2012).


Thanks and best regards,
Gilles

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

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

[Gump]

To whom it may engage...

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

Project commons-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 42 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 33 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 [9.995s]
[INFO] Apache Commons Digester :: Core ... SUCCESS [29.308s]
[INFO] Apache Commons Digester :: Annotations Processor .. SUCCESS [2.253s]
[INFO] Commons Digester :: Examples .. SUCCESS [0.559s]
[INFO] Apache Commons Digester :: Examples :: Annotations :: Atom  SUCCESS 
[3.066s]
[INFO] Apache Commons Digester :: Examples :: API :: Address Book  SUCCESS 
[2.002s]
[INFO] Apache Commons Digester :: Examples :: API :: Catalog . SUCCESS [1.832s]
[INFO] Apache Commons Digester :: Examples :: API :: DB Insert  SUCCESS [1.936s]
[INFO] Apache Commons Digester :: Examples :: API :: Document Markup  SUCCESS 
[1.582s]
[INFO] Apache Commons Digester :: Examples :: EDSL :: Atom ... SUCCESS [1.836s]
[INFO] Apache Commons Digester :: Examples :: Plugins :: Pipeline  SUCCESS 
[1.472s]
[INFO] Apache Commons Digester :: Examp

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

[James Carman]

We also need to consider k-partite graphs.  Not all nodes will be of the
same type.

Sent from tablet device.  Please excuse typos and brevity.
On Mar 3, 2012 11:19 AM, "Simone Tripodi"  wrote:

> hola again,
>
> > good observation. My 2 cents: it might still make sense for users to map
> > their existing domain (including "edges") to the graph (e.g. Routers to
> > Vertices and Cables to Edges) and "get it back" as soon as they are done
> > with graph operations (e.g. once they find the shortest path, they
> > automatically have the sequence of Cables they need).
>
> so, at least WeightedEdge is something that still has to exist - what
> is the reason to query the Network to know the Cable capacity?!? Isn't
> it enough getting it directly from the Cable itself?
>
> -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
>
>

Re: DomainValidator in Java on your website

[Christian Grobmeier]

Hello Commons-Fellowers,

this is meant for us

Cheers,
Christian

On Sat, Mar 3, 2012 at 11:41 PM, Nadia Sokolova
 wrote:
> Dear Apache Software Foundation,
>
> I am contacting you in regards to the DomainValidator code in Java that you
> have listed at:
>
> http://svn.apache.org/viewvc/commons/proper/validator/trunk/src/main/java/org/apache/commons/validator/routines/DomainValidator.java?view=markup
>
> The hard coded list of TLDs that you have in the code appears to be out of
> date and does not reflect the total number of TLDs currently delegated in
> the root zone:
>
> http://data.iana.org/TLD/tlds-alpha-by-domain.txt
>
> We encourage you to update the list and also visit this webpage for more
> information:
>
> http://www.icann.org/en/topics/tld-acceptance
>
> If you have any questions or comments, please contact me.
>
> Thank you,
>
> Nadia Sokolova
> ICANN
>
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: [lang] test failures

[Gary Gregory]

You're right! The build is OK with Java 6, but not 7.

Thank you!
Gary

On Sat, Mar 3, 2012 at 1:42 PM, Benedikt Ritter wrote:

> Hi Gary,
>
> that somehow reminds of a problem we had in BeanUtils2 (see
> http://markmail.org/thread/**obtmhywxxeo2ykp7).
> Some tests were failing with my configuration, while they passed on Simos
> machine. The problem was, that I'm using Java 7 and that seems to cause
> problems with reflective operations on arrays.
>
> I would suggest that you at first make sure, that maven and eclipse are
> using the same Java version. And that can be a bit tricky, if m2e mixes
> some addition spice into you dev-setup-soup. There are several
> configurations that come into play:
>
> - the jre eclipse is startet with
> - the jdk the workspace uses as default
> - the jdk maven uses
> - the jdk m2e starts maven with
>
> HTH,
> Benedikt
>
> Am 03.03.2012 19:33, schrieb Gary Gregory:
>
>  Hi All:
>>
>> Odd: These pass in Eclipse but fail from Maven...
>>
>> Failed tests:
>> testReflectionFloatArrayArray(**org.apache.commons.lang3.**
>> builder.ToStringBuilderTest)
>>
>> testReflectionDoubleArrayArray**(org.apache.commons.lang3.**
>> builder.ToStringBuilderTest)
>>
>> testReflectionBooleanArrayArra**y(org.apache.commons.lang3.**
>> builder.ToStringBuilderTest)
>>
>> testReflectionHierarchyArrayLi**st(org.apache.commons.lang3.**
>> builder.ToStringBuilderTest)
>>
>> testReflectionArrayCycleLevel2**(org.apache.commons.lang3.**
>> builder.ToStringBuilderTest)
>>
>> testReflectionArrayArrayCycle(**org.apache.commons.lang3.**
>> builder.ToStringBuilderTest)
>>
>> testSimpleReflectionObjectCycl**e(org.apache.commons.lang3.**
>> builder.ToStringBuilderTest)
>>
>> testSelfInstanceVarReflectionO**bjectCycle(org.apache.commons.**
>> lang3.builder.**ToStringBuilderTest)
>>
>> testSelfInstanceTwoVarsReflect**ionObjectCycle(org.apache.**
>> commons.lang3.builder.**ToStringBuilderTest)
>>
>> testReflectionArrayAndObjectCy**cle(org.apache.commons.lang3.**
>> builder.ToStringBuilderTest)
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [lang] test failures

[Benedikt Ritter]

Hi Gary,

that somehow reminds of a problem we had in BeanUtils2 (see 
http://markmail.org/thread/obtmhywxxeo2ykp7). Some tests were failing 
with my configuration, while they passed on Simos machine. The problem 
was, that I'm using Java 7 and that seems to cause problems with 
reflective operations on arrays.


I would suggest that you at first make sure, that maven and eclipse are 
using the same Java version. And that can be a bit tricky, if m2e mixes 
some addition spice into you dev-setup-soup. There are several 
configurations that come into play:


- the jre eclipse is startet with
- the jdk the workspace uses as default
- the jdk maven uses
- the jdk m2e starts maven with

HTH,
Benedikt

Am 03.03.2012 19:33, schrieb Gary Gregory:

Hi All:

Odd: These pass in Eclipse but fail from Maven...

Failed tests:
testReflectionFloatArrayArray(org.apache.commons.lang3.builder.ToStringBuilderTest)

testReflectionDoubleArrayArray(org.apache.commons.lang3.builder.ToStringBuilderTest)

testReflectionBooleanArrayArray(org.apache.commons.lang3.builder.ToStringBuilderTest)

testReflectionHierarchyArrayList(org.apache.commons.lang3.builder.ToStringBuilderTest)

testReflectionArrayCycleLevel2(org.apache.commons.lang3.builder.ToStringBuilderTest)

testReflectionArrayArrayCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)

testSimpleReflectionObjectCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)

testSelfInstanceVarReflectionObjectCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)

testSelfInstanceTwoVarsReflectionObjectCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)

testReflectionArrayAndObjectCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)




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

[lang] test failures

[Gary Gregory]

Hi All:

Odd: These pass in Eclipse but fail from Maven...

Failed tests:
testReflectionFloatArrayArray(org.apache.commons.lang3.builder.ToStringBuilderTest)

testReflectionDoubleArrayArray(org.apache.commons.lang3.builder.ToStringBuilderTest)

testReflectionBooleanArrayArray(org.apache.commons.lang3.builder.ToStringBuilderTest)

testReflectionHierarchyArrayList(org.apache.commons.lang3.builder.ToStringBuilderTest)

testReflectionArrayCycleLevel2(org.apache.commons.lang3.builder.ToStringBuilderTest)

testReflectionArrayArrayCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)

testSimpleReflectionObjectCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)

testSelfInstanceVarReflectionObjectCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)

testSelfInstanceTwoVarsReflectionObjectCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)

testReflectionArrayAndObjectCycle(org.apache.commons.lang3.builder.ToStringBuilderTest)

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Graph] Test problems after last commit

[Simone Tripodi]

Hi again Marco,

I though once again on this and maybe having a synchronized Graph
would be different than having a ConcurrentGraph, like
Collections.synchronizedMap() and ConcurrentHashMap, so my suggestion
is keeping the synchronized proxy as they are AND provide Concurrent*
version of actual graphs. I would implement these adapters in a proper
`concurrent` package. Does it make sense to you?

Feel free to fill an issue and assign to yourself if you want to work on it!

best,
-Simo

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



On Sat, Mar 3, 2012 at 3:53 PM, Simone Tripodi  wrote:
> Hi Marco,
>
> yes I know it, what doesn't convince me is not the problem, but the
> solution. Have a look at Collections.* source code to see how  this
> problem is fixed in synchronizedMap.
>
> Anyway that confirms that maybe proxies are not the best to handle
> that situation - unless James has a solution (he's our proxy expert,
> just for the record) - and we have to manage read/write locks as James
> suggested - that it would be a nice addition
>
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sat, Mar 3, 2012 at 3:29 PM, Marco Speranza  
> wrote:
>> Ciao
>>
>>
>>> rue, but *all* methods executions (synchronized and not) are
>>> performed inside the handler, contained in the proxy instance anyway.
>>>
>>> So an user cannot use the same "lock"  in order to synchronize a block
>>> like this:
>>
>> Let's give you an example.
>>
>> here is our handler implementation, and imagine that the 'lock' is not 
>> export outside:
>>
>> ===
>> synchronized ( this.lock )
>> {
>>        try
>>        {
>>                return method.invoke( checkedToBeSynchronized, args );
>>        }
>>        catch ( InvocationTargetException e )
>>        {
>>                throw e.getTargetException();
>>        }
>> }
>> ===
>>
>> here is a possible user implementation:
>>
>> - Main class create a synchronized graph instance:
>>
>>    MutableGraph g = CommonsGraph.synchronize( new UndirectMutableGraph );
>>
>> - Thread 1 loops over the vertices:
>> synchronized(g) {
>>    for ( BaseLabeledVertex v2 : g.getVertices() )
>>    {
>>        // do somethings
>>    }
>>  }
>>
>> - Thread 2, insert a new vertex:
>> for ( int i = start; i < end; i++ )
>> {
>>        BaseLabeledVertex v = new BaseLabeledVertex( valueOf( i ) );
>>        g.addVertex( v );
>> }
>>
>>
>> in that example thread, probably you would have a 
>> ConcurrentModificationException because:
>>
>> 1) Therad 1 uses a lock 'g' for the Iterator returned by g.getVertices()
>> 2) Thread 2 uses its own lock 'this.lock' stored into Handler class.
>>
>> in this situation our data structure is *not* thread safe.
>>
>> The only way to synchronize the data structure is that:
>>
>> -Thread 2:
>> for ( int i = start; i < end; i++ )
>> {
>>   synchronized(g) {
>>          BaseLabeledVertex v = new BaseLabeledVertex( valueOf( i ) );
>>          g.addVertex( v );
>>  }
>> }
>>
>> but this IMHO  is a wrong way to fix the problem, and moreover with this 
>> workaround we don't need to
>> use CommonGraph.synchronize() method, isn't it?
>>
>>
>>> I have not clear which benefit you want to obtain with that - looks at
>>> Collections#synchronized* methods and see that the separation of
>>> concerns in clear.
>>
>> you are right maybe use an external lock is not useful.
>>
>>
>>> Sure that we can, the only issue we have is that GroboUtils is not in
>>> the central repo, adding the external repository would make not easy
>>> having the component released.
>>
>> unfortunately GroboUtil was the only lib that I found yesterday. Any 
>> suggestions to some other libs?
>>
>> all the best  ;-)
>>
>> --
>> Marco Speranza 
>> Google Code: http://code.google.com/u/marco.speranza79/
>>
>> Il giorno 03/mar/2012, alle ore 14:34, Simone Tripodi ha scritto:
>>
>>> Hola Marco,
>>>
 my doubt is this:  opening a synchronized block into handler 
 implementation on 'this',  in my opinion is not enough, because the method 
 "CommonsGraph.synchronize()" returns a instance of the Proxy and not an 
 instance of handler.
>>>
>>> true, but *all* methods executions (synchronized and not) are
>>> performed inside the handler, contained in the proxy instance anyway.
>>>
>>> So an user cannot use the same "lock"  in order to synchronize a block
>>> like this:
>>>
>>> 
>>> Graph g = CommonsGraph.synchronize(g_);
>>>   ...
>>> synchronized(g) {
>>>     for ( BaseLabeledVertex v2 : g.getVertices() )
>>>     {
>>>         // do somethings
>>>     }
>>> }
>>> 
>>>
>>> I am not sure we can do much more of what we've already done, for that
>>> situation: the snippet below mixes the *data structure*
>>> synchronization with the business logic performed outside.
>>>
 So my idea is to open synchronized block insi

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

[Simone Tripodi]

hola again,

> good observation. My 2 cents: it might still make sense for users to map
> their existing domain (including "edges") to the graph (e.g. Routers to
> Vertices and Cables to Edges) and "get it back" as soon as they are done
> with graph operations (e.g. once they find the shortest path, they
> automatically have the sequence of Cables they need).

so, at least WeightedEdge is something that still has to exist - what
is the reason to query the Network to know the Cable capacity?!? Isn't
it enough getting it directly from the Cable itself?

-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

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

[Simone Tripodi]

please follow up code modifications on SANDBOX-404

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



On Sat, Mar 3, 2012 at 5:11 PM, Claudio Squarcella
 wrote:
> Hi Simone,
>
> answering briefly below:
>
>
>> Vertex is something we can safety drop because we
>> know its nature at priori, markers are unnecessary.This is fine.
>
>
> +1.
>
>
>> what is the sense, at that point, on keeping the Edge?!! It would be
>> more than enough to know which is the Head and which is the Tail in
>> the Edge to get the W!
>
>
> good observation. My 2 cents: it might still make sense for users to map
> their existing domain (including "edges") to the graph (e.g. Routers to
> Vertices and Cables to Edges) and "get it back" as soon as they are done
> with graph operations (e.g. once they find the shortest path, they
> automatically have the sequence of Cables they need).
>
>> maybe because they implement OrderedMonoid? :)
>> [...]
>>
>> how much would Addition and Multiplication interface differ each other?
>> [...]
>> that would be fine, what is not clear is that Monoids expose the same
>> interface, so *Operations class implementation canot declare same
>> method multiple times
>
>
> answering all the above: that is another reason why I would like our current
> Monoid to be called Addition (and Addition#sum instead of Monoid#append,
> etc), so that it is semantically clearer and later we can introduce
> Multiplication as a completely independent interface.
>
>
>> enough talk IMHO, time to code and make concrete proposals
>
>
> Sure!
> I'll play with weights first, because I already know what I want to do.
> As for Vertex/Edge markers I still see valuable feedback coming in, so I'll
> wait a bit.
>
> Branching is ok -- especially for the second part which sounds like a real
> earthquake ;)
>
>
> Ciao,
> 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
>

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

[Claudio Squarcella]

Hi Simone,

answering briefly below:


Vertex is something we can safety drop because we
know its nature at priori, markers are unnecessary.This is fine.


+1.


what is the sense, at that point, on keeping the Edge?!! It would be
more than enough to know which is the Head and which is the Tail in
the Edge to get the W!


good observation. My 2 cents: it might still make sense for users to map 
their existing domain (including "edges") to the graph (e.g. Routers to 
Vertices and Cables to Edges) and "get it back" as soon as they are done 
with graph operations (e.g. once they find the shortest path, they 
automatically have the sequence of Cables they need).



maybe because they implement OrderedMonoid? :)
[...]
how much would Addition and Multiplication interface differ each other?
[...]
that would be fine, what is not clear is that Monoids expose the same
interface, so *Operations class implementation canot declare same
method multiple times


answering all the above: that is another reason why I would like our 
current Monoid to be called Addition (and Addition#sum instead of 
Monoid#append, etc), so that it is semantically clearer and later we can 
introduce Multiplication as a completely independent interface.



enough talk IMHO, time to code and make concrete proposals


Sure!
I'll play with weights first, because I already know what I want to do.
As for Vertex/Edge markers I still see valuable feedback coming in, so 
I'll wait a bit.


Branching is ok -- especially for the second part which sounds like a 
real earthquake ;)


Ciao,
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: [graph] Why the Vertex and Edge interfaces?

[Simone Tripodi]

Hi Oliver,

of course that you can, everybody here is invited on giving his
contribution! And every contribution is always much more than
appreciated :)

best,
-Simo

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



On Sat, Mar 3, 2012 at 5:03 PM, Oliver Heger
 wrote:
> Hi, if I am allowed to throw in some (unfinished) thoughts into this
> discussion:
>
> My preference would also be to keep the actual graph data structure lean and
> simple. As James pointed out, if algorithms need additional information, a
> function from the vertex/edge type to the target type is required. This
> could indeed be implemented in a very generic way using a functor interface
> (maybe with an underlying map as a default implementation).
>
> The advantage over a pack of interfaces as I see it is that such functors
> could be added dynamically to a graph. Thus it could be adapted for the
> execution of different algorithms at runtime.
>
> Just my 2 cents.
> Oliver
>
> Am 03.03.2012 16:47, schrieb Simone Tripodi:
>
>> Cloud.io,
>>
>>> back to James' first email: any type could be immediately used as
>>> edge/vertex without wrappers, while specific data related to the domain
>>> of
>>> graphs (weights, labels) would be handled separately. I actually think
>>> this
>>> is useful: back to my days of "DIY Java graphs" I implemented something
>>> similar to what we have now, just to think every time: "why should I wrap
>>> my
>>> objects with these markers? I already know my Router is a Vertex in the
>>> graph..."
>>
>>
>> I already showed be open on dropping elements, do I have to copy my
>> first reply as well so we start again? :)
>> OK, I started collecting various thoughts and trying to converge them
>> to a common path: Vertex is something we can safety drop because we
>> know its nature at priori, markers are unnecessary.This is fine.
>>
>>>
>>> Here's the way I see it. A Graph  implementing HasWeightedEdges
>>> would
>>> have something like this inside:
>>>
>>> Map  edgeWeights = new HashMap();
>>>
>>> [... populate map, other methods, etc ...]
>>>
>>> // implementing HasWeightedEdges#getEdgeWeight
>>> public W getEdgeWeight(E edge)
>>> {
>>>    [... check null etc...]
>>>    return edgeWeights.get(edge);
>>>
>>> }
>>>
>>
>> what is the sense, at that point, on keeping the Edge?!! It would be
>> more than enough to know which is the Head and which is the Tail in
>> the Edge to get the W!
>>
>>> then let's find a better name, but why *OrderedMonoid?
>>
>>
>> maybe because they implement OrderedMonoid? :)
>>
>>> Assume we replace the
>>> whole set of current interfaces (see my comment to the next paragraph
>>> below)
>>> with just Addition and Comparable (the latter already exists of course).
>>> There is no need to create another interface to merge the two
>>> (ComparableAddition? OrderedAddition?). Then we have:
>>>
>>
>> how much would Addition and Multiplication interface differ each other?
>>
>>> public class DoubleWeightOperations
>>>    implements Addition, Comparator
>>> {
>>>    [...]
>>> }
>>>
>>> I would not rename the class to DoubleWeightAddition or even
>>> DoubleWeightComparableAddition. What if later we need to e.g. add a
>>> function
>>> that normalizes weights by some factor, or returns the reciprocal of a
>>> weight, etc? With the above code it would suffice to add new interfaces:
>>>
>>> public class DoubleWeightOperations
>>>    implements Addition, Comparator, Normalization, Reciprocal
>>> {
>>>    [...]
>>>
>>> }
>>>
>>>
>>
>> that would be fine, what is not clear is that Monoids expose the same
>> interface, so *Operations class implementation canot declare same
>> method multiple times
>>
>>>
>>> That is fine for me. I simply followed pure theory while implementing
>>> that
>>> and used all possible granularity.
>>
>>
>> questionable, that is why we are still speaking about it
>>
>>> Now looking at our implementations I
>>> think it is save enough to even merge Zero, Semigroup and Monoid (so
>>> that's
>>> one step further than your example below) and call the result Addition so
>>> that its role is clear to everybody. Does that sound good? :)
>>
>>
>> Sounds more than good, it is what I already proposed messages ago:
>>
>>> Zero, name of an element, contains `zero` method to get the zero (it
>>> is still confusing to me), Monoid  extends Zero and Semigroup - given
>>> the use inside graph math, Zero#zero and Semigroup#append can be moved
>>> directly to Monoid and rename it as WeightOperation
>>
>>
>> despite the rename, I still like the Monoid :P
>>
>> enough talk IMHO, time to code and make concrete proposals
>>
>> best,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Sat, Mar 3, 2012 at 2:58 PM, Claudio Squarcella
>>   wrote:
>>>
>>> Hi,
>>>
>>>
 Apologize but I still don't understand 

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

[Oliver Heger]

Hi, if I am allowed to throw in some (unfinished) thoughts into this 
discussion:


My preference would also be to keep the actual graph data structure lean 
and simple. As James pointed out, if algorithms need additional 
information, a function from the vertex/edge type to the target type is 
required. This could indeed be implemented in a very generic way using a 
functor interface (maybe with an underlying map as a default 
implementation).


The advantage over a pack of interfaces as I see it is that such 
functors could be added dynamically to a graph. Thus it could be adapted 
for the execution of different algorithms at runtime.


Just my 2 cents.
Oliver

Am 03.03.2012 16:47, schrieb Simone Tripodi:

Cloud.io,


back to James' first email: any type could be immediately used as
edge/vertex without wrappers, while specific data related to the domain of
graphs (weights, labels) would be handled separately. I actually think this
is useful: back to my days of "DIY Java graphs" I implemented something
similar to what we have now, just to think every time: "why should I wrap my
objects with these markers? I already know my Router is a Vertex in the
graph..."


I already showed be open on dropping elements, do I have to copy my
first reply as well so we start again? :)
OK, I started collecting various thoughts and trying to converge them
to a common path: Vertex is something we can safety drop because we
know its nature at priori, markers are unnecessary.This is fine.



Here's the way I see it. A Graph  implementing HasWeightedEdges would
have something like this inside:

Map  edgeWeights = new HashMap();

[... populate map, other methods, etc ...]

// implementing HasWeightedEdges#getEdgeWeight
public W getEdgeWeight(E edge)
{
[... check null etc...]
return edgeWeights.get(edge);

}



what is the sense, at that point, on keeping the Edge?!! It would be
more than enough to know which is the Head and which is the Tail in
the Edge to get the W!


then let's find a better name, but why *OrderedMonoid?


maybe because they implement OrderedMonoid? :)


Assume we replace the
whole set of current interfaces (see my comment to the next paragraph below)
with just Addition and Comparable (the latter already exists of course).
There is no need to create another interface to merge the two
(ComparableAddition? OrderedAddition?). Then we have:



how much would Addition and Multiplication interface differ each other?


public class DoubleWeightOperations
implements Addition, Comparator
{
[...]
}

I would not rename the class to DoubleWeightAddition or even
DoubleWeightComparableAddition. What if later we need to e.g. add a function
that normalizes weights by some factor, or returns the reciprocal of a
weight, etc? With the above code it would suffice to add new interfaces:

public class DoubleWeightOperations
implements Addition, Comparator, Normalization, Reciprocal
{
[...]

}




that would be fine, what is not clear is that Monoids expose the same
interface, so *Operations class implementation canot declare same
method multiple times



That is fine for me. I simply followed pure theory while implementing that
and used all possible granularity.


questionable, that is why we are still speaking about it


Now looking at our implementations I
think it is save enough to even merge Zero, Semigroup and Monoid (so that's
one step further than your example below) and call the result Addition so
that its role is clear to everybody. Does that sound good? :)


Sounds more than good, it is what I already proposed messages ago:


Zero, name of an element, contains `zero` method to get the zero (it
is still confusing to me), Monoid  extends Zero and Semigroup - given
the use inside graph math, Zero#zero and Semigroup#append can be moved
directly to Monoid and rename it as WeightOperation


despite the rename, I still like the Monoid :P

enough talk IMHO, time to code and make concrete proposals

best,
-Simo

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



On Sat, Mar 3, 2012 at 2:58 PM, Claudio Squarcella
  wrote:

Hi,



Apologize but I still don't understand what the benefit is on storing
nodes/arcs data in the Graph data structure



back to James' first email: any type could be immediately used as
edge/vertex without wrappers, while specific data related to the domain of
graphs (weights, labels) would be handled separately. I actually think this
is useful: back to my days of "DIY Java graphs" I implemented something
similar to what we have now, just to think every time: "why should I wrap my
objects with these markers? I already know my Router is a Vertex in the
graph..."



- sounds to me like a
Collectionwhere, to know the int value of its elements, have
to query the data structure, i.e.

CollectionintegerCollection = ...;
for ( Integer ptr : integerCollection )
{
 int value = integerCollection.ge

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

[Simone Tripodi]

+1 for branches!
-Simo

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



On Sat, Mar 3, 2012 at 5:01 PM, James Carman
 wrote:
> Yes code will speak volumes.  Perhaps a couple proposal branches if we have
> incompatible ideas?
> On Mar 3, 2012 10:47 AM, "Simone Tripodi"  wrote:
>
>> Cloud.io,
>>
>> > back to James' first email: any type could be immediately used as
>> > edge/vertex without wrappers, while specific data related to the domain
>> of
>> > graphs (weights, labels) would be handled separately. I actually think
>> this
>> > is useful: back to my days of "DIY Java graphs" I implemented something
>> > similar to what we have now, just to think every time: "why should I
>> wrap my
>> > objects with these markers? I already know my Router is a Vertex in the
>> > graph..."
>>
>> I already showed be open on dropping elements, do I have to copy my
>> first reply as well so we start again? :)
>> OK, I started collecting various thoughts and trying to converge them
>> to a common path: Vertex is something we can safety drop because we
>> know its nature at priori, markers are unnecessary.This is fine.
>>
>> >
>> > Here's the way I see it. A Graph implementing HasWeightedEdges would
>> > have something like this inside:
>> >
>> > Map edgeWeights = new HashMap();
>> >
>> > [... populate map, other methods, etc ...]
>> >
>> > // implementing HasWeightedEdges#getEdgeWeight
>> > public W getEdgeWeight(E edge)
>> > {
>> >    [... check null etc...]
>> >    return edgeWeights.get(edge);
>> >
>> > }
>> >
>>
>> what is the sense, at that point, on keeping the Edge?!! It would be
>> more than enough to know which is the Head and which is the Tail in
>> the Edge to get the W!
>>
>> > then let's find a better name, but why *OrderedMonoid?
>>
>> maybe because they implement OrderedMonoid? :)
>>
>> > Assume we replace the
>> > whole set of current interfaces (see my comment to the next paragraph
>> below)
>> > with just Addition and Comparable (the latter already exists of course).
>> > There is no need to create another interface to merge the two
>> > (ComparableAddition? OrderedAddition?). Then we have:
>> >
>>
>> how much would Addition and Multiplication interface differ each other?
>>
>> > public class DoubleWeightOperations
>> >    implements Addition, Comparator
>> > {
>> >    [...]
>> > }
>> >
>> > I would not rename the class to DoubleWeightAddition or even
>> > DoubleWeightComparableAddition. What if later we need to e.g. add a
>> function
>> > that normalizes weights by some factor, or returns the reciprocal of a
>> > weight, etc? With the above code it would suffice to add new interfaces:
>> >
>> > public class DoubleWeightOperations
>> >    implements Addition, Comparator, Normalization, Reciprocal
>> > {
>> >    [...]
>> >
>> > }
>> >
>> >
>>
>> that would be fine, what is not clear is that Monoids expose the same
>> interface, so *Operations class implementation canot declare same
>> method multiple times
>>
>> >
>> > That is fine for me. I simply followed pure theory while implementing
>> that
>> > and used all possible granularity.
>>
>> questionable, that is why we are still speaking about it
>>
>> > Now looking at our implementations I
>> > think it is save enough to even merge Zero, Semigroup and Monoid (so
>> that's
>> > one step further than your example below) and call the result Addition so
>> > that its role is clear to everybody. Does that sound good? :)
>>
>> Sounds more than good, it is what I already proposed messages ago:
>>
>> > Zero, name of an element, contains `zero` method to get the zero (it
>> > is still confusing to me), Monoid  extends Zero and Semigroup - given
>> > the use inside graph math, Zero#zero and Semigroup#append can be moved
>> > directly to Monoid and rename it as WeightOperation
>>
>> despite the rename, I still like the Monoid :P
>>
>> enough talk IMHO, time to code and make concrete proposals
>>
>> best,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Sat, Mar 3, 2012 at 2:58 PM, Claudio Squarcella
>>  wrote:
>> > Hi,
>> >
>> >
>> >> Apologize but I still don't understand what the benefit is on storing
>> >> nodes/arcs data in the Graph data structure
>> >
>> >
>> > back to James' first email: any type could be immediately used as
>> > edge/vertex without wrappers, while specific data related to the domain
>> of
>> > graphs (weights, labels) would be handled separately. I actually think
>> this
>> > is useful: back to my days of "DIY Java graphs" I implemented something
>> > similar to what we have now, just to think every time: "why should I
>> wrap my
>> > objects with these markers? I already know my Router is a Vertex in the
>> > graph..."
>> >
>> >
>> >> - sounds to me like a
>> >> Collection  where, to know the int value of its elements, have
>> >> 

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

[James Carman]

Yes code will speak volumes.  Perhaps a couple proposal branches if we have
incompatible ideas?
On Mar 3, 2012 10:47 AM, "Simone Tripodi"  wrote:

> Cloud.io,
>
> > back to James' first email: any type could be immediately used as
> > edge/vertex without wrappers, while specific data related to the domain
> of
> > graphs (weights, labels) would be handled separately. I actually think
> this
> > is useful: back to my days of "DIY Java graphs" I implemented something
> > similar to what we have now, just to think every time: "why should I
> wrap my
> > objects with these markers? I already know my Router is a Vertex in the
> > graph..."
>
> I already showed be open on dropping elements, do I have to copy my
> first reply as well so we start again? :)
> OK, I started collecting various thoughts and trying to converge them
> to a common path: Vertex is something we can safety drop because we
> know its nature at priori, markers are unnecessary.This is fine.
>
> >
> > Here's the way I see it. A Graph implementing HasWeightedEdges would
> > have something like this inside:
> >
> > Map edgeWeights = new HashMap();
> >
> > [... populate map, other methods, etc ...]
> >
> > // implementing HasWeightedEdges#getEdgeWeight
> > public W getEdgeWeight(E edge)
> > {
> >[... check null etc...]
> >return edgeWeights.get(edge);
> >
> > }
> >
>
> what is the sense, at that point, on keeping the Edge?!! It would be
> more than enough to know which is the Head and which is the Tail in
> the Edge to get the W!
>
> > then let's find a better name, but why *OrderedMonoid?
>
> maybe because they implement OrderedMonoid? :)
>
> > Assume we replace the
> > whole set of current interfaces (see my comment to the next paragraph
> below)
> > with just Addition and Comparable (the latter already exists of course).
> > There is no need to create another interface to merge the two
> > (ComparableAddition? OrderedAddition?). Then we have:
> >
>
> how much would Addition and Multiplication interface differ each other?
>
> > public class DoubleWeightOperations
> >implements Addition, Comparator
> > {
> >[...]
> > }
> >
> > I would not rename the class to DoubleWeightAddition or even
> > DoubleWeightComparableAddition. What if later we need to e.g. add a
> function
> > that normalizes weights by some factor, or returns the reciprocal of a
> > weight, etc? With the above code it would suffice to add new interfaces:
> >
> > public class DoubleWeightOperations
> >implements Addition, Comparator, Normalization, Reciprocal
> > {
> >[...]
> >
> > }
> >
> >
>
> that would be fine, what is not clear is that Monoids expose the same
> interface, so *Operations class implementation canot declare same
> method multiple times
>
> >
> > That is fine for me. I simply followed pure theory while implementing
> that
> > and used all possible granularity.
>
> questionable, that is why we are still speaking about it
>
> > Now looking at our implementations I
> > think it is save enough to even merge Zero, Semigroup and Monoid (so
> that's
> > one step further than your example below) and call the result Addition so
> > that its role is clear to everybody. Does that sound good? :)
>
> Sounds more than good, it is what I already proposed messages ago:
>
> > Zero, name of an element, contains `zero` method to get the zero (it
> > is still confusing to me), Monoid  extends Zero and Semigroup - given
> > the use inside graph math, Zero#zero and Semigroup#append can be moved
> > directly to Monoid and rename it as WeightOperation
>
> despite the rename, I still like the Monoid :P
>
> enough talk IMHO, time to code and make concrete proposals
>
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sat, Mar 3, 2012 at 2:58 PM, Claudio Squarcella
>  wrote:
> > Hi,
> >
> >
> >> Apologize but I still don't understand what the benefit is on storing
> >> nodes/arcs data in the Graph data structure
> >
> >
> > back to James' first email: any type could be immediately used as
> > edge/vertex without wrappers, while specific data related to the domain
> of
> > graphs (weights, labels) would be handled separately. I actually think
> this
> > is useful: back to my days of "DIY Java graphs" I implemented something
> > similar to what we have now, just to think every time: "why should I
> wrap my
> > objects with these markers? I already know my Router is a Vertex in the
> > graph..."
> >
> >
> >> - sounds to me like a
> >> Collection  where, to know the int value of its elements, have
> >> to query the data structure, i.e.
> >>
> >> Collection  integerCollection = ...;
> >> for ( Integer ptr : integerCollection )
> >> {
> >> int value = integerCollection.getInt( ptr );
> >> }
> >>
> >> It is weird to me even reading it.
> >>
> >> When I started modeling Graph, I had collections in mind - above all
> >> to simplify its adoption - I would b

Re: svn commit: r1296625 - /commons/sandbox/graph/trunk/checkstyle.xml

[Simone Tripodi]

Hi Thomas,

sorry for the misunderstanding :(

If it helps, I can point you to
 that
is the Eclipse settings.

best and have a nice WE,
-Simo

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



On Sat, Mar 3, 2012 at 4:02 PM, Thomas Neidhart
 wrote:
> On 03/03/2012 03:55 PM, Simone Tripodi wrote:
>> just ro make it clear: nobody vetoed it - did someone expressed a -1?
>> - I just asked you to discuss it first on ML and rollback *pom*
>> settings.
>
> ok, then I misinterpreted your last post.
>
> Anyway, I did not do any changes in the pom itself, so nothing to
> rollback there. The reason to include the file in the first place was to
> simplify the eclipse project setup, but I am also fine with the current
> solution.
>
> 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] Why the Vertex and Edge interfaces?

[Simone Tripodi]

Cloud.io,

> back to James' first email: any type could be immediately used as
> edge/vertex without wrappers, while specific data related to the domain of
> graphs (weights, labels) would be handled separately. I actually think this
> is useful: back to my days of "DIY Java graphs" I implemented something
> similar to what we have now, just to think every time: "why should I wrap my
> objects with these markers? I already know my Router is a Vertex in the
> graph..."

I already showed be open on dropping elements, do I have to copy my
first reply as well so we start again? :)
OK, I started collecting various thoughts and trying to converge them
to a common path: Vertex is something we can safety drop because we
know its nature at priori, markers are unnecessary.This is fine.

>
> Here's the way I see it. A Graph implementing HasWeightedEdges would
> have something like this inside:
>
> Map edgeWeights = new HashMap();
>
> [... populate map, other methods, etc ...]
>
> // implementing HasWeightedEdges#getEdgeWeight
> public W getEdgeWeight(E edge)
> {
>    [... check null etc...]
>    return edgeWeights.get(edge);
>
> }
>

what is the sense, at that point, on keeping the Edge?!! It would be
more than enough to know which is the Head and which is the Tail in
the Edge to get the W!

> then let's find a better name, but why *OrderedMonoid?

maybe because they implement OrderedMonoid? :)

> Assume we replace the
> whole set of current interfaces (see my comment to the next paragraph below)
> with just Addition and Comparable (the latter already exists of course).
> There is no need to create another interface to merge the two
> (ComparableAddition? OrderedAddition?). Then we have:
>

how much would Addition and Multiplication interface differ each other?

> public class DoubleWeightOperations
>    implements Addition, Comparator
> {
>    [...]
> }
>
> I would not rename the class to DoubleWeightAddition or even
> DoubleWeightComparableAddition. What if later we need to e.g. add a function
> that normalizes weights by some factor, or returns the reciprocal of a
> weight, etc? With the above code it would suffice to add new interfaces:
>
> public class DoubleWeightOperations
>    implements Addition, Comparator, Normalization, Reciprocal
> {
>    [...]
>
> }
>
>

that would be fine, what is not clear is that Monoids expose the same
interface, so *Operations class implementation canot declare same
method multiple times

>
> That is fine for me. I simply followed pure theory while implementing that
> and used all possible granularity.

questionable, that is why we are still speaking about it

> Now looking at our implementations I
> think it is save enough to even merge Zero, Semigroup and Monoid (so that's
> one step further than your example below) and call the result Addition so
> that its role is clear to everybody. Does that sound good? :)

Sounds more than good, it is what I already proposed messages ago:

> Zero, name of an element, contains `zero` method to get the zero (it
> is still confusing to me), Monoid  extends Zero and Semigroup - given
> the use inside graph math, Zero#zero and Semigroup#append can be moved
> directly to Monoid and rename it as WeightOperation

despite the rename, I still like the Monoid :P

enough talk IMHO, time to code and make concrete proposals

best,
-Simo

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



On Sat, Mar 3, 2012 at 2:58 PM, Claudio Squarcella
 wrote:
> Hi,
>
>
>> Apologize but I still don't understand what the benefit is on storing
>> nodes/arcs data in the Graph data structure
>
>
> back to James' first email: any type could be immediately used as
> edge/vertex without wrappers, while specific data related to the domain of
> graphs (weights, labels) would be handled separately. I actually think this
> is useful: back to my days of "DIY Java graphs" I implemented something
> similar to what we have now, just to think every time: "why should I wrap my
> objects with these markers? I already know my Router is a Vertex in the
> graph..."
>
>
>> - sounds to me like a
>> Collection  where, to know the int value of its elements, have
>> to query the data structure, i.e.
>>
>> Collection  integerCollection = ...;
>> for ( Integer ptr : integerCollection )
>> {
>>     int value = integerCollection.getInt( ptr );
>> }
>>
>> It is weird to me even reading it.
>>
>> When I started modeling Graph, I had collections in mind - above all
>> to simplify its adoption - I would be more than pleased to drop
>> Weighted* version of graphs and come back to the previous situation,
>> but with the annoying  type inference issue fixed.
>
>
> Here's the way I see it. A Graph implementing HasWeightedEdges would
> have something like this inside:
>
> Map edgeWeights = new HashMap();
>
> [... populate map, other methods, etc ...]
>
> // implementing HasWeightedEdges#getEdgeWeight
> public W getEdgeWeig

Re: svn commit: r1296625 - /commons/sandbox/graph/trunk/checkstyle.xml

[Thomas Neidhart]

On 03/03/2012 03:55 PM, Simone Tripodi wrote:
> just ro make it clear: nobody vetoed it - did someone expressed a -1?
> - I just asked you to discuss it first on ML and rollback *pom*
> settings.

ok, then I misinterpreted your last post.

Anyway, I did not do any changes in the pom itself, so nothing to
rollback there. The reason to include the file in the first place was to
simplify the eclipse project setup, but I am also fine with the current
solution.

Thomas

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

Re: svn commit: r1296625 - /commons/sandbox/graph/trunk/checkstyle.xml

[Simone Tripodi]

just ro make it clear: nobody vetoed it - did someone expressed a -1?
- I just asked you to discuss it first on ML and rollback *pom*
settings.
thanks
-Simo

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



On Sat, Mar 3, 2012 at 2:58 PM,   wrote:
> Author: tn
> Date: Sat Mar  3 13:58:43 2012
> New Revision: 1296625
>
> URL: http://svn.apache.org/viewvc?rev=1296625&view=rev
> Log:
> removed vetoed checkstyle.xml
>
> Removed:
>    commons/sandbox/graph/trunk/checkstyle.xml
>

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

Re: [Graph] Test problems after last commit

[Simone Tripodi]

Hi Marco,

yes I know it, what doesn't convince me is not the problem, but the
solution. Have a look at Collections.* source code to see how  this
problem is fixed in synchronizedMap.

Anyway that confirms that maybe proxies are not the best to handle
that situation - unless James has a solution (he's our proxy expert,
just for the record) - and we have to manage read/write locks as James
suggested - that it would be a nice addition

-Simo

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



On Sat, Mar 3, 2012 at 3:29 PM, Marco Speranza  wrote:
> Ciao
>
>
>> rue, but *all* methods executions (synchronized and not) are
>> performed inside the handler, contained in the proxy instance anyway.
>>
>> So an user cannot use the same "lock"  in order to synchronize a block
>> like this:
>
> Let's give you an example.
>
> here is our handler implementation, and imagine that the 'lock' is not export 
> outside:
>
> ===
> synchronized ( this.lock )
> {
>        try
>        {
>                return method.invoke( checkedToBeSynchronized, args );
>        }
>        catch ( InvocationTargetException e )
>        {
>                throw e.getTargetException();
>        }
> }
> ===
>
> here is a possible user implementation:
>
> - Main class create a synchronized graph instance:
>
>    MutableGraph g = CommonsGraph.synchronize( new UndirectMutableGraph );
>
> - Thread 1 loops over the vertices:
> synchronized(g) {
>    for ( BaseLabeledVertex v2 : g.getVertices() )
>    {
>        // do somethings
>    }
>  }
>
> - Thread 2, insert a new vertex:
> for ( int i = start; i < end; i++ )
> {
>        BaseLabeledVertex v = new BaseLabeledVertex( valueOf( i ) );
>        g.addVertex( v );
> }
>
>
> in that example thread, probably you would have a 
> ConcurrentModificationException because:
>
> 1) Therad 1 uses a lock 'g' for the Iterator returned by g.getVertices()
> 2) Thread 2 uses its own lock 'this.lock' stored into Handler class.
>
> in this situation our data structure is *not* thread safe.
>
> The only way to synchronize the data structure is that:
>
> -Thread 2:
> for ( int i = start; i < end; i++ )
> {
>   synchronized(g) {
>          BaseLabeledVertex v = new BaseLabeledVertex( valueOf( i ) );
>          g.addVertex( v );
>  }
> }
>
> but this IMHO  is a wrong way to fix the problem, and moreover with this 
> workaround we don't need to
> use CommonGraph.synchronize() method, isn't it?
>
>
>> I have not clear which benefit you want to obtain with that - looks at
>> Collections#synchronized* methods and see that the separation of
>> concerns in clear.
>
> you are right maybe use an external lock is not useful.
>
>
>> Sure that we can, the only issue we have is that GroboUtils is not in
>> the central repo, adding the external repository would make not easy
>> having the component released.
>
> unfortunately GroboUtil was the only lib that I found yesterday. Any 
> suggestions to some other libs?
>
> all the best  ;-)
>
> --
> Marco Speranza 
> Google Code: http://code.google.com/u/marco.speranza79/
>
> Il giorno 03/mar/2012, alle ore 14:34, Simone Tripodi ha scritto:
>
>> Hola Marco,
>>
>>> my doubt is this:  opening a synchronized block into handler implementation 
>>> on 'this',  in my opinion is not enough, because the method 
>>> "CommonsGraph.synchronize()" returns a instance of the Proxy and not an 
>>> instance of handler.
>>
>> true, but *all* methods executions (synchronized and not) are
>> performed inside the handler, contained in the proxy instance anyway.
>>
>> So an user cannot use the same "lock"  in order to synchronize a block
>> like this:
>>
>> 
>> Graph g = CommonsGraph.synchronize(g_);
>>   ...
>> synchronized(g) {
>>     for ( BaseLabeledVertex v2 : g.getVertices() )
>>     {
>>         // do somethings
>>     }
>> }
>> 
>>
>> I am not sure we can do much more of what we've already done, for that
>> situation: the snippet below mixes the *data structure*
>> synchronization with the business logic performed outside.
>>
>>> So my idea is to open synchronized block inside handler implementation 
>>> using the same Proxy instance that the method 'CommonsGraph.synchronize' 
>>> will return.
>>> Furthermore I'd like to modify the API by adding also the possibility for 
>>> the user to use an your own lock, in that way
>>>
>>> CommonsGraph.synchronize( G graph, Object lock )
>>
>> I have not clear which benefit you want to obtain with that - looks at
>> Collections#synchronized* methods and see that the separation of
>> concerns in clear.
>>
>>> Finally only one question. I think that we should add some tests in order 
>>> to check the correct implementation of our multithrading implementation.
>>> Do you think that we can use an external library in test scope?
>>
>> Sure that we can, the only issue we have is that GroboUtils is not in
>> the central repo, adding the external repository would make not e

Re: [Graph] Test problems after last commit

[James Carman]

it would allow thread safety without synchronizing readers
On Mar 3, 2012 9:34 AM, "Marco Speranza"  wrote:

> Ciao
> sorry I didn't understand very well. How could help a read/write lock?
> bye
>
> --
> Marco Speranza 
>
> Flickr: http://www.flickr.com/photos/marcosperanza79/
> Google Code: http://code.google.com/u/marco.speranza79/
>
>
>
>
> Il giorno 03/mar/2012, alle ore 14:40, James Carman ha scritto:
>
> > I think a read/write lock might help.  Reads only need to be synchronized
> > around writes.  They don't have to be synchronized with one another.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Graph] Test problems after last commit

[Marco Speranza]

Ciao
sorry I didn't understand very well. How could help a read/write lock?
bye

--
Marco Speranza 

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




Il giorno 03/mar/2012, alle ore 14:40, James Carman ha scritto:

> I think a read/write lock might help.  Reads only need to be synchronized
> around writes.  They don't have to be synchronized with one another.


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

Re: [Graph] Test problems after last commit

[Marco Speranza]

Ciao


> rue, but *all* methods executions (synchronized and not) are
> performed inside the handler, contained in the proxy instance anyway.
> 
> So an user cannot use the same "lock"  in order to synchronize a block
> like this:

Let's give you an example.

here is our handler implementation, and imagine that the 'lock' is not export 
outside:

===
synchronized ( this.lock )
{
try
{
return method.invoke( checkedToBeSynchronized, args );
}
catch ( InvocationTargetException e )
{
throw e.getTargetException();
}
}
===

here is a possible user implementation:

- Main class create a synchronized graph instance: 

MutableGraph g = CommonsGraph.synchronize( new UndirectMutableGraph );
  
- Thread 1 loops over the vertices:
synchronized(g) {
for ( BaseLabeledVertex v2 : g.getVertices() )
{
// do somethings
}
 }

- Thread 2, insert a new vertex:
for ( int i = start; i < end; i++ )
{
BaseLabeledVertex v = new BaseLabeledVertex( valueOf( i ) );
g.addVertex( v );
}


in that example thread, probably you would have a 
ConcurrentModificationException because:

1) Therad 1 uses a lock 'g' for the Iterator returned by g.getVertices()   
2) Thread 2 uses its own lock 'this.lock' stored into Handler class.

in this situation our data structure is *not* thread safe.

The only way to synchronize the data structure is that:

-Thread 2:
for ( int i = start; i < end; i++ )
{
   synchronized(g) {
  BaseLabeledVertex v = new BaseLabeledVertex( valueOf( i ) );
  g.addVertex( v );
  }
}

but this IMHO  is a wrong way to fix the problem, and moreover with this 
workaround we don't need to 
use CommonGraph.synchronize() method, isn't it?


> I have not clear which benefit you want to obtain with that - looks at
> Collections#synchronized* methods and see that the separation of
> concerns in clear.

you are right maybe use an external lock is not useful. 


> Sure that we can, the only issue we have is that GroboUtils is not in
> the central repo, adding the external repository would make not easy
> having the component released.

unfortunately GroboUtil was the only lib that I found yesterday. Any 
suggestions to some other libs?

all the best  ;-) 

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

Il giorno 03/mar/2012, alle ore 14:34, Simone Tripodi ha scritto:

> Hola Marco,
> 
>> my doubt is this:  opening a synchronized block into handler implementation 
>> on 'this',  in my opinion is not enough, because the method 
>> "CommonsGraph.synchronize()" returns a instance of the Proxy and not an 
>> instance of handler.
> 
> true, but *all* methods executions (synchronized and not) are
> performed inside the handler, contained in the proxy instance anyway.
> 
> So an user cannot use the same "lock"  in order to synchronize a block
> like this:
> 
> 
> Graph g = CommonsGraph.synchronize(g_);
>   ...
> synchronized(g) {
> for ( BaseLabeledVertex v2 : g.getVertices() )
> {
> // do somethings
> }
> }
> 
> 
> I am not sure we can do much more of what we've already done, for that
> situation: the snippet below mixes the *data structure*
> synchronization with the business logic performed outside.
> 
>> So my idea is to open synchronized block inside handler implementation using 
>> the same Proxy instance that the method 'CommonsGraph.synchronize' will 
>> return.
>> Furthermore I'd like to modify the API by adding also the possibility for 
>> the user to use an your own lock, in that way
>> 
>> CommonsGraph.synchronize( G graph, Object lock )
> 
> I have not clear which benefit you want to obtain with that - looks at
> Collections#synchronized* methods and see that the separation of
> concerns in clear.
> 
>> Finally only one question. I think that we should add some tests in order to 
>> check the correct implementation of our multithrading implementation.
>> Do you think that we can use an external library in test scope?
> 
> Sure that we can, the only issue we have is that GroboUtils is not in
> the central repo, adding the external repository would make not easy
> having the component released.
> 
> best,
> -Simo
> 
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
> 
> 
> 
> On Sat, Mar 3, 2012 at 2:13 PM, Marco Speranza  
> wrote:
>> Morning Simo,
>> 
>> my doubt is this:  opening a synchronized block into handler implementation 
>> on 'this',  in my opinion is not enough, because the method 
>> "CommonsGraph.synchronize()" returns a instance of the Proxy and not an 
>> instance of handler.
>> So an user cannot use the same "lock"  in order to synchronize a block like 
>> this:
>> 
>> 
>> Graph g = CommonsGraph.synchronize(g_);
>>...
>>  synchronized(g) {
>>  for ( BaseLabeledVertex v2 : g.getVertices() )
>>  {
>>  // do some

How to configure the eclipse checkstyle plugin for use in commons projects (was: Re: svn commit: r1296621 - in /commons/sandbox/graph/trunk: ./ src/main/java/org/apache/commons/graph/ src/main/java/or

[Benedikt Ritter]

Am 03.03.2012 14:52, schrieb Simone Tripodi:

I think it is good to have control over what is actually checked by
checkstyle. Having a customised version is quite common practice also in
other commons components.



I would have preferred you would have discussed first before changing
configurations. Control and customizations, if needed, can be included
in the checkstyle suppressions file. Please revert pom configuration,
if applied, and discuss first in a separated thread.


The one I checked in is from commons math, where I disabled some checks
for now (e.g. @version, license header).


The math style is not the one we've been using, if the configuration
has to be imported, then it has to be from Maven, wich is the one
we've been using.



Sorry, this may be kind of a newbe question, but I'm still looking for a 
away configure the eclipse checkstyle plugin to use the right checks.
Can you give me some advice with that? I've already tried to import the 
maven_check.xml from the maven-checkstyle-plugin.jar but that does not 
seem to workout, because there are unresolved place holders.
So my question is, where can I get/how can I generate a valid 
checkstyle.xml for a commons project, that takes the suppressions into 
account?


TIA,
Benedikt


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



On Sat, Mar 3, 2012 at 2:42 PM, Thomas Neidhart
  wrote:

On 03/03/2012 02:36 PM, Simone Tripodi wrote:

Thomas,

checkstyle is not needed because we are using the one brought by the
plugin (the maven one), you can safety drop it.


I think it is good to have control over what is actually checked by
checkstyle. Having a customised version is quite common practice also in
other commons components.

The one I checked in is from commons math, where I disabled some checks
for now (e.g. @version, license header).

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: [graph] Why the Vertex and Edge interfaces?

[Claudio Squarcella]

Hi,


Apologize but I still don't understand what the benefit is on storing
nodes/arcs data in the Graph data structure


back to James' first email: any type could be immediately used as 
edge/vertex without wrappers, while specific data related to the domain 
of graphs (weights, labels) would be handled separately. I actually 
think this is useful: back to my days of "DIY Java graphs" I implemented 
something similar to what we have now, just to think every time: "why 
should I wrap my objects with these markers? I already know my Router is 
a Vertex in the graph..."



- sounds to me like a
Collection  where, to know the int value of its elements, have
to query the data structure, i.e.

Collection  integerCollection = ...;
for ( Integer ptr : integerCollection )
{
 int value = integerCollection.getInt( ptr );
}

It is weird to me even reading it.

When I started modeling Graph, I had collections in mind - above all
to simplify its adoption - I would be more than pleased to drop
Weighted* version of graphs and come back to the previous situation,
but with the annoying  type inference issue fixed.


Here's the way I see it. A Graph implementing HasWeightedEdges 
would have something like this inside:


Map edgeWeights = new HashMap();

[... populate map, other methods, etc ...]

// implementing HasWeightedEdges#getEdgeWeight
public W getEdgeWeight(E edge)
{
[... check null etc...]
return edgeWeights.get(edge);
}


no, trying to be clearer: you propose to rename Monoid into WeightOperation,
which is like renaming Addition into Operation. Or alternatively to call the
current *WeightBaseOperations something like *WeightMonoid. In both cases I
disagree because I would prefer to keep a clear distinction between single
well-defined properties/operations (like Addition or Comparator) and the
comprehensive implementation (e.g. DoubleWeightBaseOperations) that
implements all the operations it can implement with Doubles.

OK, concept is clear, I still don't agree on the nomenclature, anyway.
Actually *WeightBaseOperations describe
*WeightAdditionalOrderedMonoid, so *BaseOperations doesn't sound self
explaining.


then let's find a better name, but why *OrderedMonoid? Assume we replace 
the whole set of current interfaces (see my comment to the next 
paragraph below) with just Addition and Comparable (the latter already 
exists of course). There is no need to create another interface to merge 
the two (ComparableAddition? OrderedAddition?). Then we have:


public class DoubleWeightOperations
implements Addition, Comparator
{
[...]
}

I would not rename the class to DoubleWeightAddition or even 
DoubleWeightComparableAddition. What if later we need to e.g. add a 
function that normalizes weights by some factor, or returns the 
reciprocal of a weight, etc? With the above code it would suffice to add 
new interfaces:


public class DoubleWeightOperations
implements Addition, Comparator, Normalization, Reciprocal
{
[...]
}




Moreover, The Zero interface is the *additional* monoid identity
element, if someone has to implement the Multiplication Monoid I
wouldn't expect he implements the One interface wich declares O one()
method.
This is why IMHO in the current algebra model, Zero has to be dropped
and has to be modified in:


That is fine for me. I simply followed pure theory while implementing 
that and used all possible granularity. Now looking at our 
implementations I think it is save enough to even merge Zero, Semigroup 
and Monoid (so that's one step further than your example below) and call 
the result Addition so that its role is clear to everybody. Does that 
sound good? :)


Claudio



/**
  * semigroup is an algebraic structure consisting of a set together
with an associative binary operation.
  */
interface Semigroup
{

 E append( E s1, E s2 );

}

/**
  * A {@link Monoid} is a {@link Semigroup} with an identity value.
  */
public interface Monoid
 extends Semigroup
{

E identity();

E inverse( E element );

}

that would continue working for every Monoid specialization. Or not? thoughts?
Thanks and best,
-Simo

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



On Sat, Mar 3, 2012 at 1:43 PM, Claudio Squarcella
  wrote:

Hi,


On 03/03/2012 02:21, Simone Tripodi wrote:

first of all: yes, I will play with this stuff as soon as I find the time
:)

this is scaring... go Orb.io, go! :)


constant), but still there is one more step of indirection. So we would
need
to test and compare performances, hopefully with acceptable results.

sounds it would be better if you implement that stuff in a branch to
keep both implementations, IMHO


sure :)



  * with the current approach: one interface for edge-weighted graphs
   (EdgeWeightedGraph, renaming the current WeightedGraph?), one for
   vertex-weighted graphs (VertexWeightedGraph) and maybe even one for
   weights on both edges and 

Re: svn commit: r1296621 - in /commons/sandbox/graph/trunk: ./ src/main/java/org/apache/commons/graph/ src/main/java/org/apache/commons/graph/spanning/

[Simone Tripodi]

> I think it is good to have control over what is actually checked by
> checkstyle. Having a customised version is quite common practice also in
> other commons components.
>

I would have preferred you would have discussed first before changing
configurations. Control and customizations, if needed, can be included
in the checkstyle suppressions file. Please revert pom configuration,
if applied, and discuss first in a separated thread.

> The one I checked in is from commons math, where I disabled some checks
> for now (e.g. @version, license header).

The math style is not the one we've been using, if the configuration
has to be imported, then it has to be from Maven, wich is the one
we've been using.

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



On Sat, Mar 3, 2012 at 2:42 PM, Thomas Neidhart
 wrote:
> On 03/03/2012 02:36 PM, Simone Tripodi wrote:
>> Thomas,
>>
>> checkstyle is not needed because we are using the one brought by the
>> plugin (the maven one), you can safety drop it.
>
> I think it is good to have control over what is actually checked by
> checkstyle. Having a customised version is quite common practice also in
> other commons components.
>
> The one I checked in is from commons math, where I disabled some checks
> for now (e.g. @version, license header).
>
> 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: svn commit: r1296621 - in /commons/sandbox/graph/trunk: ./ src/main/java/org/apache/commons/graph/ src/main/java/org/apache/commons/graph/spanning/

[Thomas Neidhart]

On 03/03/2012 02:36 PM, Simone Tripodi wrote:
> Thomas,
> 
> checkstyle is not needed because we are using the one brought by the
> plugin (the maven one), you can safety drop it.

I think it is good to have control over what is actually checked by
checkstyle. Having a customised version is quite common practice also in
other commons components.

The one I checked in is from commons math, where I disabled some checks
for now (e.g. @version, license header).

Thomas

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

Re: [Graph] Test problems after last commit

[James Carman]

I think a read/write lock might help.  Reads only need to be synchronized
around writes.  They don't have to be synchronized with one another.
On Mar 3, 2012 8:35 AM, "Simone Tripodi"  wrote:

> Hola Marco,
>
> > my doubt is this:  opening a synchronized block into handler
> implementation on 'this',  in my opinion is not enough, because the method
> "CommonsGraph.synchronize()" returns a instance of the Proxy and not an
> instance of handler.
>
> true, but *all* methods executions (synchronized and not) are
> performed inside the handler, contained in the proxy instance anyway.
>
> So an user cannot use the same "lock"  in order to synchronize a block
> like this:
>
> 
> Graph g = CommonsGraph.synchronize(g_);
>   ...
>  synchronized(g) {
> for ( BaseLabeledVertex v2 : g.getVertices() )
> {
> // do somethings
> }
>  }
> 
>
> I am not sure we can do much more of what we've already done, for that
> situation: the snippet below mixes the *data structure*
> synchronization with the business logic performed outside.
>
> > So my idea is to open synchronized block inside handler implementation
> using the same Proxy instance that the method 'CommonsGraph.synchronize'
> will return.
> > Furthermore I'd like to modify the API by adding also the possibility
> for the user to use an your own lock, in that way
> >
> > CommonsGraph.synchronize( G graph, Object lock )
>
> I have not clear which benefit you want to obtain with that - looks at
> Collections#synchronized* methods and see that the separation of
> concerns in clear.
>
> > Finally only one question. I think that we should add some tests in
> order to check the correct implementation of our multithrading
> implementation.
> > Do you think that we can use an external library in test scope?
>
> Sure that we can, the only issue we have is that GroboUtils is not in
> the central repo, adding the external repository would make not easy
> having the component released.
>
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sat, Mar 3, 2012 at 2:13 PM, Marco Speranza 
> wrote:
> > Morning Simo,
> >
> > my doubt is this:  opening a synchronized block into handler
> implementation on 'this',  in my opinion is not enough, because the method
> "CommonsGraph.synchronize()" returns a instance of the Proxy and not an
> instance of handler.
> > So an user cannot use the same "lock"  in order to synchronize a block
> like this:
> >
> > 
> > Graph g = CommonsGraph.synchronize(g_);
> >...
> >  synchronized(g) {
> >  for ( BaseLabeledVertex v2 : g.getVertices() )
> >  {
> >  // do somethings
> >  }
> >  }
> > 
> >
> > So my idea is to open synchronized block inside handler implementation
> using the same Proxy instance that the method 'CommonsGraph.synchronize'
> will return.
> > Furthermore I'd like to modify the API by adding also the possibility
> for the user to use an your own lock, in that way
> >
> > CommonsGraph.synchronize( G graph, Object lock )
> >
> > WDYT?
> >
> > Finally only one question. I think that we should add some tests in
> order to check the correct implementation of our multithrading
> implementation.
> > Do you think that we can use an external library in test scope?
> >
> >
> > have a nice day
> >
> >
> > --
> > Marco Speranza 
> > Google Code: http://code.google.com/u/marco.speranza79/
> >
> > Il giorno 03/mar/2012, alle ore 13:50, Simone Tripodi ha scritto:
> >
> >> Good morning Marco,
> >>
> >> I had the chance to have a deeper look at your yesterday's night work
> >> and think your additions are good improvements - I just wonder if we
> >> can replace the lock object with the handler itself, referencing
> >> `this` instead.
> >>
> >> Thoughts?
> >>
> >> best and have a nice WE,
> >> -Simo
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://simonetripodi.livejournal.com/
> >> http://twitter.com/simonetripodi
> >> http://www.99soft.org/
> >>
> >>
> >>
> >> On Sat, Mar 3, 2012 at 1:56 AM, Simone Tripodi <
> simonetrip...@apache.org> wrote:
> >>> I saw the commit, please read comments inline.
> >>> best,
> >>> -Simo
> >>>
> >>> http://people.apache.org/~simonetripodi/
> >>> http://simonetripodi.livejournal.com/
> >>> http://twitter.com/simonetripodi
> >>> http://www.99soft.org/
> >>>
> >>>
> >>>
> >>> On Sat, Mar 3, 2012 at 1:40 AM, Marco Speranza <
> marcospera...@apache.org> wrote:
>  Hi I fixed the problem using proxy/handler.
> 
>  I put also a couple of tests. For do that I insert a test scoped
> dependency to a library net.sourceforge.groboutils.groboutils-core
> 
>  Ciao
> 
>  --
>  Marco Speranza 
>  Google Code: http://code.google.com/u/marco.speranza79/
> 
>  Il giorno 03/mar/2012, alle ore 01:29, Simone Tripodi ha scritto:
> 
> > yes, what I didn't understand is how you would like to manage the
> > i

Re: svn commit: r1296621 - in /commons/sandbox/graph/trunk: ./ src/main/java/org/apache/commons/graph/ src/main/java/org/apache/commons/graph/spanning/

[Simone Tripodi]

Thomas,

checkstyle is not needed because we are using the one brought by the
plugin (the maven one), you can safety drop it.
thanks,
-Simo

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



On Sat, Mar 3, 2012 at 2:26 PM,   wrote:
> Author: tn
> Date: Sat Mar  3 13:26:08 2012
> New Revision: 1296621
>
> URL: http://svn.apache.org/viewvc?rev=1296621&view=rev
> Log:
> added initial checkstyle.xml, removed duplicate getWeight interface method, 
> javadoc cleanup
>
> Added:
>    commons/sandbox/graph/trunk/checkstyle.xml   (with props)
> Modified:
>    
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/Graph.java
>    
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/GraphException.java
>    
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/MutableGraph.java
>    
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/VertexPair.java
>    
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/WeightedEdge.java
>    
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/WeightedPath.java
>    
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/spanning/SpanningTreeSourceSelector.java
>
> Added: commons/sandbox/graph/trunk/checkstyle.xml
> URL: 
> http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/checkstyle.xml?rev=1296621&view=auto
> ==
> --- commons/sandbox/graph/trunk/checkstyle.xml (added)
> +++ commons/sandbox/graph/trunk/checkstyle.xml Sat Mar  3 13:26:08 2012
> @@ -0,0 +1,157 @@
> +
> +
> +
> +
> + "http://www.puppycrawl.com/dtds/configuration_1_1.dtd";>
> +
> +
> +
> +  
> +  
> +
> +  
> +
> +    
> +
> +    
> +    
> +      
> +    
> +
> +    
> +    
> +
> +    
> +    
> +
> +    
> +
> +
> +
> +
> +     
> +    
> +      
> +    
> +
> +    
> +    
> +
> +    
> +    
> +       
> +    
> +
> +    
> +    
> +
> +    
> +    
> +      
> +    
> +
> +    
> +    
> +
> +    
> +    
> +    
> +    
> +
> +    
> +    
> +
> +    
> +    
> +    
> +
> +    
> +    
> +
> +    
> +    
> +        
> +        
> +    
> +
> +    
> +    
> +      
> +      
> +      
> +    
> +
> +    
> +    
> +      
> +      
> +      
> +    
> +
> +    
> +    
> +      
> +      
> +      
> +    
> +
> +    
> +    
> +    
> +
> +    
> +    
> +
> +    
> +    
> +
> +    
> +    
> +
> +    
> +    
> +
> +   
> +    
> +
> +    
> +    
> +    
> +       value='^(("")|(".")|("unchecked"))$'/>
> +    
> +
> +    
> +
> +  
> +
> +  
> +
> +
> +
> +
> +  
> +  
> +
> +  
> +  
> +
> +  
> +  
> +
> +
> +
>
> Propchange: commons/sandbox/graph/trunk/checkstyle.xml
> --
>    svn:eol-style = native
>
> Propchange: commons/sandbox/graph/trunk/checkstyle.xml
> --
>    svn:keywords = Id Revision HeadURL
>
> Propchange: commons/sandbox/graph/trunk/checkstyle.xml
> --
>    svn:mime-type = text/xml
>
> Modified: 
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/Graph.java
> URL: 
> http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/Graph.java?rev=1296621&r1=1296620&r2=1296621&view=diff
> ==
> --- 
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/Graph.java 
> (original)
> +++ 
> commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/Graph.java 
> Sat Mar  3 13:26:08 2012
> @@ -91,6 +91,7 @@ public interface Graph      * NOTE: implementors have to take in consideration throwing a 
> {@link GraphException}
>      * if an error occurs while performing that operation.
>      *
> +     * @param v the {@link Vertex} which connected vertices have to be 
> returned.
>      * @return all vertices which touch this vertex.
>      */
>     Iterable getConnectedVertices( V v );
> @@ -113,27 +114,29 @@ public interface Graph      * NOTE: implementors have to take in consideration throwing a 
> {@link GraphException}
>      * if an error occurs while performing that operation.
>      *
> +     * @param e the input {@link Edge}
>      * @return the set of {@link Vertex} on this Edge.
>      */
>     VertexPair getVertices( E e );
> -
> -
> +
>     /**
>      * Returns true if the vertex is contained into the graph
>      *
>      * NOTE: implementors have to take in consideration throwing a 
> {@link GraphException}
>      * if an error occurs while performing that operation.
>      *
> +     * @param v the {@link Vertex} to be checked
>      * @return Returns true if the vertex is contained into the graph, false 
> otherwise
>      */
>     boolean

Re: [Graph] Test problems after last commit

[Simone Tripodi]

Hola Marco,

> my doubt is this:  opening a synchronized block into handler implementation 
> on 'this',  in my opinion is not enough, because the method 
> "CommonsGraph.synchronize()" returns a instance of the Proxy and not an 
> instance of handler.

true, but *all* methods executions (synchronized and not) are
performed inside the handler, contained in the proxy instance anyway.

So an user cannot use the same "lock"  in order to synchronize a block
like this:


Graph g = CommonsGraph.synchronize(g_);
   ...
 synchronized(g) {
 for ( BaseLabeledVertex v2 : g.getVertices() )
 {
 // do somethings
 }
 }


I am not sure we can do much more of what we've already done, for that
situation: the snippet below mixes the *data structure*
synchronization with the business logic performed outside.

> So my idea is to open synchronized block inside handler implementation using 
> the same Proxy instance that the method 'CommonsGraph.synchronize' will 
> return.
> Furthermore I'd like to modify the API by adding also the possibility for the 
> user to use an your own lock, in that way
>
> CommonsGraph.synchronize( G graph, Object lock )

I have not clear which benefit you want to obtain with that - looks at
Collections#synchronized* methods and see that the separation of
concerns in clear.

> Finally only one question. I think that we should add some tests in order to 
> check the correct implementation of our multithrading implementation.
> Do you think that we can use an external library in test scope?

Sure that we can, the only issue we have is that GroboUtils is not in
the central repo, adding the external repository would make not easy
having the component released.

best,
-Simo

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



On Sat, Mar 3, 2012 at 2:13 PM, Marco Speranza  wrote:
> Morning Simo,
>
> my doubt is this:  opening a synchronized block into handler implementation 
> on 'this',  in my opinion is not enough, because the method 
> "CommonsGraph.synchronize()" returns a instance of the Proxy and not an 
> instance of handler.
> So an user cannot use the same "lock"  in order to synchronize a block like 
> this:
>
> 
> Graph g = CommonsGraph.synchronize(g_);
>    ...
>  synchronized(g) {
>      for ( BaseLabeledVertex v2 : g.getVertices() )
>      {
>          // do somethings
>      }
>  }
> 
>
> So my idea is to open synchronized block inside handler implementation using 
> the same Proxy instance that the method 'CommonsGraph.synchronize' will 
> return.
> Furthermore I'd like to modify the API by adding also the possibility for the 
> user to use an your own lock, in that way
>
> CommonsGraph.synchronize( G graph, Object lock )
>
> WDYT?
>
> Finally only one question. I think that we should add some tests in order to 
> check the correct implementation of our multithrading implementation.
> Do you think that we can use an external library in test scope?
>
>
> have a nice day
>
>
> --
> Marco Speranza 
> Google Code: http://code.google.com/u/marco.speranza79/
>
> Il giorno 03/mar/2012, alle ore 13:50, Simone Tripodi ha scritto:
>
>> Good morning Marco,
>>
>> I had the chance to have a deeper look at your yesterday's night work
>> and think your additions are good improvements - I just wonder if we
>> can replace the lock object with the handler itself, referencing
>> `this` instead.
>>
>> Thoughts?
>>
>> best and have a nice WE,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Sat, Mar 3, 2012 at 1:56 AM, Simone Tripodi  
>> wrote:
>>> I saw the commit, please read comments inline.
>>> best,
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Sat, Mar 3, 2012 at 1:40 AM, Marco Speranza  
>>> wrote:
 Hi I fixed the problem using proxy/handler.

 I put also a couple of tests. For do that I insert a test scoped 
 dependency to a library net.sourceforge.groboutils.groboutils-core

 Ciao

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

 Il giorno 03/mar/2012, alle ore 01:29, Simone Tripodi ha scritto:

> yes, what I didn't understand is how you would like to manage the
> iterators issue
>
> sorry for the brevity but tonight I am getting crazy with at least 3
> other projects :D
>
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sat, Mar 3, 2012 at 1:16 AM, Marco Speranza  
> wrote:
>> I think that we have to use the same patter of java Collections: a 
>> wrapper

Re: [Math] Toward 3.0 release: First deliverables

[Luc Maisonobe]

Hi Sebb,

Le 03/03/2012 00:41, sebb a écrit :
> On 2 March 2012 00:59, 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.
> 
> I think there are quite a few things that need checking before it is
> safe to do a release.
> This is the first release with the new package, so it's a chance to
> fix all the inherited poor APIs.

I think all the important problems have been addressed by now.

> 
> We need to try and apply all the changes that will break binary
> compat. before this release, rather than after.

The API have been stabilized since a few weeks and reviewed. The latest
problems identified seems to me merely implementation details. such
problems can be fixed in a 3.1 version if needed. This would even force
us to really release more often, which is clearly our greatest problem
for [math] now.

> 
> As such, any mutable public or protected variables should ideally be
> made private.

Some of these fields have been designed like this for years (the ODE
package was started in 2002 in another library and imported in [math] in
2006 for example). Of course we should go for better encapsulation,
better design. But we are late. Very late.

> 
> Thread-safety is harder to achieve with mutable variables, so any
> classes with setter methods should be checked to see if the setters
> are really needed or not.

This cannot be adressed before 3.0. [math] is *not* thread safe and does
not intend to be, at least for now.

I strongly agree with Gilles desire to get 3.0 out soon. In fact, I know
two important operational projects that need it really really soon.
Delaying the release would be a very negative sign.

The current state of 3.0 is good. It has been used for months by
numerous users, but now some of them need an official release, they
cannot rely on a development snapshot any longer.

We must release 3.0 now.

best regards,
Luc


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


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

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

[Simone Tripodi]

Hola Claud.io,

>  * a set of interfaces: e.g. HasWeightedEdges#getWeight(edge),
>   HasWeightedVertices#getWeight(vertex), etc.
>  * #1 implementation with external properties: the graph keeps the
>   mapping between edge/vertex and weight, so that any type can be used
>   for edges/vertices
>  * #2 classical implementation: we keep markers like WeightedEdge and
>   WeightedVertex but only the graph knows about them. algorithms keep
>   asking the graph for weights of edges/vertices, and the graph in
>   turn asks the edge/vertex itself (passed as parameter).
>
> WDYT?

Apologize but I still don't understand what the benefit is on storing
nodes/arcs data in the Graph data structure - sounds to me like a
Collection where, to know the int value of its elements, have
to query the data structure, i.e.

Collection integerCollection = ...;
for ( Integer ptr : integerCollection )
{
int value = integerCollection.getInt( ptr );
}

It is weird to me even reading it.

When I started modeling Graph, I had collections in mind - above all
to simplify its adoption - I would be more than pleased to drop
Weighted* version of graphs and come back to the previous situation,
but with the annoying  type inference issue fixed.

> no, trying to be clearer: you propose to rename Monoid into WeightOperation,
> which is like renaming Addition into Operation. Or alternatively to call the
> current *WeightBaseOperations something like *WeightMonoid. In both cases I
> disagree because I would prefer to keep a clear distinction between single
> well-defined properties/operations (like Addition or Comparator) and the
> comprehensive implementation (e.g. DoubleWeightBaseOperations) that
> implements all the operations it can implement with Doubles.

OK, concept is clear, I still don't agree on the nomenclature, anyway.
Actually *WeightBaseOperations describe
*WeightAdditionalOrderedMonoid, so *BaseOperations doesn't sound self
explaining.

Moreover, The Zero interface is the *additional* monoid identity
element, if someone has to implement the Multiplication Monoid I
wouldn't expect he implements the One interface wich declares O one()
method.
This is why IMHO in the current algebra model, Zero has to be dropped
and has to be modified in:

/**
 * semigroup is an algebraic structure consisting of a set together
with an associative binary operation.
 */
interface Semigroup
{

E append( E s1, E s2 );

}

/**
 * A {@link Monoid} is a {@link Semigroup} with an identity value.
 */
public interface Monoid
extends Semigroup
{

   E identity();

   E inverse( E element );

}

that would continue working for every Monoid specialization. Or not? thoughts?
Thanks and best,
-Simo

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



On Sat, Mar 3, 2012 at 1:43 PM, Claudio Squarcella
 wrote:
> Hi,
>
>
> On 03/03/2012 02:21, Simone Tripodi wrote:
>>>
>>> first of all: yes, I will play with this stuff as soon as I find the time
>>> :)
>>
>> this is scaring... go Orb.io, go! :)
>>
>>> constant), but still there is one more step of indirection. So we would
>>> need
>>> to test and compare performances, hopefully with acceptable results.
>>
>> sounds it would be better if you implement that stuff in a branch to
>> keep both implementations, IMHO
>
>
> sure :)
>
>
>>>  * with the current approach: one interface for edge-weighted graphs
>>>   (EdgeWeightedGraph, renaming the current WeightedGraph?), one for
>>>   vertex-weighted graphs (VertexWeightedGraph) and maybe even one for
>>>   weights on both edges and vertices (EdgeAndVertexWeightedGraph?) --
>>>   not to talk about their counterparts with labels, etc;
>>>  * with the proposed approach: a Graph would implement
>>>   HasWeightsOnEdges and/or HasWeightsOnVertices -- and maybe also
>>>   HasLabelsOnEdges if needed.
>>
>> do you remember that we reintroduced the WeightedGraph just for the
>> type inference issue on fluent APIs in Eclipse, do you? ;) It would
>> have been worked otherwise as well dropping the WeightedGraph and
>> expressing types only on Vertex/Edges
>
>
> that is right. On the other hand with "HasWeightedEdges" we could drop
> "WeightedEdge" and so on: one interface in, one out.
>
> Or we could even save both approaches as alternative implementations. That
> is:
>
>  * a set of interfaces: e.g. HasWeightedEdges#getWeight(edge),
>   HasWeightedVertices#getWeight(vertex), etc.
>  * #1 implementation with external properties: the graph keeps the
>   mapping between edge/vertex and weight, so that any type can be used
>   for edges/vertices
>  * #2 classical implementation: we keep markers like WeightedEdge and
>   WeightedVertex but only the graph knows about them. algorithms keep
>   asking the graph for weights of edges/vertices, and the graph in
>   turn asks the edge/vertex itself (passed as parameter).
>
> WDYT?
>
>
>>> I know that this kind of "mismatch" is not your favourite ;) but wou

Re: [Graph] Test problems after last commit

[Marco Speranza]

Morning Simo,

my doubt is this:  opening a synchronized block into handler implementation on 
'this',  in my opinion is not enough, because the method 
"CommonsGraph.synchronize()" returns a instance of the Proxy and not an 
instance of handler.
So an user cannot use the same "lock"  in order to synchronize a block like 
this:


Graph g = CommonsGraph.synchronize(g_);
...
 synchronized(g) {
  for ( BaseLabeledVertex v2 : g.getVertices() )
  {
  // do somethings
  }
 }


So my idea is to open synchronized block inside handler implementation using 
the same Proxy instance that the method 'CommonsGraph.synchronize' will return.
Furthermore I'd like to modify the API by adding also the possibility for the 
user to use an your own lock, in that way

CommonsGraph.synchronize( G graph, Object lock )

WDYT?

Finally only one question. I think that we should add some tests in order to 
check the correct implementation of our multithrading implementation.
Do you think that we can use an external library in test scope?


have a nice day


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

Il giorno 03/mar/2012, alle ore 13:50, Simone Tripodi ha scritto:

> Good morning Marco,
> 
> I had the chance to have a deeper look at your yesterday's night work
> and think your additions are good improvements - I just wonder if we
> can replace the lock object with the handler itself, referencing
> `this` instead.
> 
> Thoughts?
> 
> best and have a nice WE,
> -Simo
> 
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
> 
> 
> 
> On Sat, Mar 3, 2012 at 1:56 AM, Simone Tripodi  
> wrote:
>> I saw the commit, please read comments inline.
>> best,
>> -Simo
>> 
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>> 
>> 
>> 
>> On Sat, Mar 3, 2012 at 1:40 AM, Marco Speranza  
>> wrote:
>>> Hi I fixed the problem using proxy/handler.
>>> 
>>> I put also a couple of tests. For do that I insert a test scoped dependency 
>>> to a library net.sourceforge.groboutils.groboutils-core
>>> 
>>> Ciao
>>> 
>>> --
>>> Marco Speranza 
>>> Google Code: http://code.google.com/u/marco.speranza79/
>>> 
>>> Il giorno 03/mar/2012, alle ore 01:29, Simone Tripodi ha scritto:
>>> 
 yes, what I didn't understand is how you would like to manage the
 iterators issue
 
 sorry for the brevity but tonight I am getting crazy with at least 3
 other projects :D
 
 -Simo
 
 http://people.apache.org/~simonetripodi/
 http://simonetripodi.livejournal.com/
 http://twitter.com/simonetripodi
 http://www.99soft.org/
 
 
 
 On Sat, Mar 3, 2012 at 1:16 AM, Marco Speranza  
 wrote:
> I think that we have to use the same patter of java Collections: a 
> wrapper of Graph/MutableGraph that use a synchronize block.
> 
> WDYT?
> 
> --
> Marco Speranza 
> Google Code: http://code.google.com/u/marco.speranza79/
> 
> Il giorno 03/mar/2012, alle ore 01:10, Simone Tripodi ha scritto:
> 
>> OK now sounds better, thanks - how would you intend to fix it?
>> TIA,
>> -Simo
>> 
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>> 
>> 
>> 
>> On Sat, Mar 3, 2012 at 1:01 AM, Marco Speranza 
>>  wrote:
> 
> furthermore there is another problem: with handler is not possible to 
> use correctly synchronization block like this
> 
> 
> Graph g = CommonsGraph.synchronize(g_);
> ...
>  synchronized(g) {
>   for ( BaseLabeledVertex v2 : g.getVertices() )
>   {
>   // do somethings
>   }
>  }
> 
 
 sorry I don't understand what you meant/intend to do
>>> 
>>> I'm trying to explain better. the method getVertices return an 
>>> Iterator. In a multi-thread environment you have to ensure that during 
>>> the 'for' execution the [graph] data structure remains  consistent.
>>> Also for java collection is the same 
>>> [http://docs.oracle.com/javase/6/docs/api/java/util/Collections.html#synchronizedCollection(java.util.Collection)]
>>> 
>>> So if we use a proxy/handler there is no way to "export" the mutex/lock 
>>> variable used into handler class.
>>> 
>>> In  our CommonsGraph the variable this.lock is private and is non 
>>> possible to export out of the method, so the user can not utilize the 
>>> lock to synchronize his block.
>>> 
>>> ===
>>>public Object invoke( Object proxy, Method method, Object[] args 
>>> )
>>>throws Throwable
>>>{
>>>

Re: [Graph] Test problems after last commit

[Simone Tripodi]

Good morning Marco,

I had the chance to have a deeper look at your yesterday's night work
and think your additions are good improvements - I just wonder if we
can replace the lock object with the handler itself, referencing
`this` instead.

Thoughts?

best and have a nice WE,
-Simo

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



On Sat, Mar 3, 2012 at 1:56 AM, Simone Tripodi  wrote:
> I saw the commit, please read comments inline.
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sat, Mar 3, 2012 at 1:40 AM, Marco Speranza  
> wrote:
>> Hi I fixed the problem using proxy/handler.
>>
>> I put also a couple of tests. For do that I insert a test scoped dependency 
>> to a library net.sourceforge.groboutils.groboutils-core
>>
>> Ciao
>>
>> --
>> Marco Speranza 
>> Google Code: http://code.google.com/u/marco.speranza79/
>>
>> Il giorno 03/mar/2012, alle ore 01:29, Simone Tripodi ha scritto:
>>
>>> yes, what I didn't understand is how you would like to manage the
>>> iterators issue
>>>
>>> sorry for the brevity but tonight I am getting crazy with at least 3
>>> other projects :D
>>>
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Sat, Mar 3, 2012 at 1:16 AM, Marco Speranza  
>>> wrote:
 I think that we have to use the same patter of java Collections: a wrapper 
 of Graph/MutableGraph that use a synchronize block.

 WDYT?

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

 Il giorno 03/mar/2012, alle ore 01:10, Simone Tripodi ha scritto:

> OK now sounds better, thanks - how would you intend to fix it?
> TIA,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sat, Mar 3, 2012 at 1:01 AM, Marco Speranza  
> wrote:

 furthermore there is another problem: with handler is not possible to 
 use correctly synchronization block like this

 
 Graph g = CommonsGraph.synchronize(g_);
     ...
  synchronized(g) {
       for ( BaseLabeledVertex v2 : g.getVertices() )
       {
           // do somethings
       }
  }
 
>>>
>>> sorry I don't understand what you meant/intend to do
>>
>> I'm trying to explain better. the method getVertices return an Iterator. 
>> In a multi-thread environment you have to ensure that during the 'for' 
>> execution the [graph] data structure remains  consistent.
>> Also for java collection is the same 
>> [http://docs.oracle.com/javase/6/docs/api/java/util/Collections.html#synchronizedCollection(java.util.Collection)]
>>
>> So if we use a proxy/handler there is no way to "export" the mutex/lock 
>> variable used into handler class.
>>
>> In  our CommonsGraph the variable this.lock is private and is non 
>> possible to export out of the method, so the user can not utilize the 
>> lock to synchronize his block.
>>
>> ===
>>        public Object invoke( Object proxy, Method method, Object[] args )
>>            throws Throwable
>>        {
>>            if ( synchronizedMethods.contains( method ) )
>>            {
>>                try
>>                {
>>                    synchronized ( this.lock )
>>                    {
>>                        return method.invoke( synchronizedMethods, args );
>>                    }
>>                }
>>                catch ( InvocationTargetException e )
>>                {
>>                    throw e.getTargetException();
>>                }
>>            }
>>            return method.invoke( synchronizedMethods, args );
>>        }
>> ===
>>
>> ciao
>>
>> --
>> Marco Speranza 
>> Google Code: http://code.google.com/u/marco.speranza79/
>>
>> Il giorno 03/mar/2012, alle ore 00:45, Simone Tripodi ha scritto:
>>
 furthermore there is another problem: with handler is not possible to 
 use correctly synchronization block like this

 
 Graph g = CommonsGraph.synchronize(g_);
     ...
  synchronized(g) {
       for ( BaseLabeledVertex v2 : g.getVertices() )
       {
           // do somethings
       }
  }
 
>>>
>>> sorry I don't understand what you meant/intend to do
>>>
 I really think that a synchronized wrapper it's the best solution.

>

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

[Claudio Squarcella]

Hi,

On 03/03/2012 02:21, Simone Tripodi wrote:

first of all: yes, I will play with this stuff as soon as I find the time :)

this is scaring... go Orb.io, go! :)


constant), but still there is one more step of indirection. So we would need
to test and compare performances, hopefully with acceptable results.

sounds it would be better if you implement that stuff in a branch to
keep both implementations, IMHO


sure :)


  * with the current approach: one interface for edge-weighted graphs
   (EdgeWeightedGraph, renaming the current WeightedGraph?), one for
   vertex-weighted graphs (VertexWeightedGraph) and maybe even one for
   weights on both edges and vertices (EdgeAndVertexWeightedGraph?) --
   not to talk about their counterparts with labels, etc;
  * with the proposed approach: a Graph would implement
   HasWeightsOnEdges and/or HasWeightsOnVertices -- and maybe also
   HasLabelsOnEdges if needed.

do you remember that we reintroduced the WeightedGraph just for the
type inference issue on fluent APIs in Eclipse, do you? ;) It would
have been worked otherwise as well dropping the WeightedGraph and
expressing types only on Vertex/Edges


that is right. On the other hand with "HasWeightedEdges" we could drop 
"WeightedEdge" and so on: one interface in, one out.


Or we could even save both approaches as alternative implementations. 
That is:


 * a set of interfaces: e.g. HasWeightedEdges#getWeight(edge),
   HasWeightedVertices#getWeight(vertex), etc.
 * #1 implementation with external properties: the graph keeps the
   mapping between edge/vertex and weight, so that any type can be used
   for edges/vertices
 * #2 classical implementation: we keep markers like WeightedEdge and
   WeightedVertex but only the graph knows about them. algorithms keep
   asking the graph for weights of edges/vertices, and the graph in
   turn asks the edge/vertex itself (passed as parameter).

WDYT?


I know that this kind of "mismatch" is not your favourite ;) but would you
really call "Operations" something which is just an "Addition" -- or
viceversa "DoubleWeightAddition" something that might later be expanded with
other operations?

I am confused now: this is what you did in the concrete implementation!


no, trying to be clearer: you propose to rename Monoid into 
WeightOperation, which is like renaming Addition into Operation. Or 
alternatively to call the current *WeightBaseOperations something like 
*WeightMonoid. In both cases I disagree because I would prefer to keep a 
clear distinction between single well-defined properties/operations 
(like Addition or Comparator) and the comprehensive implementation (e.g. 
DoubleWeightBaseOperations) that implements all the operations it can 
implement with Doubles.


Hoping we'll converge somewhere, maybe asymptotically ;)
Claudio



time to sleep, cannot reply anymore, read tomorrow

-Simo

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



On Sat, Mar 3, 2012 at 1:37 AM, Claudio Squarcella
  wrote:

Hi,



what if that mapping function becomes a responsibility of WeightedGraph
itself?
And more generally, what if any property of vertices and/or edges is
moved to the containing graph?

that would imply that Graph implementations have to implement vertices
and/or edges metadata indexing, that would be anyway less performant
than accessing directly on metadata contained in current node/arc -
just count the number of time you should have to touch the adapted
data structures, of course will be at least one more than the actual.


that is absolutely right. Not asymptotically if the implementation is good
(hashmaps are already good enough with their read time which is basically
constant), but still there is one more step of indirection. So we would need
to test and compare performances, hopefully with acceptable results.



We could externalize all different graph properties to appropriate
interfaces (HasWeightsOnEdges, HasLabelsOnVertices, etc) and then each
algorithm specifies the needed input graph including the subset of
interfaces it needs to implement. We do something like that with weight
operations already.

I am worried that with that approach the number of interfaces would
proliferate like pollen during Spring, users - and devs - would get
easily lost


but that would happen anyway as soon as we implement an algorithm with
weights on vertices, right? Here are the options I see:

  * with the current approach: one interface for edge-weighted graphs
   (EdgeWeightedGraph, renaming the current WeightedGraph?), one for
   vertex-weighted graphs (VertexWeightedGraph) and maybe even one for
   weights on both edges and vertices (EdgeAndVertexWeightedGraph?) --
   not to talk about their counterparts with labels, etc;
  * with the proposed approach: a Graph would implement
   HasWeightsOnEdges and/or HasWeightsOnVertices -- and maybe also
   HasLabelsOnEdges if needed.




weights are somet

[Meiyo] Sharing some ideas...

[James Carman]

I've been playing around with class path scanning lately.  I've put
together some code ideas that I'd like to share.  The library is located
here:

https://github.com/jwcarman/scaninator

I still have some work to do on specifying exactly what to scan, but I
think there are some good ideas here.  Let me know what you think.

Sent from tablet device.  Please excuse typos and brevity.